Most “accept crypto” guides skip the part that actually matters: the moment a customer hits Pay, who is holding the money? Custodial gateways — BitPay, Coinbase Commerce, NOWPayments, Plisio — take temporary custody of the funds. That single instant of custody is the regulatory trigger that forces merchant KYC, payout delays, frozen withdrawals, country bans, and the whole tax-and-treasury overhead that comes with being a “merchant”. A non-custodial payment link routes the swap straight from the customer’s wallet to yours, so the money never sits with a third party. This guide walks through the architecture, the trade-offs, and how to start accepting payments in under a minute.
The 2026 landscape: custodial vs non-custodial vs self-hosted
There are three real architectures for accepting crypto payments today, and the marketing language across them is deliberately blurry. Strip away the branding and you get this:
| Gateway | Custodial? | Merchant account required | Business verification | Customer can pay in multiple coins | Settle in multiple coins | Self-host required |
|---|---|---|---|---|---|---|
| BitPay | Yes | Yes | Yes | Yes | Limited | No |
| Coinbase Commerce | Yes (since 2024 model) | Yes | Yes | Yes | Limited | No |
| NOWPayments | Yes | Yes | Tiered | Yes | Limited | No |
| Plisio | Yes | Yes | Tiered | Yes | Limited | No |
| BTCPay Server | No (self-custody) | No | No | Yes (with plugins) | Limited (no built-in swap) | Yes |
| SwapZilla Pay | No | No | No | Yes | Yes | No |
The first four are gateways that take custody, convert, and pay you out. BTCPay Server is the self-hosted opposite: you run a Bitcoin node and your own invoice server, the funds go straight to your wallet, but you carry the operational burden and the conversion problem is on you. SwapZilla Pay sits between them — hosted like a gateway, but non-custodial like BTCPay, with the swap built into the routing.
If the gateway can freeze a payout to you, it is custodial — no matter what the homepage says.
The trade-off triangle is simple. Custodial: fast to set up, heavy compliance, real freeze risk. Self-hosted: maximum sovereignty, weeks to deploy, no built-in multi-coin swap. Non-custodial hosted link: fast to set up, no merchant onboarding, conversion built in, but you rely on the aggregator’s provider routing instead of running your own node.
What “non-custodial payment link” actually means
The phrase is misused enough that it is worth being precise. “Non-custodial” in this context means three things together:
- No third party ever holds your settlement balance. The asset you chose to receive is sent directly to the wallet address you provided. SwapZilla does not maintain a merchant balance, a payout queue, or a withdrawal flow.
- The customer’s funds do not pass through a SwapZilla wallet. When the customer pays, their deposit goes to an address generated by the routed provider for that specific swap. The funds spend the minimum time in any intermediate wallet — the provider’s own — and that wallet exists for the duration of one swap, not for your account.
- There is no “merchant account” object on our books. Your payout address is just a string you typed into a form. We do not link it to a profile, an email, an identity, or a tax record on our side.
What it does not mean:
- It does not mean you self-custody the keys to the intermediate swap wallet — you do not. The provider does, for the duration of the swap.
- It does not mean no entity in the chain runs KYC or AML procedures. Providers in the routing apply their own procedures, especially on larger amounts. SwapZilla itself does not identify you on this side of the flow.
- It does not mean you are exempt from your own tax or accounting obligations on the revenue you receive.
The failure modes also live in different places. A custodial gateway fails when it freezes your payout. A non-custodial link fails when a single swap fails — but a single failed swap returns to the customer’s refund address, not to a frozen SwapZilla balance. Your settlement either lands or it does not; there is no in-between state where money is “stuck on the platform”.
How to accept crypto payments in under 60 seconds with a payment link
The fastest path is the inline create form on SwapZilla Pay. Walkthrough:
- Pick the asset and network you want to receive. USDT on TRC-20 is the most common pick for low fees; BTC if you want to accumulate; XMR if your treasury wants privacy by default. The choice is independent of what your customer wants to pay with.
- Open the create form at /pay/. No sign-up. No email field.
- Enter the receive amount. This is what arrives at your address. The customer-facing page shows the equivalent in whichever asset they choose to pay in.
- Paste your payout address. Use a fresh address per payment if you can — it makes accounting and tax reconciliation dramatically cleaner. Most modern wallets generate a new receive address per click.
- (Optional) reference and redirect. A short order ID for your own books and a thank-you URL the customer lands on after paying.
- Hit create. You get back a
/pay/r/{id}URL and a QR code. Send the URL in an invoice email, drop the QR into a checkout page, or paste the link in chat.
The customer side mirrors this simplicity. They open the link, see the amount in fiat-equivalent and in a default coin, switch the pay-in coin if they want, and send one on-chain transaction from a wallet they control. No account creation on their side either.
From the moment the deposit confirms, the track page walks through five states: WAIT_DEPOSIT → CONFIRMING → EXCHANGING → SENDING → DONE. When you see DONE, the asset you chose has landed at your address — typically within 5 to 25 minutes depending on the pay-in coin’s confirmation time.
Pricing the payment and letting the customer pay in any coin
The mental model that trips up most merchants is treating the payment link like a fixed price tag. The link fixes the receive amount (what lands in your wallet), and the customer-facing page recomputes the pay-in amount in whatever coin they pick.
This solves two problems at once. First, you do not have to chase the BTC price every time you send an invoice — if you charge in USDT, the receive amount stays put. Second, the customer is not locked into a single coin: they pay in what they already hold, and the SwapZilla aggregator routes through providers in parallel to find the best rate for that specific pair at execution time.
A non-custodial payment link is the only checkout flow where your customer pays in one coin, you receive a different coin, and no third party ever has the right to freeze either side.
A few things to know about pricing:
- Fiat-denominated pricing. You can hold the invoice value in USDT and treat it as a stable proxy for USD. If you need strict fiat pricing (e.g. EUR invoices), re-issue the link with the new receive amount when the rate moves materially — there is no auto-re-quote on a paid link.
- Fees. There is no separate platform fee on top of the provider rate — the spread sits inside the swap route. The rate you see when the customer pays is what the customer pays; the receive amount you set is what you get.
- Slippage on volatile pairs. For very volatile pay-in coins, expect minor variance between quote and execution if you use floating rate. For invoice-style certainty, fixed-rate links lock the quote for a short window.
If you want to see exactly how the multi-provider routing works under the hood, the How it works page walks through the aggregator’s quote stream.
Integrating into a real checkout: links, API, webhooks
For a one-off invoice or a Stripe-style “Pay” button, the hosted link is enough. For automated order systems, you have three integration shapes:
1. Hosted link in an invoice or email. The lowest-effort path. You create the link manually (or via the create form) and paste it into the invoice template. The customer pays, the asset lands, you reconcile by reading the track page or your wallet activity. Good for consulting, freelance, low-volume e-commerce.
2. API + webhooks. Create the link programmatically when your checkout fires, store the returned id against your order, and listen for payment.completed on your webhook endpoint. The webhook is signed with HMAC-SHA256 in the X-SwapZillaPay-Signature header — verify it server-side before marking the order paid. Never trust the webhook payload by itself; an unverified webhook is an attacker’s free order-fulfillment button. The full reference is in the Pay docs.
3. Embedded redirect. Same as API + webhooks, except instead of inserting the link as an iframe, you redirect the customer to the hosted /pay/r/{id} page after order creation, and they return to your redirect_url after paying. This is what most modern checkouts look like (Stripe Checkout style) and is the right pattern for e-commerce platforms.
For all three: use a fresh idempotency key per order to avoid duplicate links if the customer double-clicks Pay, and persist the link id against your order before you redirect — if the customer drops off and returns the next day, you can show them the same link instead of creating a new one.
Common mistakes that lose merchants money
Patterns we see repeatedly when merchants set up a payment-link flow for the first time:
- Reusing one payout address across all customers. It works, but it makes accounting painful, weakens your privacy on chains where addresses are public, and complicates refunds. Most wallets generate fresh addresses on demand — use them.
- Treating an underpayment as “close enough”. If the customer sent less than the link expected, the swap did not complete and the funds were returned to their refund address. Do not fulfill the order. Always read the track-page status before shipping.
- Picking a slow settlement network for a small-ticket product. If you sell $5 digital goods and settle in BTC on the main chain, the customer might wait 30 minutes for confirmation while the BTC fee eats a chunk of the payment. Match the network to the price point: USDT on TRC-20 for small tickets, BTC main chain for higher value, Lightning where supported.
- Treating “no merchant account” as “no compliance”. Non-custodial routing does not exempt you from your own tax reporting, VAT/sales tax obligations, or sector-specific licensing. If your business is regulated, get advice — the payment rail is non-custodial; your business is still your business.
- Skipping HMAC verification on webhooks. An unverified webhook endpoint is the single most common security mistake in crypto checkouts. Every webhook must be verified before it triggers fulfillment.
- Not setting a refund address on the customer side. This is a customer-side concern but it lands in your support inbox: if the customer mistypes their deposit, the provider needs somewhere to refund. Make sure your customer-facing instructions tell them to set one.
When a non-custodial payment link is the wrong tool
Be honest about fit. A hosted non-custodial link is excellent for solopreneurs, indie SaaS, freelancers, and small to mid e-commerce operators who want crypto revenue without a merchant relationship. It is the wrong tool for:
- High-volume retail with chargeback culture. Crypto payments are final. If your category has a 15% refund rate driven by buyer’s remorse, you will spend more on manual refunds than the gateway fee you saved.
- Strict fiat-first reconciliation. If your accounting system expects EUR amounts down to the cent and cannot absorb the small variance from swap routing, a fiat-on-ramp model fits better.
- Jurisdictions that require a licensed PSP. Regulated industries (online gambling, securities, certain financial services) require a licensed payment service provider regardless of the rail’s custody model. Non-custodial routing does not satisfy the license requirement.
- Products with extremely frequent refunds. Same logic as chargeback-heavy retail — every refund is a manual outgoing transaction from your wallet at the prevailing rate, not a one-click reversal.
For most other businesses — anyone selling software, content, services, consulting, or physical goods to a crypto-aware audience — a non-custodial payment link is the lowest-friction way to accept crypto in 2026. You stop being a “merchant” in the gateway sense, and you start being someone with a wallet address and a link.