Why Online Payments Fail, And How To Build A Checkout That Recovers Them
Online payments fail for two completely different reasons, and treating them as one problem is why most attempts to fix them do not work.
Some failures are decisions. The customer looked at the total, saw a shipping charge they were not expecting, and left. Baymard Institute, aggregating fifty separate studies, puts documented cart abandonment at 70.22%, with unexpected extra costs the most cited reason. Others are mechanical. The customer entered valid details, pressed pay, and the transaction did not complete because of an issuer decline, an authentication flow that broke on their phone, an expired stored card, or a bug in how your system handled the response.
The second category is where the recoverable money sits, because those customers had already decided to buy. This piece is about that category.
Before diagnosing anything, split your funnel at the point of payment submission.
Abandonment happens before submission. The customer never pressed pay. Baymard's data on the reasons is specific and worth knowing: around 48% of abandoners cite extra costs such as shipping, tax and fees pushing the total higher than expected, roughly 19% leave because the site demanded an account, and about 18% because the checkout was too long or complicated. Baymard also suggests a large site can gain around a 35.26% conversion increase through better checkout design, which is a substantial prize and a design problem.
Note what the top reason implies. Nearly half of abandonment is caused by information arriving late rather than by the amount itself. A shipping cost shown on the product page annoys nobody; the same cost revealed at step four of checkout reads as a bait and switch. That is a merchandising fix, not a payments fix, and it is why the split matters. Several of those causes trace back to the product data model.
One cause sits awkwardly between the two categories and deserves its own note: missing payment methods. If a customer reaches checkout and their preferred method is absent, they abandon, so it lands in the abandonment bucket and gets treated as a design problem. It is really a coverage problem, and it is heavily regional. Cash on delivery in parts of South Asia and the Gulf, UPI in India, iDEAL in the Netherlands, Klarna and similar instalment options across much of Europe. Check the abandonment rate for customers by country against your method coverage in that country. A market that abandons at fifteen points above your average usually has a missing method rather than a broken form.
Failure happens after submission. The customer pressed pay and the transaction did not complete. Causes are technical and financial.
These need different owners, different metrics and different fixes. A team that reports one blended "checkout conversion" number cannot tell which one is moving, and will end up redesigning a form to fix an authorisation problem. Instrument the split first. Everything downstream depends on it.
If you are mid replatform, capture both numbers before cutover. Afterwards you cannot separate a payments regression from a migration one, and you will spend a fortnight arguing about which it was.
One number worth calculating before you read further: of the customers who pressed pay in the last ninety days, what percentage ended up with a completed order? If you cannot answer that from your own data in under an hour, that gap is the first thing to fix.
When an issuer refuses a transaction it returns a reason code, and those codes fall into two groups that demand opposite responses.
Hard declines are permanent. Stolen card, closed account, invalid card number, do not honour with a fraud flag. The answer will not change if you ask again in an hour. Retrying a hard decline is not just useless; card networks monitor excessive retries and repeated attempts against a known bad card can attract fines or higher scheme fees. Stop, and ask the customer for a different method.
Soft declines are temporary and they are the opportunity. Insufficient funds, issuer system unavailable, velocity limit hit, authentication required, temporary hold. The same card may well succeed later that day. A meaningful share of these are recoverable and most merchants recover none of them, because the checkout treats every non-success identically and shows the customer a generic error.
The practical problem is that reason codes are not uniform. Every gateway normalises them differently, and issuers do not always send an accurate one. What works is to build your own mapping from your gateway's codes into three buckets: retry automatically, prompt the customer for action, and stop permanently. Then review that mapping against real outcomes each quarter, because a code you classified as hard may be recovering at ten percent in practice.
The customer facing message should differ by bucket too. "Your bank declined this payment, please try a different card" is useful. "Payment failed" is not, and it converts a recoverable soft decline into a lost order because the customer assumes the fault is permanent.
For soft declines, retries work. They work considerably better with a policy than without one.
Do not retry immediately. An insufficient funds decline at 11pm is unlikely to succeed at 11:01pm. Same for a velocity limit. Immediate retries burn one of your limited attempts on the least likely moment to succeed.
Space attempts across days, not minutes. For recurring billing, spreading attempts over roughly a week, with attempts a few days apart, gives salary and deposit cycles a chance to land. For one off checkout you do not have days, so the equivalent move is to route the retry to a different path rather than repeating the identical request.
Cap the attempts. Card networks impose limits on retries against a declined transaction, and exceeding them carries fees. Four attempts is a common ceiling for recurring billing. Know your acquirer's specific rules rather than assuming.
Vary something each time. Repeating an identical request produces an identical answer. Retrying through a different acquirer, or after refreshing the network token, or with updated card details from an account updater service, changes the input and therefore the possible output.
Stop on any hard decline. Even mid schedule. If attempt two returns a hard code, the schedule ends there.
For subscriptions specifically, pair the technical retry with customer communication, since a payment that keeps failing usually needs the customer to act. The email that says "your card was declined, update it here" recovers more revenue than the fifth silent retry, and it does it without consuming network attempts.
Strong authentication reduces fraud and it costs conversion, and the size of that cost depends almost entirely on implementation quality.
In Europe, PSD2 strong customer authentication has been in force for years, and the merchants who handle it well are the ones who use exemptions correctly: low value transactions, transaction risk analysis and trusted beneficiary listings all reduce how often a customer is challenged. Merchants who apply full authentication to every transaction are paying a conversion penalty they did not need to pay.
India is mid transition and the dates matter. The Reserve Bank of India issued its Authentication Mechanisms for Digital Payment Transactions Directions, 2025 on 25 September 2025. Compliance for payment system providers and participants applied from 1 April 2026. A separate obligation follows on 1 October 2026, requiring card issuers to run a validation mechanism for cross border card not present transactions where an overseas merchant or acquirer raises the authentication request.
Two consequences for merchants selling into India. First, the framework moves the country beyond SMS one time passwords as the default, opening the door to authentication factors that are considerably better for conversion, including device bound methods and biometrics. Second, if you are an overseas merchant taking Indian cards, your cross border card not present flows are about to interact with a new issuer side check. Test that path specifically, ahead of the date, rather than discovering it in your October authorisation numbers.
The general principle across every market: authentication that happens in a well built flow costs a few percent of conversion. Authentication that redirects to a poorly rendered page, breaks the browser back button, or times out on a mobile connection costs far more. Test the challenge flow on a mid range Android phone on a slow connection, in the mobile app as well as the browser, because that is where it fails and it is almost never where it gets tested.
Some payment failures have nothing to do with banks. These are the ones worth fixing first, because they are entirely within your control.
Webhooks processed more than once. Payment providers guarantee at least once delivery, not exactly once. Your endpoint will receive the same event twice, and if the handler is not idempotent you get duplicate orders, double fulfilment or a double refund. The fix is a unique key per event, stored and checked before processing, so a repeat delivery becomes a no operation.
Webhooks arriving out of order. The payment.succeeded event can arrive after payment.refunded. Handlers that assume sequence will write the wrong final state. Process events against the event's own timestamp and refuse to apply anything older than the current state.
Webhooks trusted without verification. Every provider signs its payloads. Verify the signature. An unverified endpoint that creates paid orders is a way to receive free goods.
The browser treated as authoritative. If your order is created when the customer's browser returns from the payment page, then every closed laptop, dropped connection and impatient tab close produces a payment with no order. The customer is charged and has nothing. Server side confirmation via webhook must be the source of truth, with the browser redirect as a convenience only.
Timeouts handled as failures. A gateway timeout means the outcome is unknown, not that it failed. Treating it as a failure and retrying charges the customer twice. Every payment request needs an idempotency key so a retry of an uncertain request cannot create a second charge.
Payment page scripts breaking checkout. Since 31 March 2025, PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 have been mandatory, requiring merchants to inventory and authorise every script on a payment page, assure its integrity, and detect unauthorised changes at least every seven days. Note the scope: 6.4.3 covers all scripts on the page, including analytics, chat widgets and testing tools. Beyond compliance there is an availability argument, since a third party script that hangs will take your checkout with it. Every script on a payment page should be justified, monitored, and loaded so that its failure cannot block payment.
For subscriptions and saved card checkouts, a slow leak runs constantly in the background. Cards expire. Cards get reissued after fraud. Customers change bank. None of these generate any notification to you, so the first sign is a decline, by which point you have already lost the payment and possibly the customer.
Three mechanisms address it, in increasing order of effectiveness.
Account updater services from the card networks push updated card details to merchants when an issuer reissues a card. Coverage is good but not universal, and it works only where you and the issuer both participate.
Network tokenisation replaces the stored card number with a token that the network keeps current through reissues. Where it is supported it is meaningfully better than storing a card number, and it usually improves authorisation rates because issuers treat tokenised transactions as lower risk.
Prompting the customer before expiry. Unfashionable, and it works. A message thirty days before a stored card expires costs almost nothing and prevents an involuntary churn event that would otherwise require a dunning cycle to recover.
Involuntary churn is often the single largest source of subscription cancellation, and it is entirely mechanical. Every customer lost this way wanted to keep paying.
Authorisation rate. Approved transactions divided by attempted, segmented by card scheme, issuing country, card type and payment method. The segmentation is the point. A blended rate hides the fact that one issuing country is running fifteen points below the rest, which is a fixable routing problem.
Two traps in that calculation. First, decide explicitly whether transactions your own fraud rules blocked count as attempts. Including them makes your rate look worse when you tighten fraud screening, which is the opposite of the signal you want. Report blocked and declined separately. Second, a local acquirer in a market where you do real volume often authorises materially better than a cross border route, because the issuer sees a domestic transaction rather than a foreign one. If one country is dragging your average down, check how the transaction is being routed before you assume the customers are the problem.
Decline reason distribution. Which codes, in what proportion, trending over time. A sudden rise in one code is a signal, and it is usually something you changed.
Recovery rate. Of failed payments, how many eventually completed. Most teams cannot produce this number at all, which means their retry logic has never been evaluated. It is the number that tells you whether the retry schedule above is worth anything.
Time from attempt to settled. Reconciliation gaps between what your system thinks was collected and what actually settled are where quiet, long running bugs live.
Set alerts on rate of change rather than absolute thresholds. Authorisation rates vary by season, by campaign and by traffic mix, so a fixed threshold either fires constantly or never. A five point drop against the same weekday last week is worth waking someone for.
Working through this list takes a couple of days and typically finds something. It is the same list we work through at the start of any ecommerce app development engagement.
The customer already decided to buy. That is what makes this category of problem different from almost everything else in ecommerce, and it is why the return on fixing it is so much higher than the effort suggests.
Start with the split between abandonment and failure, because without it you cannot tell which problem you have. Then work through the failures that live in your own code, since those are free to fix and nobody else will fix them for you. The bank declines are a longer conversation, but a good share of those are recoverable too, and most merchants are currently recovering none.
A soft decline is temporary, such as insufficient funds, a velocity limit, an issuer system being unavailable, or authentication being required. The same card may succeed later. A hard decline is permanent, such as a stolen card, closed account or invalid number, and the answer will not change on a retry. The distinction matters commercially, because retrying a hard decline is monitored by the card networks and repeated attempts against a known bad card can attract fines or higher scheme fees.
Only for soft declines, and with a policy. Do not retry immediately, since an insufficient funds decline is no more likely to succeed a minute later. For recurring billing, space attempts across roughly a week so salary and deposit cycles can land. Cap the total attempts within your acquirer's limits, commonly around four. Vary something on each attempt, such as routing through a different acquirer or refreshing the network token, because an identical request returns an identical answer. Stop immediately on any hard decline, even mid schedule.
The Reserve Bank of India issued its Authentication Mechanisms for Digital Payment Transactions Directions, 2025 on 25 September 2025. Compliance applied to payment system providers and participants from 1 April 2026, moving the market beyond SMS one time passwords as the default and permitting device bound and biometric factors. A separate obligation applies from 1 October 2026, requiring card issuers to validate cross border card not present transactions where an overseas merchant or acquirer raises the request. Overseas merchants taking Indian cards should test that flow before the date.
Almost always because order creation depends on the customer's browser returning from the payment page. Any closed laptop, dropped connection or impatient tab close then produces a charge with no order. Server side confirmation through a verified webhook must be the source of truth, with the browser redirect treated as a convenience. The related cause is treating a gateway timeout as a failure, since a timeout means the outcome is unknown, and retrying without an idempotency key charges the customer twice.
They can. Requirements 6.4.3 and 11.6.1 became mandatory on 31 March 2025 and require merchants to inventory and authorise every script on a payment page, assure each script's integrity, and detect unauthorised changes at least every seven days. Requirement 6.4.3 covers all scripts on the page, not only payment ones, so analytics, chat widgets and testing tools are in scope. Separately from compliance, a third party script that hangs can block checkout, so scripts on a payment page should be justified, monitored and loaded so their failure cannot stop a payment.
Stored cards go stale and nobody notifies you. Cards expire, get reissued after fraud, or the customer changes bank, and the first signal is a decline. Three mechanisms help: account updater services from the card networks, network tokenisation so the stored credential stays current through reissues and usually improves authorisation rates, and simply prompting the customer before expiry. Involuntary churn from stale cards is frequently the largest source of subscription cancellation, and every customer lost that way intended to keep paying.
Vikas has around fifteen years of experience building software and now builds generative AI systems at Zyneto. His work covers retrieval augmented generation, agentic AI, knowledge graphs, AI memory, and the evaluation and guardrails that decide whether any of it is safe to put in front of customers. He has shipped enterprise copilots, document AI, chatbots and predictive analytics for e-commerce, fintech and marketing teams, and works day to day in Python, JavaScript and SQL. He follows multimodal models, business process automation and enterprise AI security closely, and mentors engineers moving into AI. He writes about architecture, inference cost and the failure modes that only show up at production scale.
Share your details and we will talk soon.
Be the first to access expert strategies, actionable tips, and the trends actually shaping the digital world. No fluff - just practical insights delivered straight to your inbox.
Dive into our blog and stay ahead of the curve with expert perspectives, future-ready trends, and tech tips written for decision-makers and doers alike.
