3-D Secure 2, explained

Most merchants meet 3-D Secure twice: once when a payment is declined and the support ticket blames "the bank", and once when someone in finance asks why the approval rate moved. Both conversations get easier if you know what the protocol actually does, when it is required, and which of your payments can skip it.

What 3-D Secure is for

3-D Secure lets the card issuer confirm that the person entering the card details is the cardholder. The three domains in the name are the issuer, the acquirer and the interoperability layer between them. When authentication succeeds, liability for a fraud-related chargeback on that transaction shifts from the merchant to the issuer. That shift is the commercial reason the protocol exists; the regulatory reason arrived later.

What changed from version 1

Version 1 was a browser redirect to an issuer page with a static password. It was built before smartphones, it broke in in-app flows, and it asked every cardholder to remember a credential they used a few times a year. Abandonment at that page was the largest single cost of using it, and the cure was often worse than the fraud.

Version 2 changes four things.

It carries data. The merchant and the provider send the issuer a structured message with device information, the billing and shipping address, the email address, the transaction history with that merchant and around a hundred other optional elements. The issuer scores the transaction on that data instead of interrogating the cardholder.

It authenticates without a redirect by default. If the data is convincing, the issuer approves the authentication without showing the cardholder anything. This is the frictionless flow.

It works outside a browser. Version 2 defines an in-app SDK flow and supports biometric confirmation in the issuer's own banking app, which is where most challenges now land.

It is decoupled from the authorization. Authentication produces a cryptogram and an ECI indicator that travel with the later authorization request, so the two steps can be separated in time — useful for delayed captures and for recurring setups.

When strong customer authentication applies

In the EEA and the UK, PSD2 requires strong customer authentication on most electronic payments where both the payer's bank and the payee's provider are inside the area. Strong means two of three independent factors: something the customer knows, something they have, something they are. For a card payment online, 3-D Secure 2 is the mechanism that delivers it.

Two points are worth being precise about, because both cause arguments.

It is the issuer that enforces it. You do not choose whether SCA applies. If a transaction requires it and you send it without authentication data, the issuer is entitled to reject it with a soft decline and a code that says "do this again with authentication". A good provider retries such a decline through authentication automatically rather than surfacing it to the customer.

One-leg-out transactions are different. If the card was issued outside the EEA or the UK, the requirement does not apply in the same way, and issuer behaviour varies by country and by bank. Merchants selling in several regions should expect different authentication rates per issuing country, and should not read that difference as a fault in the checkout.

The exemptions, and what each one buys you

Exemptions let a transaction proceed without a challenge. They are requested by the acquirer or the merchant in the authorization message, and — this is the part that surprises people — the issuer decides whether to honour one. An exemption is a request, not an instruction.

Transaction risk analysis

The acquirer's own fraud rate, measured over its whole portfolio, buys the right to exempt transactions below a value that depends on which fraud-rate band the acquirer sits in. Lower measured fraud, higher exemption ceiling. This is the most useful exemption for a merchant with clean traffic, and the reason it is worth asking a provider what its TRA rates look like: the benefit is the acquirer's to give, not yours to claim.

Low value

Transactions under a small threshold may skip authentication, subject to a counter: after a number of consecutive exempted payments, or once a cumulative amount is reached, the next one must be authenticated. The counter is held by the issuer, so from your side the behaviour looks intermittent. It is not; it is the counter resetting.

Merchant-initiated transactions

A payment you initiate, with no customer present — a subscription renewal, a metered bill, a delayed top-up — is out of scope for SCA, provided the first payment in the series was authenticated and the mandate was set up correctly. This is why the initial authentication on a subscription matters so much: it is what makes every subsequent charge exempt.

Trusted beneficiary

The customer can ask their issuer to add a merchant to a list of trusted payees, after which that merchant's payments skip the challenge. The customer is offered this during a challenge flow, so the only way to accumulate trusted-beneficiary status is to have been challenged first, with a descriptor the customer recognises.

Secure corporate payments

Payments made with lodged or virtual corporate cards through a secure, dedicated process can be exempt. It matters for travel and procurement flows and almost nowhere else.

Frictionless and challenge

Every authentication ends in one of a few outcomes. Frictionless means the issuer authenticated on data alone and the customer saw nothing. A challenge means the customer was asked to confirm, usually with a biometric prompt in their banking app. An attempt means authentication was not available but the attempt was recorded, which in some cases still shifts liability. A rejection means the issuer refused to authenticate at all, and the payment should not be sent for authorization.

The number to watch is not the challenge rate on its own but the completion rate of challenges you do send. A challenge that lands in an app the customer has installed is usually completed in seconds. A challenge that falls back to a one-time code sent by text, on a phone number the bank has not updated, is where the abandonment is. If your challenge completion rate is low in one country, the cause is usually issuer behaviour in that country rather than anything in your checkout.

What it does to the approval rate

Authentication and authorization are separate decisions. Passing authentication does not oblige the issuer to approve the authorization, although an authenticated transaction is materially more likely to be approved because the issuer's own fraud risk is lower. Skipping authentication with an exemption keeps the checkout short but leaves the fraud liability with you, and a transaction sent without authentication data gives the issuer less to decide on.

The practical position for most merchants: request exemptions where they apply, authenticate where they do not, retry a soft decline through authentication rather than showing the customer an error, and measure the result per issuing country rather than in aggregate. An average hides the one market where the flow is broken.

What to ask your provider

• Which exemptions do you request on my behalf, and on what logic
• What is your measured fraud rate, and which TRA band does it put me in
• Do you automatically retry a soft decline through authentication, and does that retry count as a second transaction on my statement
• What proportion of my authentications are frictionless, by issuing country
• Do you support the in-app SDK flow as well as the browser flow
• Can I see the authentication result, the ECI and the exemption requested on each transaction in the dashboard, or only the final approval

A provider that cannot answer the last question is asking you to run your payments on faith. The data exists on every transaction; you should be able to see it.