# Playbook: Increase Authorization Rates
Source: https://paymentsandrisk.com/docs/playbooks/increase-auth-rates

Last updated 23 October 2026.

TL;DR

-   **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](https://paymentsandrisk.com/docs/fraud/prevention/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

```mermaid
flowchart LR
    A[<b>WEEK 1</b><br/>Retry Logic] --> B[<b>WEEK 2</b><br/>Card Update] --> C[<b>WEEK 3</b><br/>3DS Tuning] --> D[<b>WEEK 4</b><br/>Network Tokens]

    style A fill:#3d5a80,color:#fff
    style B fill:#5e4b8b,color:#fff
    style C fill:#9a5b00,color:#fff
    style D fill:#1f6f4a,color:#fff
```

| 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:**

1.  Pull your top 5 decline codes from last 30 days
2.  Categorize each as: retry-able, card-updatable, fraud-related, or hard decline
3.  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

```text
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:**

1.  Enroll in Visa Account Updater (VAU) and Mastercard ABU
2.  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:**

1.  Baseline your current frictionless rate
2.  Add additional data fields (device info, customer history, etc.)
3.  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](https://paymentsandrisk.com/docs/payments/reference/tokenization/#real-world-data); 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.

Where Experiments Lie to You

-   **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:

1.  **Keep winners, kill losers**: Document which experiments improved auth rates and make them permanent
2.  **Set baselines**: Lock in new auth rate benchmarks for future comparison
3.  **Monitor for regression**: Set alerts if auth rate drops below new baseline
4.  **Expand to other segments**: Apply winning strategies to international or different card types
5.  **Balance with fraud**: Verify fraud rate didn't increase alongside auth improvements

* * *

## Related

-   [Payments Metrics](https://paymentsandrisk.com/docs/payments/metrics/) - Tracking payment health
-   [Auth Optimization](https://paymentsandrisk.com/docs/payments/auth-optimization/) - Detailed optimization guide
-   [Decline Codes](https://paymentsandrisk.com/docs/reference/decline-codes/) - Understanding decline reasons
-   [3D Secure](https://paymentsandrisk.com/docs/fraud/prevention/3ds/) - Authentication and auth rate impact
-   [Subscriptions & Recurring](https://paymentsandrisk.com/docs/payments/subscriptions-recurring/) - Recurring billing optimization
-   [Digital Wallets](https://paymentsandrisk.com/docs/payments/payment-methods/digital-wallets/) - Tokenized payment methods and wallet-based auth lift
-   [Benchmarks](https://paymentsandrisk.com/docs/reference/benchmarks/) - Auth rate targets
-   [Processor Management](https://paymentsandrisk.com/docs/operations/processor-management/) - Working with processors
-   [Risk Scoring](https://paymentsandrisk.com/docs/fraud/prevention/risk-scoring/) - Balancing fraud vs. auth
-   [Card Payments](https://paymentsandrisk.com/docs/payments/payment-methods/cards/) - Card type impact on auth rates
-   [Checkout Conversion](https://paymentsandrisk.com/docs/payments/checkout-conversion/) - Conversion optimization
-   [Payment Change Checklist](https://paymentsandrisk.com/docs/operations/change-checklist/) - Testing retry changes