Payment Decline Diagnostic Checklist
When checkout conversion drops, the instinct is often to blame "declines" as one problem. In practice, a failed payment can break down in at least four different places — a card decline, an authentication failure, checkout abandonment before payment is even attempted, or an infra
Payment Decline Diagnostic Checklist
When checkout conversion drops, the instinct is often to blame "declines" as one problem. In practice, a failed payment can break down in at least four different places — a card decline, an authentication failure, checkout abandonment before payment is even attempted, or an infrastructure issue — and each has a different fix. Treating them as one problem usually means fixing the wrong thing.
This checklist is built to help you classify where a failure is actually happening before you start optimizing.
Start Here: Classify the Failure Type
Before working through the detailed checklists below, answer these four questions using whatever transaction logs or PSP dashboard you have available:
Did the customer reach the payment step and submit a card, only to receive a decline message? → Go to Card Decline Diagnostics
Did the customer get redirected to an authentication step (OTP, banking app, 3DS challenge) and not complete it? → Go to Authentication Failure Diagnostics
Did the customer leave checkout before submitting payment details at all? → Go to Checkout Abandonment Diagnostics
Did the transaction fail with an error unrelated to the customer's card or identity (timeout, error page, duplicate charge)? → Go to Infrastructure Diagnostics
If you can't answer these confidently, that's itself a diagnosis: your reporting isn't granular enough to separate these funnel stages. Fixing that visibility gap should be the first step before anything else.
Card Decline Diagnostics
Pull the actual decline codes, not just a generic "failed" status — soft declines (temporary, retryable) and hard declines (permanent, do not retry) require different responses
Check whether declines cluster by issuer, card network, or country — a pattern concentrated in one segment points to a routing or acquiring issue, not a general problem
Check whether declines cluster by geography relative to your acquiring setup — cross-border transactions routed through a distant acquirer decline at a different rate than local ones
Review what data is being passed with each transaction (AVS, CVV, device data, 3DS data elements) — thin data increases issuer-side risk scoring
Check your Merchant Category Code — an MCC that doesn't match your actual business can itself trigger elevated decline rates
Look for expired-card patterns, especially on recurring/subscription charges — this is a data-freshness problem, not a fraud or risk problem
Compare authorization rates across payment methods, not just cards — a specific method may be underperforming while the blended number looks acceptable
Check whether you have retry logic in place, and whether it's retrying soft declines appropriately (and not retrying hard declines at all)
Authentication Failure Diagnostics
Determine what share of failures happen mid-authentication rather than at initial submission — this is a different funnel stage than a straight decline and needs to be tracked separately
Check whether challenge flows (OTP, banking app redirect) are being triggered more often than necessary — this usually points to thin authentication data or a lack of exemption use
Review whether SCA exemptions (low-value, trusted merchant, transaction risk analysis) are actually being applied where eligible
Check for OTP delivery issues specifically — delayed SMS, filtered messages, or number-mismatch problems are common and easy to miss without dedicated tracking
Review whether authentication is being applied uniformly regardless of transaction risk, rather than through risk-based rules
Check whether repeat customers on previously-used devices and cards are still being challenged every time — that's a sign the setup isn't using trusted-device or transaction-history signals
Checkout Abandonment Diagnostics
Confirm the drop-off is happening before a payment method is even selected — if so, the problem is checkout UX, not payments infrastructure
Check the number of required fields against what's actually necessary — extra fields (especially address or phone validation) are a common silent abandonment driver
Check whether guest checkout is available, or whether forced account creation is adding a barrier
Compare abandonment rates on mobile versus desktop — mobile-specific friction (small tap targets, slow load, awkward field types) often hides inside a blended number
Check whether currency and payment methods displayed match customer expectations by market — an unfamiliar currency or missing local method at the point of payment selection causes abandonment before a decline is even possible
Review page load speed at the checkout and payment-selection steps specifically, not just the site overall
Check whether checkout uses a redirect flow or an embedded flow — redirects introduce a trust and continuity gap that embedded checkouts don't
Infrastructure Diagnostics
Check for timeout errors on the payment API and how often they occur relative to total volume
Check for duplicate payment attempts caused by retries without idempotency handling — this creates both a customer experience problem and a reconciliation problem
Review whether webhook delivery failures are causing payment status mismatches between what actually happened and what your system shows
Check whether there's a documented failover path if your primary PSP or acquirer has an outage, and whether it's actually been tested
Review recent PSP status-page history for outages or degraded performance that align with any drop in your own numbers
Data You Need to Diagnose Properly
If you can't complete the checklists above, the most common blocker is missing data rather than missing effort. At minimum, you need:
Decline codes at the transaction level, not aggregated status
Funnel-stage breakdown (checkout started → payment method selected → authentication → decline/success)
Segmentation by country, issuer, card network, payment method, and device
Timestamped logs that separate "customer abandoned" from "transaction failed"
When It's Your PSP's Problem vs Yours
Not every issue on this list is something a merchant can fix directly. Checkout field count, currency display, and guest checkout are entirely in your control. Authorization rates by issuer, routing behavior, and authentication configuration are shared responsibility between you and your payment provider — and if your PSP can't give you the segmented data needed to run this checklist in the first place, that's worth treating as a finding in itself.
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