PaymentRetryAlertWhat an issuer decline is
Every card authorization travels from your processor, through the card network, to the bank that issued the card. That bank, the issuer, makes the approve-or-decline decision and sends a response code back the same way.
An issuer decline is any decline where that bank said no. It is distinct from failures earlier in the chain: a gateway validation error, a fraud filter such as Stripe Radar blocking the payment before it reaches the network, or a network routing problem. Those are worth separating in your reporting because their fixes are different. Issuer declines are the largest category by far, and the most misunderstood.
Why issuers decline valid cards
A card can be genuine, in date, in the customer’s hand, and still decline. The reasons fall into a handful of groups.
Funds and limits. Insufficient balance or credit (response code 51), a daily or per-transaction amount limit (61), or a frequency limit (65). These are the most common issuer declines on recurring payments and the most recoverable.
Card status. Expired (54), lost (41), stolen (43), closed, or replaced. Mastercard groups these under its “life cycle” response (79). Nothing you do with the old details will work; the fix is new details, usually via an account updater.
Risk and policy. The issuer’s fraud model flagged the transaction, or a rule on the card blocks this kind of use: card-not-present, cross-border, a particular merchant category, or recurring billing. “Do not honor” (05) is the catch-all here, and Mastercard’s “policy” (82) and “fraud/security” (83) groupings make the reason more specific.
Cardholder instruction. The cardholder told the bank to stop a recurring charge. On Mastercard this arrives as Merchant Advice Code 21, and continuing to bill after it is treated as a compliance failure.
Issuer availability. The bank’s systems were down or slow (91, 96). The card is fine; ask again later.
Reading the two codes
On Mastercard, an issuer decline can carry two pieces of information, and you need both.
The response code (ISO 8583 data element 39) says what happened: 51 for insufficient funds, 05 for do not honor, and so on. The full list is in our decline code lookup.
The Merchant Advice Code says what the issuer thinks you should do about it. MAC 01 means the card details have changed, MAC 02 means try again later, MAC 03 means do not try again, MAC 21 means the cardholder cancelled the recurring payment, and MAC 24 to 30 give a specific wait time before retrying an insufficient-funds decline.
Most processors surface both. Stripe, for example, exposes the decline code and the network advice code on the payment error. If your billing system only stores the response code, you are throwing away the half that tells you whether a retry is worth it.
Which issuer declines to retry
Sort by the response code first and the advice code second.
| Situation | Retry? | What to do instead |
|---|---|---|
| Insufficient funds (51), limit exceeded (61, 65) | Yes, when funds are likely back | Respect MAC 24 to 30 timing; use a network signal where available |
| Issuer unavailable (91, 96) | Yes, after a short delay | Cap attempts; escalate to acquirer if persistent |
| Do not honor (05) with no advice code | Once, after a day or more | Ask customer to contact their bank if it repeats |
| Any decline with MAC 02 | Yes, after at least a day | |
| Any decline with MAC 01 | Not with the same details | Run account updater, then retry with refreshed card |
| Expired, lost, stolen, invalid (54, 41, 43, 14) | No | Account updater or new payment method |
| Any decline with MAC 03 or MAC 21 | No | Stop billing; contact customer |
| Restricted or not permitted (57, 58, 62) | No | Different card |
Issuer declines and your reputation with the bank
Issuers see every authorization you send. A merchant who retries stolen cards, ignores “do not retry” advice, or hammers insufficient-funds cards on a daily schedule looks, from the issuer’s side, like a merchant with weak controls. Some issuers respond by tightening their risk models on that merchant’s future traffic, which shows up as more “do not honor” declines on customers who should have approved.
The card networks formalised this with reattempt rules. Visa limits reattempts on a card to 15 in 30 days. Mastercard’s Transaction Processing Excellence programme charges for attempts beyond its thresholds and adds a fee to every retry after a MAC 03 or 21. The cheapest way to stay clear of both is to only send authorizations you have a reason to expect will approve.
Reducing issuer declines on recurring payments
Four levers matter more than the rest.
- Send the right transaction type. Flag recurring and merchant-initiated transactions correctly, with the stored-credential indicators the networks require. Issuers decline more of what they cannot identify.
- Keep credentials fresh. Enrol in account updater services so expired and replaced cards are refreshed before the next billing date, not after a decline.
- Time insufficient-funds retries to the account, not the calendar. This is the largest bucket and the one where issuer behaviour is most predictable if you have a signal. Mastercard’s Payment Optimization Platform monitors the card after a code 51 decline and signals when a retry is more likely to approve; PaymentRetryAlert delivers that signal to your webhook.
- Stop when told. Honour MAC 03 and 21 immediately. Every attempt after them costs money and goodwill.
- Mastercard, Decline details and Merchant Advice Codes
- Stripe, Card declines
- Chargebacks911, Mastercard Merchant Advice Codes