Re: RequestToPay vs PaymentRequest


There are many propositions to organise the world around the payment process. The fundamental assumption is that the payment process is at the center of the galaxy. Innovation is then by reshuffling the planets and satellites around the sun: Let’s re-invent the currency (crypto), the ledger (DLT), and while waiting, let’s re-invent the old payment settlement methods by changing the format of the messages (ISO20022) and the exchange protocols.

RTP is in the latter category: another « hub and spoke » complex solution to allow a payee to send a request to a payer. The payee sends the RTP to his bank, his bank sends it to the hub, the hub to the payer’s bank, and the payer’s bank to the payer.
B-BAU: Business Banking As Usual.

In real life, there is first an interaction between the payee and the payer, and next a financial transaction « to offset the payment obligation borne from the business transaction ».

If the initial interaction is secure, the payer and the payee can exchange the request to pay / invoice / « don’t forget it is Mum’birthday and we agree I’ll buy flowers ».
Next, the payment can be initiated by the payer (a credit transfer, because, so far, it is free in most countries) and the payee must receive a notification (in case the payer is standing in a shop).

Our Copernican revolution is to consider that the peer to peer interaction is the center of the galaxy, payments and financial transactions are the satellites.

P2P communication is very common. If the Payer, the Payee and their Banks can exchange securely in a « digital room », a purchase, a request to pay, any secure interaction becomes very easy. The real payment is a transfer of liability between the Bank of the Payer and the Bank of the Payee (or a transfer between 2 crypto wallets / ledgers). There are multiple settlement methods: National, SEPA, SWIFT,… depending on the respective jurisdiction in which banks are operating. 

We are working on an Account Relationship Credential (ARC). The ARC is issued by the Bank servicing the account. It can be exchanged with other parties and is verifiable.
When an ARC is exchanged, there is a secure P2P communication establish between the involved parties. They can then securely interact.

So, instead of rethinking the financial processes around the legacy hub and spoke infrastructure, our proposition is to rethink finance around trusted P2P relationships.

> Le 8 déc. 2020 à 07:24, Anders Rundgren <> a écrit :
> 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
> 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?
> 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 Saturday, 12 December 2020 10:18:39 UTC