How a crypto payment moves from checkout to an order status update in the store

By Katerina V., payments content, covering crypto processing for iGaming and eCommerce operators.

A crypto checkout payment goes through several stages: first the transaction is confirmed on the blockchain, then the provider marks the payment as received, and only after that should the store's system update the order status. These events are connected, but they do not happen automatically, so it is possible for the money to have already arrived while the order still shows as unpaid.

This article looks at the path of a crypto payment from checkout to order update and explains where errors most often occur.

Crypto checkout links the payment to a specific order

Crypto checkout is not just a wallet address. The provider creates a separate payment request with an amount, a network, an expiry time and its own status: this is a standard pattern, for example, Coinbase Commerce's checkout object explicitly stores the amount, currency/network and expiresAt in ISO 8601 format, and generates a separate checkout.payment.expired event once the time runs out (Coinbase Developer Docs, «Creates a charge», 2026).

At the same time, the store has a separate order with its own status. These two entities need to be linked to each other.

The key rule: payment status and order status are not the same thing. Their synchronisation needs to be set up in the integration.

Payment goes through three different stages

These events usually happen one after another, but each one is handled by a separate system. So a confirmed transaction does not by itself mean the order has automatically moved to processing.

The order should be updated by a server-side event, not by a redirect

After paying, the buyer can be redirected to a "Payment successful" page. But the redirect itself does not confirm that the store has received and processed the payment information: the buyer might close the tab, lose their connection, or not return to the site. The Baymard Institute, in its checkout UX research, explicitly advises against relying on a redirect to an external payment page as the source of truth for status, this weakens both conversion and confirmation reliability (Baymard Institute, «E-Commerce Cart & Checkout Usability Research», 2026).

So it is better to update the order status on the backend after an event from the crypto provider, rather than after the success page opens.

The path of a crypto payment from checkout to order goes through ten steps

A reliable integration needs to account for errors at every stage, not just the ideal scenario.

Checkout is better created on the backend

The most reliable setup is when the store's backend creates the checkout through the API and saves the link between the order and the payment request in advance.

The main advantage of a backend integration is that the amount and order ID are saved before payment even happens. This lets the store unambiguously determine which order a received transaction belongs to.

Blockchain adds extra payment statuses

After cryptocurrency is sent, the transaction does not always become final right away. First it lands on the network, then it receives confirmations. The number of confirmations needed depends on the specific blockchain and the provider's rules.

For stablecoins, choosing the right network also matters. USDT is issued simultaneously on TRON, Ethereum, Solana, BNB Smart Chain, TON and several other networks (Tether.io, «Tether to Wind Down USD₮ Support for Five Legacy Blockchains», 2025). If the store supports one network and the buyer sends funds through another, the transaction may go through on the blockchain, but not be counted as a payment.

On top of that, the checkout needs to account for several standard situations:

• underpayment, the buyer sent less than the required amount;
• overpayment, they sent more;
• late payment, they sent it after the checkout expired;
• wrong network, they chose an unsupported network.

Because of this, "paid / not paid" logic is too simple for a crypto checkout.

Webhook links the payment to the store's system

A webhook is a message the crypto provider sends to the store's backend after the payment status changes. For example, when the checkout becomes paid, the provider sends an event, and the store checks it and moves the order to the next status.

This is the same pattern used in card processing: Stripe's official documentation recommends verifying the event signature against the raw request body (not the already-parsed JSON), using event.id for idempotency, storing processed IDs with a unique constraint so the same update isn't applied twice, and quickly returning a 2xx response while offloading heavy logic to a background queue, since delivery with retries can continue for up to several days (Stripe Docs, «Receive Stripe events in your webhook endpoint», 2026).

A webhook may not arrive, may arrive twice, or may arrive later than another event. So the backend needs to:

• verify the signature;
• quickly confirm receipt;
• correctly handle repeated events;
• store the event ID and order ID;
• have a backup status check through the API.

This setup reduces the risk of a situation where the money has already arrived but the order stays unpaid.

An order can be created before payment, but is better fulfilled after confirmation

A store does not have to wait for payment to create the order itself. It can appear earlier, for example to reserve the product or save the cart.

But sending the product, opening access to a digital product, or a seller payout is better triggered only after the backend has received and verified the final payment status.

For marketplaces, an extra layer appears: the buyer's payment, the order status, and the seller's payout all need to be tracked separately.

What has changed over the last 12 months

• Tether narrowed its list of supported networks. From September 1, 2025, Tether stopped issuing and redeeming USDT on five legacy networks — Omni, Bitcoin Cash SLP, Kusama, EOS and Algorand, as part of an infrastructure review, focusing on core networks like TRON, Ethereum, Solana, BSC and TON (Tether.io, 2025). For integrations that hardcode the list of supported networks, this is a reason to check that list again.
• Requirements for webhook processing became stricter de facto, not by regulation: as the number of payment providers has grown, mandatory signature verification and idempotency by event ID have become common practice, the same standard described in Stripe's current documentation.

These changes mainly affect the technical side of an integration: the list of supported networks and the reliability of webhook processing are worth reviewing not just once at launch, but regularly.

A correct integration gives a recoverable order state, but does not remove the need for the integration itself

Neither the webhook nor the API on their own solve the desynchronisation problem, they give the store tools to detect and fix it. From there, it remains a backend development task.

The main job of the integration is to make sure the store can recover the order's state even after an error or a missed event.

Finassets sends the payment status through API and webhook, the order update stays on the store's side

Finassets provides tools for an API-first crypto checkout integration: Checkout API, order reference, Payment Button and signed webhook events.

The store's backend creates the checkout, saves the link with the order, and receives a notification after the payment status changes. The order update itself is carried out in the merchant's system, so it can be built into the store's or marketplace's own business logic.

• Onboarding. Usually takes 2–7 business days, subject to KYB and compliance review.
• Speed. A transaction is usually identified within ~15 seconds, and the balance is credited around 30 seconds after network confirmation.
• Fee. 0.40% → 0.30% → 0.25% → 0.20% depending on volume.
• Integration security. The API supports authentication, request signing, IP whitelisting and signed webhook events.
• Support. The technical team is available on Telegram. The Help Center has up-to-date instructions for integration and working with the platform.

Crypto checkout works reliably when the store tracks each of the three events separately

Crypto checkout works reliably when the store separately tracks the transaction on the network, the payment status at the provider, and its own order status. The main job of the integration is to correctly link these events through the backend and the webhook.

Then, even if there is a network delay or an event delivery failure, the store will still be able to determine the payment's state and correctly update the order.

→ Discuss crypto checkout architecture with the Finassets team