The question is mechanical
Not how bad the failure is, but whether charging the same card again can ever succeed. Insufficient funds can clear. An expired card never will.
Failed payment recovery
When a subscription charge fails, the decline code says whether charging the same card again can ever work. Most tools retry everything on the same schedule. Exeechain routes each failure by its code: retry the ones that can clear, ask for a new card where retrying is futile, and stop entirely where the issuer has blocked it.
Read-only to start. Connect Stripe and see the open invoices, the codes behind them, and what each one is worth.
The routing table
This is the live classification Exeechain routes on, not an illustration. The only question it asks is mechanical: can charging the same card again ever work?
The card is fine, the moment was wrong
Retry can work. Timing is the only lever.
insufficient_fundsThe card works, but the balance was short at the moment we charged it.
Retry near the next payday window. Do not ask for a new card yet.
card_velocity_exceededThe card hit its spending or frequency limit.
Wait and retry. Repeated quick attempts will keep hitting the same limit.
withdrawal_count_limit_exceededThe card exceeded its allowed number of withdrawals.
Wait and retry, or ask the customer to use a different card.
processing_errorA temporary processing error. Nothing is wrong with the card.
Retry shortly. This usually clears on its own.
try_again_laterThe issuer asked us to try again later.
Retry shortly.
issuer_not_availableThe issuing bank could not be reached.
Retry shortly. This is the bank being unreachable, not a refusal.
reenter_transactionThe issuer could not process it and asked for the charge to be re-submitted.
Retry shortly.
The card itself is unusable
No retry will ever clear. Ask for new details.
expired_cardThe card has expired. Every retry will fail the same way.
Send a card-update link. Do not retry this card.
incorrect_numberThe card number is wrong, so no charge against it can succeed.
Send a card-update link.
incorrect_cvcThe security code is wrong. Only the customer can correct it.
Send a card-update link so they can re-enter the card.
invalid_cvcThe security code is invalid.
Send a card-update link so they can re-enter the card.
invalid_expiry_monthThe expiry month on file is invalid.
Send a card-update link.
invalid_expiry_yearThe expiry year on file is invalid.
Send a card-update link.
invalid_accountThe account behind this card is not valid.
Ask for a different payment method.
currency_not_supportedThe card cannot be charged in this currency.
Ask for a card that supports the billing currency.
card_not_supportedThe card does not support this kind of purchase.
Ask for a different payment method.
The issuer refused and will not say why
One retry is reasonable. After that, ask.
do_not_honorThe issuing bank refused and gave no reason. The card itself looks valid.
One retry is reasonable. If it fails again, a person should call them.
generic_declineThe bank declined without giving a reason.
One retry is reasonable. If it fails again, a person should reach out.
transaction_not_allowedThe bank does not permit this type of transaction on this card.
Ask for a different card. Retrying this one is unlikely to change the answer.
service_not_allowedThe bank does not permit this service on this card.
Ask for a different card.
authentication_requiredThe bank requires the cardholder to authenticate this payment.
Send a payment link so the customer can complete authentication themselves.
The issuer has blocked the card
Stop. Automated contact is inappropriate here.
lost_cardThe card was reported lost. The issuer has blocked it.
Stop automated retries and outreach. A person should contact the customer.
stolen_cardThe card was reported stolen. The issuer has blocked it.
Stop automated retries and outreach. A person should contact the customer.
pickup_cardThe issuer has flagged this card and asked for it to be retained.
Stop automated retries and outreach. A person should contact the customer.
fraudulentThe payment was declined as suspected fraud.
Stop automated retries and outreach. Review before contacting anyone.
merchant_blacklistThe payment was blocked by a merchant-level block list.
Stop automated retries. Review before contacting anyone.
revocation_of_authorizationThe cardholder revoked authorisation for recurring charges on this card.
Stop charging this card. Ask for explicit re-authorisation before any retry.
revocation_of_all_authorizationsThe cardholder revoked authorisation for all recurring charges.
Stop charging this card. Ask for explicit re-authorisation before any retry.
stop_payment_orderThe cardholder placed a stop-payment order on this charge.
Stop charging this card. This needs a conversation, not a retry.
Anything Stripe does not give a code for falls through to a conservative default: Exeechain says it does not know, rather than assuming the harmless case. What is deliberately absent from this table is any estimate of how often a retry succeeds. That is a measurement, not a constant, and it belongs to your book rather than to a vendor page.
Not how bad the failure is, but whether charging the same card again can ever succeed. Insufficient funds can clear. An expired card never will.
Every attempt on an expired or blocked card is a hard decline against your merchant account, and card networks price merchants on their decline ratio.
How likely a retry is to succeed is a measurement, not a constant. Exeechain holds out a control group and reports what actually cleared.
Why generic dunning underperforms
Most billing tools treat a failed charge as a single event: retry it a few times on a fixed schedule, send a chasing email, then cancel. That is the right handling for exactly one class of failure and the wrong handling for the rest.
A card short of funds on the 28th is not the same problem as a card that expired last month, and neither is the same as a card the issuer has reported stolen. The first needs better timing. The second needs the customer. The third needs you to stop.
Nothing is wrong with the card. Retrying near the next likely payday is the fix, and Exeechain labels that as the heuristic it is rather than presenting it as a prediction.
Stripe will keep scheduling attempts and every one will fail. The only useful action is a card-update link the customer can complete in one tap.
Lost, stolen, fraudulent and revoked authorisations end automated contact. A person decides what happens next.
What Exeechain does with it
Failed payments used to be a flag on a customer record, which is enough to say something is wrong and not enough to say what it is worth or what to do. Exeechain reads Stripe invoices directly, so a failure carries its amount, its attempt count, its decline code and its age.
That is what makes the queue orderable by money rather than by date, and it is what lets a save be attributed later: an invoice that moved from open to paid is a receipt, not an inference.
An unpaid invoice is money that failed to clear. It is reported as cash and never multiplied into a yearly figure to make the number larger.
A hosted link the customer opens without logging in, because the point of failure is usually a card, not an account.
The impact ledger records a recovery only when the invoice actually settles. Estimated value is kept in a separate tier and labelled.
Keep reading
Where to go next, depending on what you're trying to work out.
FAQ
Most failures fall into four groups: the balance was short, the card details are no longer valid (expired, wrong number, wrong CVC), the issuing bank refused without giving a reason, or the card has been blocked as lost, stolen or fraudulent. Only the first group reliably clears on a retry.
Yes, Stripe can retry automatically and you can also retry an invoice manually. Whether you should depends on the decline code. Retrying an insufficient-funds decline is sensible. Retrying an expired card produces another hard decline and no revenue.
Stripe exhausts the retry schedule you configured and then applies your chosen end state, usually cancelling or marking the subscription unpaid. Customers lost this way did not choose to leave, which is why the lane is worth working before the schedule runs out.
Stripe can send its own dunning emails. They are generic by design and identical for every decline code. Exeechain sends the action that matches the code instead, and never contacts an account where the issuer has blocked the card.
Exeechain does not publish one, and treats any vendor figure with suspicion. Recovery depends on your customers, your prices and your decline mix. What the product does instead is hold back a control group and report the difference, so the number you get is measured on your own book.
Connect Stripe read-only. Every open invoice with its amount, decline code and age, before you change anything.
Not ready to switch? Run the free 60-second revenue leak scan and see what staying put costs.