Crypto Payment Gateway: What It Is and How to Choose One
Contents
A crypto payment gateway is the software layer that lets a business accept bitcoin, stablecoins and other digital assets without handling wallets or blockchains itself. It creates a payment request, shows the customer an address or QR code, watches the blockchain for the incoming transfer, and reports back to your order system once the payment confirms. The customer pays from their own wallet; you receive settlement in crypto or in regular currency, depending on the provider.
That single function hides a lot of decisions. The gateway you pick determines which assets you accept, how fast you get paid, who carries price risk, and how much of your checkout you have to rebuild. This guide covers what the gateway actually does, what to check before signing up, and where merchants usually get it wrong.
What a crypto payment gateway actually does
Think of it as the crypto equivalent of a card processor, with one structural difference: there is no chargeback rail. A confirmed on-chain transfer is final. That removes fraud disputes from the merchant side, but it also means refunds are negotiated, not forced, so your refund policy has to be written before your first crypto sale.
Under the hood, a gateway runs four jobs:
- Payment request — calculates an amount in crypto from your fiat price using a live rate, usually with a short validity window.
- Address handling — issues a deposit address or invoice per order, so payments can be matched to the right customer.
- Monitoring and confirmation — watches the chain until the transfer reaches the confirmation count the provider considers settled.
- Notification and settlement — sends a webhook to your order system, then either forwards the crypto to your wallet or converts it and pays out in fiat.
Two settlement models dominate. In a non-custodial setup, funds go straight to a wallet you control; you keep the coins and the volatility. In a custodial setup, the provider holds or converts the funds and pays you later, which shifts price risk to them and adds a third party to your cash flow.
How to add a crypto payment gateway for website checkout
For most small and mid-sized merchants, the integration is lighter than expected. The typical path looks like this:
- Open the merchant account. Expect standard KYB checks: business registration, ownership details, a bank or wallet destination for payouts, and sometimes a description of what you sell. Rules differ by country and provider, so confirm the requirements with the provider and check the licensing or registration status with the relevant national regulator.
- Pick the integration route. Hosted checkout redirects the customer to a provider page. An embedded widget keeps them on your site. A direct API integration gives you full control of the UI. Hosted is fastest; API is the most work.
- Map the payment states. Your order system needs to handle at least: awaiting payment, detected, confirmed, underpaid, overpaid, expired. Most support tickets come from these edge states, not from successful payments.
- Set expiry and rate locks. A 15-minute window is common, but the right number depends on which chains you accept and how volatile the asset is. Short windows reduce your exposure; long windows reduce failed checkouts.
- Test on a testnet. Send underpayments, overpayments, late payments and a wrong-asset transfer before you go live. Confirm what the webhook sends in each case.
If you sell through a hosted storefront rather than custom code, a no-code option such as a website crypto widget can sit on the checkout page and handle address generation and confirmation tracking without a developer, which is usually enough for a first launch.
What a crypto payment gateway API needs to expose
The API is where a gateway proves itself. Any provider can show a payment page; the differences appear in how much control and information the API gives you.
| Capability | Why it matters to your operations |
|---|---|
| Invoice creation with fixed or floating rate | Determines who absorbs price movement during the payment window |
| Signed webhooks with retries | Prevents lost orders when your server is briefly down |
| Idempotency keys | Stops duplicate invoices on retried requests |
| Partial and excess payment handling | Lets you decide whether to top up, refund, or credit the balance |
| Refund or payout endpoints | Turns a manual process into something your support team can run |
| Sandbox environment | Lets you test failure paths before real money moves |
| Per-asset configuration | You may want stablecoins only, or to exclude low-liquidity tokens |
Ask for the webhook payload spec before you commit. If the documentation does not describe what happens on an underpayment, the integration will be guesswork.
Criteria for choosing a provider
Price is the easiest thing to compare and rarely the deciding factor. These criteria separate providers in practice.
Assets and networks
Accepting bitcoin is table stakes. The real question is which stablecoins and which networks, because network choice drives cost and speed for your customer. A gateway that supports a widely used stablecoin on a low-fee network will produce fewer failed payments than one that only supports bitcoin on a congested chain.
Fee structure
Fees usually combine a percentage of the transaction with a network fee, and sometimes a conversion spread if you settle in fiat. Because these vary by provider, corridor and volume, compare them on your own expected order size rather than on a headline rate. Ask specifically whether the spread is included in the quoted percentage.
Custody and settlement
Decide in advance whether you want to hold crypto. If you plan to convert to fiat, check the payout schedule, the minimum threshold, and which currencies are supported in your country. A gateway that only settles in crypto is a different product from one that pays out to your bank.
Compliance posture
Ask whether the provider performs KYC on your customers, what records it keeps, and how you can export transaction data for accounting. Requirements vary by jurisdiction; confirm your own obligations with a local accountant, and verify the provider's registration on the relevant regulator's public register.
Reliability and support
Look for published status pages, uptime history and documented incident processes. Blockchain congestion and provider outages both happen; what matters is whether you find out from the provider or from a customer.
A short worked example
The numbers below are illustrative, not a quote from any provider or a reflection of market rates.
A SaaS business sells an annual plan at $600 and wants to accept a major stablecoin. It uses a floating rate with a 20-minute window. A customer opens checkout, the gateway locks an amount, the customer sends it, and the transfer confirms. The provider deducts its percentage and forwards the balance to the merchant's payout wallet in stablecoins. Because the asset is pegged, the merchant carries little price risk during the window.
Now change one variable: the merchant accepts bitcoin instead and settles in fiat three days later. The gateway still works, but the merchant now carries three days of price movement. That is not a reason to avoid bitcoin. It is a reason to decide settlement terms before launch rather than after.
Common mistakes
- Testing only the happy path. Underpayments and expired invoices generate most support load.
- Ignoring accounting early. Crypto transactions need consistent record-keeping from day one; retrofitting is painful.
- Assuming refunds work like cards. They do not. Write the policy and display it at checkout.
- Choosing on fees alone. A cheaper gateway that loses webhooks costs more than it saves.
- Mixing personal and business wallets. Keep payout addresses separate and documented.
- Forgetting the customer's view. If the payment page does not explain the time window and the exact amount, people abandon.
Practical takeaway
Start with three decisions: which assets and networks you accept, who carries price risk between payment and settlement, and how your order system handles partial, late and expired payments. Write those down before you compare providers. Then evaluate gateways against the API surface, the settlement terms and the compliance answers, using a testnet to prove the failure paths work.
A gateway is infrastructure, not a growth channel. It should be boring: correct webhooks, clear payment states, predictable payouts. Choose the provider that makes it boring on your stack.
This article is general information, not financial, legal or tax advice.
