A website preparing to accept crypto payments should define how checkout instructions connect to an order, which payment states its systems recognize, and what documented confirmation condition permits fulfillment. A transaction being broadcast or detected is not automatically sufficient: the merchant’s configured settlement conditions must be met before fulfillment. source

Map the crypto checkout flow

Treat checkout as connected responsibilities, not as one screen or notification that represents the entire payment process. The checkout interface presents payment instructions. The selected payment-processing infrastructure handles the payment flow and reports activity according to its design. The order-management system links the activity to a customer order and applies the business’s fulfillment rule. A website may bring these functions together, but the boundaries should still be explicit.

Before implementation, decide how an order will be associated with its payment reference. Specify where that link is recorded and how an authorized operator can use it to identify the relevant order when reviewing activity. Keep the information needed for that purpose distinct from unnecessary customer details. The precise reference fields and integration behavior are infrastructure-specific, so verify them in current documentation rather than assuming that different systems use identifiers in the same way.

Keep three milestones separate: the customer initiates payment, the infrastructure detects or reports payment activity, and the business reaches its defined fulfillment state. Detection is an observation; fulfillment is an operating decision. A transaction broadcast alone does not satisfy the merchant’s configured settlement conditions. source

A useful architecture note can name the owner of each responsibility: the system that presents instructions, the system that reports payment status, the record that associates payment with an order, and the process that authorizes fulfillment. If one component performs more than one role, document that too. The point is not to prescribe a particular product arrangement, but to make it possible to trace how payment information becomes an order decision.

Define payment states and confirmation criteria

Write down the states the checkout and order systems need to represent. A BTCPay invoice is one implementation example that distinguishes awaiting payment, processing, settled, expired, invalid, partial, overpaid, and late states. The example demonstrates why “paid” may be too simple a status for operational use; other systems may use different labels and transitions.

For each state in the selected infrastructure, document what happens next. Identify which documented state or condition permits fulfillment, which means the order should continue waiting, and which sends the case for review. Do not treat the arrival of an event or transaction reference as proof that the order is ready to fulfill. The merchant’s configured settlement conditions govern that decision. source

Avoid specifying a universal confirmation threshold. The evidence here does not establish one, and the appropriate settlement policy depends on the network, asset, amount, product, and risk tolerance. Instead, obtain the selected infrastructure’s current description of its payment states and settlement behavior, then record the business decision that maps those states to order actions. Keep the documented infrastructure behavior separate from the organization’s own fulfillment policy.

Plan exception states deliberately. A partial, late, invalid, or overpaid payment should be visible as a case that can be reviewed, not silently forced into a standard paid-or-unpaid result. Decide who can review it and what record captures the disposition. The state itself describes what the system reports; it does not decide whether the business should release an order.

Plan how to accept crypto payments on website

Assign responsibility for preparing checkout instructions, linking payment references to orders, and reviewing exceptions. Then identify which record is authoritative for payment status in the organization’s workflow. A page may show progress to the customer, while another system or record drives fulfillment; document which status the fulfillment process actually relies on.

Before enabling checkout, verify the selected infrastructure’s support for the exact asset and network the business intends to accept. Payment instructions are not interchangeable across all assets and networks. Compatibility and acceptance depend on the requested asset, network, destination, recipient requirements, and service. Compare the exact asset and network with the recipient’s instructions before authorization, and verify any service-specific compatibility with the provider.

Also verify the service’s availability for the business context, its settlement or conversion behavior, and its applicable fees in current documentation or contractual terms. The general architecture does not establish a particular provider’s availability, fee, timing, or conversion outcome. Do not substitute a general assumption for a check of the chosen service’s current terms.

Write a decision rule that joins the order record to the documented payment state. It should answer: What counts as detected activity? Which documented status or condition permits fulfillment? Who reviews a mismatch? What happens when the status is unclear? These questions make the division between technical reporting and business operations visible before code or live checkout depends on it.

Connect payment events to order operations

A payment event is a notification that a system has observed a change; it is not automatically a fulfillment authorization. Review the selected system’s current documentation for how it authenticates events and what it says about delivery behavior. This guide does not establish any provider’s authentication method, retry schedule, or event-ordering guarantees, so those details must be checked for the actual integration.

Plan for repeated, delayed, missing, or out-of-order notifications. Decide how the order system will avoid interpreting a repeated event as a second payment, and how staff will identify an order whose payment status has not updated as expected. The specific controls depend on the selected infrastructure’s documented behavior. Keep the architecture decision at the level of required outcomes until those implementation details are verified.

The central safeguard remains the fulfillment rule: base it on the business-approved payment state, not merely on receipt of a notification. A broadcast transaction alone does not fulfill the merchant’s configured settlement conditions. source A notification can prompt the system or a reviewer to examine status, but the documented confirmation criterion and the business’s policy determine whether fulfillment proceeds.

Set exception, refund, and reconciliation boundaries

Assign responsibility for reviewing unresolved or unusual cases and recording their disposition. Make sure the workflow allows staff to distinguish a known exception from a settled payment. The state model should not hide an uncertain case behind a generic success label simply to keep the checkout flow moving.

Decide how payment records will be compared with order records and who may access or change them. The available evidence does not establish a particular provider’s reconciliation feature, audit trail, or access-control capabilities. Confirm those requirements in the selected system’s current documentation and terms before relying on them. Record which team or role owns unresolved differences, without assuming that an automatic match is available.

Treat refunds as a separate capability to verify. Do not assume a crypto payment can be reversed, that a refund has the same timing as the original payment, or that asset and network limitations are interchangeable. Check the selected infrastructure’s documented refund capabilities and contractual terms. Detailed refund procedures are outside this architecture guide; the pre-launch decision is to confirm what the chosen arrangement actually supports and who is responsible for handling the result.

Verify security and jurisdiction requirements

Before launch, review the selected infrastructure’s documented responsibilities for key management, credential protection, access controls, incident response, and recovery. Distinguish a provider’s description of its controls from independent security assurance. The evidence available for this general guide does not establish specific security properties, recovery guarantees, or a particular provider’s capabilities. Require the relevant documentation and decide who owns each operational responsibility before depending on the system.

Verify jurisdiction-specific availability, regulatory, tax, and compliance requirements using current authoritative sources and qualified advisers. No business location, customer group, or operating model is specified here, so no jurisdiction-specific conclusion can be drawn. Legal, tax, and regulatory obligations depend on the user’s jurisdiction and circumstances; consult the applicable local authority or a qualified professional for the relevant situation.

Confirm current fees, supported assets and networks, settlement behavior, and service availability for the particular business context. Plan non-production checks for ordinary and exception paths before enabling live checkout. These checks are a preparation step, not a claim that any test or transaction has been performed.

A pre-implementation review is complete when the team can trace an order to its payment reference, explain the relevant payment states, identify the documented condition that permits fulfillment, and name who handles exceptions. It should also be clear which system reports payment activity, which record is authoritative for the order decision, and which service-specific details remain to be verified. The core safeguard is to keep detection, confirmation, and fulfillment distinct—and not to rely on infrastructure behavior that has not been documented for the chosen arrangement.

Sources and references

  • Invoices — BTCPay Server; retrieved 2026-10-19.