3DS2 for cross-border shops: friction, exemptions and where SCA applies

For a shop selling only inside Europe, 3-D Secure is a compliance question with a clear answer: authenticate unless an exemption applies. For a cross-border shop, the answer depends on the payment. A German card paying a merchant whose acquirer is in the EEA is inside the rules. The same card paying through an acquirer outside the EEA is not. A card issued in Kazakhstan or Saudi Arabia is outside them entirely. Treating all three the same either adds friction where nobody asked for it or skips authentication where issuers expect it.

This article explains how EMV 3-D Secure decides between a frictionless and a challenge flow, which data raises the frictionless share, where strong customer authentication applies, which exemptions a cross-border shop can use, what liability shift does and does not cover, and how to decide, segment by segment, when to request 3-D Secure. For the basic definitions, see our glossary entries on 3-D Secure, 3DS exemptions and strong customer authentication.

How does 3DS2 decide between frictionless and challenge?

The issuer decides. The merchant’s provider sends authentication data to the issuer’s access control server, and the issuer either authenticates silently or asks the customer to prove who they are. EMVCo describes the result for many transactions as consumers simply clicking buy and the payment being approved, with a challenge reserved for higher-risk purchases. Checkout.com’s documentation puts it in data terms: if the issuer has enough data it continues with a frictionless flow; if not, it requests more information through a challenge.

The merchant can state a preference but not force it. Stripe’s API, for example, lets a merchant request 3-D Secure with a preference for a frictionless or a challenge flow, and says it cannot guarantee the preference because the issuer determines the final flow. EMVCo recommends version 2.2 or higher for the best functionality.

What data raises the frictionless rate?

More of the right data. Checkout.com’s guidance on improving authentication performance says it strongly recommends sending as many address and contact fields as possible, and most of the cardholder account fields. The groups look like this:

Data group	Examples of fields	Why the issuer cares
Address and contact	Billing and shipping address, whether they match, mobile and email	Consistency with what the bank knows
Customer account with you	Account age, date of last change, password change, purchase count, transactions today and this year	A long, stable relationship looks like the real cardholder
Merchant risk	Delivery timeframe, delivery email for digital goods, reorder or preorder flags, gift card amounts	Context for what is being bought
Previous authentication	Reference and method of the customer’s last successful authentication	Evidence that this card was recently verified with you

Stripe adds that its browser and mobile SDKs collect basic device information during 3DS2 authentication and send it to the issuer for risk analysis. For a hosted checkout, most of the device data is collected for you. The account and order history is the part only the merchant can supply, and it is the part most often left empty.

Where does strong customer authentication apply?

In Europe, by law. Stripe’s SCA guide says the requirements apply to online card payments where both the business and the cardholder’s bank are in the European Economic Area. Its table lists two categories outside the scope:

• One-leg-out payments, where the acquirer or the issuer is outside the EEA.
• Merchant-initiated transactions, such as charges on a saved card when the customer is not in the checkout. The card must be authenticated when it is saved or on the first payment, and the bank can still decide that a later payment needs authentication.

Stripe’s overview names similar regulations in the UK, India, Japan and Australia that may require 3-D Secure. Checkout.com’s documentation says 3-D Secure is required in Europe for SCA and optional in other regions. For markets such as Turkey, Kazakhstan, the UAE, Brazil and Mexico, neither source lists a mandate, so check local rules and issuer practice with the acquirer in each market. Market practice can matter as much as law: for Saudi Arabia, Checkout.com recommends applying 3-D Secure to all card payments in the region, noting that most cards used there are debit cards.

Why issuers care even outside the mandate: the EBA and ECB’s December 2025 joint report on payment fraud found that card payment fraud was 17 times higher when the recipient was outside the EEA, where SCA is not legally required and often not used. A European issuer looking at an unauthenticated payment from a merchant abroad knows that statistic.

Which exemptions can a cross-border shop use?

Inside the PSD2 scope, the regulation allows the provider to ask the issuer to skip the challenge in defined cases. The thresholds below are as Stripe’s SCA guide sets them out.

Exemption or exclusion	Condition	Who asks	Fraud liability
Low value	Under EUR 30; authentication needed again after five exempted payments or EUR 100 in total since the last one	Acquirer or provider	Merchant
Transaction risk analysis	Up to EUR 100, 250 or 500 if the provider’s card fraud rate is below 0.13%, 0.06% or 0.01%	Acquirer or provider	Merchant
Recurring, same amount	Same amount to the same business; the first payment needs SCA	Provider	Merchant on exempted payments
Trusted beneficiary	Customer allowlists the merchant at their bank; Stripe says bank adoption has been slow	Issuer offers it	Merchant
Merchant-initiated	Customer not present; card authenticated when saved	Provider flags it	Merchant
One-leg-out	Issuer or acquirer outside the EEA	Not an exemption; outside scope	Merchant unless 3DS is used

