Thinking about how to architect re-occuring payments on Bitcoin. Feels like an unsolved problem.
Discussion
The credit-card style recurring payments are certainly not what clients want. With Bitcoin we can do better. We could have Bitcoin wallets that do payments upon request from authorized entities where the user sees:
* Spotify may pull up to $15/month
* Uber may pull up to $100 per transaction, $100 per day, $300 per month
* ...
And that wallet should:
* Show a notification when limits get exceeded: Uber requested $12, exceeding your $300/month limit by $5. Do you want to increase the limit to $305, allow only this payment now or decline this payment
* Suggest lowering limits if not used: Spotify hasn't requested payments in 3 months. Allowance removed. Click to undo.
* Permit to manually change or remove allowances.
Payments would still be push payments but the payer would be in control. No bogus charges where you have no idea who did them. No hours on some hotline to get your subscription canceled. Etc.
Sounds like nostr wallet connect with pre-defined limits
Yes, I like this line of thinking. A richer experience around control would be great.
But, need to keep merchants in mind too.
Needs to be win-win.
I think the clients should be able to control, on a per-merchant, or per invoice-feed, basis if the payment is automatically paid. And merchants should be able to programmatically supply deadlines, if the payments aren't made by a certain time, then service may be encumbered. The wallet could use this information, to conditionally auto-pay an invoice, if the invoice hasn't been rejected manually by a certain point in time. Of course all of this behaviour should be user configurable.
Are you also working on this problem?
Not sure if I'm following you. With my Uber configured, I'd usually confirm paying only within the Uber app. My wallet would get notifications and issue payments. If my wallet is not reachable, Uber would tell me that payment failed like it does with an expired CC resulting in the ride not getting booked.
Now my webhoster might not instantly delete my stuff the second my wallet doesn't play along. It could send me a warning email that a payment failed and how it will be re-tried tomorrow etc. again like it does with CC.
All this is compatible with my proposal. What are you missing?
No, I am not working on this but I hope to use this asap instead of CC ;)
I think we are saying the same thing. Ie, fine-grained control.
Important to consider binning the use cases, maybe?
Uber - on-demand, pay-per-use.
Rent/Mortgage - non-negotiable.
Internet Bill - fixed amount, specific day per-month.
Water Bill - variable/consumption based, non-negotiable, specifc day
V4V/charity - completely optional
...just thinking outloud.
Fine line between "budget"-setting features and "trusted-invoicer"-features.
So lets say you rent a car. The company would take your CC and "threaten" to charge it if you return the car dirty or scratched or whatnot. With a Bitcoin wallet I could remove any allowance the minute I receive the key.
For this insurance use case, the wallet would require me to lock up funds with the company. Maybe 2-of-3 with a trusted third party. I see no other way than to involve a third party to force the client's payment.
Of course the third party could also be a respected insurance where the car company would trust to get a payment. This would allow the client to avoid locking up $10k for a car rental in exchange for paying some monthly fee for example.