Offer from Yandex.Money in the new W3C payment standard
Hello! My name is Evgeny Vinogradov. I work in Yandex.Money and participate in the work of the W3C group dedicated to Internet payment standards. In addition to us and several other payment services, it included international IT companies, banks, regulators, organizations working with Bitcoin. In fact, the group has been around for more than three years. All this time, she has been discussing the content of the future standard for Internet payments, but only recently - after an in-person meeting of the participants - the case has noticeably moved forward.
We at Yandex.Money know firsthand what difficulties developers have to face, for example, online stores. Now, to use different payment systems, they have to deal with the documentation and the features of each of them, and the process of connecting payment solutions to a small store can take months. If the connection is performed almost identically, it will be enough to study the procedure once - and you will be able to work with all payment systems.
One of our proposals as part of the work on the standard was a method of initiating a payment with the code name “payto:” - by analogy with the well-known script for sending email messages via the “ mailto: ” URI scheme .
In this post we want to talk about why it so happened that there is still no single standard, why it is very needed and what it can be, in our opinion.
The standards that the payment business is working with today were created decades ago - by large companies for large companies. The segment of Internet payments that has appeared and expanded since then has involved new players in the process. There were more market participants and they were faced with new tasks for which there were variegated solutions - both useful and rake-like. And the standards that exist on the Internet have not yet reached them. Converging in the architecture of each ecommerce project, all these "rakes" and "crutches" turn out to be a headache for developers, for business owners and, ultimately, for users. The faster and easier it is to get the result, the more efficient the business is, so entrepreneurs will certainly benefit from standardization as much as developers.
Payments as a way of exchanging values have been working quite successfully for many millennia, but only at the end of the last century did mass payments become intangible.
It began in the United States in the late 50s - early 60s. The buyer came to the store with cash or with checkbooks, and was limited in purchases by the amount of cash with him or the balance on the account to which the checks were attached. The retail business realized that profits would be noticeably greater if a person would not be limited to the contents of their pockets - this is how private credit accounts appeared in large retail chains (Sears, Montgomery Ward, JCPenney), and then cards of these networks.
Then the banks noticed that retailers make good money on their field and entered the game: financial associations appeared to create a single universal solution -Visa and MasterCard . The client received one card for different outlets, and the seller each time called the credit organization to confirm the payment.
Soon, there were a lot of bank card owners, and approval of telephone transactions became inconvenient for customers and costly for business. To solve the problem, they came up with magnetic tapes on cards and POS terminals that transmitted data via dial-up and approved transactions automatically. It was a big leap forward.
The business began to grow in infrastructure, and in the struggle to minimize costs, an evolutionary separation of system functions occurred: issuing banks, acquiring banks, processing centers, payment gateways, organizations supporting POS infrastructure and others. Since there were few participants in each segment, it was much easier for them to agree on standards: for example, the ISO 20022 currently used was developed under the supervision of SWIFT in the interests of banks and describes interbank transfers, various types of OFX were proposed by IT companies for financial messaging, the standard ISO 8583 , on which data transfer is used for payments by bank cards, appeared through the efforts of Visa and Mastercard.
The Internet needs other payment standards that take into account the needs of important micro-players: sellers and developers. The Yandex.Money experience, which summarizes the experience of an Internet service, the experience of a payment solution for other Internet services, and the experience of a “large” financial institution, along with banks, just gave us an understanding of what a universal payment initialization scenario could be. At the first meeting of the W3C working group this spring, we made sure that this understanding coincided with the expectations of other major representatives of the financial and technological industry.
In the mailto scheme, everything that can be automated is already automated: mail clients, browsers, applications understand what mailto is: you need to create a letter to the specified address, just add the content and confirm that you are ready to send, the hardware will do all the steel.
When last year we launched “money letters” (the ability to “attach” money to a Yandex.Mail message by entering only the amount and password), it was perceived as magic - it suddenly turned out to be so simple, usually requiring much more action. A single payment protocol will add similar seamlessness anywhere, for example, on the store’s website, in one short line:
Similarly, mailto, browsers and email clients, applications, etc. implementing the standard will be able to recognize this markup on the pages and automatically guide the payer through the procedure for sending money - if he wants to use the offer.
There are many questions around this simple-looking structure, of course. And if the browser does not understand the standard? If the markup specifies the PSP URI , it can send the user simply by reference. And if there is an attempt to phishing / fraud? PSP can ensure that the user is warned of such a hazard. The process of developing a standard just involves finding answers to such related questions.
It should be noted that the idea of using URIs for payment already has its own implementations. The APIs of many PSPs allow you to initiate a payment request by a specific URL with parameters.
And, for example, for Bitcoin there is BIP 0021 (0020) - a way to describe payment through a URI, which includes the parameters amountparam, labelparam, messageparam, and several others. At the same time, any Bitcoin client can easily parse these parameters and use them to make a payment. Moreover, the URI scheme of bitcoin in principle allows not only to request money, but also to send, if there is a corresponding private key.
Of course, decrease friction (the notorious “seamlessness”) in relation to payments will mean the complication of the infrastructure required to ensure this very decrease on the side of the payment operator. But now the role of payment providers in the production chain is reduced to “simplifying life for everyone else”, so this is the most reasonable place for applying innovations.
A separate big question that we are asked in this regard from the side: how does the need for standardization relate to competition. There is no contradiction: payment as such begins much earlier than the transaction itself to transfer the amount to N money. It begins when a person thinks about where to put up his material resources. Each country has its own characteristics of this process, but in general, the interaction between specific companies and specific people still occurs in a similar way.
For some companies, income from a specific operation is more important, for others - from a group of operations, for someone, transferring money is simply an additional, non-core service. This is where the difference begins in the level of service and its cost, in the specifics of additional services.
Another important field of near-paying activity is security at a very different level: from trust between the seller and the buyer to the fight against counterfeit money and confidence that exactly those for whom the participants claim to be involved in the operation. And here the de facto standard can become a lever that promotes safe methods of conducting operations to the masses.
It is clear that the requirements and requests are different for everyone. Regulators want to regulate, that is, to control cash flows; banks want security and income; IT companies want technology transparency - this list can be continued, and in many of these tasks the standard will be a good help.
Will users win? Definitely. In fact, payment is an infrastructure issue, which in itself is not particularly interesting to any of them. No one wakes up with the thought, “Should I make a transaction?”, Wake up with the thought “I want a new phone” or “Champagne to number 25!”. And the standard that describes the processes of money transfer allows you to make the actions associated with payments routine, familiar, and therefore - as invisible as possible for a person.
We at Yandex.Money know firsthand what difficulties developers have to face, for example, online stores. Now, to use different payment systems, they have to deal with the documentation and the features of each of them, and the process of connecting payment solutions to a small store can take months. If the connection is performed almost identically, it will be enough to study the procedure once - and you will be able to work with all payment systems.
One of our proposals as part of the work on the standard was a method of initiating a payment with the code name “payto:” - by analogy with the well-known script for sending email messages via the “ mailto: ” URI scheme .
In this post we want to talk about why it so happened that there is still no single standard, why it is very needed and what it can be, in our opinion.
The standards that the payment business is working with today were created decades ago - by large companies for large companies. The segment of Internet payments that has appeared and expanded since then has involved new players in the process. There were more market participants and they were faced with new tasks for which there were variegated solutions - both useful and rake-like. And the standards that exist on the Internet have not yet reached them. Converging in the architecture of each ecommerce project, all these "rakes" and "crutches" turn out to be a headache for developers, for business owners and, ultimately, for users. The faster and easier it is to get the result, the more efficient the business is, so entrepreneurs will certainly benefit from standardization as much as developers.
History of Standards: From Checkbooks to Payto
Payments as a way of exchanging values have been working quite successfully for many millennia, but only at the end of the last century did mass payments become intangible.
It began in the United States in the late 50s - early 60s. The buyer came to the store with cash or with checkbooks, and was limited in purchases by the amount of cash with him or the balance on the account to which the checks were attached. The retail business realized that profits would be noticeably greater if a person would not be limited to the contents of their pockets - this is how private credit accounts appeared in large retail chains (Sears, Montgomery Ward, JCPenney), and then cards of these networks.
Then the banks noticed that retailers make good money on their field and entered the game: financial associations appeared to create a single universal solution -Visa and MasterCard . The client received one card for different outlets, and the seller each time called the credit organization to confirm the payment.
Soon, there were a lot of bank card owners, and approval of telephone transactions became inconvenient for customers and costly for business. To solve the problem, they came up with magnetic tapes on cards and POS terminals that transmitted data via dial-up and approved transactions automatically. It was a big leap forward.
The business began to grow in infrastructure, and in the struggle to minimize costs, an evolutionary separation of system functions occurred: issuing banks, acquiring banks, processing centers, payment gateways, organizations supporting POS infrastructure and others. Since there were few participants in each segment, it was much easier for them to agree on standards: for example, the ISO 20022 currently used was developed under the supervision of SWIFT in the interests of banks and describes interbank transfers, various types of OFX were proposed by IT companies for financial messaging, the standard ISO 8583 , on which data transfer is used for payments by bank cards, appeared through the efforts of Visa and Mastercard.
The Internet needs other payment standards that take into account the needs of important micro-players: sellers and developers. The Yandex.Money experience, which summarizes the experience of an Internet service, the experience of a payment solution for other Internet services, and the experience of a “large” financial institution, along with banks, just gave us an understanding of what a universal payment initialization scenario could be. At the first meeting of the W3C working group this spring, we made sure that this understanding coincided with the expectations of other major representatives of the financial and technological industry.
Payto: like mailto, but with money
In the mailto scheme, everything that can be automated is already automated: mail clients, browsers, applications understand what mailto is: you need to create a letter to the specified address, just add the content and confirm that you are ready to send, the hardware will do all the steel.
When last year we launched “money letters” (the ability to “attach” money to a Yandex.Mail message by entering only the amount and password), it was perceived as magic - it suddenly turned out to be so simple, usually requiring much more action. A single payment protocol will add similar seamlessness anywhere, for example, on the store’s website, in one short line:
payto:example.com/payto.xml?item=BigBook&sum=10.0&account=111223344&someparams=paramsSimilarly, mailto, browsers and email clients, applications, etc. implementing the standard will be able to recognize this markup on the pages and automatically guide the payer through the procedure for sending money - if he wants to use the offer.
There are many questions around this simple-looking structure, of course. And if the browser does not understand the standard? If the markup specifies the PSP URI , it can send the user simply by reference. And if there is an attempt to phishing / fraud? PSP can ensure that the user is warned of such a hazard. The process of developing a standard just involves finding answers to such related questions.
It should be noted that the idea of using URIs for payment already has its own implementations. The APIs of many PSPs allow you to initiate a payment request by a specific URL with parameters.
And, for example, for Bitcoin there is BIP 0021 (0020) - a way to describe payment through a URI, which includes the parameters amountparam, labelparam, messageparam, and several others. At the same time, any Bitcoin client can easily parse these parameters and use them to make a payment. Moreover, the URI scheme of bitcoin in principle allows not only to request money, but also to send, if there is a corresponding private key.
Who will pay for the progress?
Of course, decrease friction (the notorious “seamlessness”) in relation to payments will mean the complication of the infrastructure required to ensure this very decrease on the side of the payment operator. But now the role of payment providers in the production chain is reduced to “simplifying life for everyone else”, so this is the most reasonable place for applying innovations.
A separate big question that we are asked in this regard from the side: how does the need for standardization relate to competition. There is no contradiction: payment as such begins much earlier than the transaction itself to transfer the amount to N money. It begins when a person thinks about where to put up his material resources. Each country has its own characteristics of this process, but in general, the interaction between specific companies and specific people still occurs in a similar way.
For some companies, income from a specific operation is more important, for others - from a group of operations, for someone, transferring money is simply an additional, non-core service. This is where the difference begins in the level of service and its cost, in the specifics of additional services.
Another important field of near-paying activity is security at a very different level: from trust between the seller and the buyer to the fight against counterfeit money and confidence that exactly those for whom the participants claim to be involved in the operation. And here the de facto standard can become a lever that promotes safe methods of conducting operations to the masses.
It is clear that the requirements and requests are different for everyone. Regulators want to regulate, that is, to control cash flows; banks want security and income; IT companies want technology transparency - this list can be continued, and in many of these tasks the standard will be a good help.
Will users win? Definitely. In fact, payment is an infrastructure issue, which in itself is not particularly interesting to any of them. No one wakes up with the thought, “Should I make a transaction?”, Wake up with the thought “I want a new phone” or “Champagne to number 25!”. And the standard that describes the processes of money transfer allows you to make the actions associated with payments routine, familiar, and therefore - as invisible as possible for a person.