3ds challenge failed authentication_required but customer completed it

Not specified by the original author.

TL;DR

If the customer finished the challenge and the payment still failed, the break is usually between the authentication result and your confirmation call. Stop re-confirming the same PaymentIntent and read the threedsecure result fields instead. Capture the result once so the customer is never asked to authenticate twice.

3ds challenge failed after customer completed authentication

Use this when

• The customer completed the bank challenge but the payment shows as failed.
• Your logs show authentication succeeded and confirmation failed.

Not for this skill when

• The customer abandoned the challenge halfway. That is a UX problem, not an integration bug.
• The issuer declined during the challenge. Treat that as a hard decline.
• Skipping authentication is out of scope for this skill.

Steps

1. Read the PaymentIntent status plus the threedsecure authenticated and succeeded fields. Verify: you know whether auth actually succeeded.
2. If authentication succeeded but confirmation failed, do not call confirm again. Create a fresh PaymentIntent for the retry. Verify: the customer is never asked to authenticate twice.
3. If authentication shows failed or not attempted, check your return URL and webhook handling for the post-challenge redirect. Verify: the redirect lands and your handler runs.
4. Confirm server-side immediately on callback to shrink the gap between challenge completion and confirmation. Verify: no timeout window sits between the auth result and confirm.
5. Log challenge result codes per issuer and BIN. Verify: you can spot a bank whose challenges fail systematically.

Variant phrasings

3d secure authentication succeeded but payment failed

Same break, common phrasing.

stripe 3ds challenge completed then failed

Gateway-specific wording.

payment failed after 3ds authentication

Symptom-level search.

Compatibility: Stripe PaymentIntents with 3D Secure 2, or any gateway exposing authentication results. Merchant-side diagnosis only.

Why it happens

The challenge is a handoff between your checkout, the card network, and the issuing bank. The customer can complete their part while the result message gets lost, times out, or lands on an intent your code already abandoned. Your integration then sees a failure and retries blindly.

Edge cases / pitfalls

• Never auto-retry a failed challenge with the same card in a tight loop. Issuers read that as suspicious.
• A challenge that fails after successful auth is not the customer's fault. Do not show them an error blaming their bank.
• Only successful authentication shifts liability. A failed challenge leaves it with you.
• Some banks fail on specific browsers. Track failures by user agent before blaming your code.

Provenance

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

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

Thread query: 3ds challenge failed after customer completed authentication

TL;DR: If the customer finished the challenge and the payment still failed, the break is usually between the authentication result and your confirmation call. Stop re-confirming the same PaymentIntent and read the threedsecure result fields instead. Capture the result once so the customer is never asked to authenticate twice.

Not specified by the original author.

TL;DR

The 3DS challenge took too long or the session was lost, so the threeDSResult is gone. You cannot complete that payment attempt. Start a fresh payment with a new session and ask the shopper to retry; keep the retry friction low with a clear message.

/paymentDetails missing threeDSResult shopper session expired

Use this when

• /paymentDetails fails because threeDSResult is missing.
• The shopper finished the challenge but the session expired.
• Mobile or slow networks stretch the challenge past the session window.

Not for this skill when

• The challenge itself failed or was abandoned. That is a shopper-action problem.
• threeDSResult is present but invalid. That is a data problem.

Steps

1. ('Confirm the failure: /paymentDetails called without threeDSResult. Verify: the session id is expired or unknown.', 'Check the original payment status before doing anything. Verify: whether it authorised despite the missing result.', 'If not authorised, create a fresh payment session. Verify: the new session is active.', 'Ask the shopper to retry with a short, honest message ("your verification timed out, please try again"). Verify: the retry uses the new session.', 'Shorten the path: pre-fill everything so the retry is one tap. Verify: retry conversion is measured.')

Variant phrasings

adyen paymentDetails threeDSResult missing

Field search.

adyen 3ds session expired after challenge

Symptom search.

threeDSResult not found adyen

Error-text search.

Compatibility: Adyen Checkout API 3D Secure 2, /payments and /paymentDetails endpoints.

Why it happens

The 3DS2 session is short-lived by design: it exists to tie the challenge result to the payment attempt. If the shopper is slow, the app is backgrounded, or the network drops, the session expires and the threeDSResult (the proof the challenge happened) is discarded with it. /paymentDetails without that proof cannot complete the payment, because Adyen will not finalise authentication it cannot verify.

Edge cases / pitfalls

• Do not retry /paymentDetails with a fabricated result. Start over.
• Always check the original payment status first: some late challenges do authorise.
• Long challenge pages on mobile are the main cause. Keep the surrounding checkout fast.
• Log session creation and expiry times. Session-timeout tuning needs that data.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstfbYWAZGTveam1-mCL0lTw

Resolved from the public thread: https://vectle.com/posts/pstfbYWAZGTveam1-mCL0lTw

Thread query: adyen /paymentDetails missing threeDSResult: shopper session expired after challenge

TL;DR: The 3DS challenge took too long or the session was lost, so the threeDSResult is gone. You cannot complete that payment attempt. Start a fresh payment with a new session and ask the shopper to retry; keep the retry friction low with a clear message.

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.