Recurring Payments on Lightning: How BOLT12 Offers Enable Subscription Billing

Subscription billing is the backbone of modern software, media, and services. Netflix, Spotify, AWS, and thousands of SaaS companies depend on the ability to charge customers on a recurring schedule. On traditional payment rails, this is straightforward: a merchant stores a card on file and initiates charges each billing cycle. On the Lightning Network, it has been nearly impossible.

The problem is structural. BOLT11 invoices are single-use and expire, meaning a merchant cannot simply "charge" a customer again next month. Every payment requires the recipient to generate a fresh invoice and the sender to actively pay it. BOLT12 offers change this by introducing static, reusable payment endpoints with native support for recurrence parameters: the first credible path to subscription billing on Bitcoin.

Why BOLT11 Cannot Support Subscriptions

To understand why recurring payments on Lightning required a new protocol, it helps to examine the limitations of BOLT11 invoices. Each BOLT11 invoice contains a single payment hash tied to a single preimage. Once paid, the invoice is consumed. Paying it again would reuse the same hash, creating a security risk where any routing node that saw the original preimage could intercept the second payment.

Single-Use by Design

BOLT11 invoices are fundamentally one-shot. The invoice encodes a specific amount, a specific payment hash, and an expiration timestamp (defaulting to one hour in most implementations). After expiration, the invoice becomes invalid. After payment, the preimage is revealed to the network and the invoice should never be reused. There is no mechanism in the BOLT11 specification to say "pay this again next month."

The Server-Side Invoice Loop Workaround

Services that want recurring Lightning payments today must build custom infrastructure: a server that generates a fresh BOLT11 invoice each billing cycle, notifies the customer (via email, push notification, or in-app prompt), and waits for the customer to manually pay. This is not a subscription in any meaningful sense. It is a series of one-time payments that the merchant hopes the customer will remember to complete.

The failure modes are significant. Customers forget to pay. Invoices expire before they are seen. The merchant needs a persistent server generating invoices and tracking payment state. There is no standard protocol for any of this, so every implementation is bespoke.

The core limitation: BOLT11 invoices are pull-request artifacts in a push-payment system. The recipient must initiate each invoice, and the sender must be online to pay it. Neither side can automate the cycle without custom infrastructure outside the Lightning protocol.

How BOLT12 Offers Work

BOLT12 introduces a new primitive called an offer. Unlike a BOLT11 invoice, an offer is a static, reusable payment endpoint. It does not contain a payment hash or expiration by default. Instead, it describes the terms under which the recipient will generate invoices on demand. Offers are encoded as bech32-formatted strings with the lno1 prefix (on mainnet) and can be embedded in QR codes, printed on physical media, or published on websites.

The Three-Step Protocol Flow

BOLT12 replaces the simple "decode invoice, pay invoice" model of BOLT11 with a three-step negotiation:

1. The recipient creates and publishes an offer containing payment terms: currency, amount (fixed or variable), description, and optional recurrence parameters. The offer includes a blinded path so the recipient's node identity remains private.
2. The sender's wallet reads the offer and constructs an invoice_request message. This message is encrypted and sent to the recipient via onion messages, a new messaging layer that does not require a payment channel between the two parties.
3. The recipient's node validates the request and returns a fresh invoice with a unique payment hash, proper amount, and expiration. The sender's wallet then completes the payment using standard HTLC forwarding.

This flow means the recipient never needs to manually generate invoices. The offer acts as a standing instruction, and the protocol handles invoice creation automatically when a payer requests one.

Recurrence: Native Subscription Support

The most significant feature of BOLT12 for subscription billing is the recurrence parameter set. While the formal BOLT12 specification merged into the Lightning spec in October 2024 marks recurrence as a future extension, Core Lightning has fully implemented these fields and they are functional in production.

Recurrence Parameters

The recurrence system uses four parameters that a merchant encodes directly into the offer TLV structure:

An optional proportional amount feature allows the first period to be prorated. If a subscriber starts mid-cycle, the initial invoice amount scales proportionally to the remaining time in the period, similar to how traditional billing systems handle mid-cycle signups.

