BTCPay Server Alternative: Self-Hosted vs Managed Non-Custodial Crypto Payments
If you are looking for a BTCPay Server alternative, most comparisons start with the wrong question. They ask which product has more features.
The question that actually decides this one is narrower. Who runs the payment server, and what can your customers pay with?
BTCPay Server and Paymento share the thing that matters most. Both are non-custodial. In both cases, payments settle directly into a wallet you control, and neither company can move your funds. If you are comparing them against a custodial processor, they are on the same side of the line.
They differ on everything downstream of that.
What BTCPay Server actually is
BTCPay Server is free, open-source, self-hosted payment software. You deploy it, you run it, and you are your own payment processor. Their documentation states this directly: the software is non-custodial and there are no subscriptions and no transaction fees.
It is Bitcoin-first by design and by stated policy. It supports Bitcoin on-chain and over the Lightning Network, and a set of community-maintained altcoins including Litecoin, Dash, Dogecoin, Monero, and Tether on Tron via plugin. Ethereum and Solana are not supported.
That focus is deliberate, not an oversight. The project’s own documentation says Bitcoin is the only focus of the project and its core developers, and that altcoin support depends on community developers rather than the core team.
If you are a Bitcoin business, this is a feature. It means the roadmap will not drift.
Where BTCPay Server wins
Any comparison that skips this part is selling you something.
There is no transaction fee. BTCPay charges nothing per payment. At volume, that is real money. Paymento charges 0.5% per transaction. If your margins are thin and your volume is high, do the arithmetic before anything else in this article matters.
Lightning Network support. If you take small Bitcoin payments where on-chain fees are prohibitive, Lightning is the answer and Paymento does not offer it. This is a genuine capability gap, not a positioning difference.
Zero third-party dependency. With BTCPay, no company sits between you and your payments in any capacity, including as a service provider. Paymento never holds your funds, but Paymento does run the infrastructure that generates your addresses and monitors the chain. For some operators, particularly Bitcoin-native ones, removing that last dependency is the entire point.
Full control and extensibility. Point of sale, crowdfunding, pull payments, subscriptions, a plugin ecosystem, and the ability to modify the source. If you have engineering capacity and specific requirements, you can build exactly what you want.
For a business that sells in Bitcoin, has technical staff, and wants no counterparty of any kind, BTCPay Server is the correct choice. That is a real category of merchant, and if you are in it, the rest of this article is not for you.
The two costs of self-hosting
BTCPay is free of transaction fees. It is not free of cost.
The first cost is operational. You are running a payment server. That means a machine with enough storage for a full node, monitoring so you know when it stops, backups you have tested, and a person who applies updates. When something breaks at 3am on a Saturday, the person who fixes it works for you.
This is manageable. Plenty of businesses do it well. But it is worth pricing honestly, because the cost is not the VPS bill. It is the attention. A payment server is not a system you can leave alone for a quarter, and the cost is highest for exactly the businesses that are otherwise good candidates: small teams where the person who understands the server is also the person building the product.
The second cost is coverage. This is the one merchants tend to discover later, and it is not an operational problem you can solve with better ops.
The stablecoin question
Ask a merchant why they want to accept crypto and you rarely hear “because of Bitcoin.” You hear that customers in Brazil, Nigeria, or Vietnam are asking to pay in USDT, or that international card authorization is failing and crypto is the workaround.
That demand is largely stablecoin demand, and it mostly lives on account-based chains.
BTCPay supports Tether on Tron through a community plugin and USDt on Liquid. Both work. Both are maintained outside the core project, by the project’s own description. USDC is not listed at all, and Ethereum and Solana are not supported.
If your customers ask for USDT on Tron and nothing else, that plugin may be all you need. If they ask for USDC, or for USDT on Solana or Ethereum, or if you want stablecoin support maintained as core functionality rather than as a community contribution, that is where the two approaches genuinely diverge.
Paymento supports Bitcoin and Litecoin on the UTXO side, and Ethereum, Tron, and Solana on the account side, with USDT across Tron, Ethereum, and Solana and USDC on Ethereum and Solana. One integration covers all of them, and you choose which chains to switch on.
Supporting those account-based chains without giving up self-custody is the hardest thing we have built. The next section explains why.
What managed non-custodial actually means
The word “managed” usually implies someone is holding your money. Here it does not.
Paymento never takes custody. You give us an extended public key from a wallet you already control. From that key we derive a fresh receiving address for every invoice, using the same hierarchical deterministic derivation standard BTCPay uses. An extended public key derives forward only. There is no computation that gets from it back to the private key that unlocks the funds.
So we can generate as many addresses as you need. We cannot generate the key required to move anything out of them. That is not a policy commitment. It is what the mathematics permits.
The part that was actually hard
Everything above describes Bitcoin and Litecoin. That is the well-understood case, and it is why most non-custodial payment software is Bitcoin-only.
UTXO chains make it straightforward. Every payment arrives as a distinct output at its own address, so an invoice and a payment are matched by construction. Derive an address, watch it, done.
Account-based chains do not work that way. Ethereum, Tron, and Solana have one address holding one running balance. Payments do not arrive as separate objects. Two customers sending the same merchant the same amount produce two changes to the same balance, and nothing about the chain itself tells you which invoice either one belongs to.
This is the point where a gateway usually adds custody. Route the payment through a wallet the processor controls, credit the merchant internally, and the accounting problem disappears. That is the shortcut, and it is why “multi-chain” and “non-custodial” so rarely appear in the same product description.
We built it the other way. Paymento runs a separate monitoring service for each chain, written for that chain’s own model rather than adapted from the Bitcoin one. Each service identifies the payer and the amount and matches them back to the open invoice. The services are independent, so a problem on one chain stays on that chain. Funds arrive at your address on every chain, the same way they do on Bitcoin.
This is the hardest thing we have built, and it carries a visible cost. On account-based chains, checkout currently asks the customer to connect a wallet. That is real friction and we are not going to pretend otherwise. It exists because identifying the payer is what allows the payment to reach you directly instead of passing through us. Removing that step, without quietly reintroducing custody in order to do it, is our main engineering investment right now.
Multi-chain support is common. Multi-chain support where you still hold the keys on every chain is the part that took the work.
What we run instead of you
The checkout page, the blockchain monitoring across every chain you enable, the confirmation tracking, the webhooks, the invoice and payment link infrastructure, and the servers all of that sits on.
What you get out of that trade is a payment stack with no server to patch, and one integration that covers five chains instead of a plugin per chain. What you give up is 0.5% per transaction, Lightning, and the last piece of independence.
Side by side
| BTCPay Server | Paymento | |
|---|---|---|
| Custody model | Non-custodial | Non-custodial |
| Who runs the server | You | Paymento |
| Transaction fee | None | 0.5% |
| Infrastructure cost | Your hosting and your time | Included |
| Bitcoin | Yes | Yes |
| Lightning Network | Yes | No |
| Litecoin | Yes | Yes |
| Ethereum | No | Yes |
| Tron | Via community plugin (USDT) | Yes |
| Solana | No | Yes |
| USDC | Not listed | Ethereum, Solana and EVM chains |
| Fiat-denominated pricing | Yes | Yes |
| WooCommerce, WHMCS, OpenCart | Yes | Yes |
| Source code access | Full, open source | No |
| Updates and patching | Yours | Ours |
Which one you should actually use
Choose BTCPay Server if Bitcoin is your primary or only currency, you want Lightning, you have someone who can own a server, and you want zero third-party involvement of any kind. Also choose it if your volume is high enough that 0.5% is the deciding number, which is a perfectly rational reason.
Choose a managed non-custodial gateway if your customers are asking for stablecoins on chains BTCPay does not cover, your team has no capacity to own payment infrastructure, or you want multi-chain support without maintaining a plugin per chain.
A note for hosting providers specifically, since you are the most common overlap between these two options. If you run WHMCS, both integrate with it. The deciding factor is usually not the plugin. It is whether your customer base is Bitcoin-native or stablecoin-native, and whether adding a payment server to your infrastructure is a reasonable ask for a team that is already running hosting infrastructure for other people. Some hosting operators are exactly the right team to self-host. Others have quite enough servers already.
There is no universally correct answer here, and any comparison that produces one is not a comparison. The right BTCPay Server alternative depends on your currency mix and whether you want to run a payment server at all.
Getting started with Paymento
If the managed side is where you land, setup takes an extended public key from a wallet you already own, and either a plugin install or a payment link. No server, no node, no maintenance window.
Hunderds of merchants run on Paymento today, and roughly 70,000 payments have settled through it. Every one of them went to a merchant’s own wallet.
