Card Payment Security Task Force

Review of SRC payment method draft and issues list.

Issue 6

https://github.com/w3c/src/issues/6

lte: With regards to SRC, I'm trying to think through the determination of the payment type

IJ: This is pre consumer selection; helps with matching

benoit: I see having type selection as being an issue
... I may not want to process for gift cards
... There is no reliable source of the data....could we issue a challenge to the issuers for reliable source of data publicly available?
... it would be great to have trustworthy data

deanezra: The question here is for SRC systems...do you have this data?

lte: Is it the SRC-I or the SRC system that holds that info?

Jalpesh: Some of these things are dynamic; to David's point the database is online but keeping it up-to-date on the device raises challenges.
... merchants can determine debit or credit; that exists.
... it's consuming from a consumer perspective to not have cards available with some merchants.
... What is the value of merchants say "I accept only credit"

jonathan: there are use cases where the merchant does not accept prepaid cards
... so Google Pay, for example, grays out card to mean "not accepted at this merchant"

benoit: I would say the inverse is more likely: someone is more likely to accept debit but not credit. That has more to do with fees than anything else.
... in some markets there are promotions run by issuing banks for debit v. credit

<deanezra> Not accepting AMEX is common in uk, due to costs

Jalpesh: From a user experience perspective, doesn't seem like good UX to not allow the user to pay with a card
... There needs to be merchant preference expression, but no need to complicate the UX
... you'd rather not have a failed transaction.

benoit: How is the merchant to know?

Jalpesh: Via acquirer; and routing decisions would happen as they do today.

benoit: Even if we say we don't want to limit user choice, to not return back to the merchant the card type info seems a bit strange to me.

jalpesh: I think we are talking about two things (1) data returned in response to the merchant (2) can it be a request element....here that's mostly what I'm talking about...don't want to prevent user from using a card.

lte: Regarding the user experience part, I think that's important from a consumer experience standpoint.

IJ: Depends on the definition: "preference" v "cannot accept"
... Do you need a ux where the merchant cannot accept a type?
... So is there more reliable source of type info in the SRC?

Jalpesh: Types get convoluted.

<scribe> ACTION: Jonathan to investigate reliability of card type info from SRC metadata.

<trackbot> Created ACTION-116 - Investigate reliability of card type info from src metadata. [on Jonathan Grossar - due 2019-05-22].

Issue 7

https://github.com/w3c/src/issues/7

Jalpesh: Two examples of transactionType....purchase, p2p are examples
... there are other use cases like disbursements
... this can drive behavior from src system or dcf
... the intent was to enable those use cases

IJ: I am hearing this is transaction parameter not a filtering parameter

lte: Is purchase return a transaction type? e.g., I don't take returns?

<jalpesh> +q

jalpesh: I don't see it as a filter, as much as an enabling piece of data
... e.g., you may not need dynamic data for some transactions
... there's still a transaction that has happened between merchant and the network but it's slightly different payload knowing transaction tyep

deanezra: Is this data useful to browser UX?

jalpesh: More the payment handler than the browser.

deanezra: I'm not yet sure what the use cases are.
... if today transactionType were not in the payment handler, would it matter?
... the payment handler might show different information in the UX depending on transactionType

Jalpesh: My current thinking is that trasnactionType will not so much affect UX but more the response payload.

IJ: Got a link to where that's discussed?

Jalpesh: Not yet.

<scribe> ACTION: Jalpesh to figure out how to describe or refer to transactionType.

Issue 8

https://github.com/w3c/src/issues/8

https://w3c.github.io/webpayments-methods-tokenization/index.html#tokenusagetype-enum

IJ: Is it useful in an SRC context to know this info?

Jalpesh: Yes, I think so. When merchant adding card on file
... backend processes are different depending on one-time v. card-on-file
... but the syntax is the same. We would add domain controls for card-on-file.

IJ: Is "recurring" useful?

Jalpesh: I think card-on-file suffices.

lte: I agree that card-on-file indicator would be useful.

<benoit> q: can we use the same terminology as Stored Credential Transaction Framework?

Jalpesh: The distinction of card-on-file v. recurring may not work for a merchant.
... a company, say, might use the same credential for both card-on-file and recurring
... they might use token for partial shipment but also my recurring subscription.

benoit: Can we use the same terminology as Stored Credential Transaction Framework?
... these do matter e.g., in PSD2 regarding SCA

Jalpesh: That's part of the transaction info, however.

IJ: I am hearing:

- some param useful

- may not be for filtering but backend / response behavior

- at least one-time and card-on-file useful; still open issue about recurring.

IJ: I will update the issue with those findings

<scribe> ACTION: Ken to look into whether identifying a token for a recurring payment is useful beyond card-on-file identifier.

lte: I think all networks should reply
... since they may behave differently.

Jalpesh: If even one network wants it we should include it.

Ken: I will look from both EMVCo spec perspective and also Amex-Specific.

Next meeting

29 May