RFC-8905: The 'payto' URI Scheme for Payments (2020) | Hacker News Reader

RFC-8905: The 'payto' URI Scheme for Payments (2020)

datatracker.ietf.org

124 pointsrapnie73 comments

In Europe, the EPC QR Code is taking off. Most bank apps support them, and they are making their way onto payment requests, both in paper and digitally. You then open your banking app and scan it manually. It's not exactly a link.

Details: https://en.wikipedia.org/wiki/EPC_QR_code

Would be nice for something more generic to take off, though.

Why are people so in love with the QR payment systems vs what Apple Pay has done? I'm not saying to be excited about being beholden to Apple, but their payment system just seems so much more efficient than the whole QR system. What am I missing?

It's a whole lot easier to slap QR codes on things than getting NFC tags and applying them.

On the other hand, QR code payment systems only work while the user has a good network connection.

NFC payment terminals can work while the user's device is offline, like rural areas with poor cellular coverage. Not to mention tap-and-pay cards that don't even need a battery.

(Note: The few cases in the US I've seen QR code based payments, it's been for things like Alipay at a traditional point of sale terminal - which would also have a traditional card terminal with NFC reader. I could see QR codes being useful in other contexts, like paying a paper bill that came in the mail.)

In Europe these QR codes are also printer on invoices

I live in Southern California and I pay via QR codes printed on the receipt at some restaurants.

It is very convenient.

How many bits are in the NFC token? Or is it more complex handshakes?

It’s a complex handshake, very closely related to the same one used for the EMV chip used on modern credit cards.

First, offline only works when an institution chooses to extend credit to the user. That's not nearly as widespread in other countries as it is in the US. Second, QR codes don't need a battery either. Third, having someone send money (i.e. authenticated user actively tells their provider/network to send money) is far superior to having merchants take money (i.e. charge a CC, even over NFC, even with temporary CC numbers).

