Skip to main content
Crossmint checkout exposes status codes for multiple aspects of the order. There is the top-level 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 time
  • valid — The quote is valid
  • expired — The quote has expired and needs to be refreshed
  • requires-recipient — The order is missing recipient information (email or wallet address)

Payment Statuses

  • draft — The order was created with state: "draft". It is a quote preview only: not persisted, and it cannot be polled or paid
  • requires-quote — The order is still in the quote phase
  • requires-crypto-payer-address — A crypto wallet address needs to be provided for the payment
  • requires-email — An email is required to proceed (typically for card payments or receipts)
  • requires-kyc — The buyer must complete KYC verification to proceed
  • manual-kyc — KYC requires manual review; the buyer will be notified of the outcome
  • failed-kyc — KYC verification failed and the buyer cannot proceed
  • crypto-payer-insufficient-funds — The specified payer address cannot cover the purchase
  • crypto-payer-insufficient-funds-for-gas — The payer address cannot cover the required network fees
  • awaiting-payment — Ready to submit the payment
  • in-progress — The payment is underway
  • completed — 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 real
  • awaiting-payment — Delivery not started because payment is not yet complete
  • in-progress — Delivery is being processed
  • failed — Delivery failed; affected items will be refunded automatically
  • completed — 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'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.
A card decline returns the order to 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