[MrThoughtful]

The same flow would work for subscriptions.

The amount would just be a string like "whatever+whenever".

So you tell your payment provider that you authorize this merchant to pull whatever amount of money whenever they feel like.

And not give out a piece of data that authorizes anybody to pull whatever amount of money whenever they feel like.

[AndroTux]

So, PayPal, with the exception of „whatever“, as subscriptions may increase in price or you decide to upgrade without wanting to adjust your payment method. Plus, you have excellent protection as a buyer on PayPal with the option to request refunds for basically every reason.

[MrThoughtful]

We still have a misunderstanding.

The difference I propose is not about the modalities of the payments. Not about the merchant being able to change the price or you being able to request refunds.

It's about how the relationship between you, your payment provider and the merchant you want to buy from is initiated.

Currently you hand over some secret data to the merchant. Who then communicates with your payment provider.

Instead you should communicate directly with your payment provider. Never giving secret data to anybody.

[AndroTux]

So, PayPal. You sign in on PayPal.com, and PayPal communicates with the merchant. That’s how it works today. You never give any secret data to the merchant. You only allow the merchant to ask PayPal for your money.

That’s exactly how your proposed solution would have to work as well, if you want to support recurring payments or price adjustments. As soon as you allow the merchant to adjust pricing and/or interval, it opens the possibility for fraud. Because there is some way that the merchant needs to have to adjust these parameters. And if the merchant can do it, so can an attacker that takes over the merchants accounts. Like it would be the case with PayPal today.

(And by the way, that’s also how most of the credit card payments work today. Stripe for example does not allow the merchant to collect credit card information of the customer. Instead, the merchant embeds a Stripe web page into the checkout process which collects the credit card information. All the merchant gets is a token that allows them to collect money from the customer to their Stripe account. If an attacker were to obtain this token, all they could do would be to collect money to the merchants Stripe account. So they would have to also take over the merchants Stripe account to get paid out.

All in all, this is a quite secure system. The only problem is that people love to type in their credit card information on sketchy sites that just plain out steal them. With your suggestion, people will still send scammers money because after all, people are and will always be stupid. Just search for „crypto scam“ on Google and you’ll find plenty of examples of people actively sending money to scammers.)