- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Tue, 8 Dec 2020 07:24:38 +0100
- To: Web Payments Working Group <public-payments-wg@w3.org>
Hi Payment Aficionados, Apparently RequestToPay (R2P) was discussed at the last TPAC. According to the R2P promoters it is designed to cover all payment scenarios, including on-line C2B payments. As a user of PaymentRequest [*], I'm wondering if that means that PaymentRequest is never going to be of major significance. Personally, I'm a bit skeptical about R2P because a generic issue with systems claiming to "do it all", is that they typically are not very good at anything. That R2P builds on a heavy machinery of intermediaries and pretty complex ISO20020 messaging, while still doesn't come with a complete security solution, will probably delay mainstream adoption. I believe that for R2P for businesses (invoicing), PaymentRequest is fairly useful "as is", since the business can simply send an invoice URL like https://mybusiness.com/invoice/20044/CjwKCAiAn7L-BRBbEiwAl9UtkMf_5njkYxFku4YIART to the payer which would open a "checkout" page. Invoice URLs can also be provided on paper or on the Web, as QR codes. This is trivial to implement. The considerably more problematic part is R2P for individuals, like when you sell a car privately. A possibility is that the seller's PSP (bank) acts like a Merchant; then the invoice URL scheme would work as well. However, there is a difference: the "Merchant" is just a representative for a user which at least in my system will require some adjustments in core messages (which I will try to implement it as well) . In this model invoice URLs would have to be created through the PSP by an authenticated user. This is pretty much what for example PayPal offers but here in a decentralized fashion. The reliance on PSPs makes it possible to block users in case they start sending fake invoices. Maybe you even need some kind of report URL in the PaymentRequest? WDYT? Yet another complication is the [likely] introduction of CBDC which (depending on where this thing goes...), probably calls for more lightweight solutions than offered by R2P and PaymentRequest. Anders *] A "bastardized" version supporting many more use cases including gas stations, subscriptions, and secure CoF/AoF.
Received on Tuesday, 8 December 2020 06:24:55 UTC