Push, Pull, Sync or Async?

[mattsaxon]

The CT spec was originally envisaged as an exploration of a push payment.

Recent PRs (e.g. #44) have added the possibility of other modes of usage (i.e. pull or async).

Its need to be resolved the clarification of these different modes. The options are;

1. Have the different modes as different PMI (though in the same spec)
2. Use a single PMI, but have flags in the request/response of which modes are preferred/supported, e.g. similar to other filters (such as SupportedNetworks)

[CYV]

I had rather a flag. It could eanble merchant to begin with the "push CT", existing today and then easily migrate to "PullCT" when available.

[mattsaxon]

Why would a separate PMI not allow the scenario you outline also? My preference for a separate PMI is based on the flows being different, it seems to me that flags are filters to day (in other PMIs). Though I appreciate technically, either approach works.

[CYV]

But, maybe with the PMI approach, we will generate confusion just by having two different names "PushCT" and "PulCT" may be confusin for people not paraticpating directly at our works.

[mattsaxon]

anyone using this will need to know the distinction regardless of how we flag it. Benefit of PMI is that you get to use the mediator/browser filter algorithm

[CYV]

you win

[mattsaxon]

Reference PR #60

[ianbjacobs]

Hi @mattsaxon,

Apologies -- although I had seen this thread, I had not noticed its relation to the bits of spec that I edited last week, changing from 2 PMIs to a filter. Reopening the issue as a result.

The main point I hear in favor of 2 PMIs is that "the flows are different." This raises an interesting question: is a payment method mostly about a data model, or is it a data model and corresponding flow?

Personally, I have been thinking about payment methods as primarily data model descriptions. Thus, because the data models between the payer-initiated and payee-initiated credit transfers are nearly identical, it made sense to me to implement this as a filter.

I believe both you and @vkuntz have indicated that you think the flows are sufficiently different that we should consider two payment method identifiers. I'd like to understand more of your thinking.

One difference between 2 PMIs v. a filter is that the payment method can be more explicit about preference ordering than via 2 PMIs. Other than that, it seems to me that either approach could be used to achieve the same result.

Lastly, if we do go down the path of 2 PMIs, then I want to revisit how that is specified. For instance:

• The request data is likely the same.
• The response data for payee-initiated could be defined as a specialization of the payer-initiated
  response. The payee-initiated response data would have an extra field: the authorizationToken.

[mattsaxon]

For me a PMI represents the interaction model and hence a change of flow or data can represent one.

I also believe that filters were added (I think I was one of the first to propose) to not adversely grow the number of PMI to huge numbers, specifically so we didn't end up with one per payment network.

Since there seem to be only 2 PMIs here, I don't tkink this is a large increase and the fact that the interaction is different means we should use PMIs.

Regarding specification of the data, since the data was so close, I believe with only a single field different (the token), I chose to put this in a single dictionary to avoid duplication, however I'm largely ambivalent to this as it is only editorial, I just thought it would be less likely to incorrectly/unintentionally diverge, certainly during initial edits where volatility of the spec is higher.

Regarding ordering, I doubt that a particular payment app will support both PMIs for the same network, so in this case I believe is to be irrelevant. It is however likely that different network will support different PMIs.

[ianbjacobs]

@mattsaxon, thanks for the comments. Based on your previous discussion and also discussion with Vincent and Kris today, I will return to the 2 PMI model in the next draft.

Ian

[ianbjacobs]

Added back 2 PMIs in:
#70

[CYV]

I think we could go firther in this issue with the "form filler approach". As I try to explain in the previous thred, the form filler approach is only for the Pull-CT and we could see that the datamodel is quite different.

waiting for your comments on this subject.

[mattsaxon]

Update: a discussion was had at TPAC about returning to a single PMI and also folding in the PISP-credit-transfer PMI.

This discussion remained unresolved due to lack of time, but I suggest we continue the debate here.

[cyberphone]

Before restructuring the project, it might be worth considering the fact that a "true" push solution only supports direct, one-off payments rendering it pretty inferior compared to card schemes.

Pull CT has no such limitations. Recently upgraded Pull CT State Diagram.

As can be seen in the state diagram, Pull CT can also decouple user authorization from payment systems making the client-side (the one you are targeting), simpler and potentially universal.

Just my 0.02 €.

[mattsaxon]

@cyberphone, this flow would appear to be very similar to Cyril's PISP-Credit-Transfer PMI with some additional crypto on top (which I support).

Were just discussing how to deal with crypto in the payment payload so will have an update soon on this. Your opinion will be valued on this.

[cyberphone]

@mattsaxon @CYV Well, there is a fundamental difference: PISPs rely on "Open Banking" kind of APIs where payers authorize requests in their on-line bank pretty much like in the Dutch iDEAL, whereas Saturn builds on a specific "Wallet" (usage-, security- and process-wise comparable to Apple Pay), which does not depend on direct bank account access.

A PISP is effectively only a [quite complex] "firewall" between the Merchant and the Payer's Bank.

My sole opinion on this topic is that since PISP solutions depend on currently not standardized APIs, security solutions must probably be aligned with each specific API as well.

[saathvika]

can u please explain pull credit transfer, push credit transfer, sync credit transfer, async credit transfer and the same pull push sync and async for RFP(request for payment )

[cyberphone]

@saathvika Let me try...

Pull CT: The Merchant has (in some way) obtained an authorization token which it can send (via a provider or not) to the Payer's bank for fulfillment. This is similar to card payments

Push CT: The Payer authorizes the payment request in his/her on-line bank context. This is similar to wire transactions

Sync: The payment process is dealt with as a single step

Async: The payment process consists of an initiation and execution phase which is typical for batch payments. In such cases the result may be a receipt indicating something like "accepted, intend to perform, but later"

[saathvika]

hey @cyberphone! thank you so much for making me to understand these 4. but regarding 4th one async, i have following doubts.. please clarify.
1.
Your words:The payment process consists of initiations and execution phase which typical for batch payments.
My understanding : While initiating a payment bulk payments cannot be done, right? , it happens between one to one. I mean ordering customer, beneficiary bank and beneficiary details.
My doubt : What does batch payments means here, your refering to.?

[cyberphone]

@saathvika As far as I understand banks validate payment authorizations but do not necessarily immediately act upon them. There are both technical reasons (like an entirely separate payment engine) and business reasons (holding money in order to get interest from it aka "float") for such arrangements. After a certain time they run all payments for a particular period as a batch job.

Exactly how the editors of this specification intend to deal with this I don't know; personally I would provide the beneficiary (Merchant) with a receipt delivered immediately after the validation of the request.

As far as I know, card payments are usually not instantaneous either so that would not be a novelty. In B2B the delay between a shipment and the payment (of the invoice) often exceed 30 days. It all boils down to trust rather than technology. In the CT case the trusted party is a bank which is sort of a bank's core business.

[saathvika]

could you please tell me, what is the use of remittance information in PMI(manually initiating payment )