Ok. One is reoccurring donation with no obligations or expectations. If it happens, great, if not, it’s ok.
Subscription on the other hand, promises to give you a service for a payment and the service terminates when payment is not made. 🐶🐾🫡
Ok. One is reoccurring donation with no obligations or expectations. If it happens, great, if not, it’s ok.
Subscription on the other hand, promises to give you a service for a payment and the service terminates when payment is not made. 🐶🐾🫡
Ah I see now.
I approached it with a no obligations mindset but I can see how it could be considered as a ‘this for that’ arrangement
I think subscriptions and the pull model are a compromise to the limitations of fiat. I think the internet native model should be micro payments, pay as you go, pay for what you consume. Wallets should be able to trickle out payments that way
I played with a prototype for this a while back: https://oak-node.net/doc/trunk/doc/ons/ons-4.md
If there's any service provider interested, LMK and I could revive it.
Essentially comes down to:
- offer a LN address where customers can easily pay to: user_id@service_provider.com
- the LNURL-pay endpoint creates invoices with the user ID in the description
- in effect, any payment to that LN Address results in an invoice with the user's ID in the description
- user can setup a recurring payment (or stop paying, or change the payment amount) anytime, using any recurring payment solution
- service provider needs a simple piece of software that can lookup current user balance based on paid invoices with that User ID as description
- the service can stop or resume, based on the user account balance