Skip to main content

Auth Optimization Tactics

On this page
Prerequisites

Before implementing these tactics:

This page covers the specific tactics for improving authorization rates. For overview and metrics, see Auth Optimization.

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​

ProblemHow Tokens Help
Card reissuanceToken stays valid when card is replaced
Fraud screeningIssuers trust tokenized transactions more
Auth rates2-5% lift on tokenized vs. raw PAN

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

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​

TypeMeaningExample
CIT (Customer-Initiated)Customer is present for the transactionOne-time purchase, initial subscription signup
MIT (Merchant-Initiated)Merchant charges without customer presentRecurring 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​

FlagUse Case
recurringSubscription billing
installmentScheduled payment series
unscheduledVariable charges on stored card
resubmissionRetry 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 is a double-edged sword. Do it right, recover revenue. Do it wrong, damage your issuer reputation.

What's Allowed​

Decline TypeRetry?Strategy
Soft decline (insufficient funds)YesWait 3-5 days, retry around payday
Issuer unavailableYesWait 4-24 hours
Velocity limit exceededMaybeWait 24 hours, try once
Card expiredNoRequest new card
Do not honorOnceTry once more, then stop
Fraud/stolenNeverStop 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 CodeMeaningRetry Strategy
51Insufficient fundsWait 3-5 days
91Issuer unavailableWait 4-24 hours
85Card not activatedWait 1-2 days
61Exceeds withdrawal limitWait a few days
65Activity limit exceededWait 24 hours

Hard Declines: Do Not Retry​

Decline CodeMeaningAction
05Do not honorTry once more max
14Invalid card numberStop, request new card
41Lost cardStop immediately
43Stolen cardStop immediately
54Expired cardStop, request new card
57Function not permittedStop, 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.

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 can help or hurt depending on how you use it.

3DS Impact Reality​

ScenarioAuth Rate ImpactLiability Shift
3DS challenge, customer completes-5 to -15% conversionYes
3DS frictionless (no challenge)Neutral to +1%Yes
No 3DSBaselineNo

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:

ExemptionCriteriaBest For
TRA (Transaction Risk Analysis)Low-risk based on your fraud rateLow-risk merchants
Low-valueUnder €30 (EU)Small purchases
RecurringSubsequent subscription chargesRecurring billing
Trusted beneficiaryCustomer whitelisted the merchantReturning customers
Ask Your Dev

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

CauseScenario
Customer retryCustomer clicks "Pay" twice
Network retryNetwork retransmits due to timeout
Merchant retryYour 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 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​

PatternCauseFix
High decline rate on one BINIssuer-specific policyContact issuer, adjust fraud rules
International cards decliningCross-border frictionConsider local acquiring
First-time customers declining moreNew card, no historyAdd 3DS for liability shift
Weekend declines higherBank staffing/limitsAdjust retry timing
High declines on specific amountVelocity or limit triggersVary 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: 1-3% improvement in overall auth rate.

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​