Re: [Minutes] 13 November Card Payment Security Task Force call

Clarifying question:

(I have asked this before but so far have no answer so it's hard to fully
understand how you envision SRC working)

What entities do you envision publishing payment handlers?
Are these companies that we would call "wallets" today like PayPal, Google
Pay etc?
Would the networks (SRC systems) each publish a payment handler?


On Sat, 16 Nov 2019 at 01:46, Chitalia, Jalpesh <jchitali@visa.com> wrote:

> Hi Adrian,
>
>
>
> Thank you for your comments.  in your example when merchant invokes 4
> PMIs, issues exist with following use cases:
>
>
>
>    1. If the consumer is recognized by one or more PH, they’d still be
>    first selecting the PH before they can select an instrument.
>       1. that can result in back and forth UX if they choose on PH1 but
>       the instrument they want to pay with is in PH3.
>    2. Consumer is recognized by one of the three PHs (e.g. Visa DCF), the
>    orchestration across other DCFs is not possible (??) to fetch list of all
>    instruments upfront.
>    3. If the user is not recognized or for a recognized user there are no
>    instruments, consumer must select a PH before they can add one.  Depending
>    on instrument they add, this may need switching back to another PH.
>
>
>
> I am thinking phone conversation will be simpler than emails.  Happy to
> find time offline in convenient timezone.  Including @Grossar, Jonathan
> <Jonathan.Grossar@mastercard.com> @Blachowicz, Tomasz
> <Tomasz.Blachowicz@mastercard.com> in this discussion.
>
>
>
> -jalpesh
>
>
>
>
>
>
>
> *From: *Adrian Hope-Bailie <adrian@coil.com>
> *Date: *Friday, November 15, 2019 at 1:36 AM
> *To: *Ian Jacobs <ij@w3.org>, Rouslan Solomakhin <rouslan@google.com>
> *Cc: *Web Payments Working Group <public-payments-wg@w3.org>
> *Subject: *Re: [Minutes] 13 November Card Payment Security Task Force call
> *Resent-From: *<public-payments-wg@w3.org>
> *Resent-Date: *Friday, November 15, 2019 at 1:35 AM
>
>
>
> Hi all,
>
>
>
> Sorry I couldn't join the call.
>
> The time changes due to DLS have resulted in conflicts for me with
> meetings rooted in UTC.
>
>
>
> Having reviewed the minutes I wanted to make a few points that may or may
> not be obvious:
>
>
>
>  - The requirements imposed on a payment handler that purports to "support
> SRC" are defined by the payment method owner (EMVCo?) and enforced through
> the payment method manifest.
>
>  - If there is a requirement that "Any SRC payment handler can enroll a
> card in any SRC system." then it would be up to the SRC payment method
> owners to devise a way to verify this for any payment handlers that wish to
> claim support for SRC and enforce it by including those handlers in the
> "allowed list" of the manifest.
>
>  - Payment handlers are just code. It is possible that a single publisher
> (from a single origin) installs multiple payment handlers into a single
> browser (e.g. one per instrument) if that's desired. @Rouslan Solomakhin
> <rouslan@google.com> may tell me I'm wrong here.
>
>
>
> It has been my understanding to date that the likely publishers of a
> payment handle that supports SRC will be SRCIs and DCFs, is that correct?
>
>
>
> On that basis my suggestion would be the following:
>
>
>
>  - Each SRC system define a unique URL based payment method identifier for
> SRC and should host a payment method manifest for SRC that is discoverable
> from that PMI URL
>
>  - Each SRC system will define requirements for payment handlers that
> claim to support SRC and will only list handlers they have vetted in their
> own manifest
>
>  - Each SRC system MAY define a default payment handler that will be used
> to bootstrap a user's browser in the case that they have no SRC supporting
> payment handlers installed.
>
>  - Merchants that accept SRC will explicitly list the SRC systems from
> which they accept SRC by constructing a payment request with all of the
> PMIs form all of the SRC systems they support.
>
>
>
>  - SRC systems can (outside of W3C) coordinate their efforts to define
> payment handler requirements and mechanisms for verification of payment
> handlers against those requirements
>
>  - As such, it could be that the list of "approved" payment handlers is
> the same in all SRC system manifests however how this is coordinated (and
> whether these are super-sets of the shared list or simply exact copies) is
> outside the scope of what W3C and the browsers need to worry about.
>
>
>
> For a user that has a fresh new browser and lands on a merchant page that
> supports SRC from 3 SRC systems (e.g. visa, mastercard, amex) the following
> happens:
>
> (Let's also assume that the merchant acquirer is an SRCI and has their own
> PH)
>
>
>
> 1. The merchant constructs a PR with 4 PMI's (one for each SRC system and
> one with the PMI that is purely for their acquirer/SRCI's payment handler):
> e.g. https://visa.com/src, https://mastercard.com/src https://amex.com/src,
> https://stripe.com/src
>
> 2. The browser is able to asynchronously discover and process the
> manifests for each of these before the user even hit's "Pay"
>
> 3. Assuming each manifest has a default payment handler defined the user
> will get prompted to pick one.
>
> 4. The user picks a PH and from there it's up to the PH to handle
> enrollment and handling the payment
>
>
>
> Step 4 above could involve asking the user to select a DCF?
>
>
>
> I may have this completely wrong but wanted to point out that there are a
> lot of options if you leverage the existing primitives the browser is
> already providing.
>
>
>
> Adrian
>
>
>
>
>
> On Wed, 13 Nov 2019 at 20:32, Ian Jacobs <ij@w3.org> wrote:
>
> Hi all,
>
> Minutes from today’s discussion on user experience assumptions and
> requirements related to SRC:
>  https://www.w3.org/2019/11/13-wpwg-minutes
>
> Next call: 27 November
>
> Ian
>
> --
> Ian Jacobs <ij@w3.org>
> https://www.w3.org/People/Jacobs/
> Tel: +1 718 260 9447
>
>
>
>
>

Received on Tuesday, 19 November 2019 12:09:34 UTC