Not necessarily. Debit cards in the UK can be trusted to work offline as certain "ceiling" is saved to the card with nearly every transaction, saying ok the owner has 10.000 in the bank, they probably have enough to cover a 4 GBP coffee (yes it's still technically credit but really?)

Exactly. As you said, that is credit. And it is not available to consumers in most other countries.

You can be quite far from a QR code and it’ll still work. In addition, QR codes can be shared with others and saved for later.

I have to admit, I never tried Apple Pay. How do I install it on my Android phone?

Not sure if this is sarcastic, Android has literally the same feature provided by Google.

It randomly doesn't work until I reboot though.

yeah stuff like this happens on iPhones too (although not Pay in my experience, Pay is solid).

https://en.wikipedia.org/wiki/Google_Pay

you mean the part where I literally stated being beholden to Apple? Apple made contactless payments pretty pain free. If someone else hasn't taken up the baton, then that's kind of on them.

Other people have taken up the baton though. Apple just so happens to have the ability to pre-install it on the phones of ~500 million MAU, so they "win".

Google did it first I believe but I rarely used Google Pay even if it was installed because it wasn’t as deeply integrated into the OS.

I find Apple Pay integration to be deeper and so I find it more convenient to access. However I haven’t used a Google phone in a while so maybe the situation has been improved.

If you want someone to use a feature that you made, you need to put it out there. Everywhere.

Google Pay got a redesign last year, but I also never really found the old app to be that bad either. It did NFC transactions, I can't really imagine a much "deeper integration" than that.

QR Codes are backwards compatible to every screen, paper and heck, even papyrus scrolls!

The poor scribes having to write QR codes on that papyrus must have really cussed at their tasks. "Oops, I wonder if that stray drop of ink will cause problems. Not my problem though, so oh well." Then the next scribe making a copy of that scroll...

Apple Pay is not available in all contexts (Eg Chrome on desktop)

Shameless plug:

https://gamma-pay.com

solves this problem, using QR Codes.

> Why are people so in love with the QR payment systems vs what Apple Pay has done?

QR code payment systems don't require me to buy into the entire integrated Apple hardware/software ecosystem just to make payments.

If you mean “NFC payments in general”, that’s a different question.

My commment stipulates Apple Pay being part of the Apple system. If you really have to ask "is that what I meant", then yes it is a different question. So what's your answer?

> My commment stipulates Apple Pay being part of the Apple system

Your comment suggests you think it is, at worst, an acceptable cost for the convenience of Apple Pay over other alternatives. I’m saying that, for some of us, it is not.

Apple Pay is not an open standard.

Cheap, easy, work on everything.

Some huge proportion of payments in China are already done with QR codes (WeChat/AliPay).

From the consumer side basically any phone that can (1) run apps (2) communicate with the internet and (3) has a camera supports payments this way. You may recognize that as "every single smartphone". A $100 little 2" Unihertz Jelly Pro supprots it. A $30 old used phone off of Aliexpress supports it.

From the merchant end, there's no extra hardware requirements. Literally just print a QR code and stick it on the counter and you're ready to accept payments. (E.g., https://sampi.co/wechat-pay/) Some of the smaller shops just have you show them your screen showing the payment being sent. Others will keep a phone or other device on hand to confirm the payment was received on their end.

Half of the value of a payment system is in it being ubiquitous. The onboarding experience with QR codes is so hilariously simple and accessible that it's much easier to get that market penetration.

What are you referring to?

My favorite so far has been many restaurants giving a bill with a QR code that opens up a website that allows for in browser Apple Pay.

Seems not to be separate from QR codes to me, but I still like the Apple Pay portion and total integration

Are you referring to the browser thing? Or the NFC thing which isn't used in this payment flow?

> Apple, but their payment system just seems so much more efficient than the whole QR system

I'm hoping this is sarcasm and I missed the joke.

I really hope I didn't get the joke.

Ahhhhh I'm so glad to see that this exists.

I had an "idea" of having something like this in the past, to save having to manually type bank account numbers into a thing (and risk typos...), instead you just scan a QR code with the data already embedded and it's good to go.

The only thing that nagged me in the back of my head was how do you verify that the QR code hasn't been tampered with? I mean you could say the same about just plain text and someone replacing the bank account details (replacing with their own), or sticking an imposter QR code over the top and hoping people don't notice.

Does this EPC code account for tampering/misuse?

I guess you'd expect the bank to double check the payee name + bank account number and reject anything that does not match.

Here in New Zealand the payee name and the bank account number are not checked by banks for domestic electronic payments. I can only assume this is standard practice overseas as well.

They often are checked now in the UK, after a lot of complaints and scams.

The only "tampering protection" is the error correction by the QR code. Proper protection would need a PKI, which would make it so complex, no one would use it.

You always have to bullshit check the data anyway.

Payee name + bank account number are _not_ checked in Austria. I guess this is similar to other EU countries, as @kiwijamo also suggested.

Previous discussion seven months ago: https://news.ycombinator.com/item?id=24885193

It is important to note also that this is an Independent Submission, Informational in nature only. Despite being published through IETF and having an RFC number, it’s probably fair to consider it as little more than a blog post, as regards authority.

With the launch of Stripe Payment Links [0] it is worth pointing out this IETF informational draft that may be a better open-standards approach for the future of the open web (which Stripe of course would gladly adopt ;)

[0] https://news.ycombinator.com/item?id=27280096

This is a custom, non-HTTP URL scheme which requires registering handlers and needing to teach your client about handlers. Stripe's payment links are regular web pages on the regular web. So purely from an open web perspective, Stripe's existing system seems better.

I think it's better to build such systems on open standards, and to not rely on private companies to define and control the outcome.

But since Stripe is way ahead here they might end up the de-facto standard anyway.

The whole QUIC thing showed that new protocols must play nice with the many layers of packet analysis. I suspect that a real-world informed approach will differ quite a lot from an ideal design - and a company "way ahead" has more reason than inertia to be copied

An URI scheme does not necessarily imply a new transport layer network protocol. I can't see any immediate reason why a new protocol would be required here.

The IBAN scheme is probably a bit too simplistic, but I'd say it's a good start. You can't figure out how to pay someone with just an account number. If my browser were to implement this scheme, it wouldn't know what to do. Redirect me to my bank so I can launch a SEPA instant payment? How does it know where my bank is? What if I have multiple banks? What if I want to pay by card?

mailto has the same problems; which is probably why so many sites have a contact form instead of a mailto link.

I don't see what's hard about mailto:. Your browser sees a mailto: link, and passes it off to OS default-open-action logic. Some program on your OS has registered itself as wanting the mailto: scheme-association, so it gets opened. That program receives the mailto: URI as its ARGV[1], and can then parse it.

In theory, different mail programs might do different things with a mailto: URI, or expect different things to be in a mailto: URI — but by registering an association with the mailto: scheme, they're claiming to do something useful with a mailto: URI if passed one.

It's not hard, it's just a lot of different stakeholders that need to be coordinated for it to work. And it took a long time for said products to get organised, meanwhile companies still needed convenient ways of allowing customers to contact them....hence the contact forms.

It will be the same problem here. It's safer not to use a payto scheme if it is the difference between a future customer being unable to buy your services because they haven't yet got the latest associations installed.

Even worse: The stakeholders in the companies that decide to have contact forms are generally not very technical. They probably never successfully installed a mail client in their life, so it's not very surprising they don't opt into using mailto links.

In addition to the OS handling, browsers will happily let Gmail or other websites handle mailto links. I believe they are normally registered with registerProtocolHandler[1] which is how, for example, Fastmail has a "Open mailto links from other sites in Fastmail" button in the advanced settings.

Notably, payto does not seem to be on the allowlist for registerProtocolHandler.

[1]: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/r...

Spam is why many don't use mailto...

That's certainly one strong reason for not using it in the 90s. But it's less true these days now that any and all email addresses get hit by spam hard and spam countermeasures have gotten better.

I'm willing to bet you don't admin MTAs on a daily basis...

Thank you for your service as one of those countermeasures

Taking the sibling commentor's analogy to mailto: links further:

Imagine "digital wallet" apps, that would register themselves for the payto: scheme at the OS level — just like web browser apps are registered openers for the http: scheme, or like email client apps are registered openers for the mailto: scheme.

(I mean, you don't actually have to imagine them, they already exist. Apple Wallet is a "digital wallet app" on iOS. Native-app crypto wallets are "digital wallet apps." Paypal's mobile app is a "digital wallet app." None of them register for payto:, but they all could.)

Now imagine that, like web browsers or email clients, every OS default-installed its own minimal first-party wallet app, so that it had something to fire up in response to a click on a payto: link, if you didn't have any other piece of software installed. Think "Outlook Express."

Like with web browsers or email clients, you could install your own wallet apps, and then choose which one to make the default for the payto: scheme.

There could be single-service wallet apps (created by your bank; by Visa/Mastercard/etc.; by Paypal/Venmo/etc.), and multi-service wallet apps (created by bigcorps and ISVs); just like there are single-service email apps (the "native Gmail client" kind of apps), and multi-service email apps.

If you had multiple equal-priority scheme associations for payto:, your OS would pop a menu to ask you which app you want to use to open the link, just like it pops a menu when you go to open a file and there isn't a clear default association.

The apps themselves would be free to ask more questions (or not) upon being intent-opened. If you click a mailto: link, then some email apps, when configured with multiple accounts, ask you which account you want to send the email as; others don't, but instead just let you switch the "From" field between your accounts, and do all the book-keeping to move the draft email between services, etc., in response. Same idea here.

Thanks for pointing that out. That seems so obvious in retrospect.

I like the idea of putting a QR code on invoices with the payment url.

My current bank has OCR reading of invoices built in to their app but that feels like a bit of a hack.

Which In turn makes my think about if the Swedish postgiro/bankgiro payment system would work with this type of link.

Why not a human-readable URL instead? Or both, I guess.

The point of the QR code would be to be able to scan it with a cell phone. The url on a paper would not help with that. But I guess if you have a digital invoice the link would become clickable which is nice.

The OCR codes/checksums are readable both by machine and human, which was the point. Not a hack.

But the bit-length of the QR-code is probably bigger than what humans would accept so putting the information into alphanumerics might not be practical.

The bank account nr are not.

With so many different cryptocurrencies available, why choose the one (Bitcoin) that's least useful as a form of payment? It takes a very long time to get confirmations, and the fees are too high to be useful for small transactions.

The proposal should be inclusive of all cryptocurrencies.

Looks like the proposal supports a lot of different payment types

Wouldn't this float or sink solely based on adoption by large Internet-focused commercial corporations (e.g. Amazon, AliExpress)? Or payment processors/mediators like Paypal?

This doesn't look like something the global marketplaces would be interested in. Maybe with some extensions on top?

PayPal and invoice generators are more likely. Also content donation links like Coil or BAT. Things that don't need a synchronous confirmation for the result in order to ship you stuff.

Hum, somebody will have to support this for it to be successful, but who exactly is not clear to me.

We have cryptocoins and national standards that any software could support, for example.

Not the same but, if I remember correctly, Ripple was trying to do something similar i.e. use URIs for money transfer.

Technically most cryptocurrencies support QR code payments. Unless I'm missing something here(?)

It is not QR code. It is something called PayString: https://paystring.org

Interesting. Seems like it could interact with (for instance) confirmation-of-payee systems in the UK, through use of the "name" field.

I can see it growing all sorts of new fields though, and being used maliciously. I guess security considerations are largely out of scope for the rfc though.

Not sure entirely out of scope - there is a security considerations section - https://datatracker.ietf.org/doc/html/rfc8905#section-8

It's certainly there, but for anything approaching the sphere of payment systems, seems rather short.

I wonder how such a thing might play with things like OpenBanking payment services...

I wonder how well I'd work with email based payids in Australia. Eg payto://payid/foo@example.com?bar=baz

That's a potentially valid URI according to the scheme - pathabempty may contain @ signs according to RFC 3986

ot: Thanks Christian for your firm stance explaining crypto to the London judges.

Click to Steal /s

Reply on news.ycombinator.com