The Complete Guide to Crypto Payment Gateways

Search for "crypto payment gateway" and most of what comes back is a fee comparison: this provider claims lower rates, that one lists more supported assets, another highlights a plugin for your cart software. Those numbers are worth checking. They also skip the part of the job that decides whether your payment infrastructure holds up once a customer actually pays — everything that happens between a transaction hitting the network and money you can safely act on.

That gap is where this guide lives. It covers what a payment gateway actually does, how a crypto payment moves from broadcast to settlement, why one confirmation was never the bar, and how compliance fits inside the payment itself rather than as a separate step bolted on afterward. Treat it as the entry point to the rest of this blog: every major claim here links out to a deeper piece on the specific mechanism.

The comparison everyone runs, and the one that matters

Ask ten businesses how they picked a crypto payment gateway and most will describe a spreadsheet: fees in one column, supported cryptocurrencies in another, number of blockchain networks in a third, maybe a row for available plugins. That comparison is not wrong, exactly. It answers a real question, can this provider technically accept a transaction, and almost every provider on the market can answer yes to it.

It is the wrong question to build a business on. A blockchain transaction is easy to accept. The actual job is everything that happens after: confirmations, reorganizations, duplicate webhook deliveries, a transfer from a sanctioned address, a customer who sends the wrong amount, an API request that times out mid-write. None of that shows up on a pricing page. It shows up in production, usually the first time an integration has genuinely scaled.

A more useful question is the one this guide is built around: can this gateway reliably manage everything that happens after the payment, not just the payment itself. → Choosing a crypto payment gateway works through that question as a checklist you can run against any provider, Suward included.

What a payment gateway actually does

A crypto payment gateway is the operational layer sitting between blockchain networks and your business logic. The transfer itself is only one line item in that job. What makes that first line item safe to rely on is everything else below:

• generating a payment address, or assigning a customer's static wallet;
• monitoring the chain continuously, not only at the moment a transaction is first seen;
• tracking confirmations against a threshold calibrated per network, since a proof-of-work chain and a proof-of-stake chain fail in different ways;
• re-verifying a transaction if the chain reorganizes underneath it, before anything is credited;
• screening every incoming transfer for AML and sanctions exposure;
• crediting balances and changing payment status as one atomic operation, so the two can never drift apart;
• delivering signed, retried webhooks when a payment's state actually changes;
• accepting retried API requests without ever creating a duplicate payment;
• exposing all of it through a documented, versioned API instead of a black box.

Put together, a payment gateway transforms blockchain events into business events. A block containing your customer's transaction is a blockchain event. "It is safe to ship this order" is a business event. The list above is the machinery that turns one into the other. Skip a piece of it and you have not made your integration leaner. You are carrying the same risk the gateway exists to absorb, minus the calibration.

Gateway, wallet, exchange: three different questions

These three get lumped together constantly, and they answer genuinely different questions.

A wallet manages assets. It answers "where are my funds," "how do I sign this transaction," "how do I move money out." A wallet has no opinion about your business. It doesn't know what an order is, what compliance requires in your jurisdiction, or when it's safe to tell your warehouse to ship.

An exchange exists to facilitate trading, converting one asset into another at a market price. Some companies bundle exchange functionality with payment infrastructure, but the two solve different problems, and comparing one against the other's feature set produces a confusing comparison rather than a useful one.

A payment gateway answers operational questions specific to commerce: has the customer paid, has the transaction cleared enough confirmations, has screening completed, is it safe to ship, should the customer's balance change, has the payment become irreversible. Suward's answer to each of those is a specific status. A payment or static-wallet deposit moves through pending, accepted, and success, or terminates in failed — and each transition is what your code should actually key off. → Payment lifecycle & statuses

Why businesses are moving here now

Crypto payments stopped being an experiment a few years ago. SaaS platforms with a global customer base, e-commerce stores, gaming platforms, hosting companies, marketplaces: all of it now treats crypto as one settlement rail among several, not a novelty checkout button. Three shifts explain most of that move.

