Auth Optimization
Before optimizing auth rates, ensure you have:
- Access to processor dashboard with auth rate and decline code visibility
- Understanding of payments metrics and your current baseline
- Familiarity with 3DS concepts (impacts auth rate)
- Knowledge of your transaction types (CIT vs MIT, recurring vs one-time)
- Baseline first: CNP e-commerce averages 85-90%, best-in-class hits 95%+—know yours before optimizing
- Network tokens: +2-5% auth lift; tokenized credentials outperform raw PANs with issuers
- Retry logic: Soft declines (51, 91) = retry in 3-5 days; hard declines (41, 43, 54) = never retry
- 3DS exemptions: Request TRA, low-value, recurring exemptions where you qualify
- Flag correctly: MIT vs. CIT matters—wrong flags = higher declines
Your auth rate is revenue. Every 1% improvement in approval rate is 1% more money. Most SMBs don't know their auth rate. When asked, they guess high.
Reality: CNP e-commerce averages 85-90% auth rates. Best-in-class hits 95%+. The gap between those numbers is real money you're not collecting.
What Matters
- Know your auth rate. Can't fix what you don't measure.
- Network tokens lift approval 2-5%. Tokenized credentials perform better with issuers.
- Retry logic matters. Wrong retries burn issuer trust. Right retries recover revenue.
- 3DS is a lever, not just compliance. Used well, it improves auth. Used badly, it kills conversion.
- Issuer declines have patterns. Learn your top decline reasons and fix the fixable ones.
Know Your Auth Rate
Before optimizing, baseline.
How to Calculate
Auth Rate = Approved Transactions / Total Attempted Transactions × 100
What's Normal
| Business Type | Typical Auth Rate | Best-in-Class |
|---|---|---|
| E-commerce (US domestic) | 85-90% | 95%+ |
| Subscription (initial) | 80-85% | 90%+ |
| Subscription (recurring) | 90-95% | 97%+ |
| Card-present (CP) | 98-99% | 99%+ |
| International CNP | 75-85% | 90%+ |
If you're below "typical," there's low-hanging fruit.
Where to Find It
Check your processor dashboard. Look for:
- "Authorization rate" or "Approval rate"
- Filter by: card brand, card type, geography, transaction type
"Where can I see our overall auth rate? Can I filter by card brand and geography?"
Network Tokens
Network tokens replace raw card numbers with network-issued credentials. Visa and Mastercard issue them. Your processor manages them.
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 | 2-5% lift on tokenized vs. raw PAN |
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?"
Network tokens are free or low-cost from most processors. There's little reason not to use them.
Card-on-File Transaction Flags
How you flag a transaction affects auth rates.
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 is a double-edged sword. Do it right, recover revenue. Do it wrong, damage 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 | No | Request new card |
| Do not honor | Once | Try once more, then stop |
| 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
Card networks have rules:
- Visa: Max 15 retries in 30 days per card
- Mastercard: Similar limits with monitoring
Exceeding these can result in fines or processing restrictions.
Hard vs. Soft Decline Logic
Soft Declines: Retry-Eligible
| Decline Code | Meaning | Retry Strategy |
|---|---|---|
| 51 | Insufficient funds | Wait 3-5 days |
| 91 | Issuer unavailable | Wait 4-24 hours |
| 85 | Card not activated | Wait 1-2 days |
| 61 | Exceeds withdrawal limit | Wait a few days |
| 65 | Activity limit exceeded | Wait 24 hours |
Hard Declines: Do Not Retry
| Decline Code | Meaning | Action |
|---|---|---|
| 05 | Do not honor | Try once more max |
| 14 | Invalid card number | Stop, request new card |
| 41 | Lost card | Stop immediately |
| 43 | Stolen card | Stop immediately |
| 54 | Expired card | Stop, request new card |
| 57 | Function not permitted | Stop, different card needed |
Processor Translation
Different processors return different codes. Your processor should map network codes to actionable categories. If they don't, ask for a mapping document.
"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 can help or hurt depending on how you use it.
3DS Impact Reality
| Scenario | Auth Rate Impact | Liability Shift |
|---|---|---|
| 3DS challenge, customer completes | -5 to -15% conversion | Yes |
| 3DS frictionless (no challenge) | Neutral to +1% | 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 (current) supports frictionless authentication. 3DS1 (legacy) always challenged. If you're still on 3DS1, upgrade. The auth rate difference is significant.
Related: 3DS Deep Dive
Idempotency: Why Customers Get Charged Twice
Double charges happen when the same transaction is submitted multiple times.
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 is not code you need to understand. It's a question to ask.
Issuer Decline Patterns
Declines aren't random. They cluster by cause.
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: 1-3% improvement in overall auth rate.
Scale Callout
| Volume | Focus |
|---|---|
| Under $100k/mo | Know your auth rate. Ensure basic retry logic is sane. Enable 3DS for high-risk only. |
| $100k-$1M/mo | Monthly decline code analysis. 3DS exemption strategy. Network token migration. |
| Over $1M/mo | Issuer-level optimization. Dedicated auth rate monitoring. A/B test 3DS strategies. Multiple processor routing for auth lift. |
Where This Breaks
-
International transactions. Cross-border declines are structurally higher. Local acquiring helps but adds complexity.
-
High-risk MCCs. Some industries have elevated decline rates regardless of optimization. Issuers are more conservative.
-
New merchants without history. Issuers trust merchants with track records. New accounts face higher decline rates until they build history.
Analyst Layer: Metrics to Track
| Metric | What It Tells You | Target |
|---|---|---|
| Overall auth rate | Baseline health | > 90% US domestic CNP |
| Auth rate by card brand | Network-specific issues | Visa/MC should be similar |
| Auth rate by geography | Cross-border friction | Domestic > international |
| Soft vs. hard decline ratio | Retry opportunity | Soft should be > 50% of declines |
| Retry success rate | Retry logic effectiveness | > 20% of soft declines recovered |
| 3DS challenge rate | Friction level | < 20% of 3DS transactions challenged |
| 3DS conversion rate | Challenge completion | > 80% complete challenge |
Trend Over Snapshot
Auth rate fluctuates. Track weekly trend, not daily snapshot.
A 0.5% week-over-week decline is a signal. A 0.5% daily swing is noise.
Next Steps
Just starting auth optimization?
- Pull your current auth rate from your processor dashboard → Baseline before optimizing
- Identify your top 5 decline codes → Focus fixes on highest-impact issues
- Check if you're using network tokens → If not, migrate stored cards to tokens
Ready to improve?
- Follow the increase auth rates playbook → Step-by-step optimization
- Implement smart retry logic → Recover soft declines without burning issuer trust
- Review your 3DS strategy → Optimize exemptions for low-risk transactions
Already optimizing?
- Set up weekly auth rate monitoring → Track trends, not snapshots
- Segment by card brand and geography → Find specific weak spots
- Consider multi-processor routing → Route to best-performing processor by issuer
Related Pages
- 3DS Deep Dive - Authentication optimization
- Increase Auth Rates Playbook - Step-by-step guide
- Subscriptions and Recurring - Recurring billing
- Checkout Conversion - Reducing abandonment
- Decline Codes Reference - Understanding failures
- Payments Metrics - Performance tracking
- 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