Card Payment Security Task Force

Review flow diagrams

Flow diagrams

IJ: What does "Authenticate" mean?

Jalpesh: I see this as authentication to the Payment Handler (provider)
... how the payment handler recognizes the consumer

Jonathan: I agree that's it is auth to the payment handler distributor.

IJ: What auth is required to SRC?

Dean: There are different assurance methods

Jalpesh: I am signing up (to the payment handler) but have not yet provided my card credentials.
... when you provide the card info, that's when SRC comes into account.
... the SRC COULD take into account how the user was authenticated, but that's not necessarily part of the protocol.

Dean: So after you've added a card, is there an assurance step?

Jalpesh: There might be assurance step after 7
... e.g., whether to step up the user.
... that is an optional step after the enrolment response.
... Maybe can call out optional cardholder verification.

Dean: It's not optional is it?

Jalpesh: It's optional for SRC since it's risk-based.

Dean: The reason you might want another flow, is that the payment handler might need to show new UI.
... if SRC sees a risk then you could get an optional extra flow.

lte: Is that risk decision solely based on SRC?
... can the DCF decide?
... would there be a merchant option to take into account in the decision process?

Jalpesh: This is not in the context of payment, this is just app enrolment

IJ: Let's come back to that in the transaction flow.

lte: During checkout, an enrolment decision could be made.

IJ: Three decision points:

- accept SRC at ll

- hasEnrolled Instrument

- step up preference

Jonathan: Agree with step-up in enrolment flow; we should also indicate what we expect in in the 7 response data

deanezra: For steps 4/5...is there a case where you could do more than one card at a time?

Manoj: For Visa it's one at a time for now

IJ: Should we say "one or more cards"

deanezra: yes

Jalpesh: Doing it one card at a time is the right UX from my POV

IJ: Does SRC speak to this (e.g., do one at a time, don't do one at a time)?

lte: Since this is just enrolment and not specific to a checkout, I don't know that we have a major concern either way
... but I agree keeping it simple is a good thing
... but I'm not sure how the DCF chooses to prompt...but users should have a choice of which card to use in which circumstance

Jonathan: Think we should discuss enrolment as one card, and see N cards during transaction.

lte: If the DCF is engaging with N SRC programmes, who makes the decision about which card is presented (debit or credit)?

Jalpesh: Consumer makes a decision which cards to enroll.
... those cards can be registered with the browser (next flow)

[transaction]

IJ: Today mediator shows payment handler, user selects payment handler, browser launches payment handler for potential user interaction
... specs allow instrument-level info in the sheet; browsers don't yet implement

deanezra: I think #4 already says "multiple cards" not payment handlers

IJ: I can fix editorially

deanezra: What happens if card entered in N > 1 payment handler

IJ: Mediator can show handler container name to disambiguate

lte: I am concerned about confusion seeing the same card twice

deanezra: +1 that this needs to be addressed.

Jalpesh: Should we include a requirement that if a card is available through N > 1 DCF, the browser needs to provide consumer the choice of which DCF to use in the transaction.

Jonathan: They will display all the cards, so that would fulfill the requirement.
... the logo of the payment handler will disambiguate

IJ: Let's attack the problem of showing instrument level information first, rather than the duplication edge case

Next steps

- Ian adjusts diagram

- Ping Google and browser vendors about instrument-level display in the mediator

- How should we model the payment method (including URL-based or open)? Let's discuss at next call

Jalpesh: I like Rouslan's proposal ('src' maps to SRC Programme URIs)
... merchants still have a choice of specifying supportedNetworks?

IJ: I would assume supportedNetworks but also possibly more. Recall that for basic card we dropped cardType but it might be relevant in the context of tokenization.

Jalpesh: Yes, we shoudl revisit "cardType" in this context.
... Should we also have a single spec (e.g., src) or have multiple (src, tokenized, 3ds)
... tokenized card is not required
... with SRC
... we could just use an SRC envelope with parameters about basic or tokenization

lte: +1 we need to explore that as well.
... I would advocate having tokenization available outside SRC

Next call

6 Feb

scribe: continue discussion on structuring the payment method
... and any other lingering diagram observations