A 3D Secure check that runs does not always move a fraud chargeback off your books. The liability follows the specific result the card issuer returns, and Stripe, Adyen and Braintree each report that result in a different field. Stripe lists 3D Secure as optional outside markets such as the EEA, the UK, India, Japan and Australia, where strong-authentication rules can require it, so for a US merchant the liability shift is usually the reason to use it.
This guide maps those fields side by side, from provider documentation checked November 12, 2026.
What the liability shift covers
When a payment is successfully authenticated with 3D Secure and the cardholder later disputes it as fraud, the liability typically moves from the merchant to the card issuer. Stripe states the limits plainly: you can expect the shift for eligible fraud disputes on authenticated payments, but it is not guaranteed for any specific payment.
Three limits matter in practice:
- Only fraud disputes. A dispute for another reason, such as goods not received, goes through the normal dispute process whatever the 3D Secure result.
- Some merchants are carved out. Stripe notes that a business enrolled in a card network’s fraud monitoring program may lose the shift, and that Visa does not support it for wire transfers or money orders, non-financial institutions offering foreign or non-fiat currency, or stored-value card purchases and loads.
- Inquiries still need answers. If the issuer sends a request for information on an authenticated payment and you do not respond, the bank can open a “no-reply” chargeback that, according to Stripe, could invalidate the shift.
Early fraud warnings also keep arriving on authenticated payments, and Stripe’s fraud prevention guide says they can still count against card-brand monitoring programs.
Which results shift liability
The table lines up Stripe’s payment_method_details.card.three_d_secure.result on the Charge with Braintree’s 3D Secure status codes. The liability column follows each provider’s own description.
| What happened | Stripe result | Braintree status | Fraud liability |
|---|---|---|---|
| Issuer authenticated the cardholder, with or without a prompt | authenticated | authenticate_successful | Moves to the issuer (expected, not guaranteed) |
| Issuer not set up or down; the card network proved the attempt | attempt_acknowledged | authenticate_attempt_successful | Usually moves to the issuer |
| Issuer granted an exemption (low value, low risk) | exempted | exemption_low_value_successful, exemption_tra_successful | Stays with you |
| Data shared with the issuer, no authentication requested | data_share_only | data_only_successful | Stays with you |
| Card cannot run 3D Secure | not_supported | lookup_not_enrolled | Generally stays with you |
| Customer failed the check | failed | authenticate_failed | Stays with you; do not charge |
| Issuer’s 3D Secure system errored, no proof of attempt | processing_error | authenticate_error, lookup_error | Stays with you |
Braintree’s status table marks only authenticate_successful and authenticate_attempt_successful with liabilityShifted: true. Stripe’s Charge object reference says an attempt_acknowledged result qualifies for the shift “in most cases” and that not_supported and processing_error generally do not shift it.
Adyen reports the outcome differently. Its payment responses carry additionalData.liabilityShift, which Adyen’s API schema defines as whether a liability shift was offered, and threeDAuthenticated. The raw issuer result is the transStatus in threeDS2Result: Y for successful, A for attempted, N for not authenticated, U when authentication could not be performed and R for rejected.
Exemptions trade the challenge for the liability
An exemption removes friction and removes cover at the same time. Stripe’s SCA exemptions page says liability shift does not apply once the issuer approves an exemption, and that marking a payment as merchant-initiated produces neither a customer challenge nor a liability shift. Its Data Only flow sends no authentication request to the issuer, so it shifts nothing either. Our explainer on merchant-initiated transactions covers how those later charges are set up.
The electronic commerce indicator (ECI) shows the same split at the network level. Checkout.com’s 3D Secure documentation lists ECI 05 (02 for Mastercard) for a successful authentication that shifts liability and ECI 07 (06 for Mastercard) for an applied exemption, where liability stays with the merchant. Stripe exposes the value as electronic_commerce_indicator on the same 3D Secure object.
How each API asks for 3D Secure and pauses
Stripe. By default Radar decides when to request 3D Secure. To force it, set payment_method_options[card][request_three_d_secure] to any (prefer a frictionless flow) or challenge (prefer a prompt) when creating or confirming a PaymentIntent or SetupIntent. The issuer still picks the final flow, and Stripe says its API cannot turn 3D Secure off. A payment that needs the customer moves to requires_action, with the redirect or modal details in next_action. The flow that actually ran appears as authentication_flow: frictionless or challenge.
Adyen. Dynamic 3D Secure rules decide by default. authenticationData.attemptAuthentication set to always or never overrides them, and Adyen recommends against using it; with never, a payment that regulation requires to be authenticated is declined. A /payments response with resultCode IdentifyShopper asks for a device fingerprint, ChallengeShopper for a challenge and RedirectShopper for a redirect. The result then goes to /payments/details. Adyen’s result codes page warns that a payment’s status can change after you get the code, so order records should follow webhooks instead.
Braintree. The client SDK runs the lookup and returns a new nonce carrying the 3D Secure result. When a transaction uses that nonce, options.threeDSecure.required defaults to true, and a payment without a successful authentication is gateway rejected with the reason “3D Secure”. Braintree recommends leaving that default on, because it blocks a tampered front end from skipping the check. The client reference also says threeDSecureInfo values in the browser are for convenience only; read them on the server before deciding.
A decision rule you can code
Route the order on the result, not on whether the customer saw a prompt:
authenticated/authenticate_successful/Y: fulfill. Store the ECI and the directory server transaction ID with the order for dispute evidence.attempt_acknowledged/authenticate_attempt_successful/A: fulfill in most cases, and record it separately so dispute forecasts do not treat it as full authentication.- Exempted, data-only or merchant-initiated: fulfill if your own risk check passes, but book any fraud loss as yours.
- Failed or rejected: do not retry the same card in the background. Ask for another payment method.
- Unsupported or errored: a risk decision. On Braintree with
required: true, the gateway makes it for you.
Whatever the result, answer every issuer inquiry. Our guide to chargeback API disputes shows where those events and deadlines appear, and payment decline codes covers the soft decline that asks for 3D Secure on a retry. Provider versions change; the payment API changelog tracker lists current versions for each provider.