Settlement without the correspondent-bank chain

International payments have always carried friction that has nothing to do with the product being sold: correspondent banks, settlement delays, FX spreads, regional restrictions, banking hours, reconciliation across currencies. A blockchain transfer moves value directly across a distributed network instead of through a chain of intermediary institutions. That doesn't replace card or bank rails. It adds a rail that tends to work well specifically for cross-border digital commerce, where the intermediary chain was longest to begin with.

Stablecoins turned crypto from speculation into infrastructure

A few years ago, "accepting crypto" usually meant accepting Bitcoin, with all the price exposure that implies. That's no longer the default. The Chainalysis Geography of Cryptocurrency Report identifies stablecoins as one of the fastest-growing segments of the digital asset ecosystem, playing an increasingly central role in global payment activity. Circle's State of the USDC Economy makes the same point from the issuer side: businesses increasingly use stablecoins as a settlement layer for cross-border commerce, because they combine blockchain-speed settlement with the price stability day-to-day operations require.

That distinction matters for how a business should think about asset support. Customers pick assets based on what they already hold. Businesses should pick which assets and networks to accept based on operational predictability, not on which one is trending this quarter. → Which assets and networks to accept works through that decision in detail.

Less blockchain infrastructure to build and staff

A production-grade in-house payment system needs blockchain monitoring, confirmation tracking, reconciliation, balance management, webhook delivery with retries, API authentication, compliance screening, operational dashboards, before any of it ever touches your actual product. All of that consumes engineering time your product team could spend elsewhere instead. A payment gateway abstracts it behind an API call. The difference sounds small in a sentence. In headcount and incident count, it isn't.

How a payment actually moves, step by step

To a customer, paying with crypto looks instant: scan a code, approve in their wallet, done. To the system on the other end, that moment is the start of a verification sequence, not the end of one.

1. The merchant creates a payment request. A POST /v1/payments call fixes the asset and the exact amount at creation — one payment, one order.
2. The gateway issues a deposit address. A fresh, single-use address for a one-off payment, or a customer's existing static wallet if the business is modeling a balance instead of a single charge.
3. The customer broadcasts a transaction. From their side, this is the whole payment.
4. The network propagates it, and monitoring picks it up. The payment moves to pending / confirming — a transfer has been seen, nothing is credited yet.
5. Confirmations accumulate against a per-network threshold. Proof-of-stake chains rely on validator checkpoints; proof-of-work chains rely on block depth. GET /v1/blockchains reports the live requiredConfirmations for every supported network, so nobody hardcodes it.
6. Screening runs on the transfer. AML and sanctions checks happen before anything is credited, on every transaction, at every screening depth. This step cannot be skipped or turned off.
7. A reorganization, if one happens, gets resolved here, not later. If the chain rewrites the block the transaction landed in, the payment is re-verified automatically against the new canonical chain. If the transaction turns out to be genuinely gone, the payment is marked invalid and nothing was ever credited.
8. The payment reaches Accepted. Enough confirmations, clean screening, no unresolved reorg — the balance is credited and a signed payment.accepted webhook fires. This is the point where it's safe to ship or credit an account.
9. Further confirmations accrue toward Success. Once the payment is irreversible, payment.success fires and the funds move into the withdrawable balance bucket.
10. The merchant's backend verifies and acts on the webhook. Signature checked, eventId deduplicated, order fulfilled — all inside one transaction, so a retried delivery can never fulfil twice.

Steps 8 and 9 look similar and are not the same decision. → Accepted vs. Success covers why that gap exists and how to set a threshold for each side. Step 7 is the one most integrations get wrong, by assuming a single confirmation is final. → Confirmations, finality, and reorgs goes through what a reorganization actually does to a pending payment. Step 10 is its own source of production bugs the moment you skip the transaction boundary. → Webhooks and idempotency covers the handler pattern that survives retries.

Which shape you use for steps 1 and 2 depends on the product. A checkout page with a fixed order total wants a one-time payment; a customer balance that gets topped up repeatedly wants a static wallet that stays valid indefinitely. → Payments vs. static wallets covers how to pick, and Hosted checkout shows the fastest way to wire step 1 into a real storefront.

