Fix Declining Auth Rates (Playbook)
TL;DR
- Hour 1: confirm the drop is real and isn't a data artifact, isolate the segment (BIN, geo, method), pull decline codes. Half the time that's where it ends
- Hour 2-4: Match pattern. Issuer-specific? All traffic? Soft declines (51)? Hard declines (14, 54)? 3DS-related?
- Common fixes: roll back the aggressive rule, restart the card updater, fix the 3DS config, or get your processor to do issuer outreach. It's usually the first one
- 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
| Phase | Key Tasks |
|---|---|
| Identify Scope | Confirm drop is real, isolate segment (BIN, geo, method), check decline codes |
| Root Cause | Check scenarios, match symptoms to likely causes |
| Implement | Quick fixes (same day), medium fixes (this week), plan longer fixes |
| Monitor | Set up alerts, track recovery, document learnings |
Pull four things before you start. Your processor dashboard, auth rate broken out by segment, the decline code breakdown, and the timestamp of when it started dropping. Without that you're guessing, and you'll guess wrong.
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
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:
| Segment | Check For |
|---|---|
| Card brand | Visa vs MC vs Amex vs Discover |
| BIN/Issuer | Specific issuer having issues |
| Geography | US vs international; specific countries |
| Payment method | Cards vs wallets vs ACH |
| Transaction type | CP vs CNP; one-time vs recurring |
| 3DS status | 3DS vs non-3DS |
| Time of day | Certain hours affected |
Checkpoint: Identified whether drop is global or isolated to specific segment.
Step 3: Check Decline Codes
Pull decline code distribution:
| Code | Meaning | If Spiking |
|---|---|---|
| 05 | Do not honor | Issuer-side issue or fraud signal |
| 51 | Insufficient funds | Customer mix changed |
| 14 | Invalid card number | Tokenization or integration issue |
| 54 | Expired card | Card updater not running |
| 57 | Transaction not permitted | MCC or geo restriction |
| 65 | Velocity exceeded | Your 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:
- Check if issuer has known outage (check DownDetector, X/Twitter)
- Review your fraud/chargeback rate with that issuer
- Contact processor to check for issuer advisories
- 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:
- Check recent code deploys (was anything pushed?)
- Check processor status page
- Review fraud rule changes in last 48 hours
- 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:
- Compare traffic sources week-over-week
- Check for velocity spikes (fraud testing?)
- Implement retry logic if not already present
- 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:
- Verify card updater is running (check processor dashboard)
- Check tokenization integrity
- Review integration logs for malformed requests
Scenario E: 3DS-Related Decline
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:
- Check 3DS provider status
- Review 3DS risk settings (did thresholds change?)
- Compare challenge vs frictionless rates
- Test 3DS flow manually
Day 2-3: Implement Fixes
Quick Fixes (Same Day)
| Issue | Fix |
|---|---|
| Too-aggressive fraud rule | Roll back or loosen in shadow mode |
| Integration bug | Hotfix and deploy |
| Card updater stopped | Re-enable or restart |
| 3DS misconfigured | Adjust thresholds |
Medium Fixes (This Week)
| Issue | Fix |
|---|---|
| Issuer blocking you | Contact processor for issuer outreach |
| Retry logic missing | Implement smart retry for soft declines |
| Bad traffic source | Pause channel, investigate |
Longer Fixes (Ongoing)
| Issue | Fix |
|---|---|
| High fraud rate causing blocks | Improve fraud prevention |
| Need network tokens | Implement tokenization project |
| Need better 3DS | Tune risk model, consider new provider |
Monitoring After Fix
Set up alerts to catch future drops:
| Alert | Threshold |
|---|---|
| Auth rate drop | More than 0.5pp below 7-day average |
| Specific decline code spike | More than 2x normal volume |
| 3DS challenge rate | More than 5pp above baseline |
| Single issuer decline rate | More 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
| Volume | Approach |
|---|---|
| Under $100k/mo | Focus on biggest decline code first; may not have segment granularity |
| $100k-$1M/mo | Full segment analysis; processor should help with issuer outreach |
| Over $1M/mo | Real-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. That's usually A/B tests, bot traffic or something external. It's a longer investigation.
- Multiple issues at once. Fix one at a time and validate, or you won't know which fix worked.
Next Steps
After stabilizing auth rates:
- Document the root cause: Add to your runbook for faster diagnosis next time
- Set up alerts: Configure monitoring to catch future drops early
- Optimize proactively: Move to Increase Auth Rates playbook
- Review quarterly: Schedule regular auth rate reviews to catch gradual declines
Related
- Auth Optimization - Proactive improvements
- Decline Codes Reference - Understanding decline reasons
- Authorization Basics - Auth fundamentals
- Benchmarks - Industry auth rate targets
- Payments Experimentation - A/B testing changes
- Increase Auth Rates - Optimization playbook
- 3D Secure - 3DS troubleshooting
- Processor Management - Processor relationships
- Alerts Configuration - Setting up monitoring
- Payments Metrics - Tracking auth rates
- Processor Switch Checklist - When migration causes issues
- Card Payments - Card type impacts