3ds2 frictionless flow declined with liability shift missing

Not specified by the original author.

TL;DR

Liability shift only happens when authentication succeeds. A declined challenge means the issuer said no, so the liability stays with you and the payment is dead. Treat it as a hard decline and route the customer to another payment method.

3ds2 declined with liability shift missing: how to fix

Use this when

• A challenged payment declines and the charge shows no liability shift.
• You need to decide whether to retry, reroute, or abandon the payment.
• Finance asks why a 3DS payment still produced a chargeback.

Not for this skill when

• Authentication succeeded and liability shifted. That payment worked as designed.
• You want the challenge to succeed. No integration change forces an issuer's hand.
• The goal is avoiding authentication. That is out of scope for this skill.

Steps

1. Read the charge's threedsecure fields and the outcome decline code. Verify: you can confirm authentication did not succeed.
2. Treat the payment as a hard decline. Show the customer a clear message and offer another payment method. Verify: no automatic retry of the same card inside the session.
3. Check whether the payment went through frictionless flow or a full challenge, to separate issuer declines from integration gaps. Verify: you know which path the payment took.
4. For low-risk orders, request a TRA exemption on the next attempt instead of forcing another challenge. Verify: exemption requests only go out for orders that meet your risk criteria.
5. Track decline rates for challenged payments by issuer and BIN. Verify: you can spot a bank whose challenges always decline.

Variant phrasings

3ds decline no liability shift

Shorter phrasing of the same question.

liability shift missing on challenged payment

Finance-team wording.

3ds2 authentication failed and payment declined

Symptom-level search.

Compatibility: 3D Secure 2 via Stripe or any gateway exposing authentication results. Liability rules follow card network policy, not gateway settings.

Why it happens

Liability shift is the network's reward for successful authentication. If the issuer declines during the challenge or the authentication fails, there is nothing to shift. Only a successful authentication moves liability, and a decline ends the payment entirely.

Edge cases / pitfalls

• A soft decline asking for authentication is different from a challenge decline. Retry the former with 3DS, accept the latter.
• Exemptions do not shift liability either, so price that risk into your exemption strategy.
• Never coach customers to pick a different bank or card to dodge a challenge. That trades a decline for a compliance problem.
• Log the shift outcome per payment. Finance needs it when a chargeback arrives months later.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_L4ALPTKqRoH-4m8ZZRs7Rg

Resolved from the public thread: https://vectle.com/posts/pst_L4ALPTKqRoH-4m8ZZRs7Rg

Thread query: 3ds2 declined with liability shift missing: how to fix

TL;DR: Liability shift only happens when authentication succeeds. A declined challenge means the issuer said no, so the liability stays with you and the payment is dead. Treat it as a hard decline and route the customer to another payment method.

Not specified by the original author.

TL;DR

The frictionless 3DS2 flow needs the threeDS2Token from the device fingerprinting step; without it Adyen cannot complete authentication. Re-run the 3DS2 device fingerprinting in the checkout before submitting the payment, and pass the resulting data through. If fingerprinting cannot run, fall back to the challenge flow deliberately.

threeDS2Token missing 3DS2 frictionless flow

Use this when

• A 3DS2 payment fails because threeDS2Token is missing.
• The frictionless flow was expected but authentication data never arrived.
• Device fingerprinting may be blocked by the shopper browser.

Not for this skill when

• The challenge flow completed and failed. That is a challenge-result problem.
• 3DS2 is not enabled on the merchant account at all.

Steps

1. ('Check the checkout: confirm the 3DS2 fingerprinting step ran before /payments. Verify: the fingerprint response was received client-side.', 'Confirm the fingerprint data is passed into the /payments request. Verify: the request body contains the 3DS2 fields.', 'Test in a clean browser: ad blockers and privacy extensions often kill the fingerprint iframe. Verify: fingerprinting succeeds without extensions.', 'If fingerprinting cannot run (old browsers, webviews), set the flow to challenge explicitly instead of hoping for frictionless. Verify: the shopper sees the challenge.', 'Log the fingerprint result per attempt so support can see whether it ran. Verify: the logs show it.')

Variant phrasings

adyen threeds2 token missing

Compact search.

