The Four Outcomes of an Authorization
- Merchants see two authorization outcomes (approved or declined). Inside the issuer there are four: approve, approve-and-flag, soft decline, hard decline
- Approve-and-flag is invisible to you but explains "clean" approvals that turn into disputes days later, and why some customers suddenly get 3DS challenges
- Soft declines are an invitation to retry on a schedule; hard declines are a command to stop. Visa caps reattempts at 15 per card per 30 days and bans retries entirely on Category 1 codes
- Mastercard sends Merchant Advice Codes that literally tell you whether and when to retry. Most billing systems ignore them
- Retrying hard declines costs you integrity fees, poisons your merchant reputation in issuer models, and recovers nothing
Your gateway shows you two answers: approved or declined. The issuer made a four-way decision. Two of those four never reach you, and they're the ones that explain the "clean" approval that becomes a chargeback on Thursday, and the customer whose card suddenly starts asking for extra verification. I spent years on the issuer side making this call. Here's what the other two buckets are, and what each outcome lets you do next.
On this page
This page covers what an authorization decision means and what you're allowed to do next. For how issuers make the call, see How Issuers Decide to Approve or Decline. For what issuers can and can't see about your transaction, see Why Issuers Decline and Dispute. For code-by-code lookups, see Decline Codes.
The Four Buckets
| Outcome | What you see | What actually happened | Your move |
|---|---|---|---|
| Approve | Code 00 | Transaction passed cleanly | Nothing |
| Approve-and-flag | Code 00 | Approved, but marked for review, cardholder notification, or step-up on the next attempt | Watch for the follow-up dispute; consider 3DS on risky segments |
| Soft decline | 05, 51, 61, 65, 91, 1A... | "Not this transaction, right now." Funds, velocity, risk score, or a request for authentication | Retry is allowed, on a schedule, within network limits |
| Hard decline | 04, 07, 14, 41, 43, 46, 57, R0, R1, R3 | "Stop. This card is dead, stolen, closed, or the cardholder revoked permission" | Never retry. Get a new payment method |
Two of those cost real money when you misread them: approve-and-flag, and the line between soft and hard.
Approve-and-Flag: The Outcome You Never See
Issuers don't just approve or decline. A big middle band gets approved and something else happens:
- The transaction is queued for a fraud analyst to review after the fact
- The cardholder gets a push notification or text: "Did you just spend $84.99 at ACME STORE?"
- The account is marked so the next transaction gets a 3DS challenge or a decline
- A fraud report (Visa TC40 / Mastercard SAFE) is filed later, even if no chargeback ever arrives
Why this matters to you:
- An approval isn't an exoneration. A "perfectly clean" transaction turns into a fraud chargeback three days later. Here's what usually happened: the issuer approved it borderline, texted the cardholder, and the cardholder said "that wasn't me." The dispute was born at authorization. You just couldn't see it.
- Step-up behavior is sticky. If a customer complains that your checkout "suddenly started asking for extra verification," their card is probably flagged at the issuer. It isn't your gateway misbehaving.
- TC40/SAFE reports pile up silently. They shape how issuer models treat your merchant name even when your chargeback ratio looks fine. See Network Programs.
You can't see issuer flags. You can stop feeding them. Borderline traffic you push through without authentication is exactly what lands in this bucket. Route your riskiest segment through 3DS and the issuer's decision moves from "approve and flag" to "authenticated approve." Fewer surprise disputes, and a liability shift on top.
Soft Declines: An Invitation With Rules
A soft decline is the issuer saying "not this one, right now." The common ones:
| Decline | Typical code | What it usually means | Sensible retry |
|---|---|---|---|
| Insufficient funds | 51 | Balance or credit limit | 3-5 days later (paydays matter), then next billing cycle |
| Velocity limit | 61, 65 | Cardholder hit their own bank's limits | 24 hours or more |
| Issuer unavailable | 91 | Issuer system down or timing out | Pause retries for that BIN 30-60 minutes, then once after recovery |
| Authentication requested | 1A (Visa), 65 in some regions | Issuer wants 3DS before approving | Retry immediately with a 3DS challenge. This is the highest-value retry in payments |
| Do not honor | 05 | Catch-all. Could be risk score, could be anything | Treat with caution: space retries days apart, cap attempts low |
Two habits separate a billing system that recovers money from one that burns it:
- The 1A retry. "Additional authentication required" isn't a rejection. It's the issuer telling you the approval is sitting behind a 3DS challenge. Retry instantly with 3DS and you'll recover a large share of these at near-zero cost. If your billing system treats 1A like a generic decline, you're donating revenue.
- Code 05 discipline. "Do Not Honor" is where issuers hide fraud suspicion. Some 05s recover on a later attempt. Hammering them trains issuer models to treat your merchant name as hostile. Limited, spaced retries only.
Hard Declines: A Command, Not a Suggestion
Hard declines mean the account is gone, or the cardholder pulled permission. Card reported lost (41) or stolen (43). Account closed (46). Invalid number (14). "Pickup card" (04/07). Transaction not permitted (57). Revocation of authorization (R0/R1/R3), which means the cardholder told their bank to stop a recurring charge.
Every retry against these codes:
- Costs you money. You pay auth fees on declines, plus network integrity fees for excessive reattempts (below)
- Damages your reputation. Issuers score merchants on retry discipline. A merchant name that hammers dead cards looks like a card-testing operation. See Card Testing
- Recovers nothing. The issuer's answer isn't going to change
R0 and R1 matter most if you bill on a subscription. Retrying after a revocation code isn't just wasted money. It's the fastest route to a "cancelled recurring" chargeback you'll lose, and a stored-credential compliance problem on top.
The Network Rulebook on Retries
This is where the fines live.
Visa: decline categories and the 15-in-30 rule
Visa sorts decline codes into categories that dictate retry rights:
| Category | Meaning | Common codes | Retry rule |
|---|---|---|---|
| Category 1 | Issuer will never approve | 04, 07, 12, 14, 15, 41, 43, 46, 57, R0, R1, R3 | Zero retries. Reattempts are billed as violations |
| Category 2 | Issuer cannot approve right now | 05, 51, 61, 65, 91, 93, 96 | Up to 15 reattempts per card per 30 days, counted from the first decline |
| Category 3 | Fix your data first | 54 (expired), 55, 82, N7 | Correct the data (account updater, re-collect CVV), then retry. Blind retries count against you |
Go past those limits and you generate integrity fees. Your acquirer bills them per excess attempt, usually with markup, buried somewhere in your processing statement. If you've never looked, look. Serial retry fees are one of the quietest leaks in subscription billing.
Mastercard: Merchant Advice Codes
Mastercard answers many declines with a Merchant Advice Code (MAC) that tells you exactly what to do. Your processor gets it on every relevant decline. Whether they pass it through to you is worth asking.
| MAC | Instruction | Your move |
|---|---|---|
| 01 | New account information available | Run account updater, then retry with fresh credentials |
| 02 | Try again later | Scheduled retry is fine |
| 03 | Do not try again | Stop. Get a new payment method |
| 21 | Payment cancelled by cardholder | Recurring charge was revoked. Stop billing, or the next contact is a chargeback |
| 24-29 | Retry after N hours/days | Follow the stated wait |
Mastercard's Transaction Processing Excellence program bills merchants for retry abuse: repeated attempts on the same card inside 24 hours, and any reattempt after MAC 03 or 21. Fee schedules change. The principle doesn't. The network tells you the answer, then charges you for refusing to listen.
"When we get a decline, do we receive and store the Visa decline category and the Mastercard Merchant Advice Code? Does our retry logic branch on them, and do we enforce a hard cap of 15 attempts per card per 30 days?"
If any answer is no, your retry logic is guessing. The networks fine guessers.
A Retry Decision Flow
Where This Breaks
- Treating 05 as one thing. Code 05 spans everything from a temporary risk score to permanent fraud suspicion. Retry every 05 aggressively and you'll get more 05s. Issuer models learn your merchant name.
- Retry logic that never reads advice codes. Most billing systems branch on "approved or declined" and nothing else. The networks have sent machine-readable retry instructions for years. Ignoring them is now a billable offense.
- Counting outage declines as churn. When code 91 spikes, the subscriptions that failed aren't cancellations. Queue them for re-presentment after recovery instead of dunning your customers.
- "Smart retry" vendors with no cap. Some recovery tools brag about persistence. Persistence past Category 1 or MAC 03 isn't recovery. It's a fee generator. Ask any retry vendor how they handle Visa categories and MACs before you sign.
- Assuming an approval means the issuer trusts the transaction. The approve-and-flag bucket is big. If a customer segment shows approvals followed by fast fraud disputes, that segment's getting flagged at authorization. Authenticate it.
Next Steps
Building or fixing retry logic?
- Check your top decline codes - Know what you're actually getting
- Review optimization tactics - Network tokens, MIT/CIT flags, account updater
- Understand card testing - What bad retry patterns look like to issuers
Reducing surprise disputes?
- Implement 3DS on risky segments - Move flagged approvals to authenticated approvals
- Understand TC40/SAFE reports - The silent reputation ledger
- Review the issuer perspective - What issuers see and why they decline
Related Topics
- How Issuers Decide to Approve or Decline - The decisioning process behind these outcomes
- Why Issuers Decline and Dispute - Issuer constraints and incentives
- Decline Codes - Full code reference
- Auth Optimization Tactics - Network tokens, retry logic, 3DS optimization
- 3D Secure - Authentication and liability shift
- Card Testing - Retry abuse from the fraud side
- Network Programs - VAMP, ECM, TC40 impact