The issuer always has the last word. Stripe’s flow, for example, attempts the charge when an exemption applies and, if the issuer answers with a soft decline asking for authentication, reattempts with 3-D Secure. Build that retry into your own flow, in the same session, so the customer sees one extra step rather than a failed payment. Our article on soft and hard declines lists the codes involved.

What does liability shift cover, and what not?

Checkout.com’s table summarises the rule: liability generally shifts to the issuer when a payment is successfully authenticated, and stays with the merchant when authentication cannot be attempted, fails, or an exemption is applied. Stripe’s documentation adds several limits worth knowing:

• Liability shift is never guaranteed for a specific payment or dispute. Network rules and the facts of the dispute decide.
• It covers fraud disputes. A dispute for goods not received follows the normal process.
• An inquiry on an authenticated payment must be answered, or the issuer can raise a no-reply chargeback that can invalidate the shift.
• Merchants in a card network fraud monitoring programme may lose the shift even on authenticated payments.

So an exemption is a trade: less friction in exchange for keeping the fraud risk. That is a good trade on a returning customer buying a EUR 25 item, and a poor one on a first-time customer buying a EUR 900 phone.

How do you decide when to request 3-D Secure?

Segment the traffic and decide per segment.

1. EEA card, EEA acquirer. Required unless exempt. Request exemptions for low-risk and low-value payments, and authenticate the rest.
2. EEA card, acquirer outside the EEA. Not required. Request 3-D Secure on first purchases, high amounts and anything your fraud screening marks as borderline, and watch issuer soft declines.
3. Cards from markets where local practice favours authentication, such as Saudi Arabia, following your acquirer’s advice. Authenticate by default.
4. Other markets. Start without authentication on returning customers with clean history and with it on first purchases, then compare approval, fraud and abandonment on each.
5. Saved cards. Authenticate when the card is saved, then flag later charges correctly as merchant-initiated or as customer-initiated with the saved card.

Measure authentication separately from authorization. A payment lost at the challenge is a checkout problem, not an issuer decline, and our guide on how to calculate approval rate shows why it should be counted apart.

Worked example: an EEA acquirer with customers further east

Example figures, for illustration only.

A merchant with an EEA acquirer takes 20,000 card payments a month: 8,000 from EEA cards and 12,000 from cards issued in Kazakhstan, Georgia and Turkey.

Policy	3DS requests	Challenges	Abandoned at challenge	Fraud liability on
3-D Secure on everything	20,000	6,000	600	Few payments
SCA where required, exemptions where allowed, none elsewhere	6,000	1,800	180	2,000 exempted EEA payments and 12,000 non-EEA payments
Targeted: SCA as required, plus first purchases and high amounts elsewhere	9,000	2,700	270	2,000 exempted EEA payments and 9,000 returning non-EEA payments

The first policy loses 600 payments a month at the challenge to protect payments that mostly did not need it. The second loses the fewest at the challenge but leaves every non-EEA payment unauthenticated, including first purchases where fraud concentrates. The third accepts 90 more abandoned payments than the second in exchange for liability shift on the riskiest 3,000. Whether that is right depends on the merchant’s fraud rate on first purchases, which is exactly the number to measure before choosing.

What are the common mistakes?

• Authenticating everything. It is simple and safe, and it pays for the safety with abandonment on payments that needed no challenge.
• Sending thin data. An authentication request without account history or shipping data invites a challenge.
• Not retrying after an exemption is refused. A soft decline asking for authentication is a request, not a refusal.
• Assuming one-leg-out means no 3DS. It means no legal requirement. Issuers can still decline.
• Treating exemptions as free. The fraud liability stays with the merchant.
• Losing the authentication when switching provider. If a payment cascades to another acquirer, check whether the authentication result can travel with it or a new challenge is needed.

How does Omno handle 3-D Secure?

3-D Secure and exemption requests are performed by the connected PSP. Omno’s hosted checkout handles the authentication step inside the same flow, and a pending authentication resolves to a final status by webhook. If a provider is unavailable or rejects the request, the payment moves to the next provider in the rule until one accepts. The routing-decision log records the response code for each attempt, including soft declines that ask for authentication. The hosted checkout page describes the flow.