# Auth Optimization Tactics
Source: https://paymentsandrisk.com/docs/payments/auth-optimization/tactics

Last updated 22 October 2026.

TL;DR

-   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](https://paymentsandrisk.com/docs/payments/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](https://paymentsandrisk.com/docs/payments/reference/tokenization/#real-world-data) |

### How They Work

1.  Customer enters card at checkout
2.  Processor requests token from Visa/Mastercard
3.  Token is stored instead of card number
4.  Future transactions use the token
5.  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

Ask Your Dev

"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](https://stripe.com/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 |

Ask Your Dev

"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](https://paymentsandrisk.com/docs/reference/decline-codes/#mastercard-merchant-advice-codes-mac)

Sources: [Visa rules](https://usa.visa.com/dam/VCOM/download/about-visa/visa-rules-public.pdf), section 7.3.6.3, pp. 538-541; [Mastercard rules](https://www.mastercard.com/content/dam/mccom/shared/business/support/rules-pdfs/transaction-processing-rules.pdf), section 3.3; [Global Payments PMB 1311](https://ewingoil.com/sites/default/files/PMB%201311%20October%202023%20Card%20Brand%20Release%20All%20Clients%2030%20Day.pdf), 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](https://docs.stripe.com/declines/network-codes) separates networks; its [`do_not_honor` guidance](https://docs.stripe.com/declines/codes) tells the customer to contact their issuer. Checked 22 October 2026.

Ask Your Dev

"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 |

Ask Your Dev

"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](https://paymentsandrisk.com/docs/fraud/prevention/3ds/)

* * *

## 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

Ask Your Dev

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

1.  Pull all declines
2.  Group by decline code
3.  Identify top 5 codes by volume
4.  Research causes and fixes for each

### Issuer View

> The top 3 reasons we decline:
>
> 1.  Suspected fraud (velocity, geography, mismatch)
> 2.  Insufficient funds
> 3.  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

1.  **Start with network tokens** → Biggest lift for least effort
2.  **Fix your retry logic** → Stop burning issuer trust
3.  **Optimize 3DS** → Request exemptions where you qualify
4.  **Track weekly** → Monitor trends, not snapshots

* * *

## See Also

-   [Auth Optimization Overview](https://paymentsandrisk.com/docs/payments/auth-optimization/) - Metrics and scale guidance
-   [3DS Deep Dive](https://paymentsandrisk.com/docs/fraud/prevention/3ds/) - Complete 3DS reference
-   [Decline Codes Reference](https://paymentsandrisk.com/docs/reference/decline-codes/) - Code meanings
-   [Increase Auth Rates Playbook](https://paymentsandrisk.com/docs/playbooks/increase-auth-rates/) - Step-by-step guide
-   [AVS & CVV](https://paymentsandrisk.com/docs/fraud/prevention/avs-cvv/) - Verification signals
-   [Digital Wallets](https://paymentsandrisk.com/docs/payments/payment-methods/digital-wallets/) - Tokenized payments
-   [Cards](https://paymentsandrisk.com/docs/payments/payment-methods/cards/) - Card acceptance
-   [Processor Management](https://paymentsandrisk.com/docs/operations/processor-management/) - Multi-processor routing
-   [Risk Scoring](https://paymentsandrisk.com/docs/fraud/prevention/risk-scoring/) - Fraud vs auth balance
-   [Authorization Basics](https://paymentsandrisk.com/docs/payments/reference/authorization-basics/) - Auth fundamentals