Retries
How MintCash retries failed recurring charges over time — the schedule, the customer notifications, and when a subscription is cancelled.
When a subscription renewal fails, MintCash doesn't give up on the first decline. It retries the charge on a fixed schedule, escalating customer communication along the way, and only cancels the subscription once every attempt is exhausted. This is the "dunning" loop you'd otherwise build yourself.
Retries vs. cascading
Cascading happens within a single charge attempt — try provider A, then B, then C, all in seconds. Retries happen across time — try today, fail, wait a day, try again. The two combine: each retry attempt can itself cascade across providers.
The retry schedule
| Attempt | Day | Customer email |
|---|---|---|
| Renewal fails | Day 0 | None — silent, gives the retry loop a chance first |
| 1st retry | Day +1 | "Your payment failed" |
| 2nd retry | Day +3 | "Your payment failed" |
| 3rd retry | Day +5 | "Your subscription will be cancelled" — final warning, sent before the last attempt |
| 4th retry | Day +7 | "Subscription cancelled" if it fails — billing stops and access is revoked |
The day offsets are measured from the original renewal failure, not from the previous attempt.
What you see
subscription.succeeded— a charge attempt succeeded; following a failure, it means a retry recovered the subscription (back toactive).subscription.failed— a subscription charge attempt failed.subscription.cancelled— the subscription terminated (retries exhausted, a non-recoverable decline, or a merchant cancellation).
Each retry creates a new Payment linked to the subscription. On the first renewal failure the subscription moves to past_due and stays there through the dunning ladder, returning to active if a retry succeeds, or ending in cancelled once attempts are exhausted.
What stops the retry loop
Some failures end the loop immediately — there's no point retrying a card we know won't work.
| Resolution | Retry? | Why |
|---|---|---|
insufficient_funds | Yes | The customer may have funds later |
provider_error | Yes | Transient PSP issue |
issuer_decline | Yes | Issuer may approve a later attempt |
card_expired | No | Non-recoverable — subscription cancelled immediately |
invalid_cvv | No | Non-recoverable — subscription cancelled immediately |
lost_or_stolen_card | No | Non-recoverable — subscription cancelled immediately |
antifraud_error | No | Non-recoverable — subscription cancelled immediately |
A non-recoverable decline — expired or invalid card, lost/stolen, restricted or blocked, or a fraud flag — ends the dunning ladder on that attempt and cancels the subscription outright. There's no pause-and-resume: to restart billing, create a new subscription once the customer has a working card.
See also
- Subscriptions — the subscription state machine that retries feed into
- Emails — the dunning emails sent at each step, and how to turn them off
- Cascading — multi-provider attempts within a single retry
- Errors — which resolutions are retryable and which terminate the loop