Crypto Payment Gateway Development Cost: Build vs. Buy

If you are pricing a build-versus-buy decision on crypto checkout, the honest starting point is that nobody can hand you a credible dollar figure for building one, and any article quoting a range made it up. Development cost is your loaded engineering cost times engineer-months, and the engineer-months depend on which chains you settle on, how much of the payment long tail you handle by hand, and whether anyone on staff has run key custody in production.

What can be stated precisely is the work. A crypto payment gateway is nine distinct systems, and only one of them, the checkout page and the address-per-order flow, is what most teams picture when they scope it. That part takes two to three weeks. The other eight are where build projects stall, and most are not features you finish. They are systems you operate.

The arithmetic usually settles it before the engineering does. At a flat 0.8% per transaction, $1M of annual crypto volume costs $8,000 a year in gateway fees, and two months of one senior engineer costs more than that at nearly any loaded rate. We should be direct about our position: Aurpay is a payment gateway, so we are one side of this comparison. That is why the section on when building genuinely wins is worth reading first — it is the argument against us, and it is real.

The one number you can compute yourself

Skip the industry cost estimates. The comparison is one subtraction, and you hold both inputs: (build engineer-months × your loaded monthly cost) + annual run cost versus 0.8% × your projected annual crypto volume. The third column below is expressed in engineer-years so you can compare against a number you know; the $200K loaded cost is a placeholder to make the shape visible, so substitute your own.

Annual crypto volume	Gateway fee at 0.8%	Engineer-years that funds at a $200K placeholder loaded cost
$250,000	$2,000	0.01
$1,000,000	$8,000	0.04
$5,000,000	$40,000	0.20
$25,000,000	$200,000	1.0
$100,000,000	$800,000	4.0

Read the last column as the annual engineering budget the buy option has to beat, every year, because run cost never stops. Below roughly $5M in annual crypto volume the fee side is almost never the expensive side; above $25M the comparison stops being obvious. If you have not fixed which fee number belongs on the right, our breakdown of crypto payment gateway fees covers the layers headline rates leave out, including payout and conversion charges that move the comparison materially.

What you are actually building

Here are the nine systems. The third column matters most for estimation, because each is routinely scoped at a fraction of its real size.

System	What it actually requires	Why it gets underestimated
Checkout and address assignment	Deterministic address derivation per order, quote display, expiry timer	It usually isn’t. Teams size this one correctly, which is why the total looks small.
Key management and rotation	Watch-only derivation in the web tier, isolated signing, crash-safe index, two-person control	Scoped as “put the key in a secrets manager.” Rotation is the hard half, never in v1.
Node and RPC dependency	Per-chain providers, method coverage, archive depth, failover, metering	Assumed to be one vendor and one API. Bitcoin, Tron and EVM are three integrations.
Confirmation and reorg policy	Per-chain finality rules and an order state machine that can move backwards	“Six confirmations” gets hardcoded. Un-confirming a paid order is a data model problem.
Rate quote and lock window	Two independent price sources, staleness rule, tolerance band, written policy for moves	Treated as a price lookup. It is a free short option written for the customer.
Webhook delivery and idempotency	Signed events, at-least-once out-of-order arrival, dedupe on event ID, dead-letter and replay	Built as a POST plus a retry. The failure mode is double-fulfillment, found in production.
Payment long tail	Underpayment, overpayment, late payment, dust, wrong asset, each with an operator workflow	Assumed rare. It is a steady share of orders, and it is human work, not code.
Reconciliation and reporting	Chain-scan backstop independent of webhooks, ledger export, cost basis per receipt	Deferred to “after launch,” by which point finance reconciles by hand.
Security review and on-call	External review of the signing path per material change, plus a paging rota	Budgeted once. Both recur, and a rota needs enough people to be a rota.

Key custody: the rotation problem

The design itself is not controversial: derive a fresh receiving address per order from a watch-only extended public key, so the signing key never exists in the tier facing the internet. That is also what makes rotation hard. Rotating the derivation root leaves unspent outputs and in-flight orders pointing at the old root, so you cannot cut over.