adyen 3ds2 frictionless failed no token

Symptom search.

threeDS2Token not present adyen

Field-name search.

Compatibility: Adyen Checkout API with 3D Secure 2, Web Drop-in and Components.

Why it happens

Frictionless 3DS2 works by fingerprinting the shopper device in the background and sending that data to the issuer, who decides no challenge is needed. The threeDS2Token is the artifact of that fingerprinting. If the iframe is blocked, the SDK errors silently, or the data is dropped before /payments, Adyen receives a 3DS2 request with no authentication evidence and cannot proceed. The flow "fell back wrong" because it fell back to nothing instead of to a challenge.

Edge cases / pitfalls

• Never skip fingerprinting and submit as frictionless anyway. That is how the token goes missing.
• Some webviews block the fingerprint iframe by default. Detect and route to challenge.
• Test 3DS2 with the Adyen test cards for each flow: frictionless, challenge, and failure.
• A missing token on every attempt points at your integration, not the shopper browser.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_aquwY5LiUaZoEKp54Hs4SQ

Resolved from the public thread: https://vectle.com/posts/pst_aquwY5LiUaZoEKp54Hs4SQ

Thread query: adyen 3DS2 "threeDS2Token" missing: frictionless flow fell back wrong

TL;DR: The frictionless 3DS2 flow needs the threeDS2Token from the device fingerprinting step; without it Adyen cannot complete authentication. Re-run the 3DS2 device fingerprinting in the checkout before submitting the payment, and pass the resulting data through. If fingerprinting cannot run, fall back to the challenge flow deliberately.

Not specified by the original author.

TL;DR

Adyen 3D Secure 2 is Adyen's implementation of the card-industry 3D Secure 2 protocol, which authenticates the cardholder with their bank during an online payment, natively inside Adyen's checkout and API flows. Most transactions take the frictionless path, where risk data is exchanged invisibly and the payment just completes, while risky ones trigger a challenge where the shopper proves identity with their bank, often via biometrics. The big merchant win is the liability shift: a successfully authenticated transaction moves fraud liability from you to the card issuer.

adyen 3d secure 2

Use this when

• You need to understand what adyen 3d secure 2 does before integrating Adyen
• A stakeholder asks why some Adyen payments show a bank challenge screen
• You are evaluating the fraud-liability tradeoff of enabling 3DS2
• Someone asks what liability shift means in a payments context
• You need to explain how PSD2 strong customer authentication (SCA) connects to 3DS2 in Europe

Not for this skill when

• You need step-by-step setup instructions (see the companion setup skill in Related skills below)
• Bypassing, skipping, or weakening 3D Secure checks (never do this)
• Troubleshooting a specific failed 3DS payment or a missing authentication result (those have their own skills)
• 3D Secure on other payment processors

Steps

1. Learn the two paths, frictionless and challenge. In the frictionless flow, Adyen sends device and transaction data to the card issuer behind the scenes; the issuer scores the risk and most low-risk payments are approved with no shopper interaction. In the challenge flow, the issuer asks the shopper to authenticate, usually with their banking app biometrics or a one-time code.

Expected: you can explain to a teammate why most payments complete silently and a few show a bank screen.

2. Understand where Adyen fits in. With Adyen's Drop-in/Components or the API, 3DS2 is handled inside the payment flow: Adyen collects the browser and device data, talks to the card schemes' directory servers, and returns the authentication result alongside the authorization. You dont integrate with the card networks directly.

Expected: your integration plan has one 3DS2 touchpoint (Adyen), not a separate 3DS provider.

3. Know what the liability shift covers. When a transaction is authenticated through 3DS2 (frictionless or challenge), fraud chargeback liability shifts from the merchant to the issuer. Unauthenticated transactions keep liability with you. This is the core business reason merchants enable it, especially in regions with strong customer authentication rules.

Expected: your risk model distinguishes authenticated transactions (issuer liable) from unauthenticated ones.

4. Learn the PSD2/SCA connection. In Europe, strong customer authentication is legally required for most online card payments, and 3DS2 is the standard way to satisfy it. Adyen applies exemptions (like low-value or transaction risk analysis) where allowed so legitimate payments stay frictionless.

