How crypto payment gateways work in 2026: a step-by-step guide

You have probably seen the checkout screen before: a QR code, a wallet address, a countdown timer. But what actually happens between the moment a customer clicks Pay with crypto and the moment the money lands in your account? The mechanics are more interesting than most merchants realise, and understanding them helps you configure your integration correctly, set realistic customer expectations, and debug problems faster.

This guide walks through the full lifecycle of a single crypto payment — from API call to merchant balance — without skipping the parts that actually matter in production.

What a crypto payment gateway actually is

A crypto payment gateway is infrastructure that sits between your website and the blockchain. It handles four things that are surprisingly non-trivial to build yourself:

• Invoice management — generating unique payment addresses per order, tracking expected amounts, handling partial payments and overpayments.
• On-chain monitoring — watching the blockchain for incoming transactions, confirming them against the invoice, and handling edge cases like low-fee transactions stuck in mempool.
• Conversion and settlement — optionally converting volatile assets to stablecoins, aggregating balances, and calculating merchant payouts.
• Compliance and risk — AML screening of incoming funds, KYB for merchants, sanctions checks, and reporting obligations.

None of this is magic. It is engineering, and the better you understand the model, the more predictable your integration becomes.

Step 1: Invoice creation

Everything starts with your server making a POST request to the gateway API. At minimum you send an order amount (in fiat or crypto), a currency, and a callback URL. The gateway returns an invoice object with a unique identifier, a payment address, and an expiry time.

That payment address is almost always a freshly derived address — a new address for every invoice. Gateways using an HD-wallet scheme (BIP-32/44) derive child keys deterministically, so they can monitor millions of addresses with a single master key. Using a fresh address per invoice eliminates the risk of two customers sending to the same address at the same time and makes on-chain accounting trivial.

The expiry timer — typically 15 to 30 minutes for most chains, shorter for fast networks like TON — is important. Crypto prices fluctuate. An invoice with no expiry would let a customer wait for the price to move in their favour and then pay an old invoice at the new rate, leaving the merchant short. The timer locks in the exchange rate for the session.

Static vs dynamic invoices

Some gateways distinguish between static (fixed-amount) anddynamic (any-amount, used for donations or top-ups) invoices. Static invoices require the customer to send exactly the right amount — or the gateway handles underpayments and overpayments with configurable rules. Dynamic invoices accept whatever arrives, which simplifies checkout at the cost of losing amount-based payment matching.

Step 2: Customer checkout

The customer is shown a payment page — either hosted by the gateway, embedded via iframe, or rendered by your own frontend using the invoice data from the API. The essential elements are:

• The amount to pay, converted to the chosen crypto at the current rate
• The destination address (displayed as text and as a QR code)
• The countdown timer
• Optional: a wallet connect button for one-click payment

Network and currency selection happen either before checkout (the merchant pre-selects a preferred asset) or during checkout (the customer picks from supported assets). The latter improves conversion because customers pay with whatever crypto they already hold. Modern checkouts support multi-network assets like USDT: the same stablecoin running on Ethereum, Tron, BNB Chain, and Solana, with different addresses and fees on each.

Once the customer selects a currency and network, the gateway locks in the rate for that session. If the timer expires before payment arrives, the invoice is marked expired and the customer must restart.

Step 3: On-chain settlement

The gateway runs listeners (also called watchers or indexers) for every blockchain it supports. When a transaction appears in the mempool that matches a watched address, the gateway records an unconfirmed payment. At this point, the funds are not yet safe — a double-spend is technically possible on most chains, though increasingly unlikely after even one confirmation.

The gateway waits for a configurable number of block confirmations before marking the invoice as paid. For Bitcoin, typical settings are 1 confirmation for low-value transactions and 3–6 for high-value ones. For Ethereum, 12–20 blocks (about 2–4 minutes) is common. Tron and Solana are faster and typically require 1–2 confirmations.

Amount validation

The on-chain amount must match the invoice. Most gateways apply a small tolerance — typically ±1–2% — to account for network fees that some wallets deduct from the sent amount. Amounts outside the tolerance trigger an underpayment or overpayment status:

• Underpayment — the customer sent less than required. The gateway can wait for a top-up, mark the invoice as partially paid, or reject it depending on configuration.
• Overpayment — the customer sent more than required. The gateway typically credits the full received amount to the merchant's balance, sometimes flagging the surplus for refund.

For VARY-amount invoices (donations, top-ups), amount validation is skipped — whatever arrives is credited.

Step 4: Webhook notification

Once the invoice status changes — to confirming, paid,expired, or failed — the gateway makes a POST request to your callback URL with the updated invoice data. Your server should:

1. Verify the request signature (a shared secret or HMAC in the headers)
2. Check the invoice ID and amount against your database
3. Update the order status and fulfil the goods/service
4. Return HTTP 200 to acknowledge receipt

