Chase a failed payment

A failed payment is usually a card problem and occasionally a product problem. The reason code says which, and reading it first avoids both wasted retries and the worst outcome — a paying customer losing access without being told.

Steps

1. Read the failure reason on the charge. They fall into three groups and each has a different response:
   • Will succeed later: insufficient funds, temporary decline, issuer unavailable. Retry on the processor's own schedule. Do not retry immediately — it increases the decline rate and can look like card testing.
   • Will never succeed as is: expired card, lost or stolen, closed account, incorrect details. Only the customer can fix it. Retrying is noise.
   • Blocked: fraud rules, radar, 3DS required. This needs a person, and possibly a conversation with the customer, before anything is retried.
2. Check it is one customer and not a pattern. Look at the failure rate for the same day against the usual. A wave of declines across unrelated customers is a processor or configuration problem, and chasing them individually is the wrong response.
3. Find out what happens to their access, and when. Read the subscription's status and the date at which it ends or downgrades. That date is what the message to the customer is about.
4. Message them once, plainly, before anything changes: what failed, how much, what to do, how long they have, and a direct link to update the payment method. No dunning language, no threat, one link.
5. Log it where the account is managed — the CRM — so whoever talks to them next knows.
6. Confirm the recovery. When the retry or the new card succeeds, check the subscription is active again and that nothing was downgraded in between.

Stop and ask

• Before cancelling a subscription, revoking access, or writing off an invoice.
• Before issuing any refund or credit as a goodwill gesture.
• When the customer is large enough that somebody owns the relationship. They send the message, not the system.