Playbook: Increase Authorization Rates
- Week 1: Retry logic experiments. Soft declines (51, 61) retry timing, technical (91, 96) immediate retry, unless Mastercard's advice code says wait or stop
- Week 2: Card updater enrollment (VAU, ABU), proactive expiration emails
- Week 3: 3DS on recurring setup, frictionless tuning (more data = higher frictionless rate)
- Week 4: Network token conversion for card-on-file; compare matched payments with your baseline
- Measure each experiment individually: Count additional captured payments, fees and fraud losses
Systematic approach to improving payment authorization rates.
Auth rate optimization is a series of experiments, not a checklist. Each change is a hypothesis about what's causing declines.
Workflow Overview
| Phase | Key Tasks |
|---|---|
| Retry Logic | Baseline assessment, soft decline retry timing, technical retry experiments |
| Card Update | Account updater enrollment (VAU, ABU), proactive expiration outreach, measure ROI |
| 3DS Tuning | 3DS on recurring setup, frictionless tuning (more data), measure impact |
| Network Tokens | Convert cards to network tokens, compare matched payments, calculate ROI |
When to Use This Playbook
- Auth rates falling below your own baseline on matched issuer, country and transaction-type segments
- Significant auth rate decline
- High rate of soft declines
- Customer complaints about payment failures
First Experiment to Run This Week
Hypothesis: We don't know which decline codes are actually addressable.
Experiment:
- Pull your top 5 decline codes from last 30 days
- Categorize each as: retry-able, card-updatable, fraud-related, or hard decline
- Calculate what % of declines are actually addressable
Expected outcome: You'll know where to focus. Count retry-eligible declines and cards that need updated details, then measure how many become captured payments.
Baseline Assessment
Current State:
□ Overall auth rate: _______%
□ Auth rate by card brand:
- Visa: _______%
- Mastercard: _______%
- Amex: _______%
□ Auth rate by transaction type:
- First purchase: _______%
- Recurring: _______%
- Card on file: _______%
Decline Code Categorization
| Category | Example Codes | Addressable? | How to Test |
|---|---|---|---|
| Insufficient funds | 51, 61, 65 | Yes | Retry with timing experiment |
| Card errors | 14, 54, 41, 43 | Yes | Account updater |
| Do Not Honor | 05 | Maybe | Multiple approaches |
| Technical | 91, 96 | Yes | Immediate retry |
| Fraud blocks | 57, 59 | Maybe | Review your fraud rules |
Week 1: Retry Logic Experiments
Experiment: Soft Decline Retry Timing
Hypothesis: Retrying insufficient funds declines at end of month will recover X% of transactions.
Test:
- Segment A: Retry code 51/61 after 24 hours
- Segment B: Retry code 51/61 on the 1st and 15th of month
- Segment C: No retry (control)
Metrics: Recovery rate, customer complaints
Run length: 30 days (need full month for payday cycles)
Suggested starting guardrail: Pause if duplicate-charge complaints exceed 0.1% of retried payments. Tune this to your traffic and investigate every reported duplicate.
Experiment: Technical Retry
Hypothesis: Retrying code 91/96 immediately will recover X%. Skip the retry when Mastercard sends MAC 02 (wait 24 hours) or MAC 03/21 (stop).
Test:
- Retry technical errors once immediately
- If fail, retry again after 5 seconds
- Max 3 attempts
Metrics: Recovery rate per retry
Expected: Compare technical-error recovery with a matched control. Count successful captured payments, repeat failures and duplicate-charge complaints.
Week 2: Card Update Experiments
Experiment: Account Updater ROI
Hypothesis: Account updater will improve auth rate by X% and is worth the cost.
Test:
- Enroll in Visa Account Updater (VAU) and Mastercard ABU
- Measure: cards updated, auth rate lift on updated cards, cost per update
Decision rule: If auth rate lift × transaction value > cost per update, keep it
Results to check: Compare approvals and captured payments on matched customers with and without updates. Keep it only when added value covers update fees and losses.
Experiment: Proactive Expiration Updates
Hypothesis: Reaching out to customers before card expiration reduces involuntary churn.
Test:
- Segment A: Email customers 30 days before expiration with easy update link
- Segment B: No proactive outreach (control)
Metrics: Card update rate, churn rate, auth rate
Week 3: 3DS Optimization
Experiment: 3DS on Recurring Setup
Hypothesis: Using 3DS on initial recurring transaction will improve subsequent auth rates.
Test:
- Segment A: Require 3DS on initial subscription transaction
- Segment B: No 3DS on initial transaction
Metrics: Initial conversion (expect drop), subsequent recurring auth rate (expect lift)
Decision: If recurring auth improvement × LTV > initial conversion drop × AOV, keep it
Experiment: Frictionless 3DS Tuning
Hypothesis: Sending more data to 3DS will increase frictionless rate without hurting fraud protection.
Test:
- Baseline your current frictionless rate
- Add additional data fields (device info, customer history, etc.)
- Measure frictionless rate change
Expected: Compare frictionless completion before and after on matched issuers, countries and risk segments. Check fraud losses and completed purchases too.
Week 4: Network Tokens
Experiment: Network Token Conversion
Hypothesis: Network tokens will improve auth rates on card-on-file transactions.
Test:
- Convert existing saved cards to network tokens (Visa, Mastercard)
- Compare auth rates: tokenized vs. PAN
Results to check: Compare token and PAN approvals on matched payments. Visa publishes a scoped comparison; measure your own captured revenue and costs.
Cost consideration: Some processors charge per token. Calculate ROI.
Measurement Framework
For each experiment:
| Experiment | Hypothesis | Metric | Control | Result | Keep/Kill |
|---|---|---|---|---|---|
| Retry timing | Recover eligible declines | Recovery rate | No retry | ___% | |
| Account updater | Reduce failures from stale details | Auth rate | No updater | ___% | |
| 3DS on recurring | Improve recurring approvals | Recurring auth | No 3DS | ___% | |
| Network tokens | Improve COF approvals | COF auth | PAN | ___% |
Expected Improvements (Cumulative)
| Optimization | What to Measure | Compare With |
|---|---|---|
| Smart retry | Captured payments after eligible declines | Matched no-retry control |
| Account updater | Approvals and captured payments after updates | Matched customers without updates |
| Network tokens | Approvals, captured revenue and fees | Matched PAN payments |
| 3DS optimization | Challenge completion, approvals and fraud losses | Matched eligible payments under the prior setup |
| Data quality fixes | Approvals and completed purchases | Matched payments before the fix |
Cumulative potential: Measure the combined result after testing each change. Don't add separate lifts: they can affect the same payments.
More approvals aren't the whole result. Count the extra payments you captured, then subtract fees and fraud losses.
- Seasonality: auth rates move with spending patterns. Compare to the same period last year, because last month isn't the control.
- Card mix changes: If you're acquiring different customer types, your baseline is shifting.
- Processor changes: if you switched processors, your auth rates moved for that reason and you can't read your optimizations through it.
- Selection bias: If you only retry "good" looking declines, you'll overestimate retry effectiveness.
Anti-Pattern: What Not to Do
- Don't implement all optimizations at once (can't measure what worked)
- Don't retry hard declines (05 codes) aggressively (can get you blocked)
- Don't assume vendor claims (test their claimed lift on your own matched payments)
- Don't optimize auth rate at the expense of fraud rate (measure both)
Next Steps
After running optimization experiments:
- Keep winners, kill losers: Document which experiments improved auth rates and make them permanent
- Set baselines: Lock in new auth rate benchmarks for future comparison
- Monitor for regression: Set alerts if auth rate drops below new baseline
- Expand to other segments: Apply winning strategies to international or different card types
- Balance with fraud: Verify fraud rate didn't increase alongside auth improvements
Related
- Payments Metrics - Tracking payment health
- Auth Optimization - Detailed optimization guide
- Decline Codes - Understanding decline reasons
- 3D Secure - Authentication and auth rate impact
- Subscriptions & Recurring - Recurring billing optimization
- Digital Wallets - Tokenized payment methods and wallet-based auth lift
- Benchmarks - Auth rate targets
- Processor Management - Working with processors
- Risk Scoring - Balancing fraud vs. auth
- Card Payments - Card type impact on auth rates
- Checkout Conversion - Conversion optimization
- Payment Change Checklist - Testing retry changes