order.phase, and then sub-statuses for quote, payment, and delivery. Use them to build UIs that inform buyers where their order is in the payment and delivery process.
Quote Statuses
item-unavailable— No items in the order are available for purchase at the current timevalid— The quote is validexpired— The quote has expired and needs to be refreshedrequires-recipient— The order is missing recipient information (email or wallet address)
Payment Statuses
draft— The order was created withstate: "draft". It is a quote preview only: not persisted, and it cannot be polled or paidrequires-quote— The order is still in the quote phaserequires-crypto-payer-address— A crypto wallet address needs to be provided for the paymentrequires-email— An email is required to proceed (typically for card payments or receipts)requires-kyc— The buyer must complete KYC verification to proceedmanual-kyc— KYC requires manual review; the buyer will be notified of the outcomefailed-kyc— KYC verification failed and the buyer cannot proceedcrypto-payer-insufficient-funds— The specified payer address cannot cover the purchasecrypto-payer-insufficient-funds-for-gas— The payer address cannot cover the required network feesawaiting-payment— Ready to submit the paymentin-progress— The payment is underwaycompleted— Payment completed; the order proceeds to delivery/completion
When a card payment is declined, the order also carries a
payment.failureReason object with a normalized error
code, category, and retry policy — see the Payment Error Codes section below.Delivery Statuses
draft— The order is a draft (state: "draft"); nothing will be delivered until the order is created for realawaiting-payment— Delivery not started because payment is not yet completein-progress— Delivery is being processedfailed— Delivery failed; affected items will be refunded automaticallycompleted— Delivery completed successfully
Payment Error Codes
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'spayment.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.
awaiting-payment regardless of the decline code, so the order status only tells you that the order can still accept a payment. Use retryPolicy to decide whether to offer a retry: an order can be awaiting-payment with retryPolicy: "do_not_retry" (for example psp_security_block), which means the order is open but you should not offer a retry. Never retry a declined payment automatically on the buyer's behalf.
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
Handle Errors
Surface decline reasons and delivery failures in your checkout UI
Track Orders
Poll order status or receive webhook events

