should our payment request format be self-contained, or a pointer?

[michielbdejong]

We have two ways of sending a payment request (one of which I only discovered today through @sharafian):

1. the shop displays an IPR as a base64-string, the customer pastes this into their wallet, the wallet displays the details, the customer clicks 'Pay'.
2. the shop displays a webfinger-style spsp address (invoice1234@example.com) and this spsp receiver specifies minimum_destination_amount to match the invoice amount. The customer puts the spsp address into their wallet GUI, the wallet recognizes that this is an invoice payment and not a payment to a person, so it prefills the destination amount, and quotes for the source amount. The customer checks these details and clicks 'Pay'.

Advantage of 1 is that the payment request is self-contained, it doesn't require an extra round-trip
Advantage of 2 is that it's more like how the normal 'Alice pays Bob' flow goes in ilp-kit.

@sharafian (on Slack):

I'd still argue pointer is better because:

• Shorter
• It's easier to read
• It's less opaque (harder for an attacker to modify without noticing, unlike a cryptocurrency address)
• Can point to additional metadata that might not be included in an IPR
• Gives a consistent format for users to understand as "something I can pay"

Note that this issue just aims to get a decision on 'self-contained vs pointer', once we decide that, we can see if we continue adding key derivation to IPR or continue adding invoice balance to SPSP

[adrianhopebailie]

Both are required. They solve for different use cases.

A short-easy to exchange pointer is useful for manual entry by users or exchange out of band (e.g. via text message). It is a pointer and helps the sender down a path of discovery to determine all of the payment details they require before making the payment. The disadvantage of such a pointer is that it likely requires both parties to be online as the payment is setup.

A larger self-contained payment request is very useful to reduce indirection (for speed) and especially useful for use cases where the data exchanged is machine readable and exchanged between systems where one system may be offline. e.g. A QR code being scanned at a POS.

My suggestion is that we continue to develop the IPR format as a means for a payee to pass the data required for a payment to the payer.

Separately we should continue work on the pointer concept and refine the discovery protocol that is used by a sender to resolve the payment details they require from that pointer. Ideally the payment pointer should be agnostic of transport protocol. Part of the discovery process should be discovering what transport protocols the payee accepts.

[emschwartz]

Part of the discovery process should be discovering what transport protocols the payee accepts.

👍

One thing to note: the way we had IPR working before doesn't allow you to do either end-to-end quoting (in the way implemented by PSK, though you could do it without the receiver signing their response) or send more than one chunk for the payment. If the Max Payment Size supported by the network is very low, that type of IPR might not be that useful.

[adrianhopebailie]

I imagine IPR being primarily used for C2B use cases where the receiver is accepting payment on behalf of a merchant or similar.

The payments will traverses very few networks/hops all of which will support at least retail size "chunks" ($500 or so) and fees between intermediaries will be fixed or at least easy for the sender to calculate.

This may progress to intermediaries doing path-finding through some data service in future to determine the sending cost.

An alternative view is that there will evolve an IPR based transport protocol where the receive amount is not fixed but has a minimum and the amount the sender is charged will have a maximum. The sender's ILPSP/wallet will find the path to the receiver that meets their minimum receive amount and maximizes the profit for the wallet.

This will be driven by cost competition with cards for these types of payments and the fact that consumers are not familiar with paying fees to do retail payments.

Example: A merchant sells a $10 widget and can accept payment via card (at 2% fee) or ILP. They will prefer the user to use ILP as they can set a minimum receive amount (e.g. $9.85) where they already earn more than if this was a card transaction AND they no longer have a risk of the tx being disputed later and charged back.

This saving can be passed on to the wallet in-exchange for pushing the user toward using ILP. The wallet now needs to find a path to the merchant that costs them less than $0.15 and they get the difference.

The consumer protections that the customer is used to having (e.g. insurance against non-delivery) can now be offered by the wallet (or it's partners) directly and funded by this revenue.

[sharafian]

Advantage of 1 is that the payment request is self-contained, it doesn't require an extra round-trip

A single HTTP round trip is negligible, especially because it doesn't even happen on every chunk sent. Loading the page that displays your IPR is going to take numerous round trips, as will the wallet interface into which you put the IPR.

A short-easy to exchange pointer is useful for manual entry by users or exchange out of band (e.g. via text message). It is a pointer and helps the sender down a path of discovery to determine all of the payment details they require before making the payment. The disadvantage of such a pointer is that it likely requires both parties to be online as the payment is setup.

A larger self-contained payment request is very useful to reduce indirection (for speed) and especially useful for use cases where the data exchanged is machine readable and exchanged between systems where one system may be offline. e.g. A QR code being scanned at a POS.

Practically, there are much larger obstacles to doing ILP offline than generating an identifier for the payment. If the PoS system ever wants to know if the payment succeeded, for instance, it will need a connection to whatever system is running the ILP receiver.

[adrianhopebailie]

A single HTTP round trip is negligible

Unless it is impossible due to bandwidth or connectivity limitations. In a lot of retail payment scenarios one of the entities is offline or has bad enough connectivity that their "liveness" should not be a dependency of the payment execution.

Loading the page that displays your IPR is going to take numerous round trips, as will the wallet interface into which you put the IPR.

That's not always going to be true. I should be able to generate an IPR entirely offline.

If the PoS system ever wants to know if the payment succeeded, for instance, it will need a connection to whatever system is running the ILP receiver.

Again, not always true. I can have an offline receiving system (mobile wallet?) that reads a QR code or is sent a signed receipt from the sender visa bluetooth after they get the fulfillment from my always online receiving system. I use that to verify the payment is complete without ever being online.

There are a lot of different deployment scenarios just for POS payments where the capabilities and connectedness of both the payer and payee vary. Having both an IPR and a pointer as exchangeable data are important for different cases.

[sharafian]

I agree that there are cases where it's possible to have those kinds of constraints, but supporting it in our current implementation doesn't make sense until we have a complete picture of some of those cases.

In order for that IPR based flow to be feasible, we would need an app on the phone that can do 2-way communication with the PoS system either over bluetooth (which then requires some set-up protocol), or over a different system (QR codes with scanners on both sides?). And this is already based on the assumption that the merchant wants to join the payment network of the future but doesn't want to join the internet. Next to the ask of supporting Interledger, connecting to the internet might be comparatively minor. I'm not saying that there's definitely not anyone in that position, but it seems like a bit of a strange edge case to design around.

For the questions we need to answer right now (what payment identifier and payment request formats should ILP clients and UI wallets use?), I'm not seeing any compelling cases as to why we would use IPR instead of just SPSP.

[adrianhopebailie]

To answer the original question: "Should our payment request format be self-contained, or a pointer?"

It makes sense to support both. Priority over which to implement first is based on the use cases that are currently prioritized but until it's proven that all use cases can be accommodated by one or the other we should be open to developing standards for both.

[adrianhopebailie]

@michielbdejong can this be closed?