DePay vs BTCPay Server

The same structural promise on different rails#

Both settle to a wallet the merchant controls with no intermediary balance. Both offer a self-hosted tier at no transaction fee. Both are, in the strict sense, the same kind of answer to the same question.

BTCPay Server delivers it on Bitcoin and Lightning. DePay delivers it on Ethereum, BNB Chain, Polygon, Solana, Optimism, Base, Arbitrum, Gnosis, Avalanche and World Chain.

That is the comparison. Everything else follows from which set of rails a merchant's customers already hold value on, and no amount of product quality moves a customer from one to the other.

Free is free on both, with different conditions#

One is free unconditionally: no company, no fee, no tier. The other offers an open-source tier at zero percent with platform features explicitly excluded, alongside a managed service at 1.5%.

Naming what the free tier leaves out is more candid than most of this index manages, and it makes the choice legible rather than a trap discovered later.

The managed rate ladder runs down to 0.5% at enterprise level, unlocked by volume or by holding the provider's own token. A rate available only to holders of an asset the provider issues is a discount with a market position attached.

Layer twos are the coverage argument#

Naming Base, Arbitrum and Optimism individually rather than folding them into an Ethereum entry is scarce in this index, and it is where a payer holding stablecoins on a cheap network actually wants to transact.

The Bitcoin side answers the same problem with Lightning, which settles in seconds at negligible cost and requires the customer to already be on it.

Both solutions work and neither is portable. A customer with USDC on Base cannot pay over Lightning, and a customer with sats in a Lightning wallet cannot pay on Base.

Neither publishes an asset count#

One describes support as thousands of tokens across hundreds of wallets. The other names Bitcoin and Lightning and leaves altcoin support to separate plugins with independent release cycles.

Both are dashes on the card and for different reasons. A router working against decentralised liquidity genuinely cannot enumerate; a project whose plugins move independently genuinely cannot either.

For a merchant neither answer is planable. The practical version of the question is which two or three assets your customers actually send, asked of a live account rather than a marketing page.

Twenty-three plugins against three#

Shopify, WooCommerce and WordPress on one side; twenty-three named platforms on the other, from WooCommerce and Magento down to Ghost, Pretix and Invoice Ninja.

The gap is a community effect rather than a budget one. Twenty-three plugins exist because twenty-three people ran those platforms; three exist because three cover the mass market.

For a shop on one of the three, the shelves are equivalent. For a shop on anything else, only one of these cards has already done the work.

Fiat is absent on both, differently#

One documents fiat settlement as absent. The other records it as unpublished. In practice a merchant on either side receives crypto and arranges conversion elsewhere.

That is structural on both cards rather than a gap either could close. A system that never holds a balance is not the shape that pushes bank transfers on a schedule.

A business that needs euros should treat this whole pair as the wrong page and start from the providers that settle fiat instead.

Who stands behind each#

One states it is an open-source project and not a company. The other says it is made in Switzerland without naming an operating entity or a registration.

Neither would satisfy a procurement review, and for a non-custodial product that matters less than it would elsewhere, because no company holds merchant funds in either case.

It still leaves a question a reviewer will ask. The honest answer on both cards is that the software is the counterparty, which some organisations accept readily and others cannot.

What to ask each of them#

To the chain router: which tokens route cleanly and at what spread, because thousands of tokens includes a great many that route at punitive rates and that difference is invisible in the count.

To the project: which altcoin plugins are maintained against the release you plan to run, and how Lightning channel liquidity is handled at your payment sizes.

To yourself, on both: who owns the wallet keys in eighteen months and whether the recovery phrase has ever been restored on a spare device. The key security guide covers the minimum arrangement.

Where this pair actually lands#

A merchant selling to customers with browser wallets and stablecoins on layer twos takes the chain router, and gets three plugins and a priced managed option.

A merchant selling to a Bitcoin-holding audience takes the project, pays nothing at all, and gets the deepest plugin shelf in this index along with an indefinite operational commitment.

There is no middle here, which is unusual for a comparison. These two do not compete for the same customer so much as serve two populations that rarely overlap.

What the free tier costs in practice#

On both cards the zero is real and the labour is the price. Somebody rents the server, applies the updates and notices when an invoice stops confirming, and that person is on your payroll rather than the provider’s.

The chain router’s free tier carries an extra condition worth reading: platform features are excluded, so the hosted dashboard and its conveniences belong to the paid version.

Model a year of engineering attention against 1.5% of your revenue before treating either free tier as an obvious saving. Below a certain volume the percentage is simply cheaper.