Payment Gateway with Crypto: How It Works

A payment gateway with crypto connects a merchant’s checkout to a process for requesting, detecting, and accounting for a cryptocurrency payment. The term describes a system role, not one standardized architecture: gateways can differ in how they create payment requests, report status, handle funds, and define settlement. The key operational distinction is that a payment instruction or transaction broadcast is not necessarily the same as a payment meeting the merchant’s fulfillment conditions.

What Payment Gateway with Crypto means

At checkout, a merchant needs to tell a customer what amount to pay and how to pay it, then determine whether the payment satisfies the order’s requirements. A crypto payment gateway supports that workflow by coordinating payment information and status between checkout and payment processing. Depending on the implementation, it may also connect the merchant’s order system to a wallet or another service. The source material here documents specific invoice and integration behavior in BTCPay Server; it does not establish that every gateway has the same components or controls.

An invoice is one useful way to represent a payment request. In BTCPay Server’s invoice model, an invoice records a requested amount and a time-limited exchange rate, while tracking states such as new, processing, settled, expired, invalid, partial, overpaid, and late. These labels make clear that payment processing is not always a simple paid-or-unpaid switch. A gateway’s status names and quote policies may differ, so merchants should check the behavior of the implementation they use rather than assume that these labels are universal.

The gateway’s system boundary also matters. It may report that an invoice has reached a configured state, but that does not by itself explain who controls the receiving keys, how funds are held or converted, or what operational steps follow. Those details depend on the implementation and must be verified separately.

Core components of Payment Gateway with Crypto

A typical integration can be understood through several functional components. These are roles to investigate, not a claim that every gateway implements them as separate services.

  • Merchant checkout and order system: Presents the payment option, associates a payment request with an order, and decides what order action follows a status update.
  • Payment request or invoice: Carries information needed to make and track a payment. In the BTCPay example, it includes a requested amount and time-limited exchange rate and can progress through multiple states.
  • Payment interface: Gives the customer payment instructions. The precise address, QR code, network, and display depend on the implementation; the accepted claims do not prescribe a universal interface.
  • Payment detection and status reporting: Lets the merchant’s integration learn whether the request is new, processing, settled, or in another relevant state. In BTCPay’s e-commerce integration pattern, the integration handles processing, settled, expired, invalid, partial, overpaid, and late states.
  • Merchant integration: Connects gateway events to the merchant’s order system. The BTCPay pattern requires validating a webhook signature before updating the order. Other implementations may use different event names and signature mechanisms.
  • Settlement policy and funds control: Determines what evidence or conditions are sufficient for the merchant to treat an invoice as settled, and what happens to the received funds. These arrangements are implementation-specific and should not be inferred from a status label alone.

This functional map helps teams distinguish checkout presentation from payment state, and payment state from custody or settlement arrangements. A gateway can coordinate the first two without the available documentation establishing every detail of the third.

How Payment Gateway with Crypto works

A merchant workflow can be mapped as a sequence, while recognizing that exact steps vary by gateway and asset.

  1. Create an order and payment request. The checkout system identifies the order and requests payment details. An invoice model can record the requested amount and a time-limited exchange rate, as BTCPay Server documents. The merchant should establish which order and quote the request refers to.
  2. Present instructions to the customer. The gateway or checkout shows the payment details needed by the customer. The source pack does not define one universal set of screens or payment instructions, so the implementation’s supported assets, networks, and customer steps need separate verification.
  3. Observe payment activity. After the customer attempts payment, the invoice may move into a processing state or another state defined by the gateway. Processing should not automatically be treated as final settlement. The BTCPay invoice model includes distinct states for processing and settled, alongside cases such as partial, overpaid, late, expired, or invalid.
  4. Receive and validate status events. An integration may receive webhook notifications and use them to update an order. In BTCPay’s e-commerce integration pattern, the integration must handle the documented payment states and validate the webhook signature before updating the order. A merchant should not treat an unvalidated event as authoritative merely because it arrived at an endpoint.
  5. Apply the merchant’s settlement conditions. The merchant determines what conditions must be met before fulfillment. BTCPay’s operational guidance says an onchain payment should not be fulfilled solely because a transaction was broadcast; the merchant’s configured settlement conditions must be met. Appropriate policy depends on network, asset, amount, product, and risk tolerance.
  6. Reconcile the order and funds. The merchant’s systems should record the relationship among the order, payment request, status changes, and fulfillment decision. How funds are held, moved, or converted is not specified by the accepted claims and must be confirmed from the relevant implementation documentation and operating arrangements.

