worldpay 3DS challenge timed out waiting for the shopper

Not specified by the original author.

worldpay 3DS challenge timed out waiting for the shopper

TL;DR

The shopper never finished the 3DS challenge, so the payment has no authentication result. Treat it as incomplete, not failed: check the payment status, expire the attempt cleanly, and invite the customer to try again. Never assume the charge went through and never charge twice.

worldpay 3DS challenge timed out waiting for the shopper

Steps

1. Confirm the payment status with Worldpay: expect an incomplete or challenge-pending state. Success check: the gateway confirms no authorization happened.
2. Expire or cancel the timed-out attempt so it cannot complete late. Success check: the attempt is closed on the gateway side.
3. Tell the customer plainly: the verification step timed out and no charge was made, with a link to retry. Success check: the message rules out a mystery charge.
4. Create a fresh payment attempt for the retry; do not resurrect the timed-out one. Success check: the retry has its own attempt id tied to the same order.
5. If shopper timeouts spike, shorten your challenge prompt and surface the 3DS step clearly instead of burying it. Success check: timeout rate drops after the UX change.

When this applies

• A Worldpay 3DS challenge times out because the shopper never responds.
• The payment is stuck in a challenge-pending state.
• You need a safe retry path after a shopper timeout.

When it doesn't

• Issuer-side timeouts; those are gateway-to-bank failures.
• Shoppers failing the challenge; that is an authentication failure.
• 3DS configuration errors; those fail before any challenge renders.

Tool + version compatibility

Worldpay payments with 3D Secure (all current API versions).

"worldpay 3ds challenge expired"

Close the attempt and start a fresh one for the retry.

"worldpay shopper did not complete 3ds"

No authorization happened; invite the retry explicitly.

"worldpay 3ds timeout payment status"

Check status first; incomplete is not the same as declined.

Why it happens

3DS hands control to the shopper: approve the charge in their banking app or on the challenge page. Shoppers abandon, close tabs, or never see the prompt. Worldpay keeps the attempt open until it times out, and a timed-out challenge authorizes nothing. The risk is entirely on your side: assuming failure and double-charging, or assuming success and shipping unpaid goods.

Edge cases / pitfalls

• A timed-out attempt can occasionally complete late; expiring it first closes that window.
• Mobile shoppers time out more; test the challenge flow on a phone, not just desktop.
• Log challenge start, shopper action, and timeout separately; abandonment vs issuer failure need different fixes.
• Agent-built retry loops must wait for the timeout to be final before creating the next attempt.

Provenance

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

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

Thread query: worldpay 3DS challenge timed out waiting for the shopper

TL;DR: The shopper never finished the 3DS challenge, so the payment has no authentication result. Treat it as incomplete, not failed: check the payment status, expire the attempt cleanly, and invite the customer to try again. Never assume the charge went through and never charge twice.

Not specified by the original author.

checkout.com 3DS timeout: "y" timeout waiting for issuer response

TL;DR

The issuer never answered the 3DS challenge in time, so the payment is in an unknown state. Do not assume it failed and do not retry blindly. Poll the payment status, treat timeout as unknown until Checkout.com says otherwise, and only retry after confirming the original attempt did not succeed.

checkout.com 3DS timeout: "y" timeout waiting for issuer response

Steps

1. Treat the timed-out attempt as unknown, not failed. Success check: your code has an explicit unknown state, not a failure assumption.
2. Poll the payment by its id until Checkout.com reports a final status (authorized, declined, or expired). Success check: you have a definitive status from the gateway.
3. If the status stays unknown past your window, void or cancel the attempt before creating a new one. Success check: no two live attempts exist for the same order.
4. Retry the payment only after the original attempt is confirmed dead or voided. Success check: the retry uses a fresh attempt tied to the same order.
5. Set a customer-facing message that is honest: the bank did not respond in time, and you are checking the payment status. Success check: the customer is not charged twice or left guessing.

When this applies

• A Checkout.com 3DS challenge times out waiting for the issuer.
• The payment status is ambiguous after a challenge.
• You need retry logic that cannot double-charge.

When it doesn't

• Issuer declines or authentication failures; those are final states.
• 3DS configuration errors; those fail before any challenge.
• Gateway-wide outages; those are status-page events.

Tool + version compatibility

Checkout.com payments and 3D Secure flows (all current API versions).

"checkout.com 3ds challenge timeout"

Unknown state until the gateway reports final; poll before retrying.

"checkout.com issuer timeout 3d secure"

The issuer side hung; reconcile status before any retry.

"checkout.com 3ds y timeout"

The challenge result never arrived; treat as unknown, not declined.

Why it happens

3DS adds a round trip to the card issuer: challenge the shopper, wait for the issuer's verdict. Issuers sometimes never answer, and the gateway cannot invent a result, so the payment sits in limbo. The dangerous move is treating limbo as failure and charging again; the original attempt can still authorize later. Unknown must stay unknown until the gateway confirms it.

Edge cases / pitfalls

• Timeouts during high-traffic sales are common; have the unknown-state path tested before the sale, not during it.
• A second attempt with the same idempotency key is safe; a new key for the same order is how duplicates happen.
• Log the challenge start and every status poll; issuer timeouts are the hardest disputes to reconstruct.
• Some issuers answer minutes late; keep the poll window generous before voiding.

Provenance

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

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

Thread query: checkout.com 3DS timeout: "y" timeout waiting for issuer response

TL;DR: The issuer never answered the 3DS challenge in time, so the payment is in an unknown state. Do not assume it failed and do not retry blindly. Poll the payment status, treat timeout as unknown until Checkout.com says otherwise, and only retry after confirming the original attempt did not succeed.

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.