Build vs. White Label Crypto Payment Gateway Development

Most iGaming operators should white label.

That is the conclusion, up front, because the rest of this article is arithmetic. In-house crypto gateway development usually costs a multiple of licensing across years one to three, and it bolts permanent on-call, treasury and compliance load onto a payroll that never sheds it. Building makes sense in a narrow band: very high crypto volume, plus crypto engineering depth you already have in the building.

I have not yet met an operator under roughly $100m of annual crypto volume who finished an in-house gateway and felt good about the decision eighteen months later. Usually the regret is not the build. It is the fourth chain, the Lightning node nobody wants to own, and the 3am page about a stuck withdrawal batch.

What does "build" actually mean for a crypto payment gateway?

The most common failure in a build vs buy crypto payments iGaming analysis is scoping the build as "accept USDT."

Accepting a deposit on one chain is a two-week spike. A production gateway that a licensed operator can defend to a regulator and a Big Four auditor is a different animal entirely. At minimum, it includes:

• Deterministic address generation and deposit attribution per player, per chain, with derivation paths you can reconstruct after a database restore.

• Memo and tag handling for XRP, XLM and BNB Beacon-style deposits, where the address is shared and the destination tag is the only thing linking money to a player.

• Confirmation policy tuned per asset, including reorg handling and stuck-transaction recovery.

• Sweeping: moving player deposits from derived addresses into your hot or warm wallet, on a schedule that balances fee cost against exposure. On UTXO chains this means coin selection and consolidation. On EVM chains it means funding each derived address with gas before you can sweep the token out of it, which is a whole subsystem people forget until the first fee spike.

• Fee estimation and replacement policy. Bitcoin needs a fee estimator, RBF (replace-by-fee) on outbound transactions, and a documented rule for when you bump a stuck payout instead of letting it sit. EVM chains need EIP-1559 tip logic and nonce management. Solana needs priority fees. Get this wrong and your withdrawal queue jams at exactly the moment mempools are busy, which is exactly when players are watching.

• Withdrawal batching and signing, with an approval workflow: velocity limits, dual control, manual review queues, and a signing path through MPC or an HSM that a security auditor will accept.

• Hot, warm and cold wallet segregation, with a documented key ceremony and a hot wallet top-up cycle somebody owns by name.

• A double-entry ledger that reconciles on-chain state to the player wallet balance in your platform, to the cent, daily.

• Webhooks into the platform or PAM so a confirmed deposit credits the player's balance in seconds, with idempotency, retries, dead-letter handling and replay. This is the piece that turns a wallet service into a payment method.

• Cashier UX: address display with QR, network selector, copy-to-clipboard, amount hints, expiry countdowns for Lightning invoices, and clear "you sent the wrong network" recovery paths.

• Stablecoin and fiat conversion, plus a treasury policy that says how much crypto exposure you hold overnight and who signs off when it breaches.

• Wallet screening and transaction risk scoring against a commercial blockchain analytics provider.

• Chain abstraction, so a player who sends the right asset on the wrong network does not become a support ticket that costs more than the deposit.

Every item there is a permanent owned system, not a project. That is the honest starting point.

Each chain is a new integration, not a config toggle

This is the assumption that quietly destroys build budgets. Engineers estimate "multi-chain support" once, then discover that support means six separate integrations sharing a logo grid in the cashier.

EVM chains (Ethereum, BNB Chain, Polygon, Arbitrum, Base)

The RPC interface rhymes across them, so people assume the work is a config file. It isn't. Gas tokens differ. Finality assumptions differ. Arbitrum and Base inherit L1 reorg semantics you have to reason about. Bridged versus native USDC on Polygon and Arbitrum are different contracts, and players will send you both.

ERC-20 handling brings its own tail: approvals if you touch any router or swap path, decimals that vary by token (USDT and USDC are 6, most others are 18, and a hardcoded 18 will overcredit a player by a factor of a trillion), non-standard tokens that return no boolean on transfer, and fee-on-transfer tokens you should simply refuse.

TRON

Still the highest-volume USDT rail in iGaming, and structurally different. TRC-20 transfers consume energy and bandwidth, not a gas token you can price with an EVM estimator.

You either stake TRX for energy, rent it, or burn TRX per transaction, and each option is a treasury decision plus code. Your sweeping logic needs energy accounting or your payouts fail at scale for no obvious reason.

Solana

SPL tokens live in associated token accounts, which must exist and carry rent before a transfer lands. Priority fees move fast. Transaction expiry is measured in blockhash lifetime, so a slow signing path means dropped transactions rather than pending ones. Versioned transactions and compute budgets are a separate learning curve.

Bitcoin on-chain

UTXO management, coin selection, change handling, consolidation windows, fee estimation, RBF, and dust thresholds. All the mechanics fintech engineers have never had to think about.

Bitcoin over Lightning

See below. It is its own product.

Memo and tag chains (XRP, XLM, BNB Beacon)

Deposits land on one shared address, and the destination tag or memo is the entire attribution mechanism. Players omit it constantly.

