Virtual Payment Pointers

[wilsonianb]

Open Payments payment pointers that do not exist at account providers.

Background

Rafiki supports payment pointers for (KYC-ed) users with accounts at the account provider.

It is expected that, in the near term, all Rafiki operators will be directly peered with each other. Payments will only be between (KYC-ed) accounts at direct peers.

Machine-to-machine payment use cases have been discussed, particularly in the context of Dassie.

Such machines are unlikely to (ever?) have accounts at a Rafiki account provider.

Rafiki allowing raw ILP access on accounts could support such use cases, but:

• it is currently not supported
• it is unclear how that could enable Open Payments transactions

Proposal

Support payments to and from payment pointers that do not correspond to any Rafiki account provider accounts.

By never settling with the unknown counterparties, Rafiki operators know that all money is originating and staying within the network of licensed account providers.

👆 Is that assumption valid?

Details

Setup

A virtual payment pointer will operate its own Open Payments resource server (RS) and authorization server (AS).
The virtual payment pointer registers itself as a "virtual peer"(?) of a single Rafiki server.
It would be assigned a sub-address of the Rafiki server's ILP address prefix, and the Rafiki server would be an intermediary of the ILP “payments” (to/from other Rafiki servers).

Assigning the ILP address under the Rafiki connector’s would work around:

• Support non-direct peer configuration #584

Receiving money

1. Create incoming payment at virtual payment pointer.
2. Create (quote and) outgoing payment at the sending payment pointer with the incoming payment as the receiver.
3. The sending payment pointer’s Rafiki will credit a balance for the virtual payment pointer. This is comparable to a peer liquidity balance, but it can never be withdrawn or settled.

Sending money

1. Create incoming payment at receiving payment pointer (virtual or not).
2. Create (quote and) outgoing payment at the sending virtual payment pointer.
   The ILP payment will go through the "peered" Rafiki connector, which will check the virtual payment pointer's "peer" liquidity balance before fulfilling any packets.
3. The "peered" Rafiki connector will debit the virtual payment pointer's "peer" liquidity balance before fulfilling any packets.
   If the receiver incoming payment belongs to a non-virtual payment pointer, peer liquidity accounts at each Rafiki server will be updated (and eventually settled).

[wilsonianb]

Virtual Payment Pointer --> Virtual Peer?

[wilsonianb]

Could this be supported completely out of Rafiki?
An account provider could provide an endpoint to register as a virtual peer, which it then configures via the Rafiki admin api (and never calls addPeerLiquidity).