"Crypto payment gateway," "crypto payment processor," and "crypto payment network" get used interchangeably across vendor sites and listicles, but they describe three different layers of the same checkout. The gateway is the front door where a wallet connects and a customer signs. The processor is the backend that confirms the transaction, converts assets, and settles to the merchant. The network is the aggregator above both that connects many wallets, exchanges, and chains through one integration. A 2026 stack typically uses all three, sometimes from the same vendor and sometimes from three different ones.
​

Most vendors sell across all three layers and market themselves with whichever word ranks highest on Google. "Gateway" has the largest search volume, so processors and networks frequently brand as gateways. The underlying functions are distinct, though, and any team integrating crypto payments will encounter all three. Treating them as one bucket leads to wrong vendor shortlists and missing pieces in production.
​

The card-payments world has the same three layers: a gateway (Stripe.js, Authorize.net) collects the card, a processor (Stripe, Adyen) clears it, and the card networks (Visa, Mastercard) route between banks. Crypto inherits the structure with different mechanics underneath.
​

A crypto payment gateway is the front-end transaction layer that a customer interacts with at checkout. Its job is to surface a payment request to the customer's wallet or exchange account, collect the signature or authorization, and hand the resulting transaction off to a processor for confirmation. A gateway does not move funds itself. It generates a payment address or builds a transaction payload, and it returns a success or failure signal to the merchant's order system.
​

Concretely, a gateway handles four things. First, address generation or payment-intent creation, so each order has a unique destination or session. Second, wallet connection through WalletConnect, browser extensions, or exchange-account OAuth flows. Third, signing UX, which is the modal or redirect that asks the customer to confirm. Fourth, status callbacks back to the merchant once the transaction is broadcast. Examples that sit primarily at this layer include Coinbase Commerce's checkout widget, BitPay's invoice UI, and the hosted checkout components offered by larger networks.
​

A crypto payment processor is the backend that takes a broadcast transaction and turns it into a settled merchant balance. It watches the chain for confirmations, applies the merchant's confirmation policy, performs any required conversion (crypto to stablecoin, or stablecoin to fiat), debits its own treasury or a liquidity partner, and credits the merchant. The processor is where the financial primitives live: balance accounting, FX, reconciliation, and the payout rail to a bank account or stablecoin wallet.
​

The processor also owns the operational risk. Confirmation policy is a processor decision: how many blocks to wait on Bitcoin, whether to accept zero-confirmation on Lightning, how to handle a chain reorganization. Conversion policy is a processor decision: lock the FX rate at the moment the payment intent is created, at the moment of broadcast, or at the moment of final confirmation. Settlement currency is a processor decision: USDC on Solana, USD via ACH, EUR via SEPA. BVNK, Bridge, and Circle's Web3 Services sit primarily at this layer per their respective public documentation, though most of them also sell gateway components.
​

A crypto payment network is the aggregator layer above gateways and processors. Its job is to give a merchant one integration that reaches many wallets, many exchanges, and many chains, rather than forcing the merchant to maintain a separate integration per asset or per custodian. The network normalizes the differences between, for example, a self-custody MetaMask user on Ethereum and a Coinbase account user paying from an exchange balance. Mesh (meshpay.com) is one example of a network-layer vendor.
​

Per Mesh's public material, the network connects 300+ wallets and exchanges and supports 120+ tokens across 24+ chains, with settlement available in USDC, PYUSD, USDT, RLUSD, or local fiat. The architectural pattern Mesh calls SmartFunding decouples the asset the customer pays in from the asset the merchant receives: a customer can pay in BTC, ETH, or SOL while the merchant settles in USDC. That decoupling is the defining feature of a network-layer product. A pure gateway or pure processor typically requires the customer's source asset and the merchant's settlement asset to match, or it surfaces conversion to the customer rather than absorbing it.
​

In practice the three layers run sequentially on every transaction. The gateway opens the wallet, the processor confirms and converts, and the network (if one is in the stack) chose which gateway and processor combination to use based on the customer's source asset. Whether they come from one vendor or three depends on the merchant's volume, the asset mix, and how much routing flexibility is needed.
​

