JaakkoMultanen on Nostr: Probably not many people are aware of this, but bitcoin (lightning) payments are just ...
Probably not many people are aware of this, but bitcoin (lightning) payments are just now starting to be on par with credit card payments.
The biggest hurdle until now has been that bitcoin doesn't natively support pull payments, which has made otherwise basic things like subscription payments impossible.
Alby (nprofile…q7y6) has recently solved this with ZapPlanner: https://zapplanner.albylabs.com/
It allows merchants to request recurring payments from an NWC compatible wallet. The user doesn't have to accept every payment as long as they are within the budget set by the user originally when accepting the subscription.
This alone is huge!
Right now, even bitcoin services and apps such as fountain_app (npub1v5u…n0v5) are only offering their subscriptions on credit cards because ZapPlanner or nothing like it used to exist (the Fountain guys are already looking into this).
However, the payment amounts are defined in sats, and bitcoin isn't yet a unit of account. This limits the usefulness of this otherwise great system, as the sat amounts will need adjusting as the purchasing power of bitcoin goes up.
Alby itself has already ran into this problem once, as there was Nostr drama about their sat-defined subscription prices getting out of hand when we suddenly got near $100k...
It would be great to be able to define the payment amount in fiat and just do the fiat/sat conversion on the fly. I'm hoping this gets solved somehow.
There is some discussion in GitHub on this topic: https://github.com/getAlby/ZapPlanner/issues/44
To speed things up, I wrote this comment there:
----------------------
From a user perspective, if/when they can trust that the sat amount will be defined by the fiat price, higher budget shouldn't be an issue.
There are a couple of issues though: flash crashes (or glitches with the price feed), and short-term dips.
Flash crashes could be solved by using average prices instead of spot prices (averaging from multiple exchanges might not be enough, as arbitrage bots can temporarily spread the crashes from one exchange to others).
If the fiat amount was defined by an average bitcoin price, for example "previous 24h average", then flash crashes would have no effect. Dips would still matter, and it might be annoying if a large monthly subscription hits on a temporary low dip day.
Therefore, I think it would be great to have a "fiat price dollar cost average" as a pricing option. Using a monthly average for monthly subscriptions would solve both flash crashes and short-term dips.
This would mean having three different ways to calculate the sat amount:
1. Spot price according to whatever source (Dangerous! At least some basic sanity checks should be in place.)
2. Short-term average, let's say the previous 24 hours
3. Long-term average price, probably defined by the subscription length, ie. the previous months average price
Having the user decide between these different options is not a great user experience. This adds friction when compared to credit card payments: users don't need to think about these things.
Bitcoin is different though and SOME choice needs to be made. Spot is simple but not great. I think maybe the best option would be for the merchant to suggest a default (with perhaps the subscription length average being the default?), and this could be overridden by the user if they so wish.
-----------------------
Long post, I know, sorry... any thoughts on how you would like to see automatic sat/fiat conversion to work with subscriptions? :)
The biggest hurdle until now has been that bitcoin doesn't natively support pull payments, which has made otherwise basic things like subscription payments impossible.
Alby (nprofile…q7y6) has recently solved this with ZapPlanner: https://zapplanner.albylabs.com/
It allows merchants to request recurring payments from an NWC compatible wallet. The user doesn't have to accept every payment as long as they are within the budget set by the user originally when accepting the subscription.
This alone is huge!
Right now, even bitcoin services and apps such as fountain_app (npub1v5u…n0v5) are only offering their subscriptions on credit cards because ZapPlanner or nothing like it used to exist (the Fountain guys are already looking into this).
However, the payment amounts are defined in sats, and bitcoin isn't yet a unit of account. This limits the usefulness of this otherwise great system, as the sat amounts will need adjusting as the purchasing power of bitcoin goes up.
Alby itself has already ran into this problem once, as there was Nostr drama about their sat-defined subscription prices getting out of hand when we suddenly got near $100k...
It would be great to be able to define the payment amount in fiat and just do the fiat/sat conversion on the fly. I'm hoping this gets solved somehow.
There is some discussion in GitHub on this topic: https://github.com/getAlby/ZapPlanner/issues/44
To speed things up, I wrote this comment there:
----------------------
From a user perspective, if/when they can trust that the sat amount will be defined by the fiat price, higher budget shouldn't be an issue.
There are a couple of issues though: flash crashes (or glitches with the price feed), and short-term dips.
Flash crashes could be solved by using average prices instead of spot prices (averaging from multiple exchanges might not be enough, as arbitrage bots can temporarily spread the crashes from one exchange to others).
If the fiat amount was defined by an average bitcoin price, for example "previous 24h average", then flash crashes would have no effect. Dips would still matter, and it might be annoying if a large monthly subscription hits on a temporary low dip day.
Therefore, I think it would be great to have a "fiat price dollar cost average" as a pricing option. Using a monthly average for monthly subscriptions would solve both flash crashes and short-term dips.
This would mean having three different ways to calculate the sat amount:
1. Spot price according to whatever source (Dangerous! At least some basic sanity checks should be in place.)
2. Short-term average, let's say the previous 24 hours
3. Long-term average price, probably defined by the subscription length, ie. the previous months average price
Having the user decide between these different options is not a great user experience. This adds friction when compared to credit card payments: users don't need to think about these things.
Bitcoin is different though and SOME choice needs to be made. Spot is simple but not great. I think maybe the best option would be for the merchant to suggest a default (with perhaps the subscription length average being the default?), and this could be overridden by the user if they so wish.
-----------------------
Long post, I know, sorry... any thoughts on how you would like to see automatic sat/fiat conversion to work with subscriptions? :)