A business can accept crypto subscription payments in Bitcoin, but the billing cycle works differently from that of cards. Bitcoin has no pull mechanism, so a merchant cannot debit a customer's wallet on its own initiative. Recurring charges are built instead from scheduled requests, pre-funded balances, delegated wallet permissions, or reusable BOLT12 offers.
Crypto Subscription Payments in Bitcoin
A business can take crypto subscription payment in Bitcoin, provided the design accounts for one architectural fact: the merchant automates the request, and the customer or the customer's wallet completes the payment.
There are 4 workable models today: scheduled invoices delivered each cycle, pre-funded balances the platform draws from, delegated wallet authorisation such as Nostr Wallet Connect, and BOLT12 offers at the protocol level. Lightning makes all of them practical for small tickets, because settlement completes in under 1 second and network fees sit below $0.01, so weekly or even daily billing cycles are not eaten by processing costs.
This is technical and commercial guidance, not legal, tax, or accounting advice.
Why Bitcoin Has No Pull Payments
A Bitcoin or Lightning payment is always initiated by the funds' holder. The payee can publish a request, an invoice, or an offer, but it cannot move value on its own authority. Card networks and direct debit work the other way round: they are pull systems.
Three things make a card subscription possible, and Bitcoin has none of them: a scheme rulebook defining how a stored credential may be re-presented, a card-on-file token or a direct debit mandate that the merchant submits again next cycle, and an issuer that authorises the debit on the merchant's instruction. There is no issuer, no credential to store, and no mandate registry, so there is nothing to re-present.
| Info: The absence of pull payments is why Bitcoin has no chargebacks, and also why a merchant cannot charge a customer without a fresh act of consent. Both properties come from the same design decision. |
The practical consequence is that there is no network-level retry. When a card payment fails, the scheme and the acquirer retry on the merchant's behalf. On Lightning, retries, reminders, and access control are application logic that the business owns.
4 Ways to Run Crypto Recurring Payments on Lightning
Each model trades customer effort against automation, and the price of more automation is either custody or wallet dependency.
Scheduled Invoices and Payment Links
The merchant runs a scheduled job that creates a new Lightning invoice at the start of each billing period and delivers it via email, in-app notification, or the dashboard. The customer taps once to pay, and the platform unlocks access when the settlement event arrives from its Bitcoin Lightning payment gateway. Payment links are the low-code variant, with a link generated and sent instead of an embedded checkout.
This model is the most widely supported because it requires nothing beyond a wallet capable of paying a standard invoice. The cost is 1 customer action per cycle, which is where churn creeps in on low-value plans.
Pre-Funded Balances with Automatic Deduction
The customer tops up a balance, and the platform deducts each cycle's charge from it. Automation is close to total, and it suits usage-based billing, where the amount is not known in advance, with the territory covered in more detail through micropayments on the Bitcoin Lightning Network.
The trade-off is custody. Holding customer money is an operational and regulatory commitment before it is a technical one: reconciliation, refunds of unused balance, safeguarding obligations, and the accounting treatment of funds that are not yet revenue.
Delegated Wallet Authorisation (Nostr Wallet Connect)
Wallets that support Nostr Wallet Connect allow a customer to grant an application-scoped spending permission, typically with an amount cap, a time budget, and an expiry. The application then requests payment each cycle without a manual tap, while the funds remain in the customer's wallet, making it a non-custodial middle ground for recurring Lightning payments.
Coverage depends on the customer's wallet supporting the protocol, which narrows the addressable base. And because a permission can be revoked at any moment, a revoked or exhausted budget is a distinct failure state from an unpaid invoice and needs its own handling in the billing logic.
BOLT12 Offers: Recurring Lightning Payments at Protocol Level
BOLT12 introduces offers: reusable, static payment codes that a payer can use to fetch a fresh invoice, rather than the single-use invoices of BOLT11. That reusability is the foundation for recurring Lightning payments handled by the protocol instead of by email reminders.
Status matters more than potential here. At the time of writing, the offer specification is maintained in the Lightning specification repository, implementation is uneven across node software, and wallet support is partial, with recurrence not yet something a merchant can rely on. Check the spec repository and the weekly notes from Bitcoin Optech for the current position before planning a roadmap around it.
| Quick tip: Choose the model based on how much customer action per cycle the product can absorb without churning, not on how elegant the technology is. A £200 annual plan tolerates a manual tap. A £4 monthly plan does not. |
Comparing Bitcoin Subscription Payment Models
| Model | How It Works | Customer Effort per Cycle | Automation Level | Limitations |
|---|---|---|---|---|
| Scheduled invoices and payment links | New invoice generated and delivered each period | 1 tap to pay | Merchant-side only | Churn risk on low-value plans, invoice expiry management |
| Pre-funded balances | Customer tops up, platform deducts | Occasional top-up | High | Custody, safeguarding, and reconciliation |
| Delegated wallet authorisation | Scoped spending permission with caps and expiry | 1 setup step | High, while the permission holds | Needs a supporting wallet, revocable at any time |
| BOLT12 offers | Reusable offer code that the payer draws invoices from | Varies by wallet | Protocol level, in progress | Partial implementation and wallet support |
SaaS businesses with contracted monthly seats and a decent average ticket do well on scheduled invoices: the value per cycle justifies the customer action, and finance teams get a clean invoice trail. Membership and community sites on annual renewals are the easiest case of all. Content and creator subscriptions at low monthly prices are where per-cycle friction hurts most, which pushes them towards delegated authorisation.
Usage-based billing tends towards pre-funded balances or a post-paid invoice at the end of the cycle. The axis is consistent: automation rises as either custody or wallet dependency rises, and average ticket size decides whether the extra engineering pays for itself.
Handling Missed Payments Without a Card Network
Dunning becomes the merchant's own system. A workable pattern ties the reminder cadence to invoice expiry and to the webhook events the gateway emits for paid, expired, and underpaid states, then maps those states to access levels rather than to immediate cancellation.
In practice: issue the invoice a few days before the period starts, remind once before expiry, re-issue at the current rate after it lapses, and apply a grace period with a soft downgrade before access is suspended. Keep quote windows short, because rate movement across a billing window is a real operational issue. For delegated authorisation, treat a revoked or exhausted permission as a re-authorisation prompt rather than a failed payment.
How to Build Recurring Billing on the ElenPAY API
A subscription business does not need a productised subscription feature to bill over Lightning. The pattern the ElenPAY team sees work is straightforward: a scheduled job on the merchant side creates an invoice per billing cycle through the REST Bitcoin payment gateway API, delivers it by email, payment link, or checkout widget, and listens on webhooks to unlock, extend, or suspend access when the payment state changes.
The billing calendar, retry policy, and grace periods stay in the merchant's application, where the commercial rules belong. ElenPAY handles the payment layer: settlement in under 1 second, network fees below $0.01, no chargebacks, and management of nodes, liquidity, and custody, with integration via REST API, payment links, a checkout widget, or white-label. Merchants and platforms using ElenPAY are licensed, regulated businesses.
Book a Technical Walkthrough for Crypto Subscription Payments
Recurring billing on ElenPAY runs through a scheduled invoice per billing cycle, webhook events that drive access, and a payment layer that ElenPAY manages end-to-end: nodes, liquidity, and custody. A technical walkthrough maps the integration path against the model that fits the product, whether that's scheduled invoices, pre-funded balances, or delegated wallet authorisation.
To book a technical walkthrough, contact the ElenPAY team, and a specialist will map the billing model and integration path for your specific product.
Crypto Subscription Payments: FAQs
Do customers need a specific wallet for recurring Lightning payments?
It depends on the model. Scheduled invoices and payment links work with any wallet that can pay a standard Lightning invoice. Delegated authorisation requires a wallet that supports Nostr Wallet Connect, and BOLT12 requires a wallet that implements offers, so both narrow the addressable audience.
Can a subscription be priced in USD or EUR and paid in Bitcoin?
Fiat-denominated pricing with Bitcoin settlement is the normal approach, because customers understand a monthly figure in their own currency. The amount is converted to satoshis at invoice creation and held for the life of that invoice, which is why short expiry windows and re-pricing on re-issue matter. Confirm conversion behaviour with the payment provider before building the billing logic.
What is BOLT12 and does it enable subscriptions?
BOLT12 is a Lightning specification proposal that offers reusable payment codes a payer can request invoices against, unlike single-use BOLT11 invoices. Reusability is what makes protocol-level recurrence possible in principle. Implementation and wallet support are still partial, so check the Lightning specification repository for the current position before designing around it.
Are crypto subscription payments custodial or non-custodial?Your answer here.
That depends on the model, not on Bitcoin. Scheduled invoices, delegated authorisation, and BOLT12 offer all leave funds to the customer until each payment is made. Pre-funded balances are custodial by definition because the platform holds customers' money in advance and assumes the safeguarding and reconciliation duties that follow.
Can a customer cancel a Bitcoin subscription at any time?
Yes, and more decisively than with cards. With invoice-based billing, the customer simply stops paying the next invoice, and with delegated authorisation, the permission can be revoked in the wallet without contacting the merchant. Treat cancellation as a normal event in the billing state machine and monitor revocations as a churn signal.