Voltage vs Breez SDK for Lightning payments and embedded wallets

Your app needs to receive bitcoin and let users spend it. Before comparing payment fees, decide who should control the money and who should operate the payment system.

Choose Voltage when your business needs Lightning deposits and payouts integrated with its own accounts, treasury, and reconciliation. Our Payments API supports credit-backed and customer-controlled node-backed deployments. Choose the operating model deliberately; they carry different responsibilities. Voltage implementation paths

Choose Breez SDK when a user-controlled wallet is part of the product you want to build. Its current Spark implementation brings Lightning payments and other supported payment flows into an app or service without requiring a Lightning node per user. Your team still designs the signing, recovery, storage, and payment experience. Breez SDK overview

Keep your current architecture when it already delivers the custody promise and payment experience your users expect. Switching a working self-custodial wallet to a platform balance, or the reverse, is a product change with consequences for users. A different API or a lower advertised fee is not enough reason on its own.

This comparison is written by Voltage and based on public documentation and release-source review, not a hands-on performance benchmark. It compares Voltage Payments API v1 with Breez SDK’s Spark implementation, using release 0.26.1 as the release reference alongside the documentation available on October 20, 2026. Breez release 0.26.1

Start with control of funds

Imagine two apps with the same “Send bitcoin” button.

In the first, a customer requests a withdrawal from a balance recorded by the business. The business approves it, submits the payment, and reconciles the result to its ledger. In the second, the user controls the wallet’s spending authority and authorizes the payment directly.

Those screens can look identical. The ownership and recovery obligations behind them are different.

We built Voltage Payments to give businesses a payment API around their operating model. In the credit-backed path, Voltage supplies a credit line and the customer does not manage the underlying node credentials or channels. In the node-backed path, the customer controls the node credentials and funds; direct node movements must also be reconciled with Payments API activity. Neither description, by itself, promises a separate self-custodial wallet for each end user. Credit-backed implementation, node-backed implementation

Breez supports a different starting point: embedding a wallet whose spending key can stay with the user. Its client-signing flow lets a server prepare a payment while the user reviews and signs it before publication. Client signing is opt-in, so running the SDK on a server does not automatically establish that the server lacks spending authority. Breez client signing

The useful question is: who can approve a payment, and what happens if that person, device, or service becomes unavailable? Put the answer in your architecture before choosing the integration.

Compare the current Breez implementation

Breez’s documentation now directs new integrations to Spark and recommends that existing Liquid integrations move to Spark. Treat older Greenlight or Liquid descriptions as implementation-specific history, not a description of the current recommended SDK. Breez Liquid notice

The Spark SDK is nodeless from the integrating app’s perspective. It supports Lightning interoperability, Spark payments, and Bitcoin on-chain flows. That does not make Spark transfers and Lightning payments the same transaction type. Breez documents that an invoice containing a Spark address can be paid directly over Spark when the payer supports it. A fair Lightning comparison must record which route actually carried the payment. Breez receiving, Breez sending

Breez also belongs in server-side evaluations. Its treasury configuration is a single wallet owned by a service, while its multi-user configuration hosts many wallets with short-lived SDK instances. The latter makes the host responsible for synchronization, claims, and event delivery. It is inaccurate to dismiss Breez as mobile-only or incapable of treasury use. Treasury configuration, multi-user configuration

What each integration leaves with your team

Sources: Voltage API reference, access, webhooks, wallet reports, pricing; Breez setup and languages, payment history, server configuration, cross-chain routes.

Separate bitcoin payments from dollar and stablecoin features

A USD-denominated credit wallet, a stablecoin balance, and a USDC payment to an external chain are different things.

Voltage’s documented USD credit send flow obtains a conversion quote and pays a Bitcoin invoice or address. The wallet’s USD denomination does not mean the recipient receives a dollar bank deposit. Credit eligibility and commercial terms must be confirmed separately. Voltage USD credit sends

Voltage’s wallet documentation identifies Voltage Cash as experimental stablecoin testing, not a live production wallet. It should not be counted as a production stablecoin equivalent in this comparison. Voltage wallet types

Breez documents Stable Balance using a Spark token such as USDB, with conversions between bitcoin and the token. It separately documents USDC/USDT transfers between Spark and supported external chains through a provider-driven route. Those routes carry their own limits, quotes, and completion state. Stable Balance, cross-chain payments

One implementation detail matters: automatic Stable Balance is not available in Breez’s multi-user server configuration. That configuration disables the background conversion worker. Explicit conversion flows can still be used, but a team cannot assume every feature from the default client configuration carries over unchanged. Multi-user configuration limitations

Scope the exact asset, chain, deployment, and recipient experience before comparing either product’s “dollar” capabilities.

Compare one Lightning payment journey