You need a documented reclaim process, a support runbook, and a decision about whether you credit unattributed funds manually or return them. Both answers create work.

Rule of thumb from live projects: the first chain costs 2–4 engineer-months. Chains two and three cost 1–2 each. And every chain you add drags a permanent tax behind it: node upgrades, hard forks, new token standards, a fee model that changes without asking your roadmap.

The Lightning question nobody scopes properly

If your player base skews Bitcoin-native, Lightning is not optional. Instant settlement, fees measured in cents, and no ten-minute confirmation wait. It is the best deposit experience in crypto when it works.

It is also the single most operationally demanding thing on this list, and it does not resemble any payment integration your team has done before.

Inbound liquidity

To receive a deposit, you need channel capacity pointing at you. Fresh nodes have none. You buy inbound liquidity from a liquidity marketplace, run an LSP relationship, or open and rebalance channels manually. That is capital locked in channels, plus somebody watching a dashboard.

Outbound liquidity for payouts

Withdrawals drain outbound capacity. Deposits drain inbound. A busy weekend of deposits leaves you unable to pay anyone out over Lightning until you rebalance, which usually means a circular rebalance with a routing fee, or a submarine swap to on-chain and back.

Get this wrong and payouts silently fall back to on-chain Bitcoin at 40x the fee, and nobody notices until the finance team asks why network costs tripled.

Invoice expiry

Lightning invoices are time-bound, typically 60 minutes at most, sometimes 10. A player who opens the cashier, gets distracted, and pays a stale invoice creates a failed payment that looks like a lost deposit to them and a support ticket to you.

You need invoice regeneration in the cashier, a visible countdown, and a policy for hold invoices and partial-path failures. Also: amount-less invoices, keysend, LNURL-withdraw for payouts, and BOLT12 if you care about static offers.

Node ops

Channel force-closes, watchtowers, backup of channel state (lose it and you lose funds, unlike a seed-phrase-recoverable wallet), version upgrades on lnd or Core Lightning, and a disaster recovery story specifically for channel backups. HSM-backed signing for a Lightning node is its own conversation.

Realistic build effort: 3–6 engineer-months for a first version you would trust with player money, plus 0.25–0.5 FTE forever, plus locked channel capital. Most white label providers now hand you Lightning as a row in a settings panel. That gap is the clearest single argument for buying that I know of.

Which capabilities do you own if you build, and which transfer if you buy?

The table assumes a mid-market operator with an existing platform and payments team, targeting Bitcoin on-chain plus Lightning, two or three EVM chains, TRON and Solana at launch, with four to six assets. Effort is in senior engineer-months. Treat every figure as an assumption to sanity-check against your own stack.

Read the last row twice. Buying transfers execution, not accountability. Who owns AML obligations, and how licence conditions extend to a payment partner, deserves its own article. The short version: outsourcing the rails never outsources the liability.

Now read the confirmation depth row, because it cuts the other way. That is a genuine trade-away.

What you give up when you buy: confirmation depth, fees and RBF

Vendors standardise. That is the point of them, and it is also the cost.

Confirmation depth

A provider will credit a Bitcoin deposit at, say, 1 or 2 confirmations, and a Polygon deposit at 30 or 128 blocks. Those thresholds are their risk appetite, not yours.

If you want instant credit at zero-conf for VIPs under $500 because your churn data says the first deposit experience decides retention, you are asking them to change a global policy for one client. Sometimes they will. Often it lands on a roadmap.

Fee and RBF policy

When mempools spike, who decides whether to bump a stuck payout, and how much of the extra fee the player absorbs? On a vendor stack, they do. You inherit their default.

If they batch withdrawals on a five-minute cycle and you want VIP payouts to skip the batch, that is a feature request. If they refuse to RBF and a payout sits pending for six hours, your support team eats it.

Network fee pass-through

Most providers pass network fees to you at cost, sometimes with a markup. Your policy choice (absorb it, pass it to the player, or absorb it above a threshold) is only as flexible as their configuration allows.

None of this is a reason to build. It is a reason to interrogate these three specific policies during procurement, get the answers in writing, and price the gap. More on how to price it below.

What does building actually cost over three years?

Here are the assumptions. Change them, re-run, and argue with me. The structure matters more than the numbers.

Team assumption

A credible build needs 2 senior backend/blockchain engineers, 1 infrastructure and security engineer, 0.5 QA, 0.5 product/BA, and 0.25 finance-systems analyst during the build. Roughly 4.25 FTE for 7–10 months to a hardened v1. If Lightning is in scope for v1, add 0.5 FTE or push the timeline out by two months.

Cost assumption

Fully loaded senior engineering cost of $140k–$210k per FTE per year in Western Europe, the UK or Malta. Lower in parts of CEE or LatAm. Materially higher in North America. Fully loaded means salary, employer taxes, equipment, management overhead and recruitment amortisation.

Steady-state assumption

Post-launch you cannot drop below 2.5–3.5 FTE if crypto is a primary deposit method. That covers on-call, chain upgrades, new asset requests, reconciliation exceptions, Lightning liquidity management and security response.

Non-headcount line items, annual:

