Support for real time payments

[cyberphone]

It seems "Delivery of Product" is happening after step 8.

Let's assume that the product is an air-line ticket. How is that supposed to work?

IMO, if the underlying system doesn't support real-time payments this scheme doesn't really fit the Web. If it OTOH does support real-time payments, it is not obvious that the outlined state diagram is the best approach since the merchant hardly needs two responses.

An entirely different approach is to rather consider a successful credit response a "receipt" (=intent to pay), then it doesn't matter if the actual payment is in real time or not. This also makes the notification (and associated infrastructure support), in step 8 optional.

[mattsaxon]

Agreed, that we should probably look to include a status in step 5 & 6 such that is is clear if the transfer has been executed or is pending.

[cyberphone]

@cyv @mattsaxon A brief scan indicated that SEPA SCT payments are not real time at all; it may even take a "bank-day" to do such a transfer.

[mattsaxonwp]

You are correct, but "SCT INST" will be real-time as will the "TCH" scheme.

I'm only peripherally aware of any real-time bank transfer schemes today, those being Ideal in Holland and Sofort in Germany.

We do need to decide if we will try to support both delayed and real-time under the same payment method. My expectation was that we would try to and only split into 2 payment methods if it became apparent that we needed to.

[cyberphone]

I'm just guessing here but I don't think Ideal, Sofort and their numerous "cousins" out there actually operate on the transaction layer, they probably rather authorize a payment request in the user's bank and return a "receipt" to the Merchant. This method method seems fairly universal. A challenge is establishing a scalable trust model for Merchants so that you don't need services like Sofort and Ideal.

[adrianhopebailie]

they probably rather authorize a payment request in the user's bank and return a "receipt" to the Merchant

Which is fine. For the purposes of an online checkout the merchant may be happy with a receipt. That will be a function of who it;s from and how it can be verified. I'd expect systems like Sofort and Ideal to define these things and be able to pass that receipt or just a link or reference to it in the API.

A challenge is establishing a scalable trust model for Merchants so that you don't need services like Sofort and Ideal.

That challenge is not the goal of this API though.

[cyberphone]

I'd expect systems like Sofort and Ideal to define these things and be able to pass that receipt or just a link or reference to it in the API

I'm not sure I understood this; Sofort and Ideal are services that only exist due to limitations in the banks' services which I would expect the API + the method in question to fix.

[adrianhopebailie]

I would expect the API + the method in question to fix

Why would you expect that?

The API fixes the fact that it is difficult to initiate a channel between the merchant and payment service provider. The PSP in this instance could be iDeal or Sofort. This API does not make it so that there is suddenly no need for payment schemes.

[cyberphone]

The PSP in this instance could be iDeal or Sofort.

I don't think this topic is suitable for GitHub, bailing out :-)

[mattsaxon]

Closed as conversation has dead-ended.