[HN Gopher] RFC-8905: The 'payto' URI Scheme for Payments (2020)
___________________________________________________________________
RFC-8905: The 'payto' URI Scheme for Payments (2020)
Author : rapnie
Score : 119 points
Date : 2021-06-01 14:54 UTC (1 days ago)
(HTM) web link (datatracker.ietf.org)
(TXT) w3m dump (datatracker.ietf.org)
| jgalt212 wrote:
| Click to Steal /s
| mro_name wrote:
| ot: Thanks Christian for your firm stance explaining crypto to
| the London judges.
| trissylegs wrote:
| I wonder how well I'd work with email based payids in Australia.
| Eg payto://payid/foo@example.com?bar=baz
| richardwhiuk wrote:
| That's a potentially valid URI according to the scheme -
| pathabempty may contain @ signs according to RFC 3986
| einpoklum wrote:
| 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?
| viraptor wrote:
| 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.
| marcosdumay wrote:
| 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.
| Nursie wrote:
| 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.
| richardwhiuk wrote:
| Not sure entirely out of scope - there is a security
| considerations section -
| https://datatracker.ietf.org/doc/html/rfc8905#section-8
| Nursie wrote:
| 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...
| chrismorgan wrote:
| 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.
| callesgg wrote:
| 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.
| elric wrote:
| Why not a human-readable URL instead? Or both, I guess.
| callesgg wrote:
| 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.
| elric wrote:
| 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?
| [deleted]
| derefr wrote:
| 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.
| elric wrote:
| Thanks for pointing that out. That seems so obvious in
| retrospect.
| hnlmorg wrote:
| mailto has the same problems; which is probably why so many
| sites have a contact form instead of a mailto link.
| derefr wrote:
| 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.
| hnlmorg wrote:
| 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.
| oauea wrote:
| 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.
| EE84M3i wrote:
| 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...
| bbarnett wrote:
| Spam is why many don't use mailto...
| [deleted]
| cobrabyte wrote:
| 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.
| woah wrote:
| Looks like the proposal supports a lot of different payment
| types
| _448 wrote:
| Not the same but, if I remember correctly, Ripple was trying to
| do something similar i.e. use URIs for money transfer.
| smoldesu wrote:
| Technically most cryptocurrencies support QR code payments.
| Unless I'm missing something here(?)
| dhaavi wrote:
| 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.
| dylan604 wrote:
| 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?
| psadri wrote:
| Apple Pay is not available in all contexts (Eg Chrome on
| desktop)
|
| Shameless plug:
|
| https://gamma-pay.com
|
| solves this problem, using QR Codes.
| dragonwriter wrote:
| > 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.
| dylan604 wrote:
| 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?
| dragonwriter wrote:
| > 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.
| c0nsumer wrote:
| It's a whole lot easier to slap QR codes on things than
| getting NFC tags and applying them.
| tjohns wrote:
| 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.)
| rahkiin wrote:
| In Europe these QR codes are also printer on invoices
| thrashh wrote:
| I live in Southern California and I pay via QR codes
| printed on the receipt at some restaurants.
|
| It is very convenient.
| mro_name wrote:
| How many bits are in the NFC token? Or is it more complex
| handshakes?
| jfrunyon wrote:
| 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).
| amaccuish wrote:
| 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?)
| smoldesu wrote:
| Apple Pay is not an open standard.
| dhaavi wrote:
| QR Codes are backwards compatible to every screen, paper and
| heck, even papyrus scrolls!
| dylan604 wrote:
| 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...
| bobbylarrybobby wrote:
| 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.
| vmception wrote:
| 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?
| zyx321 wrote:
| I have to admit, I never tried Apple Pay. How do I install it
| on my Android phone?
| thebean11 wrote:
| Not sure if this is sarcastic, Android has literally the
| same feature provided by Google.
| iudqnolq wrote:
| It randomly doesn't work until I reboot though.
| thebean11 wrote:
| yeah stuff like this happens on iPhones too (although not
| Pay in my experience, Pay is solid).
| dylan604 wrote:
| 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.
| smoldesu wrote:
| 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".
| thrashh wrote:
| 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.
| smoldesu wrote:
| 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.
| ceejayoz wrote:
| https://en.wikipedia.org/wiki/Google_Pay
| vagrantJin wrote:
| > 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.
| nucleardog wrote:
| 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.
| djhworld wrote:
| 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.
| kiwijamo wrote:
| 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.
| rapnie wrote:
| 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
| geofft wrote:
| 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.
| akie wrote:
| 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.
| ludamad wrote:
| 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
| elric wrote:
| 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.
___________________________________________________________________
(page generated 2021-06-02 23:01 UTC)