- The challenge screen is not the biggest leak. In Forter's 2026 network data, rejected exemptions caused 27.8% of failures on genuine transactions, more than twice shopper abandonment.
- Issuers got stricter. Ravelin found frictionless rates fell in 28 of 37 countries. A 3DS review from 2024 is out of date.
- The issuer decides; you decide what they decide with. Data quality is the highest-return lever, and the 3DS Method step fails silently.
- Exemptions buy conversion with chargeback exposure. Measure the two together, and ask your PSP what its TRA ceiling really is.
- Cheapest wins first: device wallets on, soft declines retried with 3DS, UK and EU configured and monitored separately.
If you sell into the EU or UK and your payment step underperforms, the instinct is to blame the challenge screen: the one-time code, the banking app push, the moment a shopper gives up. That is a real loss, and it is not the biggest one.
Forter's 2026 PSD2 report, drawing on June 2026 network data, found that among authentication failures on transactions it had already approved as genuine, the single largest category was exemption rejection at 27.8%, ahead of issuer rejection at 15.6%, user abandonment at 12.6%, and technical failure at 11.5%. In other words, the most common way a known-good European customer fails to pay you is that you asked for an exemption and the issuer said no.
That reframes the problem. Most 3DS advice is about surviving the challenge. The larger opportunity is in not reaching one, and in understanding why the exemptions you request are being refused. This guide covers how the decision is actually made, how each exemption really works, the liability trade nobody prices properly, and what to measure.
First, something changed in 2026
A lot of 3DS guidance online was written in 2023 and 2024 and is now pointing the wrong way.
Ravelin's Global Payments Report 2026 found that overall 3DS success rates have risen slightly, while frictionless authentication declined in 28 of 37 countries, including across Europe. Issuer risk assessment is getting stricter, not looser. The data merchants send is being held to a higher standard than it was two years ago.
The practical consequence: an integration that produced an 85% frictionless rate in 2024 and has not been touched since is probably producing less today, and nobody will have noticed, because the loss appears as checkout abandonment rather than as a payment failure. If your last 3DS review predates 2025, treat its conclusions as expired.
How the frictionless-or-challenge decision is actually made
Worth being precise, because the merchant's role is smaller than most teams assume, and larger in the one place they ignore.
Under EMV 3DS, your checkout sends an authentication request to the issuer's Access Control Server (ACS). Where 3DS 1 sent a handful of data elements and challenged nearly everyone, EMV 3DS can send over a hundred: device characteristics, browser data, billing and shipping match, account age, transaction history, prior authentication references. The ACS scores that and returns either a frictionless approval or a challenge.
The issuer decides. You decide what they decide with. You cannot override a challenge. You can make one less likely by sending better data, by requesting an exemption, or by removing the transaction from scope entirely.
Three signals you do control:
- The data you send. The single largest lever, covered below.
- The 3DS Requestor Challenge Indicator, where you state a preference. In EMV 3DS 2.2 the values that matter most here are 05 (no challenge requested, transaction risk analysis already performed), 06 (no challenge requested, data share only), 07 (no challenge requested, SCA already performed, as in delegated authentication), 08 (no challenge requested, apply the trusted-beneficiary exemption if no challenge is needed) and 09 (challenge requested, and ask the issuer to offer the shopper whitelisting if it does challenge).
- Whether you request an exemption at all, and which one.
Hard-coding a single challenge preference across all traffic is the most common configuration mistake here. The right preference differs by transaction value, customer history, market and issuer.
The exemptions, and what each one really costs
All of these survive into PSD3 and the PSR in substantially the same form. What differs between them is who can invoke them, and who carries the fraud liability afterwards.
| Exemption | Threshold | Who requests | Practical note |
|---|---|---|---|
| Low value | Under €30 / £25, with a cumulative cap of €100 / £85 or five consecutive transactions | Merchant or PSP | Simple and reliable. The issuer holds the counter, so you cannot see how close a given card is to tripping it |
| Transaction Risk Analysis | Up to €500 by regulation, scaled to the requesting PSP's fraud rate (roughly 0.01% to 0.13%) | Acquirer or PSP, on its own fraud rate | The biggest driver of frictionless conversion in practice, and the most misunderstood (see below) |
| Trusted beneficiary | No value limit | Cardholder, via their issuer | You cannot add yourself. Worth prompting returning customers to whitelist you |
| Merchant-initiated | n/a | Merchant | Requires full SCA at mandate setup. PSD3 and the PSR tighten this |
| Recurring fixed amount | n/a | Merchant | SCA on the first payment only, provided amount and payee are unchanged |
| Secure corporate payments | n/a | Merchant | Lodged cards, virtual card numbers, dedicated B2B processes |
Three details cause more trouble than anything else on this list.
TRA qualifies on the requesting party's fraud rate, not yours. If your acquirer's overall card-fraud rate doesn't meet the threshold, you cannot use TRA, no matter how clean your own book is. Conversely, if your acquirer doesn't qualify but the issuer does, the issuer can still apply TRA on its own initiative. This single fact means acquirer choice is a conversion decision in Europe, not only a pricing one, and it is almost never evaluated that way.
Your PSP's ceiling is probably lower than the regulatory one. The regulation allows TRA up to €500. PSPs set their own, narrower limits: Stripe's published caps have been around £220 for the UK and Switzerland and €250 for EEA merchants. If your average order value sits above your PSP's cap and below the regulatory one, you are leaving frictionless transactions on the table for a reason that has nothing to do with the law. Ask your PSP what their cap actually is; most merchants never have.
Trusted beneficiary is the most underused. It has no value limit, it persists, and it is controlled entirely by the cardholder. The protocol already has a way to ask: challenge indicator 09 requests that the issuer offer whitelisting when it does challenge. Outside the protocol, nothing stops you asking a repeat customer, on the confirmation page, to add you to their bank's trusted list in their banking app. Almost nobody does either.
The liability trade nobody prices
This is the decision underneath the whole exercise, and it is routinely made by accident.
- Frictionless 3DS, no exemption requested: authentication succeeded, and fraud liability generally sits with the issuer.
- An exemption applied (on 3DS rails or authorisation rails): liability generally sits with you.
- Challenge completed successfully: liability sits with the issuer.
- No 3DS at all, out of scope: liability sits with you.
Scheme rules differ in the details, particularly for exemptions requested inside a 3DS message, so treat this as the general shape and confirm the specifics with your acquirer.
So exemptions buy conversion with chargeback exposure. That can be an excellent trade: on low-value, low-risk, returning-customer transactions it usually is. It is a poor trade on high-value first-time orders in a category with a fraud problem.
What makes this hard is that the trade is usually invisible. The exemption logic lives in a PSP dashboard someone configured once, the conversion benefit shows up in checkout metrics, and the chargeback cost shows up months later in a different team's report. Nobody computes the two together. If you do nothing else after reading this, compute them together for one quarter.
Data quality: the highest-return lever
If exemption rejection is the largest failure category, the obvious question is why issuers reject them. The answer is usually that they don't have enough to go on.
The data you send is widely described as the single biggest determinant of your frictionless rate. One summary of Visa's data-field mandate reports a roughly 57% frictionless-rate lift from providing the required fields. That is a third-party figure citing Visa, so treat the number as directional, but the direction is not disputed anywhere. Entersekt describes a merchant that had around 80% of its 3DS traffic challenged and, after improving data quality alone, moved roughly 80% of those transactions to frictionless approvals. A single anecdote, but a widely repeated pattern.
Industry benchmarks commonly put frictionless rates at 80 to 85% for merchants sending complete data, and above 80% is a reasonable practical line between a well-tuned integration and a neglected one. If you are materially below that, data quality is where to look first, before exemption strategy and before anything else.
What actually goes wrong:
The 3DS Method step gets skipped or broken. Before authentication, the ACS runs a device-fingerprinting step in a hidden iframe. If your Content Security Policy blocks it, if it times out, or if your checkout doesn't allow it the time, the issuer loses its best risk signal and leans towards a challenge. This fails silently.
Billing and shipping data arrive incomplete or unnormalised. Address mismatch is a strong challenge trigger. Truncated fields, missing postcodes, country codes in the wrong format: all of it degrades the score.
Cardholder account information is omitted. Account age, previous successful transactions, the date the shipping address was first used. These are optional fields that most integrations leave empty, and they are exactly what distinguishes a returning customer from a stranger.
In-app browsers strip the fields issuers need. This one is specific and costly. The browsers inside social apps can strip JavaScript fields that issuers rely on for frictionless approval, particularly on EU debit cards. A meaningful share of your social traffic may be landing in a degraded authentication path for reasons invisible in aggregate metrics. Native SDK implementations, or Custom Tabs and SFSafariViewController rather than an embedded webview, generally produce higher frictionless rates and lower challenge abandonment on mobile.
Soft declines: the money already in the room
When an issuer returns Mastercard code 65 or Visa code 1A, that is not a refusal to pay. It means SCA is required: the transaction was submitted without authentication and the issuer wants it authenticated.
The correct response is to run 3DS and resubmit. If your integration treats a soft decline as a hard decline and shows the shopper a failure message, you are discarding transactions the issuer was willing to approve. This is one of the most common and most recoverable faults we find, and it is invisible in a dashboard that reports a single "declines" number.
Check two things: that your gateway distinguishes soft declines in its response handling, and that the retry happens automatically rather than requiring the shopper to re-enter anything. If you are reviewing the integration itself, our payment gateway integration work starts with exactly this response handling.
Wallets are the cheapest exemption available
Apple Pay, and Google Pay with device-tokenised cards, carry multi-factor authentication inside the payment flow: device possession plus biometric or device unlock. That satisfies SCA through delegated authentication, so these transactions are frictionless by construction. One caveat: Google Pay credentials that are cards saved to a Google account rather than tokenised on the device can still need 3DS, so check how your gateway handles them.
For a merchant selling into Europe, enabling device wallets is the single highest-return change available in this entire article, and it is a configuration task rather than a project. If you are debating exemption waterfalls while Apple Pay is switched off, fix the ordering. Every major platform supports them, as our platform checkout comparison covers.
UK and EU are diverging, and it matters operationally
PSD3 and the PSR are EU law. They do not apply to UK-domiciled operators, though UK businesses serving EU customers must comply for those flows.
The UK operates under its own version of the SCA rules, supervised by the FCA, which broadly mirrors PSD2 and has its own forward programme: aligned in substance, diverging in specifics and timing. The low-value thresholds are already set in pounds rather than euros, and the gap will widen rather than narrow.
Practically: if you sell into both, you need two exemption configurations and two sets of monitoring, not one averaged over both. A single blended frictionless rate across UK and EEA traffic hides whichever side is broken.
PSD3 and PSR: what's coming
The agreed texts were published on 23 April 2026, and the European Parliament's ECON committee approved both in May 2026. Application is expected across 2026 and 2027, with implementation clocks running from entry into force. Unlike PSD2, the PSR is a regulation, so its SCA and fraud-liability provisions apply directly and simultaneously across all member states without national transposition, which should end some of the country-by-country inconsistency merchants currently work around.
What changes that affects a checkout:
- The core exemptions survive (low value, TRA, trusted beneficiary, MIT, secure corporate payments), with new EBA technical standards specifically governing exemptions and TRA.
- The list of SCA triggers expands beyond payments, to include creating or replacing a tokenised payment instrument, changing spending limits, and amending contact details.
- MIT mandates require full SCA at setup. If your subscription or saved-card flows cut corners here, that is a remediation item.
- No SCA method may depend on a single device or technology unless the user has agreed. Flows that assume a smartphone need a fallback.
- Two inherence elements can satisfy SCA in place of two separate categories, where independence can be demonstrated.
- SCA delegation counts as outsourcing under DORA, which brings contractual and governance obligations if you delegate authentication.
None of this changes 3DS 2 as the mechanism. The protocol is not being replaced.
What to measure
Most teams monitor a single authorisation rate, which is why these problems persist. The minimum useful dashboard:
- Frictionless rate
- Challenge rate
- Challenge completion rate and median challenge duration
- Exemption request rate and exemption approval rate: the largest failure category, and the one almost nobody tracks
- Soft decline volume and retry success rate
- Authorisation rate after successful authentication
- Chargeback rate split by exemption-applied versus issuer-liable
Segment all of it by issuer BIN, country, device and channel. Some banks challenge the large majority of transactions regardless of what you send, and you cannot fix that, but you can see it, and you can stop attributing it to your own configuration. Without segmentation, a Germany-wide challenge spike hides inside a global average for days.
The same discipline applies on the analytics side: if your checkout funnel events don't distinguish a payment failure from an abandoned payment step, the 3DS loss is invisible there too.
One more operational note: challenge rates move when issuers change their rules, not only when you deploy. Correlate spikes with your gateway's release notes before you go looking through your own commits.
Symptom to cause
Where to look first for the 3DS failures that come up most often.
| Symptom | Likely cause | First check |
|---|---|---|
| Low frictionless rate, all issuers | Incomplete authentication data | Which optional fields are empty; whether 3DS Method completes |
| Low frictionless rate, mobile only | In-app browser or webview stripping fields | Native SDK or Custom Tab vs embedded webview |
| High exemption rejection | Wrong exemption requested, or acquirer doesn't qualify for TRA | Acquirer's fraud rate; PSP's TRA ceiling |
| Declines that look final | Soft declines (65 / 1A) treated as hard | Gateway response handling and retry logic |
| Abandonment in one market | Issuer authentication method or out-of-band timeout | Segment by BIN; median challenge duration |
| Sudden challenge-rate spike | Issuer rule change | Gateway release notes before your own deploys |
| Fine in testing, failing live | CSP blocking the ACS or 3DS Method iframe | Browser console on a real device, real card |
Find out where your authentication is actually leaking
Every number in this article is one you can only see from inside: your frictionless rate by issuer, your exemption approval rate, whether your soft declines are being retried, whether the 3DS Method step completes on a real device in a real market. None of it is visible from outside, and most of it isn't in a standard PSP dashboard either.
If you'd rather start yourself, the checkout audit checklist includes the payment and 3DS checks we run, published in full. If you are weighing outside help, our guide to who to hire for checkout optimization compares the options honestly.
Sources
The Forter and Ravelin figures are vendor network data: they are the only parties with network-level visibility, and each figure is attributed by name and date in the text. Regulatory dates and PSP limits change; this page is re-verified every quarter.
- Forter: PSD2 Report 2026 (network data, June 2026)
- Ravelin: Global Payments Report 2026, as reported in analysis of declining frictionless rates
- GPayments: 3D Secure and PSD2 SCA: a guide for European and UK PSPs (2026)
- Freshfields: PSD3/PSR: what the EU's new payments rules mean
- Stripe: Strong Customer Authentication guide
- Checkout.com: SCA compliance documentation
This article is general information, not legal or compliance advice. Checkout Experts is a checkout optimisation agency, not a payment provider. Regulatory texts, scheme rules and PSP limits change often: this page was last reviewed October 2, 2026 and is re-verified every quarter.
