Skip to main content
Two different failure points, both about turning a card into a usable token: Tokenization (bind) errors happen inside elements.submit() itself — the gateway rejects the bind call, and submit() rejects with an ElementsError whose code is the gateway’s problem+json type, verbatim. Charge-time token errors happen later, on your server’s purchase/authorize call, when a token that bound successfully has since expired.

Tokenization (bind) errors

From elements.submit()’s bind call — the gateway’s problem+json type, passed through as code verbatim. The gateway decides whether each error can be retried and the SDK passes that through as retryAllowed on the error — branch on it at runtime, and follow Merchant action below.
For the recovery pattern behind these, see Handle tokenization failures; for the bind-rate-limit and session-not-bindable cases specifically, see Prevent double submission.

Charge-time token errors

These come from your server’s purchase/authorize call, not from submit() — the token was valid at bind time but lapsed before you charged it. token:transient-expired and token:data-purged are defined once, on the Payments API — see Payment method errors: Tokens for the HTTP status and meaning. See Handle expired sessions and card tokens for the full recovery steps.

Next steps

Error object and handling

The ElementsError shape and the standard catch pattern.

SDK and integration errors

Codes thrown before you ever reach the bind call.

3D Secure errors

Codes from authenticate(), handle(), and resume().

Handle failures overview

Find the right recovery guide by symptom.
Last modified on September 15, 2026