Branding guide
Voltage vs Alby Hub in white type on a blue Voltage cover.
Lightning Payments Provider5 minutes11/11/2026

Voltage vs Alby Hub: App connections or a business payment API?

Bobby Shell
Bobby Shell

Evaluate Alby Hub's connected-wallet model against a Voltage payment integration, focusing on delegated spending, subwallet obligations, and changes to app access.

When you connect an app to a Bitcoin wallet, decide how much it can spend and how you'll remove its access when you no longer need it.

Alby Hub puts that connected-wallet experience at the center of its product. Voltage Payments gives a business a payment API to connect to its own customer accounts and authorization system.

If you're evaluating an Alby Hub alternative, start with the controls you need. Alby Hub offers a self-custodial wallet with app connections, budgets, and subwallets. With Voltage, you integrate payments into your backend and choose a funding model. Keep a working Alby setup unless switching solves a specific problem.

What permission does the application receive?

Alby Hub supports app connections with permissions and spending budgets. Nostr Wallet Connect, or NWC, lets applications request operations from a connected wallet.

Consider a business connecting a service that makes small Bitcoin payments on its behalf. The owner wants to set a spending budget, retain control of the wallet, and disconnect the service when the job ends.

Now consider an exchange customer pressing Withdraw. The exchange has to authenticate that customer, check their account balance, approve the request, and submit the payment. With Voltage, your backend owns that customer authorization and links the payment to the exchange ledger.

You can use either product from a server. Alby's SDK examples cover Node.js and browser applications, including invoice creation and sending. Your choice depends on how you want to grant and manage spending access.

Who controls the money in a subwallet?

Alby Hub's subwallets let one Hub track balances for separate people or projects. Its interface also shows whether the operator's assets cover those balances.

The Hub operator controls the underlying wallet. Creating a subwallet doesn't give its recipient a separate node and independent Bitcoin keys. If you offer accounts to other people, explain who controls the funds and who must restore service if the Hub becomes unavailable.

This is a different requirement from embedding a user-controlled wallet into an application. If that is your project, the Voltage vs Breez SDK comparison examines wallet integration and signing more directly.

Receiving capacity can be arranged for you

Its v1.23.0 release introduced just-in-time channels. The current backend documentation describes LDK/LSPS2 configurations in which a provider opens a channel for an incoming payment when needed and deducts the fee from that payment. Check the provider, amount limits, and fees for your chosen setup.

Separate three things in the evaluation: on-chain funds, spendable Lightning balance, and receiving capacity. A wallet can have Bitcoin without having the capacity or route required for a particular Lightning payment.

For Voltage, operational ownership depends on the implementation. Node-backed customers retain node-level custody and responsibilities covering funding, monitoring, treasury, and credentials. An eligible credit-backed arrangement removes customer operation of the underlying node and channels. Credit availability and commercial terms are agreed separately.

Test spending limits and revoked access

Try a payment above the app's budget, then remove its access and try another request. Check that the app explains what happened and that your records show the correct balance.

Evaluation caseAlby Hub implementationVoltage implementation
A connected service tries to exceed its allowanceTest the configured connection budget and the application's responseTest your application's customer or service spending policy before it submits a payment
You withdraw access from a serviceTest connection revocation and subsequent requestsTest the relevant application authorization and API-access changes
A recipient's invoice expiresConfirm the error reaches the app and no success is shownTrack the payment outcome and keep the ledger consistent
A response is lost after submissionResolve the original payment's state before initiating anotherLook up the original payment ID before retrying the business action
A notification arrives more than onceEnsure the application applies the financial effect onceVerify webhook authenticity and deduplicate ledger updates

Run these checks against the controls available in your chosen setup. After revoking access, check requests already submitted; don't assume revocation canceled them.

For the underlying send-and-receive check, use the same invoice amounts and fee assumptions on each side. With Alby, create a receiving request through the intended NWC connection, confirm receipt, and submit a separate outgoing invoice using the available balance.

With Voltage, supply a unique ID to the receiving API and credit the customer after confirming completed. Follow the outgoing request through the sending API. Authenticate webhook callbacks before using them to update your records.

Estimate cost from the connections you actually need

Start with one month of the proposed service: the same incoming and outgoing payments, amounts, peak demand, and availability requirements. Then list the number of Hub instances, connected applications, and subwallets that design requires.

Alby's published plans include free use and an optional Pro subscription, and advertise no added transaction fee. Hosting, network and liquidity charges, paid features, maintenance, and recovery still belong in the budget. Choose the plan around its actual allowances rather than assuming every subwallet or backup feature comes with free use.

For a Voltage proposal, describe the equivalent payment activity and the funding model you want. Include any application work needed to replace the connection-budget or subwallet experience you currently use. Ask for applicable usage charges, minimums, funding costs, and support terms.

If Alby's wallet controls meet your needs, include the cost of rebuilding them before deciding to switch. If your business already has its own authorization system, compare the work needed to connect each product to it.

Moving away from Hub means replacing the connections

An NWC connection won't become a Voltage API credential. Inventory each connected app, the operations it uses, its budget, and the account or subwallet it serves. Decide how that application will authenticate and authorize payments in the new design.

Keep payment history and old identifiers available for reconciliation. Moving new activity to another service doesn't transfer existing channels or invoices. Keep the old wallet running until outstanding payments settle or expire, and resolve uncertain payments before resubmitting them.

Pilot one connected service before moving the rest. Test its normal spending pattern, access removal, restart behavior, and support records. For a subwallet service, also reconcile the balances owed to users against the funds supporting them.

You can keep Alby Hub for connected apps and use Voltage for separate business payments. Your team would maintain both integrations; there is no native connector established by this comparison.

If the part you want to change is the backend for customer deposits and withdrawals, bring us that application flow. If the connected-wallet experience is already working well, preserve it and focus on the specific limitation you're trying to solve.

Based on primary documentation reviewed November 10, 2026. Alby features depend on the backend and deployment. We did not run the proposed payment, performance, or migration tests.

Build Lightning payments with Voltage

Talk with our team about your payment flow, integration needs, and path to production.

Schedule a strategy session