Skip to main content
Learn how to identify payment errors and guide buyers toward the right next step. When a payment fails, Crossmint returns a normalized error category and code in the order's payment.failureReason. Use the category to understand the general cause and the code to determine how your integration should handle the error. You can review payment failures in the Orders section of the Crossmint Console. The tables below describe each error code, what it means, and the action you should present to the buyer.
Payment error codes describe why a payment attempt was declined. They are different from order status codes, which describe where an order is in its lifecycle (quote, payment, and delivery statuses). A declined payment usually returns the order to the awaiting-payment status so the buyer can retry.

The failureReason Object

category, retryPolicy, and message are present when Crossmint recognizes the decline. When a decline cannot be normalized, code is unknown (or the raw code when one is available) and only code and message are returned.
Never retry a declined payment automatically on the buyer's behalf, and gate any retry affordance on the order returning to the awaiting-payment status. Some declines are terminal and leave the order in a failed state.

Error Categories

Verification Errors

Category value: verification_error The payment could not be completed because a required verification or authentication step failed or was not completed. This includes 3DS authentication and validation of the card details, identity, billing information, or network connection. Most of these declines are resolved by the buyer correcting the information or completing the authentication step, so keep the buyer on the checkout and let them retry.

Transactional Limits

Category value: transactional_limits The payment exceeds a transaction or usage limit, such as the maximum amount, transaction count, or velocity threshold within a defined period. The limit may be set by Crossmint or by the buyer's bank. Do not retry automatically; the buyer can try again after the cooldown.

Policy Restrictions

Category value: policy_restrictions The payment violates a payment policy or restriction, such as regional availability, unsupported card types, or unsupported issuers. Depending on the code, the buyer may be able to complete the purchase with a different payment method.

Risk Blocks

Category value: risk_block Crossmint, a payment partner, or the buyer's bank blocked the payment because of a fraud or risk decision. These declines are intentionally generic: the message never reveals why the payment was flagged, and your integration should not attempt to infer or display a reason beyond the user-safe message. Do not retry automatically. Direct buyers who believe the block is a mistake to your support channel.

Authorization Declines

Category value: authorization_decline The buyer's financial institution declined the authorization attempt. Examples include insufficient funds, an unsupported currency, or an issuer-specific restriction. In most cases the buyer must contact their bank or use a different payment method; do not retry automatically.

Processing Errors

Category value: processing_error A technical or processing problem prevented the payment from completing. The failure was not caused by a risk decision or authorization decline, and a retry after a short delay usually succeeds.

See Also

Display Payment Error Messages

Surface the decline reason in Embedded Checkout, including after the Apple Pay or Google Pay sheet closes

Supporting Your Customers

What to collect from a buyer before escalating a checkout issue to Crossmint

Status Codes

Order, quote, payment, and delivery statuses, which are distinct from payment error codes

Pay with Card

The payment phase of the Headless Checkout order lifecycle, including handling declined payments

Get Order

REST endpoint that returns the order, including payment.failureReason

Webhooks

Receive order updates, including declines, server-side