• Blockchain analytics and wallet screening licence: $30k–$120k

• MPC or HSM custody technology: $36k–$150k

• Node, RPC infrastructure and monitoring: $18k–$90k

• Lightning node ops, inbound liquidity purchase and rebalancing fees: $15k–$50k, plus $50k–$250k of channel capital that sits locked and does not appear on the P&L but very much appears on the balance sheet

• External security audit and penetration testing: $40k–$140k in year one, $25k–$80k annually after

• Legal and audit support for a new payment flow: $25k–$80k in year one

Time-to-revenue assumption

7–12 months to a v1 you would put in front of real player money. Three to eight weeks to go live on a licensed stack.

And then the number people leave out: 12–18 months to reach feature parity with a mature white label stack.

Parity means Lightning in production, six or more chains, memo-chain reclaims handled without a spreadsheet, batching, automated payouts above 90%, a reconciliation file your finance team accepts without manual patching, and a DR drill you have actually rehearsed.

Your v1 is a deposit rail. Parity is a payments product. If crypto is 20% of incremental deposits, that gap has a P&L cost. Quantify it separately and put it in front of the CFO on its own slide.

What does the 3-year TCO comparison look like?

Modelled on a licensed operator at $30m annual GGR, total annual deposits around $100m, crypto share ramping 15% → 25% → 35%, giving crypto processed volume of $15m / $25m / $35m.

The buy side is itemised rather than blended, because "0.9% all-in" is how operators end up surprised at renewal. Real vendor pricing has three or four moving parts:

• Monthly platform or licence fee: typically $2.5k–$6k per month at this volume ($30k–$72k annually), sometimes waived above a volume floor, sometimes not.

• Settlement and conversion spread: 0.6%–0.85% on volume you convert to fiat or a settlement stablecoin. This is where most of the cost lives, and it is the number you negotiate.

• Withdrawal network fees passed through: at cost or cost-plus. Cheap on TRON, Lightning and L2s. Painful on Ethereum mainnet during a spike. Model it per transaction, not as a percentage. Assume $0.30–$2.50 per payout depending on chain mix.

• Extras: per-address fees, API call tiers, dedicated support, additional chain activation, sandbox access. Ask for the full rate card, not the headline rate.

*Lightning is included by providers who actually run it. Several claim support and mean "on the roadmap." Ask to send a real invoice-paid deposit in their sandbox before you believe it.

**Screening is typically bundled in white label crypto payment gateway software, but confirm the provider's coverage matches your licence conditions in each market you hold a licence in.

Excluded from the build column, deliberately: the $50k–$250k of Lightning channel capital and the hot wallet float you need for instant payouts. Not costs exactly, but capital your treasury cannot use elsewhere. Your CFO will care.

Midpoint outcome: roughly $3.1m to build against $1.2m to license over three years. Call it 2.5x. That is the number to lead the business case with.

Where is the crossover? Build steady-state runs at roughly $560k–$1.27m per year. At an all-in vendor rate near 0.9%–1.0% of processed volume, that equals $56m–$140m of annual crypto processing volume before build reaches cost parity.

Providers discount at volume, which pushes real crossover higher, plausibly $150m–$250m+ on a like-for-like basis.

And parity is not superiority. At parity you have taken on the operational risk for free.

How to price the buy-side trade-offs instead of just listing them

Every honest build-vs-buy deck has a slide called "risks of buying" with five bullets and no numbers. Procurement ignores it. Do this instead: convert each trade-off into a line item, add it to the buy column, and see whether the answer changes. It almost never does, which is exactly why the exercise is worth running.

1. Roadmap dependency

Pick the two or three chains or features you will plausibly need in 24 months and the provider has not committed to in writing. For each, estimate the revenue at risk if it arrives 9 months late.

Formula: (monthly deposits you expect on that chain) × (expected margin) × (months of delay) × (probability of delay).

A concrete version: you expect $600k/month of Solana deposits, 4% contribution, 9 months late, 50% likely. That is $108k. Put $108k in the buy column as roadmap dependency cost.

2. Exit risk

Price the migration you hope never to run. Re-integration is 3–5 engineer-months, dual-running two providers for 60–90 days, re-testing reconciliation, and communicating new deposit addresses to active players (this one is the expensive part, because some players never re-deposit).

Estimate $180k–$350k, multiply by your honest probability of switching within three years (20–30% is realistic in this market), and book $45k–$105k as an expected exit cost. Then reduce it by negotiating address-derivation ownership and a clean data export up front.

A contractual right to your derivation paths can cut this number in half, which makes it the single highest-ROI clause in the agreement.

3. Policy control

Confirmation depth, RBF and batching cadence. Price the gap as either support cost or player friction. If the provider's Bitcoin credit at 2 confirmations means 12 extra minutes of wait on 3,000 monthly deposits, and your data says slower first credit costs you 1.5% of first-time depositors, put a number on it. If you cannot, say so out loud rather than hiding it in a bullet.

4. Concentration risk

If one provider carries 100% of crypto volume, price a thin fallback: a single-chain in-house USDT-on-TRON deposit path cos