The sequence separates customer action, network activity, gateway reporting, and merchant action. That separation is important when diagnosing a payment that appears to have been sent but does not meet the merchant’s configured settlement conditions.

Trust and control boundaries

A gateway workflow may involve multiple trust boundaries. The merchant relies on its checkout and integration to associate the right payment with the right order. It relies on status reporting to reflect the invoice’s state, and on its own policy to decide whether that state is sufficient for fulfillment. If webhooks are used, signature validation is part of the documented BTCPay integration pattern; the exact signature mechanism is implementation-dependent.

Protocol activity and merchant acceptance are different questions. A transaction being broadcast establishes neither that the merchant’s settlement conditions have been met nor that the merchant should fulfill the order. BTCPay’s guidance explicitly cautions against fulfillment based solely on broadcast. The appropriate settlement policy depends on the network, asset, amount, product, and risk tolerance, so no universal confirmation threshold can be inferred here.

Funds control is another boundary. The accepted claims describe invoice states and e-commerce integration behavior, but do not establish whether a gateway is custodial, who controls keys, or how conversion and withdrawals work. Teams should obtain implementation-specific evidence before treating any of those arrangements as known.

Limitations and failure modes

A payment can fail to match the expected order amount or timing. BTCPay’s invoice model includes partial, overpaid, late, expired, and invalid states, in addition to new, processing, and settled. These states signal that an integration needs explicit handling rules: for example, the system must not silently equate every non-error event with successful fulfillment. The correct operational response to each case is implementation- and merchant-dependent.

Status delivery can also create integration risk. A merchant that updates an order without validating a webhook signature would not follow the cited BTCPay integration pattern. Even with validation, teams should confirm how their own implementation names events and handles retries or duplicate notifications; the accepted claims do not specify universal behavior for those cases.

Finally, “settled” should be interpreted within the gateway’s documented model and the merchant’s policy. It is not a universal guarantee about custody, conversion, customer recourse, or the final disposition of funds. Those matters require separate evidence. Likewise, the accepted material does not establish universal fees, availability, legal treatment, tax rules, security outcomes, or recovery options.

What teams should verify

Before integrating a crypto payment gateway, technical and operational teams can use these evidence-led questions:

  • Payment request: What amount and quote information does an invoice record? Is any exchange rate time-limited, and what happens when the request expires?
  • State model: What states exist, including processing, settled, expired, invalid, partial, overpaid, and late? Which states can transition to others, and what actions does the merchant system take for each?
  • Settlement policy: What exact conditions must be met before fulfillment? Does the documented policy distinguish a broadcast transaction from a payment that satisfies settlement conditions? How does policy vary by network, asset, amount, and product?
  • Integration security: Are webhook signatures validated before an order is updated? What signature mechanism and event names does the implementation document? How are duplicate or delayed events handled?
  • Order reconciliation: Can operators trace a customer order to its payment request, status history, and fulfillment decision? What evidence supports investigating a mismatch or a late, partial, or overpaid invoice?
  • Funds and control: Who controls the receiving keys? Where are funds held, and what documented steps govern transfers or conversion? The source claims do not answer these questions; verify them from current implementation documentation and the relevant operating arrangements.
  • Scope and change: Which assets, networks, and customer flows are actually supported in the deployment being evaluated? Treat these as implementation-specific rather than assuming that one documented example applies to all gateways.

A sound evaluation keeps three records distinct: what the customer was asked to pay, what payment state the gateway reported, and why the merchant decided that its settlement conditions were satisfied. That model makes the workflow easier to audit without treating a gateway’s status labels as universal guarantees.

Source notes

The invoice states and quote behavior described above are drawn from BTCPay Server’s invoice documentation; the webhook and state-handling pattern is drawn from its e-commerce integration guide. Both are implementation examples, not a universal specification for crypto payment gateways.

Sources and references