Voltage vs ZBD for game payouts and Lightning payments

A player has earned money in your game. Your team needs to get it to them, record what happened, and keep enough funding available for the next payout.

Voltage and ZBD can both be part of that flow. The decision depends on how much of the payment experience you want your provider to own, and how your business wants to fund it.

Choose Voltage when you want to build Lightning deposits and withdrawals into your own platform, with payment operations and a funding model designed around your business. We document both credit-backed and node-backed implementations of the same Payments API. Voltage implementation paths

Choose ZBD when an embedded game rewards or cash-out experience is central to the product. ZBD documents a Unity rewards SDK and an embedded payout flow that includes user verification and payment-method selection. It also offers a Bitcoin API for teams building their own Lightning integration. Embedded Rewards, Embedded Payouts, Bitcoin API

Keep your current provider when it already meets your players’ needs, your treasury requirements, and your operating targets. A lower headline fee alone is a weak reason to rebuild a working payment flow.

This is a comparison by Voltage, based on public product documentation, not a hands-on performance benchmark. The direct comparison below is Bitcoin deposits and payouts over Lightning. ZBD’s broader embedded financial products are considered separately.

Start with the player experience you need

There are two different buying decisions hiding inside “payments for games.”

One is adding a payment rail to a platform you already operate. You own the player account, balance, withdrawal approval, and interface. You need an API to move the payment and return a dependable record.

The other is adding a packaged rewards and cash-out experience. You want the provider to handle more of the screens, verification, and payout choices.

Our recommendation is to start with Voltage for the first decision, particularly when the way you fund payments matters as much as the API. Start with ZBD for the second, especially for a Unity mobile game. ZBD’s Earn SDK includes an in-app rewards modal and supports rewards denominated in virtual currency or satoshis. Access is for approved partners. ZBD Earn documentation

For a casino, sportsbook, or other wagering product, establish provider acceptance for your exact business model and jurisdictions before choosing either integration. Game rewards documentation does not establish approval for every form of real-money gaming.

Compare the same job

For the cleanest comparison, use this acceptance case: receive a Lightning deposit, then send a separate Lightning payout to a player-controlled wallet.

Both providers document these core capabilities. ZBD is not limited to payments inside its own app: its charge endpoint creates an invoice payable by Lightning-capable wallets. Voltage’s receiving API also supports Lightning invoices. ZBD Create Charge, Voltage Receiving

Table sources: Voltage Sending, USD credit sends, Payments Access, Wallet Management, implementation paths, pricing; ZBD project wallets, API keys, Bitcoin API, payout pools, payout methods.

The funding model deserves its own conversation

With ZBD’s Bitcoin API, your project has a wallet and balance to manage. Its project-wallet guide recommends maintaining a funding buffer. Its Embedded Payouts product uses a different structure: a pool you fund, with payouts dependent on sufficient settled funds. ZBD project wallets, payout pool funding

Voltage gives businesses two implementation paths. Credit-backed customers use a Voltage-provided credit line without operating the underlying Lightning node. Node-backed customers use a customer-controlled node and reserve, with additional custody, credentials, liquidity, and treasury responsibilities. “Managed” does not mean those responsibilities are identical in every deployment. Voltage documentation, credit-backed implementation

For qualified businesses, Voltage Credit can reduce the need to pre-fund payments. It is a separate commercial credit arrangement, with underwriting and terms to confirm. Include financing costs in the business case. Voltage Credit, credit-backed scope

A USD-denominated credit wallet also needs a precise explanation. The documented send workflow obtains a conversion quote and pays a Bitcoin invoice or address. The USD denomination describes your wallet and credit arrangement; it does not mean the recipient receives a bank deposit in dollars. USD line-of-credit payment flow

For a payments team, the practical question is simple: how much money must be available, where must it sit, and who owns replenishment when payout demand spikes?

ZBD offers more than Bitcoin payouts

ZBD’s Embedded Payouts puts verification, method selection, and cash-out inside the game or platform. The program can track earnings itself or have ZBD track them. That is a broader product scope than an API that pays a Lightning invoice. Embedded Payouts overview

Availability and timing depend on the payout method and the user’s country. ZBD’s technical guidance describes mobile-wallet and some domestic payments settling in minutes, domestic bank transfers taking the same or next business day, and some cross-border transfers taking several business days. Do not compare that entire cash-out journey with only the Lightning settlement step. ZBD payout methods and timing

