UPI payments are built on a very similar standard [1]. The way click jacking is circumvented is two fold. Firstly, there is 2FA required for completing any UPI payment. Secondly, every payment request is mapped to a receiver who must have completed their KYC. In case of suspected fraud there is a redressal and recovery process.

[1]https://www.npci.org.in/sites/default/files/UPI%20Linking%20...

Because otherwise each website ends up implementing the same functionality. I'm waiting for the moment where I don't have to type my account data into a random website, but can pay using my bank's application directly.

My credit card is probably on dozens of different databases on the web where it really shouldn't need to be. That's not a good thing.

URL scheme hijacking is documented https://blog.trendmicro.com/trendlabs-security-intelligence/...

I guess fart app that pushes update to claim URI scheme cannot really do that anymore - only first come first served scheme is enabled. I guess if user uninstalled their banking app and clicked for payment and then fart app appears like your banking app and tries to steal your password...

Because lots of people pay on the web?

TFA says:

> Interactive applications handling the 'payto' URI scheme MUST NOT initiate any financial transactions without prior review and confirmation from the user and MUST take measures to prevent clickjacking.

Perhaps read the proposal before criticizing it?

Just because it's written in the RFC doesn't mean that's how it's going to work.

Isn't that true for all RFCs? Isn't that the point of an RFC, to say how things should work and interoperate?

You can criticize it for not being detailed enough or it not being realistic for someone to meet the requirements, but the point of an RFC is to say how it should work, not show it working that way.

Just because the RFC says to do it doesn't mean it's going to be done. How long did it take the browsers to solve clickjacking?

> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."

https://news.ycombinator.com/newsguidelines.html

Fair, I apologize. I can't edit the comment anymore to remove it.

I assumed the parent didn't read that part since I assumed that if they did they would comment on that section, but I should not have worded it that way.

I can also write a standard that says something along the lines of “and the server MUST NOT be hackable”

And that RFC would be criticized for being impossible or not being detailed enough. You can criticize this RFC on the same grounds if you'd like.

Because the difficulty of making and recieving payments on the web is a major cause of advertising having become the dominant revenue model.

Conceptually, I love the idea of promoting push payments, because it has so much potential to reduce "credential mishandling" fraud. I also like the idea of putting the browser in control over presentation because that has the potential to increase trust (i. e. a payment flow that takes place outside the context accessible by malicious JavaScript, or tweakable to different paranoia levels based on user and bank preferences.

But I don't see this solving the acceptance cost problem. At the end of the day, too many people are living on credit, whether due to personal preference (point collectors) or financial need. That means any new API is just going to have to be poured on top of the existing, expensive, complex wedding cake of firms that is credit card acceptance.

It might be nice to see something like FedNow arrive as a low-overhead option, but if you have to discard every customer who can't pay now, you'll also provide a link to a card acceptance option too.