Card Declined: A Decision Tree for B2B Issuing Operators
Card declines are normal; unmanaged triage is not. Operators need a repeatable path from “declined at checkout” to a root cause without loosening controls by accident. This runbook assumes you can access authorization timestamps, amounts, merchant descriptors, and standardized response codes from your processor or issuer reports.
Step 1: Confirm a real issuer decline
Timeouts, merchant gateway errors, and wallet UI bugs can look like declines to the end user. Before changing card settings, verify whether an authorization record exists and whether it reached the issuer. If there is no auth attempt, focus on connectivity and merchant configuration first.
Step 2: Spend controls and policy
Check per-transaction and cumulative limits, allowed merchant categories, and any per-merchant rules. In B2B programs, misclassified merchant category codes or outdated merchant allowlists are common causes. Confirm whether “daily” limits use UTC or local business cutoffs so support explains behavior consistently.
Step 3: Authentication and risk
For card-not-present commerce, evaluate whether strong customer authentication failed or was abandoned. On the risk side, look for velocity spikes, unusual geographies, or device signals that correlate with the decline window. If models or rules changed recently, compare decline rates before and after the change.
Step 4: Scheme and issuer factors
When internal controls look correct, partial outages, maintenance windows, or issuer-side category policies can still produce declines. Escalate with full trace identifiers and a concise timeline so partners can investigate without back-and-forth.
Step 5: Turn incidents into playbooks
Each novel pattern should become a documented branch: symptom, checks, likely causes, and safe mitigations. Where possible, expose self-serve explanations for recurring decline codes so tier-one support resolves repeats without paging engineering. The objective is predictable handling, not zero declines.