Project Idea: On-chain + Lightning Subscriptions

This topic keeps coming up so thought I'd copy over
an old "design challenge I posted a few years ago
in Bitcoin Design. Shout out to @abhiShandy over on Twitter
for getting me excited about this one again and @nothingmuch
for the months of research calls!

In Bitcoin the payer has to initiate the payment or push it to the receiver vs the receiver being able to pull the payment from the payers account. All payments in bitcoin are initiated by the one who controls the private keys.

Pull Payments

Pros

Pull Payments are fundamental to the subscription business model, it creates a predictable cash flow for the business which is reasonable. There are also consumer benefits to Pull Payments as the UX of not having to go to each service provider in order to pay for the next period of service is certainly more convenient.

Cons

This is where the benefits end. With pull payments the payer authorises the payee to be able to take funds out of their account at the beginning of the relationship - then, subsequent payments can be taken whenever the payee wants to make a charge.

Payees take advantage of this authorisation (with credit/debit cards it usually lasts until the cards expire) and use dark patterns to capture recurring payments for a longer period of service than is usually required.

The current on-demand model is inefficient. Someone who just wants a little milk in her morning coffee doesn’t subscribe to a cow 24/7, and we pay for the electricity we use, not for the privilege of having outlets just sitting in the wall. However, transaction fees and the one-size-fits-all monetisation schemes of big streaming services like Netflix, YouTube, and Spotify prohibit paying for only small, individual segments of content.

Roy from Breez

Dark Pattern: Free Trials

A trial period provides the incentive to request the initial authorisation, and the lack of central authorisation management for the payer provide the payee with the means to lock in the payer. The payer is left having to look up transactions which can have obscure memos to determine who the service provider is, then track them down and request them cancel (phone, web page, etc).

While people familiar with traditional financial services coming to Bitcoin may find its Push Payments limiting in this business model, the design of solutions is already a raising trend with challenger banks which are now providing subscription management features.

NOTE: This kind of service/tool is not new by the way, we are just seeing it becoming available to the masses. Businesses have had access to such expense management tools of their own for a few years now.

Recreating Pull Payment Flows in Bitcoin

There are potential solutions that don't require any protocol change, or trusted third parties. Just some work on the bitcoin application to keep track of renewal dates and a set of addresses or invoices to pay. The main idea, is the payer authorises first, and this authorisation can even be scheduled and batched.

We can also take this even further - e.g. pay per use but it's out of scope for this discussion but we should have alignment that:

Lightning is P2P and so cheap that nothing stands in the way of a micropayment for a five-minute video, a three-minute song, or a 10-second segment of a podcast.

Research & Design Challenge

How might we manage/approve subscription payments in a lightning or on-chain app so that the customer is not forced to visit each site to scan a QR code for renewal. It's a design challenge ripe for bitcoin designers, and we should try to solve if we do not want to recreate the same problems with pull payments as friction drive demand by payers.

Some references

Questions

Opening this up for discussion so we can explore this topic together.

Does control really trump convenience? Thoughts on the in/convenience as payers would have to authorise a payment instead of it automatically being taken?
Any research to back it?
Are there any examples already in bitcoin we can use to inspect and reference on the payer side? (e.g. btc pay server and lnurl-pay demonstrates this on the merchant side).
What are some of the technical constraints that need to be considered?
How does this fit into the overall payment experience?
Other things besides subscriptions that rely on pull payments worth mapping to bitcoin?