Many companies would like to use Interledger for their eCommerce businesses. How can they connect to Interledger? How will they be able to send and receive payments?
Good question!
Right now, we’re discussing the protocols that such a company would use in these threads:
- AnyPay, a crypto merchant processor founded by @stevenzeiler , is interested in enabling merchants to accept payment via Interledger. The conversation about the features they need and the protocols they should use are here.
- @sabinebertram kicked off this thread about how we should handle simple peer-to-peer payments and payments for invoices.
- Pull Payments are a feature that are needed for recurring payments like subscriptions and may also be useful for eCommerce. The discussion about what that protocol should look like is here.
- The W3C Web Payments API would provide a nice user experience for the actual checkout flow built using the above protocols. @adrianhopebailie provided a useful overview of the options we have for integrating the above payment methods with that API here.
We’ll need SDKs for integrating these protocols into an eCommerce company’s service, connectors that can handle the volume, and wallets that support the sending side user experience.
1 Like
How an eCommerce company connects to Interledger will depend on how they want to take settlement of payment.
Usually eCommerce companies use third party payment gateways that accept payment from customers and settle with the merchant company later, for instance Stripe as a gateway to convert credit card charges to bank wires, or Bitpay to convert Bitcoin to bank wires.
In the Interledger world these payment gateways become connectors, so a merchant will need to partner with a payment processor that can receive payments through the Interledger and convert to the merchant’s preferred settlement mechanism.
1 Like
I think the best way to model this is to think about the existing “four-corner” model that is used in the card world.
Normally you have an acquirer (the entity where the merchant has an account) and issuer (the entity where the customer has an account).
When the customer makes a payment it is payment from their account at the issuer into the merchant’s account at the acquirer. The intermediaries along the way will charge fees (possibly apply some FX) and the money will usually only get paid into the merchants account hours or days after the payment completes (i.e. when it is “settled”).
In an ILP payment I’d expect the merchant to have an account with an “aquirer” that is really just an ILP connector or more specifically an ILSP (Interledger Service Provider). Depending on the arrangement with the ILSP and the sophistication of the merchant, ILP packets sent to the merchant will either be fulfilled by the merchant themselves or by the ILSP.
The latter model is probably the most likely initially where the ILSP is effectively taking on the role of a complete Payment Service Provider (like Stripe or PayPal).
On the customer side, they need a wallet that can send ILP payments to the merchants ILSP. What’s great with ILP is that the customer could host their own wallet or get one from a wallet provider as long as the customer or the wallet provider has a connection the the open ILP network and can route packets to the merchant.
Again, I think the fastest route to adoption is the latter.
Sadly this is the easy part. Assuming the customer and merchant have the technical capability to open a STREAM connection and send money between them, the hard part is how do they securely establish that connection?
In the card world this is a well established standard. The PAN on a card is a universally unique number in a hierarchical address space (like ILP…) meaning that any aquirer should be able to route a payment to the correct issuer, even if it has to go across international borders via global networks like VISA and Mastercard.
In ILP we are hoping that Payment Pointers will be the solution and they have some major advantages over issued card PANs.
The sooner we lock down how a Payment Pointer is used to resolve secure STREAM connection details the better because that will allow ILSPs and wallets to start working together to build the ecosystem.
In my opinion we are getting distracted by the “channel” stuff (the specifics of how to exchange this info) when we should be locking down the application layer messages that will be exchanged AFTER the STREAM connection is established.
That is where the ILSP/Merchant and Wallet/Customer will communicate the details of what is being paid for, how much, has the customer authorised the payment etc.
Card payment messages are not interactive so they must do a lot of work to define how to populate the initial request from the merchant system. STREAM is an open communication channel. We should leverage that to keep the connection establishment VERY simple (meaning it can be used on almost any channel) and then do the use case specific stuff after the connection is established.
6 Likes