11 ms·

RFC 8905 – The 'payto' URI Scheme for Payments

151 points by kwk1 6y ago

com 6y ago
Interesting, and potentially useful to decrease payments friction, although the challenge with these sorts of transfer schemes is that non-repudiation of contractual “promises” is not addressed. Oh yeah, aren’t ACH numbers fraud risks too, if they’re public? I remember a story about a major German bank who reused an IBAN for one of their treasury accounts and honoured direct debits for quite some time, so there are some risks with IBANs being known in some cases. I think that removing friction will also make fraud much easier and prevalent.
- wbl 6y ago
  Just because your country's bankers are too stupid to have different numbers for in and out doesn't mean the rest of the world is.
- marcosdumay 6y ago
  Non repudiation is handled by the payment provider. The standard is just a link to ask for payment, not a money transfer system.
- dtech 6y ago
  IBAN numbers are not secret and are on payment cards and websites already. If that causes problems the system or vulnerability should be fixed, not try to twist in turns to keep those numbers secret.
trashburger 6y ago
Can't wait for clickjacking attempts with payto:// URLs. Why is anyone attempting to put a _standard_ for fscking _payment_ on the _web_ again?
- rhn_mk1 6y ago
  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.
  - spicybright 6y ago
    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.
- SahAssar 6y ago
  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?
  - dx87 6y ago
    Just because it's written in the RFC doesn't mean that's how it's going to work.
    - SahAssar 6y ago
      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.
  - andreareina 6y ago
    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 https://news.ycombinator.com/newsguidelines.html
    - SahAssar 6y ago
      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.
  - heavenlyblue 6y ago
    I can also write a standard that says something along the lines of “and the server MUST NOT be hackable”
- baq 6y ago
  Because lots of people pay on the web?
- alangibson 6y ago
  Because the difficulty of making and recieving payments on the web is a major cause of advertising having become the dominant revenue model.
  - hakfoo 6y ago
    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.
- nafey 6y ago
  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%20Specs_ver%201.6.pdf https://www.npci.org.in/sites/default/files/UPI%20Linking%20...
- dzhiurgis 6y ago
  URL scheme hijacking is documented https://blog.trendmicro.com/trendlabs-security-intelligence/ios-url-scheme-susceptible-to-hijacking/ 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...
dqv 6y ago
It doesn't really talk about gateways at all, but says it should be vendor neutral. payto:stripe.com/pk_PU1qgJjo2yW1to?amount=USD:100.0&message=Box+of+chocolates It seems weird to leave payment gateways out of consideration, but maybe I'm not understanding the purpose of this RFC.
- slim 6y ago
  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.
  - bastawhiz 6y ago
    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.
- chrismorgan 6y ago
  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.