Payer Identification and Period Tracking

Each recurring payment series is identified by a payer_key: a 32-byte secret the sender includes with every invoice request. This allows the recipient to associate payments from the same subscriber across periods. A period counter increments after each successful payment, preventing duplicate charges within the same billing cycle. The recipient's node will not generate an invoice for period n+1 until period n is paid.

A Subscription Flow in Practice

Consider a media service offering a monthly subscription for 50,000 satoshis. Here is how the flow works end to end:

Step 1: Merchant Publishes an Offer

The merchant creates a BOLT12 offer with a fixed amount of 50,000 satoshis, a recurrence interval of 1months, and optionally a recurrence_base aligned to the first of each month. The offer string (starting with lno1...) is displayed on the signup page as a QR code.

Step 2: User Subscribes

The subscriber scans the offer with a BOLT12-compatible wallet. The wallet recognizes the recurrence parameters and prompts the user: "This merchant is requesting a recurring payment of 50,000 sats per month. Approve?" The user confirms, and the wallet sends the first invoice_request with a generated payer_key.

Step 3: Automated Recurring Payments

Each month, the wallet automatically sends a new invoice_request to the merchant's node via onion messages. The merchant's node validates the payer_key, checks the period counter, generates a fresh invoice, and returns it. The wallet pays the invoice automatically from the user's balance.

Step 4: Cancellation

The subscriber cancels by instructing their wallet to stop sending invoice requests. Because Lightning payments are push-based, the merchant cannot unilaterally charge the user. No invoice request means no invoice means no payment. The subscriber is always in control.

Push vs. pull: Traditional subscription billing is a pull model: the merchant initiates charges against stored payment credentials. BOLT12 recurring payments are push-based: the subscriber's wallet initiates each payment. This eliminates unauthorized charges but requires the payer's wallet to be active and online at billing time.

UX Challenges for Wallet Developers

While BOLT12 provides the protocol-level machinery for recurring payments, significant UX challenges remain for wallet developers building subscription support.

The Online Requirement

The payer must be online and have sufficient balance when each periodic payment is due. Unlike a credit card stored on file that can be charged at any time, a Lightning wallet needs to actively construct and send the invoice request, receive the invoice, and complete the HTLC payment. For mobile wallets, this means background execution capabilities, which are constrained by iOS and Android power management policies.

Background Payment Scheduling

Wallets need a reliable scheduler that can wake the app, establish a connection to the Lightning node, send an onion message, wait for a response, and execute a payment: all while the phone may be locked, sleeping, or on a poor network connection. Android's WorkManager and iOS BackgroundTasks API provide limited guarantees about execution timing, making precise billing-cycle adherence difficult.

Failed Payment Recovery

When a scheduled payment fails (insufficient balance, routing failure, wallet offline during the pay window), the wallet needs a retry strategy. The recurrence_paywindow parameter defines how much slack exists, but wallets must handle the case where the window closes before a successful payment. Should the wallet notify the user? Retry automatically? Skip the period? These UX decisions are not specified by the protocol.

Implementation Status Across Lightning

BOLT12 support varies significantly across Lightning implementations. As of mid-2026, the landscape is fragmented:

The fragmentation matters because recurring payments require both sender and receiver to support BOLT12 offers and onion message routing. A CLN merchant with a perfectly configured recurring offer cannot bill an LND user whose node does not forward onion messages. The LNDK sidecar project bridges this gap by adding BOLT12 capabilities to LND nodes via LDK, but adoption remains limited.

Comparison With Traditional Subscription Infrastructure

Traditional subscription billing has decades of infrastructure behind it. Understanding where BOLT12 recurring payments stand relative to established systems clarifies both the opportunity and the gap.

The push-payment model is both BOLT12's greatest strength and its largest UX gap. Consumers accustomed to "set and forget" subscriptions must now trust their wallet software to handle payments autonomously. Merchants accustomed to guaranteed charge attempts must accept that a subscriber's wallet being offline means a missed payment.