Compliance has to run inside the payment, not after it

Compliance is often treated as a separate service bolted onto a payment flow after the fact: accept the funds first, screen them on a schedule, deal with problems if the screening ever catches up. That ordering creates the exact risk it's supposed to prevent, because by the time screening runs, the funds may already be sitting in a customer-facing balance.

The alternative is running screening as part of the payment lifecycle itself, before anything is credited. That approach lines up with FATF Recommendation 15, the international framework covering virtual assets and virtual asset service providers, which calls for risk-based compliance across the transaction lifecycle rather than a checkpoint bolted onto the end of it.

On Suward, every incoming transaction (payment or static-wallet deposit) is screened before crediting, and screening can't be turned off at any configuration level. A transfer that fails the check is held for review and, if rejected, ends terminally with nothing credited, or a prior credit reversed. What businesses actually choose is depth, not whether screening happens: a Basic level included in the standard 0.4% rate, or an Extended level that adds independent blockchain-analytics providers on top and carries a $0.45 minimum service fee per payment. → Screening levels

When compliance is structurally part of the payment instead of a workflow someone has to remember to run, operational complexity goes down for the same reason atomic balance updates reduce it: there's no window where the "credited" state and the "screened" state can disagree.

Frequently asked questions

What is a crypto payment gateway?

It's the operational layer between blockchain networks and a business's own systems: creating payment requests, monitoring the chain, tracking confirmations, screening for compliance, settling funds, delivering signed webhooks — all of it behind an API instead of requiring a business to run blockchain infrastructure itself.

Which assets and networks should a business accept?

Stablecoins bring price stability that simplifies pricing, accounting, and treasury operations — which is why they carry most commercial volume today. Suward settles USDT and USDC (plus each chain's native gas token) across seven EVM networks: Ethereum, BSC, Arbitrum, Optimism, Base, Polygon, and Plasma. → Which assets and networks to accept

Why isn't one blockchain confirmation enough?

A single confirmation means a transaction was included in a block the network accepted at that moment. It says nothing about how permanent that inclusion turns out to be. Reorganizations happen, and reliable infrastructure re-verifies against the canonical chain before crediting anything. →

Confirmations, finality, and reorgs

What's the actual difference between Accepted and Success?

Accepted means enough confirmations and clean screening, with no unresolved reorg — safe to ship or credit an account, but not yet final. Success means the payment is irreversible and the funds are withdrawable. → Accepted vs. Success

What is a static wallet, and when do I need one instead of a payment?

A static wallet is a permanent deposit address scoped to one customer, accepting any number of deposits in any amount from its allow-list, with no expiry. Use it for balances and top-ups; use a one-time payment for a fixed-price checkout or invoice. → Payments vs. static wallets

Should every payment use the same confirmation threshold?

No. Confirmation requirements are calibrated per network, not per business, but risk tolerance is a business decision — a $15 digital download and a $5,000,000 institutional deposit don't warrant the same settlement policy, even on the same chain.

Is AML screening optional?

Not on Suward. Every incoming transaction is screened before crediting, on every configuration. What businesses set is depth (Basic or Extended), not whether screening happens at all. → Screening levels

What should I actually evaluate before choosing a provider?

Payment lifecycle clarity, per-network confirmation policy, reorganization handling, atomic balance updates, idempotent APIs, signed webhooks, integrated compliance — plus documentation you can build against without opening a support ticket. →

Choosing a crypto payment gateway

Where to go from here

The competitive question for crypto payments is no longer whether a business accepts them. It's how reliably the entire lifecycle, from a broadcast transaction to a signed webhook your code trusts, is managed once the customer clicks pay. Confirmations, reorg handling, screening, atomic balances: all of it sits upstream of that webhook to make the downstream decision boring, read a status, act on it, move on.

The rest of this blog goes deep on each mechanism summarized here. Start with whichever step of the lifecycle your integration is closest to touching right now.