What happens inside a crypto checkout?

A checkout is a conversation between systems

A customer buys an illustrated guide from a fictional shop. The shop creates an order for one copy, asks its payment service for an invoice, and shows the resulting payment request. The customer’s wallet then attempts the payment.

That visible screen hides several responsibilities. The shop knows what is being sold and to whom. The payment system tracks an expected payment and its state. The wallet arranges the payment. A fulfillment process grants access after the shop’s rules are satisfied.

An invoice identifier connects those responsibilities. It should be mapped to the intended order on the server, alongside expected currency, amount and relevant payment method. A client-supplied “paid” flag is not a substitute for this record.

A fictional successful sequence

1. The shop creates order demo-order-42, awaiting payment.
2. The server creates an invoice and stores the order/invoice mapping.
3. The customer receives a payment request with its applicable terms.
4. The provider observes payment and sends a notification.
5. The server authenticates and reconciles the notification with current invoice state.
6. The shop records eligibility for fulfillment, then grants access once.

The browser may return to a success page, but that redirect is a user-interface event. It is not the authoritative evidence that the payment completed. A customer can close a tab before the redirect, and an attacker can visit a success URL without paying.

Expiration is a decision boundary, not an eraser

Consider an invoice that expires after a fictional ten-minute window. At minute eleven, an on-chain payment to its destination is detected. The business cannot make that transfer disappear by changing an invoice label.

Instead, it needs a late-payment policy and a reconciliation path. The order might need manual review, updated terms, fulfillment, or a refund process. Similarly, an underpayment is not equivalent to no payment, and an overpayment is not necessarily a second order.

BTCPay’s documented invoice states illustrate these distinctions, including payment exceptions and settlement settings. The exact names and event behavior belong to that provider and version. Our flow is an application design example, not a protocol-wide state machine.

Network and application failures complicate the happy path. An invoice-creation response can be lost after the provider creates the invoice. A webhook can arrive twice. A fulfillment call can time out after granting access. Each boundary needs a stable identity and a way to ask what actually happened.

Draw the failure paths

Add two branches to the successful sequence:

• The browser closes after paying. Expected behavior: the server’s provider reconciliation can still update the order; fulfillment does not depend on the customer’s tab remaining open.
• The payment arrives after expiry. Expected behavior: preserve the payment evidence, flag the applicable exception, and apply the business policy. Do not silently discard the money or immediately create a duplicate purchase.

For a developer, write the minimal mapping record:

order_id, provider, provider_store_id, invoice_id,
expected_amount, expected_currency, payment_method

These are conceptual fields. A production schema must define units, uniqueness constraints, versioning and which values come from trusted server state. Use provider documentation for authentication and verification; this publication does not implement a merchant checkout.