Two of the three gateways routinely called non-custodial in 2026 still hold your funds for a few minutes — only one of the three never touches them at all. The label “non-custodial” hides a tradeoff that decides the post: where exactly does the buyer’s BTC sit at the moment the invoice closes? This roundup walks the BTC payment path under SwapZilla Pay, self-hosted BTCPay Server, and the NOWPayments processor, with the comparison numbers locked to a 2026-05-15 snapshot. If you’re a merchant or a developer picking a stack, the answer depends less on the fee line and more on how much custody you’re willing to outsource for how much convenience.
The three flavours of “non-custodial” — and why the label hides the real tradeoff
All three providers describe themselves as non-custodial, and on a surface read they are: none of them are an exchange where you deposit funds and trust a balance sheet. But “non-custodial” is a spectrum, not a switch, and the differences matter for any merchant whose threat model includes a frozen payout, a regulatory subpoena, or a multi-hour outage during a $4,000 invoice.
| Model | Where the BTC lives during the payment | Custody window |
|---|---|---|
| SwapZilla Pay | Provider liquidity address → merchant wallet | None on SwapZilla side; provider holds only during the swap |
| BTCPay Server | Buyer → merchant’s own xpub-derived address | Zero; the merchant is the only signer |
| NOWPayments | Buyer → NOWPayments address → merchant wallet | Brief — NOWPayments holds during forward |
BTCPay sits at the strict end: the buyer pays an address that only the merchant’s xpub can spend. SwapZilla Pay sits in the middle — funds touch a provider liquidity address as part of the swap routing, but never a SwapZilla wallet, and the converted output goes straight to the merchant. NOWPayments sits closest to a classic processor: the deposit address belongs to NOWPayments first, and funds are forwarded to the merchant on a second hop. Their own documentation describes the two-step forwarding model.
“Non-custodial” is a spectrum, not a switch. The question to ask any gateway is which wallet the buyer’s funds touch first — and how many hops before they hit yours.
Setup and ops: what it actually takes to start accepting payments
The fastest path to a working invoice is the strongest filter between the three.
SwapZilla Pay. Open /pay/, paste a destination wallet, pick the asset you want to receive, set an amount, generate a link. No dashboard to log into, no API key, no DNS, no node. Send the link by Telegram, email, or QR. The link itself carries the quote and a refund_address you can specify at creation time. Time from “I want to accept BTC” to “the buyer has a link”: under a minute.
BTCPay Server. Spin up a VPS, install BTCPay (Docker compose or LunaNode one-click), sync a Bitcoin node (~600 GB pruned-mode optional), configure your store, point a domain at the instance, enable Lightning if needed. One-evening sysadmin job for a competent operator. Optional: rent a hosted BTCPay instance from LunaNode or Voltage if you don’t want the node lifecycle, with the trade-off that you reintroduce a third party.
NOWPayments. Email signup, dashboard onboarding, API key generation, optional KYB documents if you’re a registered business. Webhook configuration adds another step for developers. Time to first invoice: typically 15–30 minutes if everything goes cleanly.
If your goal is to test crypto payments before committing to infrastructure, SwapZilla Pay’s payment-link model is the lowest-friction starting point. BTCPay pays off when you’re certain you want sovereignty and have the ops bandwidth.
Custody, refund flow, and “who holds my BTC right now?”
Walk the BTC payment path under each gateway and the differences sharpen.
SwapZilla Pay (BTC paid, BTC received). Buyer scans QR or clicks link → buyer’s wallet sends BTC to a deposit address chosen from our routing → provider executes (effectively a same-coin transfer with a thin spread for the routing service) → merchant’s wallet receives BTC. SwapZilla never holds the funds; the provider holds them only during the confirm-and-forward step, which is typically under 15 minutes end-to-end.
SwapZilla Pay (BTC paid, USDT received). Same flow but the provider runs an actual BTC → USDT swap before payout. The merchant’s wallet receives USDT on the network the merchant chose. The buyer never sees the conversion.
BTCPay Server. Buyer’s wallet sends BTC to a receive address derived from the merchant’s xpub. The merchant is the only entity that can spend it. No forwarding, no provider, no intermediary. The custody window is zero — the funds arrive directly in a wallet the merchant controls.
NOWPayments. Buyer’s wallet sends BTC to a NOWPayments-controlled address. NOWPayments confirms the deposit, then forwards to the merchant’s specified wallet on a second on-chain transaction. The custody window is brief but real, and the second hop adds confirmation time.
The refund story tracks the custody story. On SwapZilla Pay, the refund_address you set at link creation is where the provider sends any over-payment or expired-deposit funds — see the pay docs for the exact pattern. BTCPay refunds happen from the merchant’s own node, fully sovereign. NOWPayments refunds go through their dashboard with their support team in the loop.
Fees and rate spread on a $200 invoice
Apples-to-apples on a $200 BTC payment, settled in BTC:
| Provider | Base fee | Rate spread | Hosting/ops | Time to settle |
|---|---|---|---|---|
| SwapZilla Pay | None on the link itself | ~0.95% median spread (BTC, aggregator data 2026-05-07) | None | ~12 min median |
| BTCPay Server | 0% protocol fee | 0% (direct payment) | ~$8–15/month VPS + node | ~10 min for 1-conf |
| NOWPayments | 0.5% base | Plus auto-conversion fee if converting | None | ~15 min (includes forwarding hop) |
A few honest notes. BTCPay’s “0%” is a real number for the protocol itself, but it does not include the cost of hosting — VPS, electricity if self-hosted at home, your time. For most merchants this still works out cheaper than 0.5% of revenue, but the line is not at zero. SwapZilla Pay’s spread is built into the quote the buyer sees, so the merchant always knows exactly how much arrives. NOWPayments’ base fee applies to mono-currency settlement; if you want USDT instead of the BTC the buyer sent, an auto-conversion fee stacks on top.
For a freelancer billing under $1,000 a month in BTC, the absolute fee delta between the three is dollars, not tens of dollars. The setup cost dominates.
Identity, limits, and account requirements
The signup question is where the gateways diverge most.
SwapZilla Pay. No merchant account. No dashboard. No API key. You create a payment link as a one-shot operation; the link itself carries the state. Identity is not collected on the SwapZilla side. Individual providers in our routing may apply enhanced checks on very large amounts (typically above $5,000–$10,000 USD equivalent), but for normal invoice-sized payments there is no verification step.
BTCPay Server. Not applicable. There is no third party to register with — you are the third party. The signup model is “install software.”
NOWPayments. Email signup is required. Merchant dashboard requires onboarding. Identity verification thresholds apply at higher transaction volumes; their documentation references enhanced checks on flagged accounts. Mid-range merchants typically pass without manual review, but the policy is theirs to enforce.
If your requirement is “no merchant signup at all,” the choice is between SwapZilla Pay and BTCPay. The split between them is convenience vs sovereignty.
Coin coverage, networks, and developer experience
Coin coverage is where NOWPayments’ surface area shows.
SwapZilla Pay. BTC and Lightning natively. The destination wallet can be in any asset supported by the underlying swap aggregator — including XMR via the private-quote pipeline. Developer surface: a single payment link with optional refund_address. Webhook integration available via the same backend our swap widget uses.
BTCPay Server. BTC and Lightning out of the box. XMR via the Monero plugin (requires a Monero node alongside the BTC node). Other assets via plugins of varying maintenance status. Developer surface: the Greenfield API, mature and well-documented; widely used reference implementation for the industry.
NOWPayments. Broadest coin list of the three — BTC and Lightning, ERC-20 (USDT, USDC), TRC-20, BEP-20, Solana, Polygon, and dozens of altcoins. XMR was removed from their public list during the 2024 privacy-coin delisting cycle and has not been restored as of this comparison. Developer surface: REST API, webhooks, plugins for major commerce platforms (WooCommerce, Shopify, Magento). The largest off-the-shelf integration story of the three.
For a single-coin merchant who wants BTC, all three are competitive on coverage. For a multi-chain merchant accepting stablecoins on five networks, NOWPayments’ coverage matters. For a privacy-tilted merchant who wants XMR settlement, only SwapZilla Pay and BTCPay-with-plugin will deliver it cleanly today.
On webhooks specifically: all three gateways expose a webhook for payment-status transitions, but the failure semantics differ. SwapZilla Pay’s status pipeline matches the swap engine’s order state machine — NEW, WAIT_DEPOSIT, CONFIRMING, EXCHANGING, SENDING, DONE, TIME_EXPIRED, FAILED, REFUNDED. BTCPay’s invoice events follow a simpler invoice-paid / invoice-expired pattern, with extra detail available through Greenfield. NOWPayments emits payment-status events with their processor-specific labels. If you’re integrating into an existing order system, plan for label translation in your webhook handler regardless of which gateway you pick.
Which gateway wins for which merchant
The honest answer is that the right gateway depends on what you optimize for. Mapped to the comparison categories:
- Fastest setup → SwapZilla Pay. Zero-setup payment link. From “I want to accept BTC” to “the buyer has a link” in under a minute.
- Cheapest at scale → BTCPay Server. 0% protocol fee, you eat hosting cost only. Pays off above ~$5k/month in volume where the spread on other gateways exceeds the VPS bill.
- Lowest friction for the buyer → SwapZilla Pay or BTCPay. Both keep the buyer in a one-step “send BTC to this address” flow; NOWPayments adds a confirmation hop the buyer can sometimes feel.
- Broadest coin and network menu → NOWPayments. Multi-chain stablecoin acceptance out of the box. If you need BEP-20 USDT on Tuesday and Solana USDC on Wednesday, this is the path of least resistance.
- No merchant signup at all → SwapZilla Pay. No dashboard, no API key, no account.
- Maximum sovereignty → BTCPay Server. Only model where no third party touches the funds and no third party can be subpoenaed.
If you’re starting from scratch with a single BTC invoice to send today, start at /pay/ — it’s the lowest-cost way to find out whether crypto payments fit your business before committing to a node or a processor account.
One under-discussed factor: the cost of switching. Payment links carry their state on the URL, so moving away from SwapZilla Pay is a matter of generating links somewhere else next month — nothing to migrate. BTCPay carries store data, invoice history, refund records, and wallet derivation paths inside the instance, so a migration is a real engineering project. NOWPayments locks you into an account with historical data; moving means re-onboarding customers to a new payment flow. If you’re not sure where your volume will land, start with the option that’s cheapest to leave.
Methodology
The numbers in this comparison were collected on 2026-05-15 and reflect public information available at that date.
SwapZilla Pay figures are derived from our internal aggregator dataset (src/data/provider-stats.ts), last refreshed 2026-05-07. The avgTimeMin for BTC payments is the median across the supported providers in our routing for BTC swaps; the rateSpread is the median spread percentage from mid-market across the same set. The min/max swap amounts are the most permissive figures available in our enabled provider set on that date. These are our own product data.
BTCPay Server figures are sourced from the official BTCPay Server documentation and the project’s published FAQ at btcpayserver.org/docs. BTCPay is open-source and self-hosted; the 0% rate spread reflects the absence of a protocol fee, not the absence of cost — hosting (VPS, full Bitcoin node, optional Lightning node) is the merchant’s responsibility and runs roughly $8–15/month for a typical small deployment. Confirmation times reflect Bitcoin’s mainnet for a 1-conf settlement.
NOWPayments figures come from NOWPayments’ published fee schedule and merchant documentation, cross-referenced with 2026 third-party reviews. The 0.5% base fee applies to mono-currency settlement; auto-conversion adds a separate conversion fee. The two-step forwarding model is described in their own merchant documentation.
Disclosure. SwapZilla publishes this post and competes in the same category as BTCPay and NOWPayments. We have not contacted either project for this comparison. Where a figure could be read multiple ways, we used the most generous reading for the competitor. The methodology above is your check on us — if any number reads wrong against current data, the right way to challenge it is to send us the source.
| Provider | Avg time | Rate spread | Min | Max | Account | Networks |
|---|---|---|---|---|---|---|
| swapzilla-pay | 12 min | 0.95% | $30 | $1M | Not required | bitcoin, lightning |
| btcpay | 10 min | 0.00% | $0 | $0 | Not required | bitcoin, lightning |
| nowpayments | 15 min | 0.50% | $0 | $0 | Required | bitcoin, lightning, erc20, trc20, bep20, solana, polygon |
Lowest average swap execution time
Lowest rate spread vs mid-market
Best rate among no-account providers
Highest single-transaction limit