If your server returns a non-200 response, the gateway will retry the webhook on an exponential backoff schedule. This means your webhook handler must be idempotent — receiving the same event twice should not create duplicate orders.

Never fulfil an order based only on the checkout redirect URL. The redirect can be spoofed or the browser tab can be closed before it fires. The webhook — which comes from the gateway server to yours — is the authoritative signal.

Step 5: Auto-conversion (optional but common)

Many merchants do not want to hold volatile crypto. A gateway with auto-conversion converts incoming payments to a stablecoin (USDT, USDC) or to fiat before crediting the merchant's balance. This happens immediately after the transaction confirms, at the prevailing market rate, before the price has a chance to move significantly.

From the merchant's perspective, auto-conversion means you accept Bitcoin from a customer and your balance goes up by the USD equivalent in USDT. You never carry BTC overnight. For most e-commerce merchants selling in fixed fiat prices, this is the correct default.

The conversion rate is typically sourced from a major exchange or an aggregated market feed. Reputable gateways publish their conversion methodology. Watch for gateways that use opaque "internal rates" — they may embed a spread that is not reflected in their advertised fee.

Step 6: Merchant balance and payouts

After conversion, the payment is credited to your merchant balance in the gateway's internal ledger. Your dashboard shows the running balance, transaction history, and statistics. At any point you can initiate a withdrawal — sending your balance to a wallet address you control.

Withdrawals go on-chain and incur a network fee, which most gateways pass through at cost (or include in the per-transaction fee). Some gateways batch withdrawals to reduce the per-merchant network cost.

For teams, merchant-level balance isolation matters. A gateway that lets you create multiple merchants under one account — each with its own balance, API key, and team members — is far easier to manage than one that pools everything under a single account.

The API and integration surface

At the integration layer, you interact with three main components:

• REST API — create invoices, query status, list transactions, initiate withdrawals. Authenticated with a per-merchant API key.
• Webhooks — real-time push notifications from the gateway to your server on every status change.
• Hosted checkout — an optional hosted page the gateway provides so you do not have to build the payment UI yourself.

More capable gateways also expose per-merchant payment method toggles (disable specific coins or networks), team management, and exportable transaction reports. These are quality-of-life features that matter more as your volume scales.

What can go wrong — and how gateways handle it

Production crypto integrations surface edge cases that staging environments never do. Common ones:

• Customer sent the wrong asset or network — for example, paying an invoice priced in USDT on Ethereum with USDC on Polygon (both EVM, same address format), or sending USDT on Polygon to an Ethereum-address invoice. A robust gateway should not punish the customer for that mistake: as long as the asset is one it already supports, the payment should be detected, re-priced at the current rate and credited to the merchant automatically. With PawPayments the invoice is closed even when a customer pays in a different supported asset than the one originally selected — no manual recovery ticket, no lost order.
• Transaction stuck in mempool — a Bitcoin transaction with too low a fee can sit unconfirmed for hours or days. The invoice expires but the transaction eventually confirms. The gateway must detect this and credit the merchant even after expiry.
• Rapid price movement during session — if BTC drops 5% while the customer is on the payment page, the fiat equivalent of the invoice amount changes. Most gateways lock the rate for the session duration (the countdown timer) and absorb small movements within the tolerance.
• RPC node outages — gateways using a single node provider (Infura, Alchemy) are exposed to their outages. Robust gateways run their own nodes or use redundant providers.

How it compares to traditional card processing

The familiar Visa / Mastercard stack has authorisation, clearing, and settlement as distinct phases, each operated by different entities. Chargebacks can reverse a settled payment weeks later. Crypto has none of this. On-chain transactions are final and irreversible once confirmed. There are no chargebacks, no clearing delay, and no acquiring bank — just the gateway's internal ledger sitting between the blockchain and your balance.

This irreversibility is a double-edged sword. It eliminates fraud from false chargebacks (a real problem for card merchants in certain categories), but it means customer mistakes — wrong address, wrong network — cannot be automatically reversed. Merchant refund policies need to account for this explicitly.

Key takeaways

• An invoice is a time-bounded payment request tied to a unique address and a locked rate.
• The webhook, not the browser redirect, is the authoritative payment signal.
• Auto-conversion insulates you from crypto volatility at the cost of a small spread.
• Block confirmation requirements trade speed for safety — tune them to your transaction value distribution.
• On-chain finality means no chargebacks, but also no automatic error recovery.

Understanding this lifecycle makes you a much better integrator. When a customer says "I paid but nothing happened," you now know which layer to debug first: was the transaction broadcast? Was it confirmed? Did your webhook handler return 200? Nine times out of ten, the answer is in the logs.

If you do not want to wire up your own indexers, rate locking and edge-case handling, that is exactly the gap PawPayments fills: invoices, auto-conversion to stablecoin, retried webhooks and cross-asset fallback come out of the box, so your integration is one POST request away from going live.