Auth Optimization Tactics
- Network tokens replace stored PANs with network-issued tokens. They can stay current when a card changes. Compare approvals with stored PANs on matched payments
- Authentication-required declines may need a 3DS challenge. Lost or stolen cards mean stop. Code 05 is ambiguous: follow the network and processor advice before retrying
- MIT/CIT flagging matters for recurring billing. Merchant-initiated transactions skip fraud checks that would reject them as cardholder-initiated
- Idempotency keys stop duplicate charges on network timeouts. Add them before you scale, not after your first double-charge complaint
This page covers the tactics themselves. For the overview and the metrics, see Auth Optimization.
Network Tokens
Network tokens replace raw card numbers with network-issued credentials. Visa and Mastercard issue them, and your processor manages them for you.
What Network Tokens Fix
| Problem | How Tokens Help |
|---|---|
| Card reissuance | Token stays valid when card is replaced |
| Fraud screening | Issuers trust tokenized transactions more |
| Auth rates | Compare tokenized vs. raw PAN approvals on matched payments; see Visa's published comparison |
How They Work
- Customer enters card at checkout
- Processor requests token from Visa/Mastercard
- Token is stored instead of card number
- Future transactions use the token
- Network keeps token mapped to current card credentials
When to Use
- Recurring billing (tokens stay valid through card updates)
- Repeat customers (stored payment methods)
- Digital wallets (Apple Pay/Google Pay are tokenized)
Operator Questions
"Are we using network tokens or raw PANs for stored cards? If raw PANs, can we migrate to network tokens?"
Confirm network-token pricing for your processor, account and billing unit before modelling the cost. Stripe US pricing includes Authorization Boost, which covers network tokens, at no additional charge on standard payments pricing. Custom pricing differs. Checked 22 October 2026.
Card-on-File Transaction Flags
How you flag a transaction changes your auth rate. It's one of the cheapest fixes on this page.
MIT vs. CIT
| Type | Meaning | Example |
|---|---|---|
| CIT (Customer-Initiated) | Customer is present for the transaction | One-time purchase, initial subscription signup |
| MIT (Merchant-Initiated) | Merchant charges without customer present | Recurring billing, delayed charges |
Why Flagging Matters
Issuers apply different rules:
- CIT may require 3DS challenge
- MIT skips 3DS but requires prior consent
- Wrong flag = higher declines
Common Flags
| Flag | Use Case |
|---|---|
recurring | Subscription billing |
installment | Scheduled payment series |
unscheduled | Variable charges on stored card |
resubmission | Retry of previously declined |
"What transaction flags are we sending on recurring charges? Are we flagging MIT correctly?"
Retry Logic Rules
Retrying declines cuts both ways. Do it right and you recover revenue. Do it wrong and you'll burn your issuer reputation.
What's Allowed
| Decline Type | Retry? | Strategy |
|---|---|---|
| Soft decline (insufficient funds) | Yes | Wait 3-5 days, retry around payday |
| Issuer unavailable | Yes | Wait 4-24 hours |
| Velocity limit exceeded | Maybe | Wait 24 hours, try once |
| Card expired | Not with the same details | Get the new expiry date or another card |
| Do not honor (05) | Check advice first | Follow the network and processor instructions. Ask the customer to contact their issuer or use another card |
| Fraud/stolen | Never | Stop immediately |
What Burns You
- Retrying hard declines (stolen, invalid, closed)
- Excessive retries (more than 2-3 on same card)
- Immediate retries (no wait time between attempts)
- Ignoring decline codes
Issuer View
We track merchants who repeatedly hit declined cards. Excessive retry behavior is a fraud signal. Merchants with bad retry patterns see lower auth rates across all their transactions.
Retry Velocity Limits
Check the network instructions before setting your schedule:
- Visa: Never resubmit Category 1 on the same credential. Categories 2-4 permit up to 20 attempts in 30 days
- Mastercard: Respect response codes and MACs. Its 10-decline/24-hour and 35-decline/rolling-30-day TPE tests are fee tripwires, not retry allowances. See the exact tests and fees
Sources: Visa rules, section 7.3.6.3, pp. 538-541; Mastercard rules, section 3.3; Global Payments PMB 1311, p. 19. Checked October 21, 2026.
Hard vs. Soft Decline Logic
Soft Declines: Retry-Eligible
| Decline Code | Meaning | Retry Strategy |
|---|---|---|
| 51 | Insufficient funds | Wait 3-5 days |
| 05 | Do not honor | Visa treats it as Category 4. Follow network and processor advice; don't retry a stop instruction |
| 91 | Issuer unavailable | Wait 4-24 hours |
| 78 (Visa) | New card not unblocked | Ask the customer to activate it and follow the processor's advice |
| 61 | Exceeds withdrawal limit | Wait a few days |
| 65 | Activity limit exceeded | Wait 24 hours |
Hard Declines: Do Not Retry
| Decline Code | Meaning | Action |
|---|---|---|
| 14 | Invalid card number | Stop, request new card |
| 41 | Lost card | Stop immediately |
| 43 | Stolen card | Stop immediately |
| 54 | Expired card | Stop. Retry only with a new expiry date or card |
| 57 | Function not permitted | Stop, different card needed |
Processor Translation
Different processors return different codes. Yours should map network codes to categories you can act on. If it doesn't, ask for a mapping document. Stripe's raw network-code table separates networks; its do_not_honor guidance tells the customer to contact their issuer. Checked 22 October 2026.
"Are we handling soft vs. hard declines differently? Can I see how we're categorizing decline codes?"
3DS Optimization
3DS (3D Secure) adds an authentication step. It'll help or hurt depending entirely on how you use it.
3DS Impact Reality
| Scenario | Auth Rate Impact | Liability Shift |
|---|---|---|
| 3DS challenge, customer completes | Track completion and subsequent approval separately | Yes |
| 3DS frictionless (no challenge) | Compare approvals on matched eligible payments | Yes |
| No 3DS | Baseline | No |
When 3DS Helps
- High-risk transactions (new customer, new shipping address)
- International transactions (required in EU, recommended elsewhere)
- High-ticket purchases
- Transactions you'd otherwise decline
When 3DS Hurts
- Low-risk returning customers
- Mobile transactions (challenge UX is painful)
- Guest checkout (adds friction to already-fragile flow)
3DS Exemptions
Request exemptions when you qualify:
| Exemption | Criteria | Best For |
|---|---|---|
| TRA (Transaction Risk Analysis) | Low-risk based on your fraud rate | Low-risk merchants |
| Low-value | Under €30 (EU) | Small purchases |
| Recurring | Subsequent subscription charges | Recurring billing |
| Trusted beneficiary | Customer whitelisted the merchant | Returning customers |
"Are we requesting 3DS exemptions where we qualify? What's our frictionless vs. challenge rate?"
3DS2 vs. 3DS1
3DS2 supports frictionless authentication. 3DS1, the legacy version, challenged every single time. If you're still on 3DS1, upgrade - the auth rate difference is big.
Related: 3DS Deep Dive
Idempotency: Why Customers Get Charged Twice
Double charges happen when the same transaction gets submitted twice. Usually it's a timeout, not a customer.
How It Happens
| Cause | Scenario |
|---|---|
| Customer retry | Customer clicks "Pay" twice |
| Network retry | Network retransmits due to timeout |
| Merchant retry | Your system retries on ambiguous response |
The Fix: Idempotency Keys
Idempotency keys are unique identifiers attached to each payment attempt. If the same key is submitted twice, the processor returns the original result instead of charging again.
Operator Impact
Without idempotency:
- Duplicate charges
- Customer complaints
- Support tickets
- Chargebacks ("I was charged twice!")
How to Verify
"Are we using idempotency keys for payment attempts? Show me the implementation."
This isn't code you need to understand. It's a question to ask.
Issuer Decline Patterns
Declines aren't random - they cluster by cause, and the clusters tell you what to fix.
Common Patterns and Fixes
| Pattern | Cause | Fix |
|---|---|---|
| High decline rate on one BIN | Issuer-specific policy | Contact issuer, adjust fraud rules |
| International cards declining | Cross-border friction | Consider local acquiring |
| First-time customers declining more | New card, no history | Add 3DS for liability shift |
| Weekend declines higher | Bank staffing/limits | Adjust retry timing |
| High declines on specific amount | Velocity or limit triggers | Vary transaction amounts |
Decline Code Analysis
Run a monthly report:
- Pull all declines
- Group by decline code
- Identify top 5 codes by volume
- Research causes and fixes for each
Issuer View
The top 3 reasons we decline:
- Suspected fraud (velocity, geography, mismatch)
- Insufficient funds
- Card restrictions (international, e-commerce)
Merchants who address #1 (better fraud signals) see the biggest lift.
Test to Run
3-week auth rate improvement:
Week 1: Baseline.
- Record current overall auth rate
- Pull decline code breakdown
- Identify top 5 decline reasons
Week 2: Implement fixes.
- Adjust retry logic for soft declines
- Request 3DS exemptions where qualifying
- Verify idempotency is in place
Week 3: Measure.
- Compare auth rate to baseline
- Track decline code distribution
Success criteria: Approval rate improves on the same issuer, country and transaction-type segments. Check completed purchases and fraud losses too.
Next Steps
- Start with network tokens → Biggest lift for least effort
- Fix your retry logic → Stop burning issuer trust
- Optimize 3DS → Request exemptions where you qualify
- Track weekly → Monitor trends, not snapshots
See Also
- Auth Optimization Overview - Metrics and scale guidance
- 3DS Deep Dive - Complete 3DS reference
- Decline Codes Reference - Code meanings
- Increase Auth Rates Playbook - Step-by-step guide
- AVS & CVV - Verification signals
- Digital Wallets - Tokenized payments
- Cards - Card acceptance
- Processor Management - Multi-processor routing
- Risk Scoring - Fraud vs auth balance
- Authorization Basics - Auth fundamentals