Re: [Agenda] 27 November Card Payment Security Task Force

HI Adrian,

Thanks for the comments. I have made some changes in the wiki to clarify some of the points.

> On Nov 26, 2019, at 2:17 PM, Adrian Hope-Bailie <adrian@coil.com> wrote:
> 
> Hi Ian, TF members,
> 
> Please can you clarify a few questions I have about the wiki:
> 
> https://github.com/w3c/src/wiki/UX-Assumptions-and-Requirements#cross-src-enrollment
> "Based on 13 November 2020 discussion, we should not assume that all SRC payment handlers will be able to enroll a card in all SRC systems."
> 
> What does it mean to "enroll a card in an SRC system"? I thought an example of an SRC System was the VISA network and therefore if my bank issues me a VISA card it is from the VISA SRC System. 
> 
> Can I "enroll" that card on other SRC systems?
> If so, what does it mean to do this?

New text that I hope is clearer:

 "Based on 13 November 2020 discussion, we should not assume that every SRC payment handlers will be able to enroll every card into its corresponding SRC system. As an example: a payment handler may be able to enroll Visa cards (into the Visa SRC system) but not Mastercard cards (into the Mastercard SRC system)."

You may still have questions, but I hope the intent of the statement is clearer. 

> https://github.com/w3c/src/wiki/UX-Assumptions-and-Requirements#cross-src-display-and-selection
> "Based on 13 November 2020 discussion, we should not assume that all SRC payment handlers will be able to display a card from any SRC system for selection."
> 
> What is the limiting factor? 
> Do SRC payment handlers need to be "certified" or have some form of relationship (technical/business) with all of the SRC systems they can display a card from?
> Is this roughly the same as "supportedNetworks" in basic card?

New text:

 "Based on 13 November 2020 discussion, we should not assume that every SRC payment handlers will be able to display cards (for selection) from every SRC system. As an example: a payment handler may be able to display cards from the American Express SRC system but not the Discover SRC system."


> https://github.com/w3c/src/wiki/UX-Assumptions-and-Requirements#add-card-based-on-pan-entry
> "The user would enter a PAN, leading ultimately to installation of a relevant payment handler capable of enrolling that PAN"
> 
> This implies that knowing the SRC system for a card is enough to select an appropriate SRC payment handler that could enroll the card.
> This further implies that payment handlers will be published by the SRC systems. (i.e. There will be an SRC payment handler from VISA, from MasterCard etc)
> Is this correct?

I don’t agree with your conclusions. My understanding is this:

 * From the PAN you can tell the corresponding SRC system.
 * Multiple payment handlers might exist that can talk to that SRC system, including payment handlers distributed by the network that runs the SRC system.

> 
> "[pre-installed] payment handlers can support "add card: functionality."
> 
> This contradicts the earlier statement that not all payment handlers can enroll cards from all SRC systems.

Good catch: that text should have been changed after we changed the assumption. I have corrected the text of the "Add Card Based on PAN entry.” 

> 
> Some clarifying questions which remain unanswered:
> 1. Would SRC-System-Published Payment Handlers live alongside DCF-published payment handlers?
> 2. If so, what flow would lead a user to installing a DFC-published handler?
> 
> https://github.com/w3c/src/wiki/UX-Assumptions-and-Requirements#no-payment-handler--wallet-selector
> "Users must be able to select an instrument for payment without an intermediate step of selecting from a set of available payment handlers (wallets)."
> 
> It is impossible to provide this experience and provide users with choice.
> If a merchant supports multiple payment methods (including SRC) and some of these are specific to a wallet (e.g. PayPal, Google Pay, Apple Pay) then the user MUST be prompted to select a wallet.

> If the requirement is restated as "without an intermediate step of selecting from a set of available SRC payment handlers" then the answer is for SRC cards to be installed as individual payment handlers and appear in the selection list, branded by SRC system alongside non-SRC wallets.

Good suggestion. The text now reads:

  "Users must be able to select an instrument for payment without an intermediate step of selecting from a set of available SRC payment handlers (wallets)."

> 
> The question remains, as I have already asked in another thread, what happens in this case but where the user has no SRC payment handler installed?
> The user is prompted to choose between "Bob Pay, Other Pay and ???????"
> What is the desired user experience here?

If the merchant accepts other payment methods, handlers for those show up and don’t for SRC.

Or, if there is a mechanism that enables just-in-time installation, then that could happen, too.

> 
> "prompting the user to select one from among multiple wallet options is not an acceptable user experience to bootstrap the ecosystem."
> 
> This seems like a bootstrapping/distribution problem for SRC payment handlers not something that the W3C needs to solve.
> Any other payment method that wants to bootstrap it's ecosystem will face the same challenges.
> The primitives are there to use: URL based payment method identifiers, payment method manifests with default payment handlers that are JIT installed etc.

--
Ian Jacobs <ij@w3.org>
https://www.w3.org/People/Jacobs/
Tel: +1 718 260 9447

Received on Wednesday, 27 November 2019 15:18:51 UTC