There’s a big difference between the pull and push models.
The pull model is where I provide you with my details, and you draw money from me. Credit card numbers are the best-known mechanism for this. Ecommerce uses the pull model almost exclusively, because it lets the retailer confirm the payment and start the next step (fulfilment of goods) immediately.
The push model is where you provide me with your details, and I send money to you. This is seldom used for ecommerce because it requires reconciliation, for you to observe that you have received the money (which may take a greater period of time, depending on the systems involved—a lot of the world still operates on nightly clearing) and correlate payments with orders. This is used for much more casual things like people sending money to one another, or for larger amounts of commerce where transaction fees are much lower this way and maybe you don’t actually need the payment to be confirmed today.
For the pull model, your payment provider needs to know how to take money from the account details I provide. Sometimes this doesn’t work out, e.g. if someone has an American Express card but the merchant only accepts Visa and Mastercard.
For the push model, each sender needs to be able to target money to the account details the recipient provides. For example, I may be able to send to an Australian bank account by BSB and account number, but if you give me an American bank account, I won’t be able to pay to it directly but will have to figure out some kind of international transfer, potentially involving routing it through a third party.
The payto: URI scheme is the push model. For payto://stripe.com/… to make sense, each person’s bank would need to know how to send money to the nominated Stripe account. But that’s not how Stripe works; Stripe payments operate by the pull model.
> Ecommerce uses the pull model almost exclusively
This varies by country - the majority of e-commerce retail transactions here in Finland operate on a push model - in checkout you get redirected to your bank or wallet provider where you login (2FA) and authorize the transaction.
The merchant usually gets confirmation of payment immediately.
In fact I am not sure if there's any other country that likes the "pull" model as much the United States does. Wherever it exists it's there mostly due to historical reasons - in the past it was not possible to quickly validate and push a transfer, so you needed credit card companies to underwrite a small amount of credit (between now and end of month settlement). Kind of similar like how the US is so backwards when it comes to regular bank transfers (good luck using SWIFT). And how the Fed dollar is not exactly the same as the eurodollar. Some countries just like to be special :)
this RFC describes a type of resource, it does not care about how it will be processed. For example you could use the iban number for your "pay with stripe" buttons like this :
`<button data-payto="payto://iban/123456789">pay with stripe</button>
then you use stripes javacript library to handle it. if you do this you can trivially use multiple gateways at the same time in a flexible way.
I don't see Stripe's involvement in this at all: Stripe has no access to your bank account. Stripe might provide an IBAN for the publisher to provide a payto URI with. It seems like the whole point of this setup is for the user agent to decide which app to open to initiate a transfer to the destination.
For Stripe, this scheme is sort of irrelevant. If Stripe wants to offer the ability for someone to transfer money to an IBAN (or any other account identifier) through a webpage, they can just...do it. They don't need a URI, they just have a JS function which triggers a payment flow.
