Declines, 3-D Secure, and Chargebacks: The Failure Paths

An approved, undisputed, settled payment needs almost no engineering attention. The failure paths are where the work lives, and there are exactly three families of them.

• The payment never happens: declines, at authorization time.
• The payment is challenged before it happens: authentication, where a suspicious transaction is forced through an extra identity check.
• The payment happens and is then unwound: disputes and chargebacks, up to months later.

Each family has its own machinery, its own economics, and its own rulebook, and they trade off against each other. Decline more and you lose real sales along with the fraud. Authenticate more and you add friction that kills conversion. Accept more and the chargebacks arrive later with fees attached.

A payments team is permanently tuning the three dials against each other, and everything in this lesson is the mechanics behind one of the dials.

A decline arrives as a response code from the issuer, and the single most important skill is separating the codes by what they permit you to do next.

Two operational rules follow. Retrying hard declines is worse than useless: issuers and networks track excessive reattempts, penalise them with fees, and downgrade the merchant's reputation, which raises future decline rates. And the do-not-honour code, the most common decline in card-not-present traffic, is deliberately opaque: the issuer's fraud model said no and will not explain. Subscription businesses live and die by how intelligently they schedule retries around these codes, which is why smart retry timing is a headline feature of every billing platform.

In the European Economic Area, the second Payment Services Directive made customer authentication a legal requirement rather than a merchant choice. Strong customer authentication, SCA, demands that electronic payments be verified with at least two of three independent factors:

• Knowledge: something only the user knows, like a password or PIN.
• Possession: something only the user has, like the phone that receives the approval prompt.
• Inherence: something the user is, like a fingerprint or face.

The factors must be independent, so a breach of one does not compromise the others. A one-time code sent to the same phone that holds the banking app still counts as possession plus knowledge in practice, but the design intent is layered proof of identity.

Key idea: SCA moved the default from "authenticate when suspicious" to "authenticate unless exempt". The commercial action in European payments is therefore not in performing authentication, which is mandatory, but in lawfully avoiding it, through the exemptions in the next step.

The regulation's authors knew that authenticating every transaction would strangle commerce, so the technical standards define exemptions. Four matter in practice.

Low-value transactions under 30 EUR may skip SCA, with velocity limits: after five consecutive exempted payments, or 100 EUR of cumulative exempted spending on the card, authentication must be applied and the counters reset.

Transaction risk analysis, TRA, is the commercially significant one: a payment provider whose measured fraud rate is low enough may exempt transactions up to amount tiers tied to that fraud rate.

Trusted beneficiaries lets a cardholder whitelist a merchant with their bank, exempting future payments. And merchant-initiated transactions, like subscription renewals charged while the customer is absent, sit outside SCA's scope entirely once the mandate was set up with authentication.

The grid explains modern European checkout design: keep baskets under thresholds where you can, earn a low fraud rate to unlock TRA, and set up recurring payments as properly authenticated mandates once.

3-D Secure is the network protocol through which card-not-present authentication actually happens: the merchant's checkout, the network's directory, and the issuer's authentication system, three domains, hence the name.

The modern version, 3-D Secure 2, was designed around a crucial idea: most authentications should be invisible. The merchant sends the issuer a rich data payload with the authentication request, device characteristics, address, transaction context, and the issuer's risk engine chooses one of two flows:

• Frictionless flow. The issuer is satisfied by the data alone and authenticates silently. The customer sees nothing.
• Challenge flow. The issuer demands proof, typically a prompt in the banking app or a biometric check, and the customer must act.

The share of traffic that goes frictionless is a quality score for the whole setup: better data in the request means more silent approvals, higher conversion, and the same legal compliance. Weak integrations that send thin payloads get challenged constantly and blame the regulation for their checkout drop-off.

One more thing rides on the protocol, and it is the part merchants care about most: liability.

When a transaction turns out to be fraudulent, somebody absorbs the loss, and the allocation follows rules worth knowing cold.

This is the liability shift, and it is the quiet price of every exemption: TRA and low-value exemptions keep checkout smooth precisely by leaving fraud liability with the merchant side. Choosing between friction and liability, transaction by transaction, is what payment orchestration logic actually does all day.

A chargeback is the scheme-rule mechanism that lets an issuer claw back a settled payment on the cardholder's behalf. It is not a refund: it is an adversarial process with stages, deadlines and fees, run under the network's rulebook.

The cardholder disputes a transaction with their issuer, citing a reason: fraud, goods not received, not as described, duplicate processing. The issuer raises the chargeback under the matching reason code; the money is pulled back from the acquirer, and therefore from the merchant, immediately, guilty until proven innocent.

The merchant then chooses: accept the loss, or fight through representment by submitting evidence, delivery confirmation, authentication records, correspondence. The issuer reviews; if it stands its ground the dispute can escalate to pre-arbitration and finally network arbitration, where the scheme itself rules and the loser pays meaningful fees.

Deadlines run through the whole machine: cardholders generally have up to 120 days from the transaction or expected delivery under the major schemes' rules, and each response stage gives the parties fixed windows measured in days to weeks.

The chargeback system was designed against criminals, but its heaviest modern use is murkier. Friendly fraud, also called first-party misuse, is the cardholder disputing a transaction they actually made: a forgotten subscription, a family member's purchase, a regretted order, or simple abuse of the process.

Industry analyses consistently attribute a large share of e-commerce disputes to first-party misuse rather than third-party crime, which changes the defensive playbook entirely. Against stolen cards, the answer is authentication before the sale. Against friendly fraud, the answers are evidence and prevention around the sale:

• Recognisable billing descriptors, because "unrecognised transaction" disputes often start with a confusing statement line.
• Delivery and usage evidence, signed delivery, download logs, in-app activity tied to the account.
• Clean cancellation paths, since a subscriber who cannot find the cancel button disputes instead.
• Pre-dispute programmes, network and issuer tools that let merchants refund or supply evidence before a dispute becomes a formal chargeback.

The economics justify the effort: a chargeback costs the merchant the goods, the money, a fee, and a mark against its dispute ratio, and merchants whose ratios exceed scheme thresholds enter monitoring programmes with escalating penalties. For a payments team, the dispute ratio is a survival metric, not a customer-service statistic.