# Exploration of Push vs Pull Payments
Bitcoin uses a push based system. The payer has to initiate the payment (push) vs the payee being able to pulling the payment from the payers account. All payments in bitcoin are initiated by the one who controls the private keys, whether it's lightning or on-chain.

## 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](https://medium.com/breez-technology/waypoints-on-the-road-to-lightnings-mass-adoption-88e4148a2c3c)

### 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.

## Design Challenge

It's a design challenge ripe for bitcoin designers which is something that would also be in demand for payers (I'd like to manage/approve my subscription payments in my lightning or on-chain app vs going to each site to scan a QR code).

### 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](https://medium.com/@BtcpayServer/btcpay-payment-request-get-paid-in-bitcoin-by-sharing-a-url-803588ebe333) 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?