Dunning
What a failed charge actually does — classification, the 14-day full-access grace window, blocking, and recovery.
Dunning is what happens when a monthly charge against your default card fails. The design principle: you get a 14-day grace window with zero service degradation to fix it, and a successful payment ends the whole episode instantly.
The state machine
| Status | Meaning |
|---|---|
active | In good standing. |
grace | A charge failed; the 14-day window is running. Full access — products don't even know: they still see the org as active. |
blocked | The window expired unpaid. Paid operations across every product return 402 ORG_BLOCKED; reads keep working. |
The dashboard surfaces payment problems with a billing banner while in grace, and each dunning email says exactly what's needed.
What happens on a failed charge
The failure is classified, and the response differs:
| Failure type | What Norcube does | What you do |
|---|---|---|
| Transient (network, processor hiccup) | Retries automatically — about a day, three days, and a week after the first attempt. Email says no action is needed. | Nothing. |
| Fixable (expired card, insufficient funds) | Emails you with a link to the payment-methods page. | Add or update the card. |
| SCA required (bank wants 3-D Secure) | Emails you an authentication link. | Complete the SCA re-auth — one inline challenge. |
| Dead card (reported lost/stolen) | Emails you to replace the card. | Add a new card. |
Whatever the type, the grace clock starts at the first failure. If the
invoice is still unpaid 14 days later, the org flips to blocked and
you're notified.
Recovering
- Fix the cause — new default card, top-up, or the SCA link from the email.
- Collection is automatic from there. The charge worker retries open invoices whenever a chargeable default card exists — typically within a minute or two of you fixing the card. No button to press.
- Success clears everything immediately: status returns to
active, the block (if any) lifts, schedules resume. There's no dwell time and no residue.
What blocked actually means
Consistent across products — documented in each product's limits-and-errors page:
- Stops: creating chargeable resources and running paid operations — scheduled backups skip (no catch-up later), AI translation calls refuse, domain checks and name generation refuse, new watchers can't be created.
- Keeps working: all reads, dashboards, and data access — and in Backup, even downloads of existing backups: access to data you've already paid for is never held hostage.
- Nothing is deleted. Data is untouched throughout; blocking is a pause, not a cleanup.
Behaviour and edge cases
- Per-organization. Only the org with the unpaid invoice is affected; your other orgs (and other members' access to them) are untouched.
- In-flight work finishes. Jobs already running when the block lands complete normally; schedules just stop enqueuing new ones.
- Budget-cap pauses look similar but aren't dunning — see the comparison.
Related
- Payment methods — fixing the card, SCA re-auth.
- Invoices — what was being charged.