top of page

Subscribe to Our Blog

Join our community for monthly updates, expert insights, and practical tips delivered straight to your inbox.

Not Every Card Decline Is a No

Oct 14
3 min read

Decline codes sort into three buckets: retry, ask the customer, or stop. Reading them is recoverable revenue.


Decline triage graphic sorting card declines into three buckets: retry, ask the customer, and stop, with examples and actions for each

Most merchants spend Q4 prep on the declines they cause themselves: fraud rules, velocity limits, manual review. The other half of the problem gets less attention. These are the declines the issuer sends back.


Those usually get one of two treatments. The system retries until something approves, or the order is written off as lost. Both are wrong more often than they're right, because every decline comes back with a code, and that code already tells you what to do next.


Visa groups its decline codes into categories with explicit retry rules, and Mastercard sends merchant advice codes alongside many declines. The details differ by network, but in practice they sort into three buckets.


Bucket 1: Retry


What lands here: insufficient funds, issuer unavailable, system or processing errors.


These are temporary. The card is valid and the customer meant to pay, but the issuer couldn't approve at that moment. A retry can recover the sale, but timing matters. Firing attempts back to back rarely changes the outcome. Spacing them out, around when funds are likely to land, works better. On many Mastercard declines, the merchant advice code tells you directly how long to wait.


Bucket 2: Ask the customer


What lands here: expired card, CVV mismatch, authentication required.


Retrying the same details gets the same answer. Something has to change first. For a live checkout, that means prompting for updated card details or sending the customer through authentication. For stored cards and subscriptions, account updater services from the networks can refresh expired or replaced cards before the next charge.


Bucket 3: Stop


What lands here: lost or stolen card, closed account, transaction not permitted.


No retry turns these into an approval. Visa treats any reattempt on these codes as excessive and bills for it, and Mastercard has its own stop-retrying advice codes with fees attached. The right move is to stop, ask for a different payment method, and, for lost or stolen card codes, consider whether the order needs a closer look.


Why this costs more now


Both networks cap how many times you can retry a declined card within a 30-day window and charge fees for attempts beyond it. Retry logic that ignores the code doesn't just fail to recover revenue. It adds a network fee to every wasted attempt and can draw scrutiny from your acquirer.


Q4 amplifies all of it. Higher volume means more declines in every bucket, and more first-time customers means fewer stored relationships to fall back on.


What to check before peak


Ask your provider, or your own team, three questions:


1. Can you see your declines by code? If your reporting just says "declined," you can't tell which bucket the revenue is in.


2. Does your retry logic follow the code? Retries should run only on recoverable codes, spaced out, and stop at the network limits.


3. Is anyone acting on bucket 2? An expired card on a returning customer is one of the easiest sales to recover, as long as someone actually asks.


The Takeaway


Your approval rate isn't fixed. Part of what looks like lost revenue is sitting in decline codes nobody reads. Sort them into retry, ask, and stop, and you recover sales while cutting the fees you pay for retries that were never going to work.

Comments


Global Payments Consultants logo

Navigate the complexity of payments with confidence

Get started today.

bottom of page