A simple flow: customer clicks "Pay with crypto" on a merchant site. The gateway component loads, detects available wallets, and prompts the customer to connect. Once connected, the gateway builds a transaction payload for the customer's chosen asset and chain, and the customer signs in their wallet. The signed transaction broadcasts to the relevant chain. The processor watches for confirmations, applies its policy, converts the inbound asset to the merchant's settlement currency, and credits the merchant's balance. If a network sits above the gateway and processor, it had already picked which gateway flow to surface based on whether the customer was a self-custody or exchange-account user, and it may route the converted output through any of several processors to optimize cost or speed.
​

Stablecoin orchestration is a 2026 category name for the routing logic that sits between the network's source-side aggregation and the processor's settlement-side execution. Orchestration decides which chain to settle on, which stablecoin to settle in, and which cross-chain transport to use if the customer's preferred asset is on one chain and the merchant's preferred asset is on another. It is a separate concern from gateway and processor because the same gateway and processor can be wired into different orchestration policies.
​

Three sub-functions usually fall under orchestration. Source aggregation, which is the network function described above. Settlement routing, which picks the chain and stablecoin per transaction based on cost, latency, and merchant preference. Cross-chain transport, where intent routers like Eco Routes, message buses like Hyperlane, and burn-and-mint rails like Circle's CCTP move value between chains when source and settlement do not align. A stablecoin orchestration product can be a feature of a payment network, a feature of a processor, or a standalone middleware piece.
​

Real merchant stacks rarely line up cleanly with the three-layer model because vendors package across layers. The point of naming the layers is to make the gaps and overlaps visible during a vendor evaluation, not to insist that any one merchant must use three separate vendors.
​

A small Shopify merchant accepting USDC might use Coinbase Commerce as a single vendor that bundles gateway, processor, and a limited network (Coinbase accounts plus a handful of self-custody wallets). A travel platform with a global customer base might use Mesh as the network layer to aggregate 300+ wallets and exchanges per the company's public material, with Mesh's own processor settling to USDC on Stellar per the May 2026 integration announcement. A B2B SaaS company invoicing in stablecoins might combine BVNK or Bridge as the processor with their own custom gateway built on WalletConnect, skipping the network layer because their customer base is all institutional self-custody. None of these is "correct" in the abstract. The fit depends on the asset mix coming in and the settlement target going out.
​

The table below summarizes the structural differences. Vendor names are listed where the company's public material identifies that layer as a core focus; many of these vendors also sell into the adjacent layers.

Evaluation criteria are different per layer, even when one vendor sells all three. Mixing the criteria is one reason vendor shortlists go wrong. Treat each layer as a separate question, then check how cleanly the vendor's offering covers the layers you actually need.
​

At the gateway layer, the questions are wallet coverage (which wallets and exchanges connect cleanly), checkout UX (hosted page, embedded modal, headless API), and mobile behavior. At the processor layer, the questions are confirmation policy, conversion policy and FX spread, settlement currencies and rails, reconciliation tooling, and how chargebacks or refunds are handled given that most chain transactions are final. At the network layer, the questions are how many wallets and exchanges are reachable, how many chains and tokens are supported, and whether the customer's source asset can differ from the merchant's settlement asset. At the orchestration layer, the question is whether routing policy is configurable or fixed, and what cross-chain transport options are available when source and settlement chains do not match.
​

Pricing is layer-specific. Gateways often charge per integration. Processors charge a percentage of volume plus an FX spread on conversion. Networks bundle gateway and processor cost into a single volume-tiered rate. A merchant comparing a bundled vendor against a multi-vendor stack should map all-in cost per layer rather than compare headline rates.
​

Layer definitions are drawn from how vendors describe their own products on public material as of June 2026. Mesh references are sourced from meshpay.com and the company's 2026 announcements, including the May 2026 Stellar integration and the Series C funding release. Coinbase Commerce, BitPay, BVNK, Bridge, and Circle Web3 Services references are sourced from each company's public documentation. Card-payments analogy is sourced from general public documentation of the Visa and Mastercard network model. The GENIUS Act framework for U.S. stablecoin issuers is covered in a separate pillar at /support/en/articles/15282223 and not restated here.
​