# 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.

```text
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