Community Call - February 9, 2022

Community
4

We have another topic for the agenda as well related to a design decision for the next iteration of Open Payments. @adrianhopebailie summarized it really well, we’d like to discuss the options with the community group:

To summarise the issue:

  • WM payments uses SPSP which allows an anonymous request to the Payment Pointer to get STREAM credentials
  • We want to allow someone to write their own WM provider that connects to an OPv2 enabled account to send the WM payments
  • WM currently surfaces receipts at the client which allow the receiver to verify payments

If a user connects their custom WM provider to their OPv2-enabled account then the expectation is that when they visit a WM-enabled website the provider will create a new outgoing-payment from the user’s account with the PP from the website as the destination

The sending provider (e.g. Fynbos) will query the PP URL using SPSP and then open a STREAM connection to the receiving provider and start sending. Presumably during the SPSP interaction between the sending provider and the receiving provider a receipt nonce and secret are exchanged so now the sending provider is getting receipts.

The problem to solve is, the website needs to verify that it is getting payments to it’s account

Option 1: OPv2 defines way for the WM Provider to get the receipts from the sending provider and surface these via the WM API
Option 2: The WM Provider creates an incoming payment at the receiving provider and pays into that. The website is able to query the incoming payment for the received amount.

Pros and Cons

Option 1:

  • + no change to the WM API in the browser
  • + website can verify payments without making requests to the receiving provider (i.e. offline)
  • - leaking across layers (STREAM protocol stuff needs to be exposed at the OPv2 layer)
  • - implementing this is going to suck (exposing the received STREAM receipts via OPv2 endpoints

Option 2:

  • + cleaner OPv2 API (no need to mingle STREAM protocol stuff into the API)
  • - receiver has to poll for received amount from incoming payment
  • - changes the WM API and moves WM to use OPv2 instead of SPSP

If we do go with option 2 it would make sense for us to change OPv2 to always use incoming payments. i.e. You can’t send to an account directly

All outgoing payments would need either:

  • An account URL and amount (send or receive)

OR

  • An incoming payment URL

When sender is executing an outgoing payment, if it has an account URL and amount, then it MUSt create an incoming payment at the receiver first

Are there any thoughts on this before our call?