Where BOLT12 Subscriptions Make Sense Today

Given the current maturity of BOLT12 recurrence support, certain use cases are more viable than others.

Strong Fit

• Digital content and API access where the subscriber runs a persistent Lightning node (developers, node operators, power users)
• Mining pool payouts on a regular schedule, where both parties run server-side infrastructure (OCEAN mining pool already uses BOLT12 offers for this purpose)
• Donations and recurring contributions to open-source projects, podcasters, or content creators where occasional missed payments are acceptable
• Machine-to-machine payments between always-on services: IoT devices, API gateways, and cloud infrastructure billing

Poor Fit (For Now)

• Consumer mobile subscriptions where the user expects zero interaction after signup
• Compliance-heavy subscriptions requiring invoicing with tax IDs, legal entity names, and jurisdiction-specific formatting
• Fiat-denominated subscriptions where Bitcoin price volatility makes sat-denominated billing impractical without real-time conversion

The Role of Stablecoins and Layer 2 Protocols

Bitcoin price volatility is a practical barrier for subscription pricing. A subscription priced at 50,000 sats could cost $25 one month and $35 the next. Two approaches address this.

First, BOLT12 offers support currency fields that allow denominating the offer amount in fiat (e.g., USD) while settling in satoshis. The invoice amount adjusts each period based on the current exchange rate. This requires a price oracle, introducing a trust dependency, but solves the pricing problem at the protocol level.

Second, stablecoin layers built on Bitcoin sidechains and Layer 2 protocols can denominate subscriptions directly in dollars. Spark, for example, supports native token issuance including stablecoins like USDB. A subscription service built on Spark could price plans in dollar terms, settle instantly, and avoid the volatility problem entirely. Spark's architecture also eliminates the channel management and liquidity constraints that complicate Lightning-based subscription infrastructure.

Beyond BOLT12: Other Approaches to Recurring Bitcoin Payments

BOLT12 recurrence is not the only approach to subscription billing on Bitcoin. Several complementary and competing models exist.

LNURL-pay with Stored Offers

LNURL provides a server-side approach where a merchant hosts an HTTP endpoint that generates BOLT11 invoices on demand. Wallets can store the LNURL endpoint and prompt users to pay periodically. This works today across most Lightning wallets but requires the merchant to run an HTTP server, lacks protocol-level recurrence semantics, and depends on the LNURL server being available. It is a workaround rather than a native solution.

Custodial Subscription Services

Custodial Lightning services can implement subscription billing by holding user funds and debiting them on a schedule. This mirrors the traditional pull-payment model but sacrifices self-custody. The user trusts the custodian not to overcharge, steal funds, or become insolvent.

Payment Streaming

Payment streaming takes a different approach: instead of periodic lump-sum payments, value flows continuously at a defined rate (e.g., 100 sats per minute of content consumed). Projects like Podcasting 2.0 use keysend payments for streaming sats, but this requires the sender to be continuously online and does not map well to fixed-price subscription models.

What Needs to Happen Next

For BOLT12 recurring payments to reach mainstream viability, several pieces need to fall into place.

• Recurrence fields need formal standardization in the Lightning specification. Core Lightning's implementation proves the concept works, but interoperability requires all major implementations to agree on encoding.
• LND needs production-grade BOLT12 support. As the most widely deployed Lightning implementation, LND's experimental-only status limits the addressable market for BOLT12 merchants.
• Consumer wallets need background payment capabilities with clear UX for managing, pausing, and canceling subscriptions.
• Onion message routing coverage must expand across the network. Without reliable message delivery between arbitrary nodes, the offer-to-invoice-request flow fails silently.
• Merchant tooling needs to emerge: dashboards for tracking subscriber status, period payment rates, churn, and revenue analytics.

For developers building on Bitcoin payment infrastructure today, the Spark SDK offers an alternative path to recurring payment models with instant settlement and no channel constraints. Explore the recurring stablecoin payment infrastructure research for a deeper look at subscription billing patterns using stablecoin rails.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.