Two details decide whether this is sound. The derivation index has to be crash-safe and strictly monotonic: if a restart replays an index, two customers pay into the same address and those payments merge into one order, with no clean way to unwind it in the ledger. And “who can move funds” needs a written answer naming at least two humans, because the alternative is one engineer who can be socially engineered or can leave.

Nodes and RPC: three integrations, not one

Multi-chain support is where scoping goes wrong quietly. Coverage converges on the major EVM chains and diverges sharply everywhere else. When Aurpay’s own RPC Gateway imported endpoint inventory from five vendors against a 20-combination network table, Alchemy and QuickNode covered all 20, Chainstack 19, dRPC 16 with no native Tron HTTP API endpoint, and Tenderly 10 EVM combinations only. That is integration data, not a marketing page, and the shape is typical.

The consequence: if your roadmap is Ethereum plus a couple of EVM chains, almost any provider serves you and this line is small. The moment Bitcoin or Tron enters scope, you run separate integrations with separate node semantics, and the fallback provider you assumed you had may not exist. Metering compounds it: compute units, credits and flat request counts weight methods differently, so two providers advertising the same allowance can differ by an order of magnitude against your traffic. We worked through the evaluation axes in our comparison of RPC node providers.

Confirmations: your order state machine has to run in reverse

Six confirmations is a convention, not a rule, and the wrong shape for a multi-chain gateway because chains finalize differently. Ethereum blocks take about 15 minutes to finalize under proof of stake (checked 2026-09-07), so accepting at one confirmation is an explicit risk decision you are taking on the merchant’s behalf, not a technical default. Tron uses a different model entirely: a block is solidified once at least 19 distinct active super representatives have produced beyond it, roughly a minute in practice (checked 2026-09-07). Bitcoin never reaches a finality point at all; it only gets progressively more expensive to reverse.

So the parameter is not a number but a table of per-chain rules crossed with the value at risk. The expensive part is not choosing the numbers: it is that a payment marked paid can stop being paid, so the order state machine needs a backwards transition. Most e-commerce order models have none, and retrofitting one after fulfillment logic already reads status = paid touches every downstream consumer.

Lightning is not a variant of this system but a second one: no confirmations apply, and you inherit invoice expiry, channel liquidity and route failure instead. Teams that scope “Bitcoin support” while meaning “and Lightning” have roughly doubled the item.

Rate locks and the option you gave away

When you quote a fiat price in crypto and hold it for ten minutes, you have written the customer a free ten-minute option. A longer window converts better and attracts more adverse selection; a shorter one abandons more carts. There is no correct answer, only a policy, and it has to exist before the code does.

The minimum version is four decisions: two independent price sources, a staleness rule that rejects a quote rather than serving an old one, a tolerance band accepting a received amount within some percentage of the quote, and a named owner for moves outside the band. Single-source pricing is the trap. A stale feed does not error, it underprices orders silently, and you find out in reconciliation weeks later.

Webhooks, idempotency and the backstop you also need

Delivery is at-least-once and arrival is out of order, so deduplication has to key on the event ID rather than the order ID, and a handler that is not idempotent will double-fulfill. You need signature verification, retry with backoff, a dead-letter queue, and a replay path an operator can use at 2am.

The part that gets skipped: webhooks alone are not sufficient. You also need a chain-scanning reconciliation job to find payments no webhook told you about, because the two fail independently. Our guide to crypto payment webhooks and reconciliation covers the event set and the fields worth storing, and works as a specification whichever way this decision goes.

The long tail is human work

Underpayments, overpayments, payments arriving after expiry, dust, and the wrong asset sent to the right address are not edge cases. They are a steady share of orders, each needing a workflow with a human at the end.

