Skip to main content

Fix Declining Auth Rates (Playbook)

TL;DR
  • Hour 1: Confirm drop is real (not data artifact), isolate segment (BIN, geo, method), pull decline codes
  • Hour 2-4: Match pattern—issuer-specific? All traffic? Soft declines (51)? Hard declines (14, 54)? 3DS-related?
  • Common fixes: Roll back aggressive rule, restart card updater, fix 3DS config, contact processor for issuer outreach
  • Set alerts: 0.5pp below 7-day average, 2x normal for specific decline codes
  • See Auth Optimization for proactive improvements

Auth rate dropped 2+ points in a week? Don't panic. This playbook helps you diagnose the cause in hours, not days. Most drops come from a small number of root causes. Find yours.

Timeline: 1-3 days to diagnose, 1-2 weeks to fix.

Workflow Overview​

PhaseKey Tasks
Identify ScopeConfirm drop is real, isolate segment (BIN, geo, method), check decline codes
Root CauseCheck scenarios, match symptoms to likely causes
ImplementQuick fixes (same day), medium fixes (this week), plan longer fixes
MonitorSet up alerts, track recovery, document learnings

Prerequisites: Access to processor dashboard, auth rate data by segment, decline code breakdown, timestamp of when decline started.

Trigger Criteria​

Use this playbook when:

  • Auth rate dropped more than 1% week-over-week
  • Auth rate dropped more than 0.5% day-over-day
  • You're suddenly below your historical baseline
  • Customer complaints about declined payments spike
Prerequisites

Before starting, ensure you have:

Hour 1: Identify the Scope​

Step 1: Confirm the Drop Is Real​

Rule out data issues first:

  • Check total transaction volume (did volume spike or drop?)
  • Verify reporting isn't lagged or broken
  • Compare multiple data sources if available

Checkpoint: Confirmed real auth rate decline, not data artifact.

Step 2: Isolate the Segment​

Break down auth rate by:

SegmentCheck For
Card brandVisa vs MC vs Amex vs Discover
BIN/IssuerSpecific issuer having issues
GeographyUS vs international; specific countries
Payment methodCards vs wallets vs ACH
Transaction typeCP vs CNP; one-time vs recurring
3DS status3DS vs non-3DS
Time of dayCertain hours affected

Checkpoint: Identified whether drop is global or isolated to specific segment.

Step 3: Check Decline Codes​

Pull decline code distribution:

CodeMeaningIf Spiking
05Do not honorIssuer-side issue or fraud signal
51Insufficient fundsCustomer mix changed
14Invalid card numberTokenization or integration issue
54Expired cardCard updater not running
57Transaction not permittedMCC or geo restriction
65Velocity exceededYour rules or issuer rules

Checkpoint: Identified which decline codes increased.

Hour 2-4: Root Cause Analysis​

Scenario A: Specific Issuer Declining More​

Symptoms:

  • One or few issuers (BINs) show major decline increase
  • Other issuers unchanged

Likely causes:

  • Issuer fraud model updated
  • Issuer technical issues
  • Your fraud rate with that issuer triggered blocks

Actions:

  1. Check if issuer has known outage (check DownDetector, X/Twitter)
  2. Review your fraud/chargeback rate with that issuer
  3. Contact processor to check for issuer advisories
  4. If persistent, escalate through network channels

Scenario B: All Traffic Declining More​

Symptoms:

  • Decline increase across all segments
  • Happened suddenly at specific time

Likely causes:

  • Integration change deployed
  • Processor/gateway issue
  • New fraud rule too aggressive
  • 3DS configuration changed

Actions:

  1. Check recent code deploys (was anything pushed?)
  2. Check processor status page
  3. Review fraud rule changes in last 48 hours
  4. Check 3DS challenge rate (did it spike?)

Scenario C: Soft Declines (05, 51) Increasing​

Symptoms:

  • "Do not honor" or "Insufficient funds" codes up
  • Customer quality may have changed

Likely causes:

  • Traffic source changed (new marketing channel)
  • Time of month (end of month, funds low)
  • Fraud testing attacks (generates declines)

Actions:

  1. Compare traffic sources week-over-week
  2. Check for velocity spikes (fraud testing?)
  3. Implement retry logic if not already present
  4. Review if new marketing is bringing lower-quality leads

Scenario D: Hard Declines (14, 54) Increasing​

Symptoms:

  • "Invalid card" or "Expired card" codes up
  • Often recurring billing affected

Likely causes:

  • Card updater stopped working
  • Token migration issue
  • Integration sending wrong data

Actions:

  1. Verify card updater is running (check processor dashboard)
  2. Check tokenization integrity
  3. Review integration logs for malformed requests

Symptoms:

  • Non-3DS auth rate stable; 3DS auth rate dropped
  • Challenge rate increased
  • Frictionless rate decreased

Likely causes:

  • 3DS provider issue
  • Risk threshold changed
  • Issuer ACS issues

Actions:

  1. Check 3DS provider status
  2. Review 3DS risk settings (did thresholds change?)
  3. Compare challenge vs frictionless rates
  4. Test 3DS flow manually

Day 2-3: Implement Fixes​

Quick Fixes (Same Day)​

IssueFix
Too-aggressive fraud ruleRoll back or loosen in shadow mode
Integration bugHotfix and deploy
Card updater stoppedRe-enable or restart
3DS misconfiguredAdjust thresholds

Medium Fixes (This Week)​

IssueFix
Issuer blocking youContact processor for issuer outreach
Retry logic missingImplement smart retry for soft declines
Bad traffic sourcePause channel, investigate

Longer Fixes (Ongoing)​

IssueFix
High fraud rate causing blocksImprove fraud prevention
Need network tokensImplement tokenization project
Need better 3DSTune risk model, consider new provider

Monitoring After Fix​

Set up alerts to catch future drops:

AlertThreshold
Auth rate dropMore than 0.5pp below 7-day average
Specific decline code spikeMore than 2x normal volume
3DS challenge rateMore than 5pp above baseline
Single issuer decline rateMore than 10pp above baseline

Success Criteria​

You're done when:

  • Root cause identified and documented
  • Fix implemented or escalation in progress
  • Auth rate recovering toward baseline
  • Monitoring alerts configured to catch recurrence

Scale Callout​

VolumeApproach
Under $100k/moFocus on biggest decline code first; may not have segment granularity
$100k-$1M/moFull segment analysis; processor should help with issuer outreach
Over $1M/moReal-time monitoring required; dedicated processor contact; issuer-level optimization

Where This Breaks​

  • No segment-level data. Ask processor for detailed reporting; you need this visibility.
  • Can't identify deploy timing. Correlate with engineering; need deploy timestamps.
  • Processor says "issuer issue" but won't help. Escalate; ask for issuer outreach or network escalation.
  • Auth rate keeps bouncing. May be A/B tests, bot traffic, or external factors; longer investigation needed.
  • Multiple issues at once. Fix one at a time; validate before moving to next.

Next Steps​

After stabilizing auth rates:

  1. Document the root cause: Add to your runbook for faster diagnosis next time
  2. Set up alerts: Configure monitoring to catch future drops early
  3. Optimize proactively: Move to Increase Auth Rates playbook
  4. Review quarterly: Schedule regular auth rate reviews to catch gradual declines