The problem: People say Lightning “can’t do subscriptions”, but that’s only true if you think subscriptions work like credit cards (where the merchant automatically pulls money from you). Lightning only does push payments (you send money to them). So the real question is: how do we make regular Lightning payments feel automatic and reliable for real businesses?

My Answer: It’s Not One Feature. It’s a Complete SystemMy Answer: It’s Not One Feature. It’s a Complete System

Enterprise Lightning subscriptions need 4 pieces:

1. A reusable payment address (something that doesn’t change each time)
2. User permission + automation (letting payments happen automatically)
3. Business billing tools (managing plans, retrying failed payments, sending receipts, customer portals)
4. Compliance features (audit logs, identity verification options)

Three Ways to Build This TodayThree Ways to Build This Today

Once you see it as a layered system, there are three practical approaches:

Option 1: Lightning as deposit method (works now for enterprises)Option 1: Lightning as deposit method (works now for enterprises)

• Customers add money to their account balance using Lightning
• You bill them from that balance on schedule
• It’s simple, boring, and works with existing billing systems

Option 2: Automated push payments (works now for self-custody users)Option 2: Automated push payments (works now for self-custody users)

• User authorizes your app/wallet with spending limits
• Your system requests payment on schedule
• Their wallet pays automatically if it matches the rules they set

Option 3: BOLT12 “offers” (in development — will become the standard)Option 3: BOLT12 “offers” (in development — will become the standard)

• A reusable, built-into-the-protocol payment identifier
• Closer to a real “subscription address” than today’s one-time invoices

The Reality CheckThe Reality Check

Here’s my test: If you’re manually chasing customers in month 2 or 3, you don’t have subscriptions. You have donations with reminders.

The metric that matters: Repeat payment success rate + why payments fail (wallet permission issues vs. not enough money vs. technical problems with the payment system)

Question for you: If you were buying this system for a business, what would matter most to you?

• Retention (how many customers keep paying month after month)
• Reconciliation time (how fast accounting can track everything)
• Compliance overhead (how much work to meet regulations)
• Payment failure rate (and understanding why each failure happened)
  ⸻

References

https://docs.btcpayserver.org/Subscriptions
BTCPay subscriptions: manual renewals + automatic renewals via prepaid/credit balance (LN as deposit rail).

https://docs.btcpayserver.org/Monetization/
BTCPay “Monetization” + paywall flows: subscription gating and customer portal concepts.

https://documentation.getflash.io/
Flash docs: subscription tooling + recurring-payment flows using wallet connections.

https://nwc.dev/
Nostr Wallet Connect spec: payer-authorized “pull-like” requests + rules-based automation.

https://blog.mutinywallet.com/solving-subscriptions-on-bitcoin-one-zap-at-a-time/
Mutiny’s write-up: why subscriptions are a wallet-automation problem (and how NWC patterns work).

https://github.com/lightning/bolts/blob/master/12-offer-encoding.md
Primary spec for BOLT12 offers: reusable payment identifiers (key primitive for subscriptions).

https://strike.me/en/blog/bolt12-offers/
Strike on BOLT12 offers (practical deployment + ecosystem momentum).

https://bolt12.org/
BOLT12 ecosystem tracker: who supports offers / sending / receiving.

https://getalby.com/blog/subscriptions-with-bitcoin
Alby overview: recurring Bitcoin payments and real subscription use cases.

https://support.coincorner.com/hc/en-us/articles/5785088860956-Recurring-Lightning-payments
Custodial recurring Lightning payments (baseline “ship now” approach with scheduling).