Voltage vs LNbits: Keep your wallet accounts or replace the stack?

If you use LNbits, replacing it means deciding what happens to your customers' balances, your API integration, and any extensions they use. You may only need a different funding backend. You may need to replace the account system too. Estimate those as separate projects.

If you're looking for an LNbits alternative, first identify what you want to change. Keep LNbits when its accounts and extensions are doing useful work. Evaluate Voltage Payments when your application should own those customer workflows and needs a business payment API underneath them. If only node operations need attention, investigate the backend separately before planning an application rewrite.

LNbits separates customer balances from the funding source

LNbits provides wallet accounts, payment APIs, and an extension system above a Lightning funding source. Each wallet has its own recorded balance and permissions, while the instance uses a shared backend to move Bitcoin.

Imagine a platform using LNbits to give several merchant projects their own wallets. One project takes payments through an extension; another creates invoices directly through the API. Those projects have separate application records even though their Lightning payments ultimately reach the same funding source.

If you replace LNbits, your application needs to preserve those account balances, permissions, and extension workflows.

A wallet API key grants access to LNbits functions. It doesn't give its holder an independent Bitcoin private key. Custody depends on who controls the instance and the underlying funding source. LNbits account and funding model.

Identify which part of LNbits you want to change

Use this inventory before requesting a replacement quote:

LNbits offers self-hosted, hardware, and hosted options. Moving from a self-hosted instance to hosted LNbits is therefore another option to evaluate alongside replacing the application.

List the extensions your customers depend on, what they cost, and who maintains them. Include their code and data in your migration plan.

Where Voltage fits in this architecture

Our Payments API lets your backend create payment requests, send Bitcoin, and track payment activity. Your business connects those records to customer accounts and authorizes the actions its customers can take.

If you already maintain customer balances and permissions in your application, you can connect our API to those systems. If LNbits supplies them today, budget for rebuilding them.

The Voltage funding model determines the operating responsibilities. With node-backed Payments, your organization retains node-level custody and responsibilities for funding, monitoring, treasury, and credentials. In an eligible credit-backed deployment, your team doesn't operate the underlying Lightning node. Agree the service scope and commercial terms for the path you need.

Can you use LNbits with a Voltage-hosted node?

LNbits documents an LND REST backend. Voltage documents direct LND access for hosted nodes. Those capabilities suggest a possible way to keep LNbits while changing where the node runs.

They don't establish a tested, jointly supported connector for every deployment. Validate the LNbits version, endpoint, TLS configuration, macaroon permissions, and support ownership before using that arrangement.

In that setup, your application would continue calling LNbits, and LNbits would call LND. Using the Voltage Payments API would require a separate integration.

Prove that each merchant gets the correct balance

Have one merchant receive a deposit and request a withdrawal. Check that both payments affect the correct account.

With LNbits, create the invoice in the intended wallet and retain its payment identifier. Confirm payment through the Payments API before applying any corresponding credit in your business ledger. Test that another project's credentials cannot spend from that wallet.

For a Voltage implementation, your application maps the merchant to the appropriate account records and wallet configuration. Supply a unique ID when creating the receive request, confirm completed, and apply the ledger credit once. Authorize the merchant's withdrawal in your application before submitting it through the sending API.

Use sufficient receiving and sending capacity, and allow for fees. Verify Voltage webhook signatures, exercise duplicate notifications, and check the original payment after a timeout before initiating another withdrawal.

For each test, record the account, the payment, the resulting balance, and the credentials that authorized it.

Budget for the functions you would have to rebuild

Price the same month of merchant activity under both designs. Hold the number of active accounts, invoice requests, completed payments, withdrawal amounts, and peak traffic constant. Include the extensions or equivalent application features those merchants need.

LNbits has no software license fee, but the deployment can include hosting, backend services, liquidity, network costs, extension charges, and maintenance. Its administrator can also configure service fees and routing-fee reserves. Distinguish a reserved amount from a final fee when reconciling costs.

Voltage pricing requires a proposal for the selected deployment and usage. Put that proposal beside the cost of any account, permissions, or extension work your engineers would take on. Include funding costs, support coverage, minimums, and overages where applicable.

Keeping LNbits may save you from rebuilding a checkout or account system your merchants already use. If your app maintains the same account records separately, compare the cost of maintaining both systems with the cost of removing one.

Preserve account history while moving payment activity

Changing a funding-backend setting doesn't move Bitcoin, Lightning channels, or existing invoices to a new node. Reconcile funds and account balances separately.

For an application replacement, map old wallet IDs to the new account records before cutover. Preserve extension data and payment history. Keep the old backend available while outstanding payments settle or expire, and stop overlapping payout workers from acting on the same withdrawal.

Start with a limited group of merchant projects. Check their balances, permissions, payment links, and support records before expanding. Rollback must specify where new requests go and how you will resolve payments already in flight.

If the larger question is whether to operate Lightning infrastructure internally at all, our Voltage vs DIY Lightning article addresses that broader decision. Here, the extra work is preserving the accounts and applications you've built with LNbits.

Bring your wallet and extension inventory to a strategy session. We can work through whether to retain LNbits, evaluate a compatible backend, or build a new payment integration around your existing customer accounts.

Based on primary documentation reviewed November 10, 2026. The merchant example is hypothetical; we did not run live integration, performance, or migration tests.