Pull Payments

Protocol Design
, , ,
16

My take:

  1. Token is opaque to the merchant. This is an important point to be flexible on. It provides no benefit to the merchant to inspect the details, since they can’t rely on it (the details can be changed on the server). And certain providers may want to use different types of tokens. Making it non-opaque means we need to pick one type of token now and stick with it forever.
  2. I don’t see much value in querying details about the token you have. Just try it and see if it works. For me this fits into a similar category as looking at the details of the token - it’s more to standardize and you can’t rely on it anyway.
  3. In the URL, because then we don’t need any special handling of these payment pointers. You just connect and it works
  4. No specific endpoint for pull payments – this is up to the provider and URL parsing is generally considered an antipattern.
  5. In some cases yes, but that’s part of a different spec that need not be standardized because it’s between the customer and their provider.
  6. Technically there’s no way to guarantee the money will be sent to the right party. You could try to restrict the ILP address prefixes it can be sent to but a) you need an ILP address and a shared secret that you got from an authenticated connection in order to be sure the packets will go to the right place and b) if you have a long-lived subscription this could get annoying because a merchant’s ILP address might change. Generally I’m all for making things like this more secure but it doesn’t seem like we can do it without a lot more overhead and it requires the protocol for getting these tokens to be interactive.

Could we also outline some of the flows we might expect people to go through to get one of these tokens? Even if it’s not part of the same spec, we’re going to need to define those flows and thinking through the use cases we want to support may change our answers to the above questions.

Some use cases off the top of my head:

  • One-off payment via the Web Payments API - the merchant requests the payment using that API and the response is a normal payment pointer with a pull token included (this would probably be a good use case for offline generation, even if the browser is technically online, because it would be much faster)
  • Recurring payment via the Web Payments API? (@adrianhopebailie does that API support subscriptions?)
  • Codius (@wilsonianb how exactly would the setup work? Would the parameters we’re talking about fit your needs?)
  • Point of Sale + NFC - Merchant communicates a request for payment (in some to-be-defined format) to the customer’s phone or watch and the device returns a payment pointer with the token included
  • Point of Sale + QR code - Merchant tells the user how much, user types the amount into their device, the device generates a QR code from the payment pointer, and the merchant scans the QR code… This doesn’t seem like a great experience.
  • Any others?

One more note: offline merchant payments are much more complicated but we may want to keep them on the back burner in this discussion. Credit cards today handle this by having the terminals trust cards for a certain amount if they’re offline and using (I think) blacklists or bloom filters that are updated when they’re online to make sure that fraudulent cards are rejected. This would be a lot more difficult in an Interledger world because you’d need a federated trust model between the providers of this service and trustworthy devices, but we might need something like that if we wanted to have a solution that’s comparable to credit cards.