A crypto payment gateway is a checkout tool that lets a merchant accept crypto from a payer and settle the merchant in fiat or crypto. A stablecoin API is payment infrastructure that moves money to and from third parties through code, with each customer and payout destination verified, and nobody in the flow has to hold crypto.
A gateway asks how a customer who already holds crypto can pay you. A stablecoin API asks how you move money to and from people who never want to see crypto. This post compares them on direction first, then compliance and settlement, then cost, and ends with a recommendation. The stablecoin API explainer covers the primitives, and the banking API comparison covers the other common confusion.
What a crypto payment gateway does
A gateway is designed around a checkout. The payer picks "pay with crypto", sends an amount from their own wallet to an address the gateway generates, and the gateway watches the blockchain, confirms the payment and credits the merchant. BitPay, one large gateway, documents this shape in its developer documentation (read on November 1, 2026): an invoice has a fixed price, typically in fiat, with an equivalent crypto amount at a rate locked for 15 minutes, and settlement goes to the merchant's bank or wallet each business day.
Three things follow from a checkout-first design. The money moves one way, to the merchant. The payer is a crypto user by definition. And paying a supplier, a seller or a contractor is a side feature at most.
On the Lumx side, the closest equivalent to a payer sending crypto is funding. Every Lumx customer has a custodial wallet, provisioned with the customer and enabled once the customer is approved, and anyone can send supported stablecoins to its address. That is funding, not a checkout.
What a stablecoin API does that a gateway does not
A stablecoin API treats the stablecoin as the settlement layer between two bank-facing legs. The sender starts with local money in a bank, a stablecoin balance sits in the middle, and the receiver ends with local money in a bank. Verification comes first: KYB (know your business, the verification of a company and its owners) for companies and KYC (know your customer, the verification of an individual) for people. Collections run over local rails such as Pix (Brazil's instant payment system, run by the Central Bank) and SPEI (Mexico's interbank transfer system, run by Banxico), and the deposit converts into a stablecoin. Then comes a quote, so the rate is known before the money moves, and a payout that lands in a bank account over the destination country's own rail, with a status event by webhook at every step. Named virtual accounts, local account numbers issued in the customer's own name, sit on the collection side.
The wallet question has its own post.
At Lumx one API covers all of it. A customer is created and verified, local-currency accounts and a wallet are provisioned for it, and money moves as an on-ramp (fiat to stablecoin), an off-ramp (stablecoin to fiat) or a transfer (stablecoin between wallets).
How do a gateway and a stablecoin API compare side by side?
The two categories on ten points, from who pays to what can go wrong.
Point | Crypto payment gateway | Stablecoin API |
Core job | Accept crypto at checkout | Move money across borders through code |
Direction of money | Built for inbound to the merchant | Inbound and outbound |
Who pays | A payer who holds crypto | Anyone with a bank account or a stablecoin balance |
Who gets paid | The merchant, by design (payouts, where offered, are an add-on) | Any verified third party: suppliers, sellers, contractors, customers |
What the receiver ends with | Crypto, or fiat in the merchant's own bank account | Local currency in a bank account, or stablecoin in a wallet |
Who is verified | The merchant, by design; payer and payee checks vary by provider | The customer that holds the account and every payout destination; checks on inbound senders vary by provider |
How a quote works | A rate shown at checkout for a short window (15 minutes on a BitPay invoice) | A quote requested through the API, with a locked rate and a known receive amount |
Price movement before settlement | Fixed on the invoice for its window, then the merchant is settled in its chosen currency | Quoted per payment and locked for 30 seconds, 1 minute or 5 minutes |
Who holds the funds mid-flow | The gateway, on its ledger until settlement | The customer, in a custodial Lumx wallet |
What usually goes wrong | Payer pays too little, too much or after the invoice expires | Payout rejected for a bad destination, or a compliance hold waiting on a document |
The stablecoin API column describes the category, and Lumx fits it as follows. Every Lumx customer, the party that holds the wallet and sends payouts, is verified with KYB or KYC, and every payout destination is registered and verified. Inbound funding can come from outside parties, because anyone can send supported stablecoins to a customer's wallet address, and Lumx screens blockchain transfers with Chainalysis, including funds arriving from outside wallets. The quote rows are the exchange-rate endpoint, where a locked rate can be held for 30 seconds, 1 minute or 5 minutes, and the custody row is the custodial wallet.
Refunds work differently too. With no card network in the middle, a crypto refund is typically a new payment the merchant starts. BitPay's refund documentation shows the pattern: the merchant raises a refund against its ledger balance, and the customer accepts it by email with a wallet address. On Lumx, paying a customer back into a bank account is a payout to a destination registered with the relationship CUSTOMER, which the docs describe as "clients for refunds, rebates, or other customer obligations".
Which flow needs which
Five common payment flows and the category that covers each.
Flow | Gateway | Stablecoin API |
A "pay with crypto" button on a web store | Yes, this is the job | No |
Paying contractors abroad in their local currency | No | Yes |
Receiving dollars from clients abroad into a named account | No | Yes |
Taking crypto from customers, then paying out later | Yes, at the front, for the crypto-paying customer | Yes, for anything paid out later |
Paying out to a bank account the payer never used (a new payout, not a refund) | Not its core job | Yes, over the local rail |
Where both are marked Yes, the split is in the cell. A marketplace with a crypto-paying minority uses a gateway at the front and a stablecoin API for everything that leaves.
Who gets verified, and who carries the compliance burden
In a gateway flow the compliance question typically centres on the merchant: whether the merchant is allowed to take the money and which wallet it came from. BitPay, for one, documents business verification at account setup and ties its processing limits to the verification level. Ask how far a gateway screens the payer.
A stablecoin API flips this, because the receiver is a third party with a bank account. The customer sending the money has to be known before it moves: who it is, who owns it, what the funds are for and where the receiving account is. That is why this category carries KYB, KYC, sanctions screening and transaction monitoring in one product, and why providers tend to refuse a platform that pools funds for parties they cannot see. The KYB explainer covers what a company submits.
At Lumx, each business that sends payouts is onboarded as a customer. The standard KYB asks for formation documents, papers for owners and representatives, and proof of address, and Lumx targets one business day for the review (effective November 2026). Verification runs through Sumsub. Every payout destination is registered with a holder relationship and verified too. Nested payments are not allowed, so a marketplace onboards each seller as its own customer.
What lands in the bank account, and when
A gateway settles a merchant. A stablecoin API settles a person or company that may never have heard of crypto, in their own currency. The rails set the clock, not the stablecoin. Per the Lumx rail cut-off page, Pix and SPEI settle instantly every day of the year, FEDWIRE settles the same business day, ACH takes one to two business days and a SWIFT wire in USD takes one to five. A FEDWIRE or SWIFT payout that misses 3:00 PM ET (2:00 PM ET for ACH) waits for the next business day, whatever the blockchain did in the middle.
The BRL corridor page and the MXN corridor page show the pairs. On Lumx, a payout is an off-ramp from the customer's wallet to a registered destination. The status moves from transferring stablecoin to trading, then transferring fiat, then success, and each step fires a webhook. On a Pix payout the recipient sees the customer's name as the payer, not Lumx.
What does each one cost, and what should you ask?
The cost components of each category, and the question to put to each vendor.
Component | Crypto payment gateway | Stablecoin API | Ask the vendor |
Per-payment fee | A fee on each checkout payment | A per-transaction fee on each collection or payout | Is it taken from the sent or the received amount? |
Conversion spread | Applies when crypto converts to the settlement currency | Applies when stablecoin converts to local currency | Is the quoted rate the rate you get? |
Payout fee | Where payouts exist, a fee on top (BitPay's payout documentation states 1%) | A per-transaction fee | What does the receiver actually get? |
Fixed charges | Settlement minimums (BitPay lists one per currency) | A platform fee, set by contract | Is there a minimum, and does it ramp up? |
Compare them per job. For checkout, take the gateway's fee per payment. For payouts, take the amount the receiver gets on a quoted transfer, because that figure already includes the spread.
On Lumx, a locked rate of 30 seconds has no fee and longer locks include one to cover volatility. On a quoted payout the final amount already includes Lumx's fee and any partner fee, so the receiver's amount is known before the payout starts. Lumx prices as "monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, no pre-funding; no published plans". No pre-funding means no capital parked in settlement accounts before a payment; a payout debits the stablecoin balance in the customer's wallet.
When you do not need a stablecoin API
A stablecoin API is the wrong tool in three cases.
Your only need is a pay-with-crypto button for customers who already hold crypto. That is a gateway's job.
All of your payments are domestic and in one currency, to payees already in your banking app. A bank's own payment API is simpler, and the banking API comparison walks through that case.
You want to accept stablecoin from shoppers as a merchant in Brazil and settle in reais. That is a merchant-acceptance problem, and the guide for Brazilian merchants covers it.
I would start every conversation with the same question: in this flow, does anyone who pays or gets paid hold crypto? If the answer is no for every party, I would not book a single gateway demo, because a gateway assumes the payer starts from a wallet and that assumption changes everything after it. If one side does hold crypto and wants to pay you with it, I would keep a gateway at the front and put the stablecoin API behind it for everything that leaves.
If every payer holds crypto, buy a gateway. If every party wants local currency, buy a stablecoin API. Lumx is not the pick for the first case, and for the second the comparison hub lists the pages we have written.
A Pix payout on Lumx, step by step
Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.
Take a platform that pays a supplier in Brazil. The platform is a Lumx customer, already through KYB. Its wallet holds USDC, funded by an on-ramp from a local deposit or by a stablecoin transfer from a wallet the platform controls elsewhere, which is funding, not a sale at a checkout. The supplier is registered once as a destination with a holder relationship, so Lumx knows whose bank account it is.
For each payment the platform requests a quote and passes it to the off-ramp call with a purpose code such as trade transactions. The wallet is debited, the conversion runs, and the reais arrive over Pix. A payout held for a missing document shows as an RFI (request for information, a compliance hold that asks for a document before a transaction clears), a bad destination fails the transaction, and the platform reads both from webhooks. The named virtual accounts page and the global payments page show the full set, and where Lumx operates is on the coverage page.
Methodology and sources
This comparison describes two categories, so the gateway column describes the core checkout design, with BitPay's own documentation as one example. We did not rank gateway vendors. All pages below were read on November 1, 2026:
BitPay developer documentation (invoices, settlement, compliance, refunds and payouts), cited by name and not linked.
Lumx stablecoin wallets, accounts, destinations and transactions.
Lumx exchange rates, coverage and payment rail cut-off times.
Lumx identity verification, nested payments and webhooks.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Jack van der Spoel on Unsplash.
Is a stablecoin API the same as a crypto payment gateway?
No. A crypto payment gateway lets a merchant accept crypto from a payer at checkout and settles the merchant. A stablecoin API uses stablecoins as the settlement layer to move money to verified third parties, and neither side has to hold crypto. Lumx is a stablecoin API with KYB and KYC built in.
Can a gateway and a stablecoin API run together?
Yes. A business with a crypto-paying minority can keep a gateway at the front and a stablecoin API behind it for everything that leaves. On Lumx, anyone can send supported stablecoins to a customer's wallet address, so a gateway that settles in USDC on a network Lumx supports can land funds there, and the balance is then available for payouts.
Can a crypto payment gateway pay suppliers or contractors abroad?
Sometimes, but it is not the core design. Check whether the gateway delivers to local bank accounts and verifies each payee. BitPay's payout product, for example, sends cryptocurrency to invited recipients, funded by a fiat wire to BitPay. On Lumx, a payout is an off-ramp from the customer's wallet to a registered destination, and the recipient receives local currency over Pix, SPEI, ACH, FEDWIRE, SEPA, Faster Payments or SWIFT in USD.
Which is cheaper, a crypto payment gateway or a stablecoin API?
They price different jobs, so compare per job: the gateway's fee per checkout payment, and for payouts the amount the receiver gets on a quoted transfer. Lumx prices as "monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, no pre-funding; no published plans".
What happens when someone wants to pay with crypto on Lumx?
Lumx is built around collections and payouts through the API, so a crypto payment arrives as funding. Anyone can send supported stablecoins to a customer's wallet address, and the balance is then available for payouts. For a marketplace, each seller is onboarded as its own customer with its own wallet, because nested payments are not allowed.