Use the same acceptance case for both: receive a 10,000-sat Lightning payment, then send a separate 10,000-sat payment to an external Lightning wallet. Provide extra funding for applicable fees. Use BTC balances and exclude conversion, Spark-only transfers, and on-chain withdrawals from this first comparison.

For Voltage, create the incoming payment request in the selected wallet, retain its payment identifier, and reconcile the completed receive. Submit a separate outgoing invoice and reconcile its final status. The documented BTC amount object uses millisatoshis: 10,000 sats equals 10,000,000 msats. Voltage receiving, Voltage sending

For Breez, initialize the intended wallet and signer, request a fixed-amount BOLT11 invoice, and record the incoming payment and fee. For the outgoing payment, prepare it, review the returned fees, then send through the appropriate signing flow. Verify that the payment used Lightning rather than a direct Spark route. Breez receiving, Breez sending

Run this test sequence and retain the results:

1. Record the SDK/package version or API environment, wallet configuration, invoice amount, and destination type.
2. Verify completed payment status and the actual credited or debited amount, including fees.
3. Exercise expired invoices, insufficient funds or available credit, delayed notifications, and a connection lost after submission.
4. Reconcile existing payment state before retrying an uncertain payment.
5. Test recovery and application restart separately from successful payment speed.

The test environments are not interchangeable. Voltage documents staging wallets for non-production testing. Breez recommends Regtest for Spark development but directs Lightning and stablecoin testing to Mainnet with small amounts because its Regtest environment does not reproduce those flows. This is an evaluation specification; no live transactions were executed for this article. Voltage staging, Breez testing guidance

Price the same workload and include the work you retain

Consider an illustrative month with 10,000 incoming and 10,000 outgoing Lightning payments, each for 10,000 sats. That is 1 BTC received and 1 BTC sent: 2 BTC of gross movement across 20,000 payments. Assume 1,000 active users, BTC balances, no conversion, and no on-chain withdrawals. These are planning assumptions, not customer results.

Breez says the SDK is free for developers and that end users pay fees to send and receive payments. Its fee guidance links to Spark’s estimates. Free SDK access should not be represented as zero payment cost. Breez end-user fees, Spark fee estimates

Voltage’s public pricing is scoped to volume, rails, and deployment rather than a fixed rate card. Request a quote for the same workload and funding model. Voltage pricing

Do not turn an example fee from a developer guide into a provider-wide rate. Without a comparable Voltage quote and measured or quoted Breez payment costs, a numerical total-cost winner would be invented.

Recovery belongs in the buying decision

Breez documents a unilateral Bitcoin exit when Spark operators do not cooperate. That is a meaningful recovery capability, with conditions: the necessary exit data must already have been collected, the user needs separate bitcoin for mining fees, and timelocks can make the process take days. The application must broadcast the transactions; the SDK builds and signs them. Small balances can also be uneconomical to exit. This is an emergency process, not a promise of an instant, free withdrawal. Breez unilateral exit

For Voltage, examine the recovery and access procedures for the implementation you actually buy. Node-backed customers retain node credentials and funds; credit-backed customers have a different operational and contractual relationship. Compare those procedures with the experience you promise users. Node-backed responsibilities, credit-backed responsibilities

Neither a custody label nor a vendor’s marketing statement settles your application’s regulatory obligations. Review the actual flow of funds, signer authority, markets, and services before launch.

Switching changes more than the payment call

Moving from Breez to Voltage can change a user-controlled wallet into a business-managed account experience, depending on the design. Do not treat users’ keys as a database export or assume the business can move funds it cannot sign for. Plan a user-authorized funds transition and explain the new ownership model.

Moving from Voltage to Breez requires decisions about wallet creation, signers, recovery, storage, and how customer balances become wallet funds. Changing providers does not transfer the business’s accounting obligations or erase unsettled payments.

In either direction, retain historical records and provider payment IDs, reconcile pending activity, and start with a small cohort. Keep enough of the old integration running to resolve outstanding payments. Test rollback before expanding, and never pay an uncertain withdrawal again simply because traffic has moved to the new provider.

Both can fit in one product: a user-controlled wallet experience and a separate business treasury/payment integration may serve different needs. That requires two deliberately designed integrations; it is not a claim of a native Voltage–Breez connector.

Choose the responsibilities that fit your business

If user-controlled wallets are central to your product, Breez SDK belongs on the shortlist. Its current Spark implementation deserves evaluation on its own terms, including its server-side capabilities.

If your business needs Lightning payments tied to platform accounts, treasury, and reconciliation, start the conversation with us at Voltage. We can scope the payment flow and the operating model together.

The right choice is the one whose ownership, funding, recovery, and support responsibilities match what you intend to build. Prove that fit first. Then compare the cost of running it.