How Does a Crypto Payment Gateway Work? The Technical Guide

High-Level Architecture

A production crypto payment gateway is not one service, it is a small constellation of services, each with a clear responsibility. The typical layout:

Every one of these services is independently scalable, independently monitored, and usually independently deployed. The blockchain indexer and the confirmation engine are the two that sweat most under load.

The Invoice Lifecycle

Every crypto payment is an invoice. Here is the lifecycle from the merchant's POV:

1. Create. Merchant calls POST /invoices with amount, fiat currency, order ID, and a callback URL. Response includes the invoice ID, a list of supported assets, and a hosted checkout URL.
2. Display. Merchant redirects the buyer to the hosted checkout or embeds it in an iframe. Buyer picks an asset. Gateway returns a deposit address and the exact crypto amount at the locked rate.
3. Detect. Buyer's wallet broadcasts the payment. Indexer picks it up from the mempool. Invoice state becomes detected. Optional webhook fires.
4. Confirm. Gateway waits for the configured number of block confirmations (higher for large amounts, lower for stablecoins on fast chains). Invoice state becomes confirming then completed.
5. Settle. Funds are available in the merchant's gateway wallet. If auto-conversion is enabled, the gateway swaps to a stablecoin or initiates an off-ramp to fiat. settled webhook fires.
6. Expire or underpay. If the buyer pays late or short, the invoice transitions to expired, underpaid, or overpaid and an exception-handling path kicks in.

Good gateways expose every state transition as a distinct webhook so the merchant's order system can react correctly. Bad ones collapse everything into "paid/unpaid" and lose information.

Rate Locks and Pricing

Crypto prices move. Between the moment a buyer sees "0.0023 BTC" on the checkout and the moment their transaction mines, the price can shift 1 to 3%. Someone has to absorb that risk.

Locked rates are the industry default because merchants want predictable revenue. Gateways hedge this exposure by holding inventory in stablecoins, running automated rebalancing, or purchasing forward hedges at scale. A 10 to 30 minute lock covers the statistical distribution of time-to-confirmation on all major chains.

Mempool Detection and Confirmation Policies

Two independent milestones drive the state machine:

Mempool detection. The moment a transaction is broadcast, full nodes see it in their mempools. A gateway's indexer watches either directly (running its own nodes) or indirectly (subscribing to a provider's websocket). For low-value payments on fast, final chains (Tron, Solana, L2s), mempool detection is often enough to release a digital good.

Block confirmations. The transaction is mined into a block. Each subsequent block is another confirmation. A block can in theory be orphaned by a chain reorganization (reorg), which is why gateways wait for several confirmations on slower, probabilistic chains.

Confirmation policy is a risk-management decision, not a technical one. A coffee shop does not need to wait six Bitcoin confirmations to release a $5 latte. A Lamborghini dealership absolutely does.

Edge Cases: Underpayment, Overpayment, Reorgs, Wrong Network

Real crypto checkouts spend most of their engineering budget on edge cases. The main ones:

• Underpayment. Buyer sends less than the invoiced amount (often because they forgot to include the network fee). Good gateways let the merchant configure a tolerance, auto-refund, or keep the invoice open for a top-up.
• Overpayment. Buyer sends too much. Default is to credit the extra to the order or auto-refund the difference. Merchant policy, not a technical constraint.
• Late payment. Buyer pays after the rate lock expired. Gateway either rejects, refunds, or credits at the new market rate. Each option has a different UX and accounting implication.
• Wrong network. Buyer sends USDC on Ethereum mainnet to an address expecting USDC on Polygon. Non-trivial to recover (requires private-key access to the original address on the new chain). Most gateways warn prominently and block obvious mistakes in the widget.
• Reorgs. A previously confirmed block is orphaned. A transaction that was completed becomes unconfirmed again. The confirmation engine reverts and re-tracks. Rare on modern chains but non-zero.
• Stuck transaction. Buyer paid a gas price too low and the transaction sits in the mempool for hours. The gateway typically allows RBF (replace-by-fee) on Bitcoin or provides tooling to speed it up on EVM chains.
• Dust attacks and spam. Unrelated addresses send tiny amounts to the invoice address to complicate accounting. Indexer ignores sub-threshold transfers.

Ask any gateway vendor how they handle all seven of these. How they answer tells you how mature the platform is.

Webhooks, Idempotency, and Integration

The webhook is where the gateway meets the merchant's order system. Getting it right is the difference between a calm ops team and a miserable one.

• Events, not states. Good gateways fire separate events for invoice.created, payment.detected, payment.completed, payment.settled, invoice.expired, and invoice.underpaid. Each event has its own idempotency key.
• Signed payloads. Every webhook should be signed with HMAC-SHA256 using a shared secret. The merchant verifies the signature before processing. Anything less is phishable.
• At-least-once delivery. The gateway retries with exponential backoff (1s, 5s, 30s, 2min, 15min, 1h...). The merchant must be idempotent: seeing the same event twice should produce the same result.
• Fast acknowledge, background process. The merchant should return HTTP 200 in under 500ms and push the heavy lifting to a queue. Webhook handlers that do business logic inline time out under load.
• Replay tooling. Good gateways let the merchant fetch and replay a webhook by event ID, for the inevitable moment an event was lost to a misconfigured firewall.

These patterns are identical to webhook best practices in fiat. The crypto specifics are about the events themselves (confirmations, reorgs, underpayments), not about the delivery model.

Custody Models and Key Management

Once crypto hits the gateway's address, someone has to hold the keys. This is the single biggest architectural decision.

Production-grade custody combines several techniques:

• HSMs (hardware security modules) for key material that cannot be exfiltrated.
• MPC or multisig for transaction authorization.
• Hot / warm / cold wallet tiers. Hot wallets hold only enough to meet short-term payout demand.
• Velocity and withdrawal limits to contain blast radius on compromise.
• Chain-analytics screening on every inbound address (Chainalysis, Elliptic, TRM) to reject sanctioned counterparties before crediting.

Off-Ramp: Turning On-Chain Payments into Bank Balances

Most merchants ultimately want dollars (or euros, or lira). The off-ramp is the service that converts inbound crypto into fiat and pushes it to a bank account.

Mechanically, the gateway aggregates inbound flows, routes them through a banking partner or exchange desk, and issues a SWIFT, SEPA, or ACH transfer to the merchant's nominated account. The operational specifics:

• Conversion venue. Licensed exchange partners (for regulated compliance), OTC desks (for large tickets with tight spreads), or on-chain AMMs (for non-fiat conversions).
• Spread. 0.5 to 1.5% on stablecoins, 1 to 3% on volatile assets, depending on size and venue.
• Settlement channels. SEPA and SEPA Instant in the EU (T+0), Faster Payments in the UK (T+0), ACH in the US (T+1-2), SWIFT for non-EUR/USD cross-border (T+1-3).
• Compliance. The off-ramp is where KYC/AML obligations bite. The merchant (the business) is onboarded once. Individual buyers are not KYC'd for the payment itself, though large transfers trigger FATF Travel Rule data sharing between the gateway and the receiving bank.
• Payout cadence. Real-time on each invoice (most transparent, more bank-fee overhead), daily sweep (most common), or on-demand via a dashboard (most flexible).

A merchant accepting crypto with automatic fiat off-ramp experiences a UX very similar to a fiat PSP: money appears in their bank. The fact that the customer paid in USDC on Tron is an implementation detail.