deleted 6y ago
[deleted]
chrismorgan 6y ago
The amount option is leaving a slightly bitter taste in my mouth. • It allows commas, which will just be stripped on execution. This feels like it’s just inviting errors unnecessarily, especially given that some parts of the world use comma (,) as their decimal separator and full stop (.) for grouping, rather than the other way round. I see no compelling reason for allowing grouping at all. • “The 'unit' value MUST be smaller than 2^53. If present, the 'fraction' MUST consist of no more than 8 decimal digits.” Both of these feel a mite surprising, and the combination of them far more surprising. The 2⁵³ limit is doubtless to allow it to be safely stored in a 64-bit floating point number, specifically for JavaScript’s sake; but (dealing with this part first) do you know how small 2⁵³ is? 9 quadrillion. That’s honestly not that large. I’ve handled a 100 trillion dollar note, and that’s hardly the highest any currency has ever gone. (Admittedly, the sorts of currencies where this is happening probably have limited use for a payto: URI scheme at the time.) But anyway, skipping onto the second part, a fraction of up to eight digits. Skipping over the apparent arbitrariness of the number (which happens to match Bitcoin’s division), if you’ve made concession to treat the unit as a Number, what about the fraction? If you wanted to retain eight decimal places of significance, you’d be limiting your unit to 2⁵³ ÷ 10⁸, about 90 million, which is obviously too low, so you clearly can’t be meant to be representing the whole thing as a Number, so why that restriction on the unit? So yeah, both of these limits simply feel weird to me. But other than these quibbles, I say: finally! I’m really glad about this and hope it gets adopted by banking apps and the likes quickly, and added to the HTML spec’s safelisted schemes (https://html.spec.whatwg.org/#safelisted-scheme https://html.spec.whatwg.org/#safelisted-scheme) so that banks’ web apps can also navigator.registerProtocolHandler("payto", "https://bank.example/payto-handler/%s https://bank.example/payto-handler/%s") soon. And also that Australian banks either register some way of addressing their accounts as a payto payment target type, or adopt IBAN.
- _Microft 6y ago
  Wow, I had not spotted this yet. Omitting a comma turns an amount with Euro Cents to 100 times the amount here in Germany. I can both see this comma/dot problem be missed in development and can also imagine such a payment go through, as a few digit amount times one hundred still gives an amount that people can have in their bank accounts. Users clicking through confirmation dialogs and dismissing wrong information as 'computer problems' is not an unheard-of problem either. This is really inviting trouble - without good reason? - as a payment 'API' having to deal with how a number was displayed to a user seems out of scope for it.
_Microft 6y ago
Does anyone understand how would this work if different payment methods had to be processed by different programs? As far as I understand, protocol handlers can only be registered for a protocol/scheme in general but not be limited to a protocol with a particular parameter as e.g. payto://IBAN/ or payto://bitcoin/.
- chrismorgan 6y ago
  It depends on the environment. If you’re dealing with a web app registering itself as a protocol handler, the scheme is the highest precision you get: navigator.registerProtocolHandler("payto", "https://bank.example/payto-handler/%s https://bank.example/payto-handler/%s"). So there, you only get the protocol level of granularity. You might therefore set up bank.example and bitcoin.example, and now when you click on a payto: link, the browser will say “do you want to open this link with bank.example or bitcoin.example?” On mobile platforms, I’m not certain, but you may be able to have the bank app only register for payto://iban/ (and any other payment authorities it supports) and the Bitcoin app only register for payto://bitcoin/.
7373737373 6y ago
It would be nice to be able to program APIs in a similar way too: https://github.com/void4/paymentchannel https://github.com/void4/paymentchannel
teddyh 6y ago
And thus, the whole web gets IAP’s.
- fouric 6y ago
  ...which is much better than the current state of the web, which is "(nearly) everything is funded by advertisements".
  - teddyh 6y ago
    Possibly. But I remember the time of Shareware, especially on the Amiga platform. It seemed that every little itty-bitty utility program on the Amiga cost some small amount of money. Meanwhile, all the popular programs on PC (DOS and Windows) and Unix (Sun etc.) were mostly GNU-style free software, and guess who won that development? I’m worried that the entire currently-free web will stagnate by all web sites feeling forced to adopt this pay-by-the-click model. However, you are certainly right in that the current ad-supported model is driving engagement, or, should I say, “enragement” clicks, which is certainly not doing much good.
- pedrokost 6y ago
  This sounds great. Instead of trusting each company to implement their own billing system with some payment processor, just have the payment processors and banks provide "apps" that support these protocols, and users can chose which one to use to complete their payment. One interesting follow up question in who covers the processing fee (e.g. the ~3% or so that Braintree or Paypal currently take)? Today, processing fees are mostly hidden to the user. If the user can chose their own payment processor, will they be required to cover the processing fee instead of the merchant?
  - teddyh 6y ago
    > Instead of trusting each company to implement their own billing system with some payment processor, just have the payment processors and banks provide "apps" that support these protocols To me, this sounds dangerously close to the argument for the W3C standardization of DRM in the browser. I remain wary.
politician 6y ago
I would appreciate if the spec explicitly stated that requests using this scheme are neither value carrying nor authorizations. It would avoid so much hassle if they clearly stepped back from any appearance that this is a money transmission mechanism.
nafey 6y ago
This reminds me a lot of the UPI payment scheme. National Payments Corporation of India has defined the UPI as an interoperable format for payments between bank accounts. It has worked out beautifully in last few years and as someone who has worked extensively with applications around UPI, a common global standard around payments would go a long way to not only enable safer and more seamless payments infrastructure but also act as a countervailing force to the duopoly of VISA and MasterCard.
- ffpip 6y ago
  UPI is the one thing I consider very well executed by the Indian govt. I'm glad it exists, even though I don't use it much. It seems to be helping every Indian daily.
hyperdimension 6y ago
To all those with critiques: remember that 'RFC' doesn't stand for 'Fully-Baked Internet Standard,' it's 'Request For Comments.' Well, the IETF is volunteer-based, so if you feel strongly enough, go submit a comment! :)
- chrismorgan 6y ago
  I don’t think that’s quite a fair representation of reality. “Standards Track” RFCs are fully-baked internet standards, and “RFC” is a misnomer the cause of which is “historical reasons”. But as regards this particular RFC, the key details that are terribly easy to miss are right at the start: • Independent Submission • Category: Informational In other words, the IETF is not “vouching for” this thing as they would be on standards track RFCs. (Another hint at this is that the registry the RFC establishes is established with GANA rather than IANA. And the URI format; I suspect that if it went through the full standardisation process it’d be pushed to payto:authority:path rather than payto://authority/path, the // style of URI being strongly linked with DNS resolution.) (I completely forgot to check this when I first read the spec, and I’m used to reading these sorts of specs and checking their status. Read my earlier comments bearing this in mind.)
throwawaysea 6y ago
Can this scheme/standard be denied to some parties? Are there vectors for censorship or deplatforming (through denial of payment) that can be guarded against?
contingencies 6y ago
Prior author of finance-related internet standards drafts here. This is quite a simplistic and Eurocentric proposal. The core design problem I see is that, in terms of the overall use case, it may in practice already often be the case that an existing identifier, not designed for payments, is used to identify the recipient (for example, an email address, phone number or nationally issued personal or corporate identifier) and that the actual settlement method (bank transfer, paypal, bitcoin, physical goods transfer, etc.) is not specified. However, in this design you see that the settlement method must be specified along with the recipient, which is functionally nearly equivalent to providing (http://closed-system.com/method/specific/URI http://closed-system.com/method/specific/URI) thus largely devaluing the payto:// proposal. A 'real world' use case for global payments: "I want to transfer some value over there": where there is defined, and some value is defined, but the potentially multiple means and steps to achieve the result may be many and varied and depend upon various additional criteria or preferences (cost, speed, trust, volume and asset type limitations, accounting or regulatory requirements, requirement for confirmation of delivery, error handling potential, day of week, time of day, holiday, reversibility, etc.). Additional design problems are that there is no transaction or invoice identification system specified which will deeply frustrate customer service/auditing/reconciliation, temporal limits are not possible to specify, and that the approach of shoving all required metadata for a transaction in to generic fields without specifying their formatting is going to cause havoc with all sorts of use cases particularly the disparate allowable character ranges of thousands of banks' various AML/KYC field requirements for SWIFT transfers. I also note that the proposal comes from Switzerland (home of SIX/SWIFT) and that its de-facto enforcement of ISO4217 effectively holds users of the protocol hostage to that central authority in terms of which currencies/asset types they are allowed to trade in. I would further suggest that any good faith global payment schema proposal should at least include https://en.wikipedia.org/wiki/WeChat#WeChat_Pay_digital_payment_services https://en.wikipedia.org/wiki/WeChat#WeChat_Pay_digital_paym... https://en.wikipedia.org/wiki/Alipay https://en.wikipedia.org/wiki/Alipay https://en.wikipedia.org/wiki/UnionPay https://en.wikipedia.org/wiki/UnionPay For a deeper exploration of the transaction area see the unfinished proposal IFEX @ https://raw.githubusercontent.com/globalcitizen/ifex-protocol/master/draft-ifex-00.txt https://raw.githubusercontent.com/globalcitizen/ifex-protoco... For an alternative approach to internet based financial endpoint identification see IIBAN @ https://tools.ietf.org/html/draft-stanish-iiban-01 https://tools.ietf.org/html/draft-stanish-iiban-01 For a broader asset type identification system that does not bar innovation, see X-ISO4217-A3 @ https://tools.ietf.org/html/draft-stanish-x-iso4217-a3-01 https://tools.ietf.org/html/draft-stanish-x-iso4217-a3-01
mattashii 6y ago
Looking at the RFC, the grammar is not well-defined: 'opt-value' is specified as any amount of 'pchar'[0], which includes both '&' and '=' (the delimiters between opts, and between opt-key and opt-values, respectively). So in order to parse a payto-link, you either go eager and have only one option in the string, or lazy and my valid opts 'description=Food & drinks' will error out on a missing value for the ' drinks' authority-specific option, or go nuts and have parser-specific behaviour. [0] pchar as defined in https://tools.ietf.org/html/rfc3986#appendix-A https://tools.ietf.org/html/rfc3986#appendix-A
dzhiurgis 6y ago
Nice. Let’s hope all banking apps accept these as a QR code.
bastawhiz 6y ago
I think this is a neat idea, but it seems like the UX of it is a bit fraught for two reasons: 1. It doesn't seem like there's any callback mechanism. Once I transfer money, the source has no knowledge of that. If this is used for an invoice, the invoice needs to wait for the transfer to happen on the back-end for the source page to become aware that it happened. There seems to be no possibility of a "thanks for paying" URI that can be triggered after payment. This limits practicality for non-donation payments. 2. Each payto URI represents one payment method. Any payee who wants to accept money in one of a few different payment methods must provide separate URIs. This offloads the burden of knowing _how_ to pay to the user. If there's a list of five payment methods (as five payto URIs), I need to be aware of which ones I have apps for that my user agent can interact with. Some may trigger an error. Versus another world where I click a single link (payto URI) representing five payment methods in one and my user agent asks which app/account/etc I want to pay from.
danellis 6y ago
This is horrific. They're actually encouraging people to put their bank account details in public in cleartext. That's just asking for abuse.
- Thiez 6y ago
  What kind of abuse do you have in mind?
  - danellis 6y ago
    Spending money from other people's bank accounts.
    - Thiez 6y ago
      How would that happen, exactly? If you were to have my bank account number you could give me money, but you couldn't just take it out. It's not like a credit card number.
      - danellis 6y ago
        Have you never had anything billed to your bank account? You give them your routing number and account number, and they take the money directly. Some sites will make you prove it's your bank account by asking you for the amount of two small deposits, but many don't. This isn't hypothetical. It happens. > In an attempt to prove that the public furore over the 2007 UK child benefit data scandal was unjustified, [Jeremy Clarkson] published his own bank account number and sort code, together with instructions on how to find out his address, in The Sun newspaper, expecting nobody to be able to remove money from his account. He later discovered that someone had set up a monthly direct debit for £500 to Diabetes UK.

151 points by kwk1 6y ago

com 6y ago

Interesting, and potentially useful to decrease payments friction, although the challenge with these sorts of transfer schemes is that non-repudiation of contractual “promises” is not addressed. Oh yeah, aren’t ACH numbers fraud risks too, if they’re public? I remember a story about a major German bank who reused an IBAN for one of their treasury accounts and honoured direct debits for quite some time, so there are some risks with IBANs being known in some cases. I think that removing friction will also make fraud much easier and prevalent.

wbl 6y ago
Just because your country's bankers are too stupid to have different numbers for in and out doesn't mean the rest of the world is.
marcosdumay 6y ago
Non repudiation is handled by the payment provider. The standard is just a link to ask for payment, not a money transfer system.
dtech 6y ago
IBAN numbers are not secret and are on payment cards and websites already. If that causes problems the system or vulnerability should be fixed, not try to twist in turns to keep those numbers secret.

trashburger 6y ago

Can't wait for clickjacking attempts with payto:// URLs. Why is anyone attempting to put a _standard_ for fscking _payment_ on the _web_ again?

rhn_mk1 6y ago
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.
- spicybright 6y ago
  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.
SahAssar 6y ago
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?
- dx87 6y ago
  Just because it's written in the RFC doesn't mean that's how it's going to work.
  - SahAssar 6y ago
    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.
- andreareina 6y ago
  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 https://news.ycombinator.com/newsguidelines.html
  - SahAssar 6y ago
    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.
- heavenlyblue 6y ago
  I can also write a standard that says something along the lines of “and the server MUST NOT be hackable”
baq 6y ago
Because lots of people pay on the web?
alangibson 6y ago
Because the difficulty of making and recieving payments on the web is a major cause of advertising having become the dominant revenue model.
- hakfoo 6y ago
  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.
nafey 6y ago
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%20Specs_ver%201.6.pdf https://www.npci.org.in/sites/default/files/UPI%20Linking%20...
dzhiurgis 6y ago
URL scheme hijacking is documented https://blog.trendmicro.com/trendlabs-security-intelligence/ios-url-scheme-susceptible-to-hijacking/ 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...

dqv 6y ago

It doesn't really talk about gateways at all, but says it should be vendor neutral. payto:stripe.com/pk_PU1qgJjo2yW1to?amount=USD:100.0&message=Box+of+chocolates It seems weird to leave payment gateways out of consideration, but maybe I'm not understanding the purpose of this RFC.

slim 6y ago
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.
- bastawhiz 6y ago
  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.
chrismorgan 6y ago
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.

deleted 6y ago

[deleted]

chrismorgan 6y ago

The amount option is leaving a slightly bitter taste in my mouth. • It allows commas, which will just be stripped on execution. This feels like it’s just inviting errors unnecessarily, especially given that some parts of the world use comma (,) as their decimal separator and full stop (.) for grouping, rather than the other way round. I see no compelling reason for allowing grouping at all. • “The 'unit' value MUST be smaller than 2^53. If present, the 'fraction' MUST consist of no more than 8 decimal digits.” Both of these feel a mite surprising, and the combination of them far more surprising. The 2⁵³ limit is doubtless to allow it to be safely stored in a 64-bit floating point number, specifically for JavaScript’s sake; but (dealing with this part first) do you know how small 2⁵³ is? 9 quadrillion. That’s honestly not that large. I’ve handled a 100 trillion dollar note, and that’s hardly the highest any currency has ever gone. (Admittedly, the sorts of currencies where this is happening probably have limited use for a payto: URI scheme at the time.) But anyway, skipping onto the second part, a fraction of up to eight digits. Skipping over the apparent arbitrariness of the number (which happens to match Bitcoin’s division), if you’ve made concession to treat the unit as a Number, what about the fraction? If you wanted to retain eight decimal places of significance, you’d be limiting your unit to 2⁵³ ÷ 10⁸, about 90 million, which is obviously too low, so you clearly can’t be meant to be representing the whole thing as a Number, so why that restriction on the unit? So yeah, both of these limits simply feel weird to me. But other than these quibbles, I say: finally! I’m really glad about this and hope it gets adopted by banking apps and the likes quickly, and added to the HTML spec’s safelisted schemes (https://html.spec.whatwg.org/#safelisted-scheme https://html.spec.whatwg.org/#safelisted-scheme) so that banks’ web apps can also navigator.registerProtocolHandler("payto", "https://bank.example/payto-handler/%s https://bank.example/payto-handler/%s") soon. And also that Australian banks either register some way of addressing their accounts as a payto payment target type, or adopt IBAN.

_Microft 6y ago
Wow, I had not spotted this yet. Omitting a comma turns an amount with Euro Cents to 100 times the amount here in Germany. I can both see this comma/dot problem be missed in development and can also imagine such a payment go through, as a few digit amount times one hundred still gives an amount that people can have in their bank accounts. Users clicking through confirmation dialogs and dismissing wrong information as 'computer problems' is not an unheard-of problem either. This is really inviting trouble - without good reason? - as a payment 'API' having to deal with how a number was displayed to a user seems out of scope for it.

_Microft 6y ago

Does anyone understand how would this work if different payment methods had to be processed by different programs? As far as I understand, protocol handlers can only be registered for a protocol/scheme in general but not be limited to a protocol with a particular parameter as e.g. payto://IBAN/ or payto://bitcoin/.

chrismorgan 6y ago
It depends on the environment. If you’re dealing with a web app registering itself as a protocol handler, the scheme is the highest precision you get: navigator.registerProtocolHandler("payto", "https://bank.example/payto-handler/%s https://bank.example/payto-handler/%s"). So there, you only get the protocol level of granularity. You might therefore set up bank.example and bitcoin.example, and now when you click on a payto: link, the browser will say “do you want to open this link with bank.example or bitcoin.example?” On mobile platforms, I’m not certain, but you may be able to have the bank app only register for payto://iban/ (and any other payment authorities it supports) and the Bitcoin app only register for payto://bitcoin/.

7373737373 6y ago

It would be nice to be able to program APIs in a similar way too: https://github.com/void4/paymentchannel https://github.com/void4/paymentchannel

teddyh 6y ago

And thus, the whole web gets IAP’s.

fouric 6y ago
...which is much better than the current state of the web, which is "(nearly) everything is funded by advertisements".
- teddyh 6y ago
  Possibly. But I remember the time of Shareware, especially on the Amiga platform. It seemed that every little itty-bitty utility program on the Amiga cost some small amount of money. Meanwhile, all the popular programs on PC (DOS and Windows) and Unix (Sun etc.) were mostly GNU-style free software, and guess who won that development? I’m worried that the entire currently-free web will stagnate by all web sites feeling forced to adopt this pay-by-the-click model. However, you are certainly right in that the current ad-supported model is driving engagement, or, should I say, “enragement” clicks, which is certainly not doing much good.
pedrokost 6y ago
This sounds great. Instead of trusting each company to implement their own billing system with some payment processor, just have the payment processors and banks provide "apps" that support these protocols, and users can chose which one to use to complete their payment. One interesting follow up question in who covers the processing fee (e.g. the ~3% or so that Braintree or Paypal currently take)? Today, processing fees are mostly hidden to the user. If the user can chose their own payment processor, will they be required to cover the processing fee instead of the merchant?
- teddyh 6y ago
  > Instead of trusting each company to implement their own billing system with some payment processor, just have the payment processors and banks provide "apps" that support these protocols To me, this sounds dangerously close to the argument for the W3C standardization of DRM in the browser. I remain wary.

politician 6y ago

I would appreciate if the spec explicitly stated that requests using this scheme are neither value carrying nor authorizations. It would avoid so much hassle if they clearly stepped back from any appearance that this is a money transmission mechanism.

nafey 6y ago

This reminds me a lot of the UPI payment scheme. National Payments Corporation of India has defined the UPI as an interoperable format for payments between bank accounts. It has worked out beautifully in last few years and as someone who has worked extensively with applications around UPI, a common global standard around payments would go a long way to not only enable safer and more seamless payments infrastructure but also act as a countervailing force to the duopoly of VISA and MasterCard.

ffpip 6y ago
UPI is the one thing I consider very well executed by the Indian govt. I'm glad it exists, even though I don't use it much. It seems to be helping every Indian daily.

hyperdimension 6y ago

To all those with critiques: remember that 'RFC' doesn't stand for 'Fully-Baked Internet Standard,' it's 'Request For Comments.' Well, the IETF is volunteer-based, so if you feel strongly enough, go submit a comment! :)

chrismorgan 6y ago
I don’t think that’s quite a fair representation of reality. “Standards Track” RFCs are fully-baked internet standards, and “RFC” is a misnomer the cause of which is “historical reasons”. But as regards this particular RFC, the key details that are terribly easy to miss are right at the start: • Independent Submission • Category: Informational In other words, the IETF is not “vouching for” this thing as they would be on standards track RFCs. (Another hint at this is that the registry the RFC establishes is established with GANA rather than IANA. And the URI format; I suspect that if it went through the full standardisation process it’d be pushed to payto:authority:path rather than payto://authority/path, the // style of URI being strongly linked with DNS resolution.) (I completely forgot to check this when I first read the spec, and I’m used to reading these sorts of specs and checking their status. Read my earlier comments bearing this in mind.)

throwawaysea 6y ago

Can this scheme/standard be denied to some parties? Are there vectors for censorship or deplatforming (through denial of payment) that can be guarded against?

contingencies 6y ago

Prior author of finance-related internet standards drafts here. This is quite a simplistic and Eurocentric proposal. The core design problem I see is that, in terms of the overall use case, it may in practice already often be the case that an existing identifier, not designed for payments, is used to identify the recipient (for example, an email address, phone number or nationally issued personal or corporate identifier) and that the actual settlement method (bank transfer, paypal, bitcoin, physical goods transfer, etc.) is not specified. However, in this design you see that the settlement method must be specified along with the recipient, which is functionally nearly equivalent to providing (http://closed-system.com/method/specific/URI http://closed-system.com/method/specific/URI) thus largely devaluing the payto:// proposal. A 'real world' use case for global payments: "I want to transfer some value over there": where there is defined, and some value is defined, but the potentially multiple means and steps to achieve the result may be many and varied and depend upon various additional criteria or preferences (cost, speed, trust, volume and asset type limitations, accounting or regulatory requirements, requirement for confirmation of delivery, error handling potential, day of week, time of day, holiday, reversibility, etc.). Additional design problems are that there is no transaction or invoice identification system specified which will deeply frustrate customer service/auditing/reconciliation, temporal limits are not possible to specify, and that the approach of shoving all required metadata for a transaction in to generic fields without specifying their formatting is going to cause havoc with all sorts of use cases particularly the disparate allowable character ranges of thousands of banks' various AML/KYC field requirements for SWIFT transfers. I also note that the proposal comes from Switzerland (home of SIX/SWIFT) and that its de-facto enforcement of ISO4217 effectively holds users of the protocol hostage to that central authority in terms of which currencies/asset types they are allowed to trade in. I would further suggest that any good faith global payment schema proposal should at least include https://en.wikipedia.org/wiki/WeChat#WeChat_Pay_digital_payment_services https://en.wikipedia.org/wiki/WeChat#WeChat_Pay_digital_paym... https://en.wikipedia.org/wiki/Alipay https://en.wikipedia.org/wiki/Alipay https://en.wikipedia.org/wiki/UnionPay https://en.wikipedia.org/wiki/UnionPay For a deeper exploration of the transaction area see the unfinished proposal IFEX @ https://raw.githubusercontent.com/globalcitizen/ifex-protocol/master/draft-ifex-00.txt https://raw.githubusercontent.com/globalcitizen/ifex-protoco... For an alternative approach to internet based financial endpoint identification see IIBAN @ https://tools.ietf.org/html/draft-stanish-iiban-01 https://tools.ietf.org/html/draft-stanish-iiban-01 For a broader asset type identification system that does not bar innovation, see X-ISO4217-A3 @ https://tools.ietf.org/html/draft-stanish-x-iso4217-a3-01 https://tools.ietf.org/html/draft-stanish-x-iso4217-a3-01

mattashii 6y ago

Looking at the RFC, the grammar is not well-defined: 'opt-value' is specified as any amount of 'pchar'[0], which includes both '&' and '=' (the delimiters between opts, and between opt-key and opt-values, respectively). So in order to parse a payto-link, you either go eager and have only one option in the string, or lazy and my valid opts 'description=Food & drinks' will error out on a missing value for the ' drinks' authority-specific option, or go nuts and have parser-specific behaviour. [0] pchar as defined in https://tools.ietf.org/html/rfc3986#appendix-A https://tools.ietf.org/html/rfc3986#appendix-A

dzhiurgis 6y ago

Nice. Let’s hope all banking apps accept these as a QR code.

bastawhiz 6y ago

I think this is a neat idea, but it seems like the UX of it is a bit fraught for two reasons: 1. It doesn't seem like there's any callback mechanism. Once I transfer money, the source has no knowledge of that. If this is used for an invoice, the invoice needs to wait for the transfer to happen on the back-end for the source page to become aware that it happened. There seems to be no possibility of a "thanks for paying" URI that can be triggered after payment. This limits practicality for non-donation payments. 2. Each payto URI represents one payment method. Any payee who wants to accept money in one of a few different payment methods must provide separate URIs. This offloads the burden of knowing _how_ to pay to the user. If there's a list of five payment methods (as five payto URIs), I need to be aware of which ones I have apps for that my user agent can interact with. Some may trigger an error. Versus another world where I click a single link (payto URI) representing five payment methods in one and my user agent asks which app/account/etc I want to pay from.

danellis 6y ago

This is horrific. They're actually encouraging people to put their bank account details in public in cleartext. That's just asking for abuse.

Thiez 6y ago
What kind of abuse do you have in mind?
- danellis 6y ago
  Spending money from other people's bank accounts.
  - Thiez 6y ago
    How would that happen, exactly? If you were to have my bank account number you could give me money, but you couldn't just take it out. It's not like a credit card number.
    - danellis 6y ago
      Have you never had anything billed to your bank account? You give them your routing number and account number, and they take the money directly. Some sites will make you prove it's your bank account by asking you for the amount of two small deposits, but many don't. This isn't hypothetical. It happens. > In an attempt to prove that the public furore over the 2007 UK child benefit data scandal was unjustified, [Jeremy Clarkson] published his own bank account number and sort code, together with instructions on how to find out his address, in The Sun newspaper, expecting nobody to be able to remove money from his account. He later discovered that someone had set up a monthly direct debit for £500 to Diabetes UK.