Here the refund path collides with network economics in a way that is easy to miss. In our own transfer measurements — a sample of production transfers we ran and recorded, not an industry figure — an ERC-20 transfer cost around $0.02 while TRC-20 transfers came in between $2.11 and $4.36. Those snapshots move with network conditions, and they run opposite to what most people assume. The rule that falls out is concrete: on Tron, refunding a $3 underpayment costs more than the underpayment, so you need a written policy floor below which you credit or absorb instead. A refund button without that floor loses money on every press.

The infrastructure bill is the cheap part

Teams that budget a build by pricing infrastructure are measuring the wrong side. A managed key service costs $1 per key per month plus $0.03 per 10,000 requests on AWS KMS (checked 2026-09-07), and RPC plans are meaningful but not decisive. The hosting and key-management line for a modest gateway is a rounding error next to one engineer.

The recurring costs that matter look like overhead: external review of the signing path, recurring with every material change rather than once at launch, and a paging rota. Blockchains keep no business hours, and a payment stuck between “customer sent funds” and “order exists” is a customer whose money has left with nothing to show for it. Answering that in minutes needs enough people to be a rota, and that headcount usually ends the build discussion.

The middle path most teams skip

Build-versus-buy is posed as two options when there are three. Self-hosted open-source gateway software removes the per-transaction fee without making you write the state machines above. You inherit them and take on the operations instead. Price this first, because it isolates the real question: are you avoiding a fee, or do you need control no existing implementation gives you? We compared the trade-offs in Aurpay versus BTCPay Server.

When building is actually the right call

Four conditions, none of them rare. If two or more apply, build deserves serious evaluation rather than a reflexive no.

• You already run blockchain infrastructure in production. If node operations or key custody are staffed today, the expensive hires are made and the marginal cost of a gateway is a fraction of the above. This is the strongest single signal.
• Settlement logic is your product. Marketplace splits, escrow, per-vendor sub-ledgers, programmatic disbursement on conditions. If you need these, you are building a ledger regardless, and a third-party gateway’s order model will fight you. Wrapping someone else’s checkout around your own settlement engine is usually more work than owning both.
• Volume where the fee dominates. At $25M in annual crypto volume, 0.8% is $200,000 a year, which funds real headcount. That is where the comparison genuinely tips, and pretending otherwise would not survive your finance team.
• A constraint that forbids a third party in the payment path. Some contractual and regulatory positions rule out an external processor outright. If that is your situation, cost is not the deciding variable.

The counter-signals are equally concrete: crypto under 5% of revenue, one engineer part-time, nobody who can be paged at 3am, or a plan that starts “we will just support one stablecoin first.” That last one is the most common mistake, because the long tail does not shrink when you shorten the asset list. Underpayments and expiries happen at the same rate on one asset as on six.

How to settle this in a week

Run this before writing production code. It produces one comparable number in five working days.

1. Day 1. Fix the scope: exact chains and assets, and whether Lightning is in or out. This is the variable that swings the estimate most.
2. Day 2. Walk the nine systems above with the engineer who would own them and record an estimate per row. Any row estimated under a week has not been thought about.
3. Days 3–4. Spike only the confirmation and reorg state machine on a testnet, including the backwards transition from paid to unconfirmed. These are the highest-information two days available, because they force the order data model question open early.
4. Day 5. Total the estimate, add annual run cost (review, on-call, provider bills) and compare against 0.8% of projected annual volume plus a gateway’s integration effort. If the two land within 2x, buy: build estimates are biased low, and this one has a long tail attached.

If the decision lands on buy, the next question is which model, and that is a custody question before it is a pricing one. Aurpay is a non-custodial gateway: customer payments settle directly to the merchant’s own wallet at a flat 0.8% per transaction, with no intermediary account holding funds in between. It supports Ethereum, Tron, Bitcoin mainnet and Bitcoin Lightning, covering BTC, Bitcoin over Lightning, ETH, USDT on ERC-20 and TRC-20, USDC on ERC-20 and TRC-20, and DAI on ERC-20, with a REST API spanning payin, payout, orders and invoices across testnet and mainnet. If you are comparing on total cost rather than headline rate, our gateway fee comparison lays out the layers to check on any provider you evaluate, ours included.