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.
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?
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.
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.
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.)
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?)
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.
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...
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.
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.
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.
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 ;)
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.
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?
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
Details: https://en.wikipedia.org/wiki/EPC_QR_code
Would be nice for something more generic to take off, though.