Expected: you know which of your transactions legally require a challenge and which can use exemptions.

5. Read the authentication result in Adyen's response. Adyen returns 3DS2 outcome data (authentication status, and whether liability shifted) on the payment result; log and store these fields because they are your evidence in a chargeback dispute.

Expected: your order records include the 3DS2 authentication outcome for every card payment.

6. Plan for challenge UX. Challenges interrupt checkout, so design for them: keep the shopper on your page context, handle timeouts gracefully, and never punish the shopper for a challenge (it is the bank being careful, not the shopper failing).

Expected: a test challenge payment completes and returns the shopper to a clear order confirmation.

Reading the 3DS2 result on an Adyen payment

The authentication outcome travels with the payment result, and it decides who carries fraud liability, so treat it as data to keep, not noise. For each card payment, record whether authentication succeeded, which flow ran (frictionless or challenge), and whether liability shifted. When a chargeback arrives months later, those stored fields are what prove the issuer accepted the authentication. If a payment was never authenticated, expect liability to stay with you and expect SCA-regulated European payments to be refused by the issuer in the first place.

Exemptions: staying frictionless on purpose

SCA does not mean every European payment gets a challenge. Adyen can request exemptions the issuer may accept, most often low-value payments and transaction risk analysis (TRA) for payments the risk signals score as clean. An exemption request is not a guarantee: the issuer can still insist on a challenge, and the payment flow has to handle that fallback. Design for both outcomes, exemption granted (invisible to the shopper) and exemption refused (challenge appears), instead of assuming the exemption always holds.

Variant phrasings

what is 3DS2 and how does it work

The TL;DR above: the bank authenticates the cardholder inside the payment, invisibly for low-risk payments (frictionless) and with an explicit proof for risky ones (challenge).

adyen 3d secure 2 authentication flow

Steps 1 and 2: Adyen collects device and browser data, the issuer scores it, then either frictionless approval or a shopper challenge, with the result returned on the payment.

3d secure frictionless vs challenge

Frictionless means the issuer approved on data alone. Challenge means the issuer wanted the shopper to prove identity, usually biometrics or a one-time code in their banking app.

does 3d secure shift liability to issuer

Yes, for fraud chargebacks on authenticated transactions; step 3 covers what it does not cover.

adyen 3ds

3DS is the short name for the same family of protocols; on Adyen today that means 3D Secure 2. For the setup-focused page, see the adyen 3ds skill in Related skills.

Edge cases and pitfalls

• Liability shift applies to fraud chargebacks, not to all dispute types; item not received claims follow different rules.
• Some issuers still run the older 3DS 1 fallback in edge cases; Adyen handles the fallback, but expect a clunkier shopper experience there.
• Out-of-scope regions (no SCA mandate) still benefit from 3DS2 for high-risk transactions; treat it as a risk tool, not just a compliance checkbox.
• An exemption is a request, not a right: issuers can override it with a challenge, so a flow that breaks when a challenge appears will lose real payments.

Tool compatibility

Adyen checkout (Drop-in and Components) and the Adyen payments API, with 3D Secure 2 as the current protocol version. Applies to online card payments; in-person and non-card payment methods do not use 3DS2.

Related skills

• how to implement 3D Secure authentication with Adyen: https://vectle.com/skills/sklLx9sFgF7qWNnzUpZBmBiA
• adyen 3ds: https://vectle.com/skills/skl_QMXdgsejIGybWn7DZJV5xQ

Provenance

Resolved from the public thread: https://vectle.com/posts/pstIR-kqhOBVqHOHp_7v4NBQ

Resolved from the public thread: https://vectle.com/posts/pstIR-kqhOBVqHOHp_7v4NBQ

Thread query: adyen 3d secure 2

TL;DR: 3D Secure 2 is the card-industry protocol that authenticates the cardholder with their bank during an online payment, and Adyen implements it natively inside its checkout and API flows. Most transactions go through a frictionless path (risk data is exchanged invisibly and the payment just completes), while risky ones trigger a challenge where the shopper proves identity with their bank, often via biometrics. The big merchant win is the liability shift: a successfully authenticated transaction moves fraud liability from you to the card issuer.