Confusion over payment flow about webpayments

[adrianhopebailie]

While this is certainly one way to do it, I don't think it's preferred or ideal. The user should be put through and 3DS flow inside of the payment instrument before any data is returned to the merchant. The goal is to make things easier for merchants and put the complicated logic inside of the payment instrument and whomever is providing that instrument.

Not sure this is possible. The way 3DS works today (as I understand it from a South African perspective) is that the merchant PSP has to go out and get the URL that they will redirect the payer to for them to do their 3DS auth. This can only happen after the paymentResponse has been returned to the merchant PSP.

To do this in the "payment instrument" would require a second call to the API or would require 3DS to adapt to our flow.

[mattsaxon]

You seem to be conflating the user and the browser ("Payer (Shopper) Browser"), but these are distinct roles and I'm getting confused who is taking what action. Perhaps you really just mean "Browser" here? Since there's only one browser (or "User-Agent") in any given transaction, I don't think we need to be more specific here.

Yes I have conflated them for the moment, I intended this to cover user interactions and the part of the user-agent that renders pages and deal with redirects. I can split them out if necessary, but for simplicity I had hoped this wasn't necessary.

I do not know what a "Browser Payment Agent/Wallet" and a "Payer (Shopper) PSP Wallet [aka Issuer Wallet]" are or how they differ.

Browser Payment Agent/Wallet is the Browsers inbuilt wallet

Payer (Shopper) Wallet [aka Issuer Wallet] is a 3rd party payment instrument and/or wallet and is an optional part of the flow. I added this to underline that it may come from something outside the browser and also that credit card issuers may provide these payment instruments.

While this is certainly one way to do it, I don't think it's preferred or ideal. The user should be put through and 3DS flow inside of the payment instrument before any data is returned to the merchant. The goal is to make things easier for merchants and put the complicated logic inside of the payment instrument and whomever is providing that instrument.

Yes, its not the end goal of what we are trying to achieve, but the existing 3DS implementations are a reality we need to deal with in our implementations. Whilst 3DS 2.0 is being discussed, I believe we will need to deal with 3DS 1.0 in our time-frames as I currently understand them. If the payment instrument is going to deal with 3DS, are you proposing that we will provide a vanilla 3DS implementation in the browser (at least initially)?

I think we need to as a group understand where we are talking about 'strategic' flows, where we need payment instrument from 3rd parties to enable the flow and where we are talking about 'transitional' flows, i.e. ones that will assist with our adoption, whilst not being ideal. This flow is definitely 'transitional'!

I am using planttext.com to take plain text and convert it into actual diagram, so not 100% sure it's accurate
I have no reason to think this is inaccurate, but for consistency, I'm recommending people use this site for rendering http://plantuml.com/plantuml/

[LaurentCastillo]

Since 3DS is meant to authenticate the cardholder, I'd expect in the mid-term that the schemes (sorry - methods) would define a way to transport in the payment response a proof-of-ownership (and consent) that would be recognized as a valid replacement for 3DS. This would typically be some kind of signature generated by the payment app.

In the mean time, for the "legacy" payment method, we can add an optional "UCAF" field in the payment response (UCAF stands for Universal Cardholder Authentication Field, and is the value that is generated by the issuer of the card at the end of the 3DS authentication, and attached by the merchant's PSP to the authorization request). That way, if the payment app is able to generate that value (typically if it's acting on the issuer behalf or if it's running 3DS itself), the merchant can skip the whole 3DS redirect phase and send the authorization request directly.

[mattsaxon]

Laurent, I agree with this, though we do need to address the short-term solution also to improve adoption speed as far as I am concerned. The specification need to allow the extension of the 'standard common payment methods' (i.e. cards) for things like tokenisation, 3DS 2.0, encryption etc. rather than treat cards as a legacy.

[halindrome]

Quite. Payment cards must be first class citizens in any solution.

On Wed, Nov 25, 2015 at 7:01 AM, mattsaxon [email protected] wrote:

Laurent, I agree with this, though we do need to address the short-term
solution also to improve adoption speed as far as I am concerned. The
specification need to allow the extension of the 'standard comment payment
methods' (i.e. cards) for things like tokenisation, 3DS 2.0, encryption
etc. rather than treat cards as a legacy.

—
Reply to this email directly or view it on GitHub
#10 (comment).

Shane McCarron
[email protected]

[adrianhopebailie]

@mattsaxon any plans from anyone in the flows TF to try their hand at a 3DS payment method spec?

[adrianhopebailie]

Closing as flows related work is now in https://github.com/w3c/webpayments-flows