ZBD also documents Embedded Accounts for player balances, spending, transfers, and cash-out. If that is what you need, evaluate it as an additional product rather than assuming a Bitcoin API is an equivalent substitute. ZBD documentation index

On our side, avoid treating every documented asset type as a live commercial offering. Voltage’s wallet guide explicitly identifies Voltage Cash as experimental stablecoin testing and says it is not currently live for production use. It is excluded from this comparison’s production payment scenario. Voltage wallet types

Price one workload, not two different products

Use a shared quote brief before declaring a winner.

Illustrative monthly workload: 10,000 Lightning deposits and 10,000 Lightning payouts, each for 10,000 sats. That is 1 BTC inbound plus 1 BTC outbound, or 2 BTC of gross payment movement across 20,000 transactions. These are assumed quantities, not customer results. They exclude bank payouts, gift cards, and conversion.

Ask both providers to price that exact workload for the same eligible business and recipient markets. Keep the funding models explicit; a pre-funded wallet and a credit-backed deployment have different treasury costs.

Pricing sources: Voltage pricing, Voltage Credit, ZBD pricing page, ZBD embedded payout fees.

For a sensitivity check, an assumed all-in variable fee of 10 basis points on 2 BTC equals 0.002 BTC. An assumed per-transaction charge of 1 sat across 20,000 transactions equals 20,000 sats. These are illustrations, not either provider’s prices, and they should only be added together if both apply in the quote.

There is no defensible public-price winner from the evidence reviewed. Near-zero network fees are not the same as near-zero total operating cost.

Validate the payment lifecycle before judging the experience

Here is a repeatable evaluation plan for the shared Lightning workflow. It is a test specification, not a report of tests performed for this article.

1. Match the amount and destination type. Use a fixed 10,000-sat invoice for each trial, generated separately for each payment. That is 10,000,000 millisatoshis. Keep network and recipient-wallet conditions comparable.
2. Receive a deposit. Create the invoice, pay it from a compatible wallet, and verify that your application credits the player only after confirmed completion.
3. Send a payout. Submit a fresh invoice, record the provider’s payment identifier, and reconcile the final state and fee to your internal withdrawal record.
4. Exercise failure paths. Include expired invoices, insufficient funding or available credit, unavailable destinations, delayed callbacks, and an interrupted request. Check existing payment state before retrying an uncertain send.
5. Compare the output. Record completed value, actual fees, elapsed time to terminal status, reconciliation completeness, and support effort. Test your real ticket-size distribution before drawing a production conclusion.

Voltage documents staging wallets on test networks and warns against assuming test limits or behavior match production. ZBD’s Bitcoin sandbox page is internally inconsistent: it describes broad test access but specifically warns that only Send to Gamertag is available in sandbox. Confirm current invoice-testing access with ZBD rather than treating the two test environments as equivalent. Voltage staging, ZBD Bitcoin sandbox

In both integrations, an accepted request is not enough to credit or discharge a player’s balance. Use terminal payment state. Voltage documents status retrieval; ZBD documents asynchronous payments and callbacks. Voltage payment status, ZBD payment lifecycle

Switching requires more than replacing an endpoint

Treat migration as a controlled payment-system change.

Keep your own player identifiers and accounting ledger as the reference. Map old and new provider IDs to it, retain historical records, and reconcile outstanding deposits and withdrawals before moving traffic.

Rebuild the provider-specific pieces: credentials, wallet mappings, invoice creation, status handling, reconciliation, and any embedded screens or reward logic. Do not assume a ZBD gamertag, hosted account, verification result, or rewards balance transfers automatically into Voltage.

Fund or approve the new deployment first. Route a small cohort through it, keep the existing integration available for rollback, and expand only after balances and payment results reconcile. Resolve uncertain sends before allowing a second provider to pay the same withdrawal.

You may decide to use both for separate jobs. For example, one product could serve a rewards experience while another serves platform-level Lightning payments. That is an architecture choice requiring separate integrations, not a claim of a native Voltage–ZBD integration.

Make the decision around the work your team needs to own

If your game needs a packaged rewards experience, ZBD belongs on the shortlist. Its SDK and embedded payout products address work that would otherwise sit with your team.

If your platform needs Lightning deposits and withdrawals with an operating and treasury model built around the business, that is the conversation to have with us at Voltage.

The strongest choice is the one that fits your player journey, funding requirements, and reconciliation process at a price you can verify. Start there, then prove the payment flow.