w3c / src Goto Github PK

Checkout API returns EventHistory as one of the top-level response parameters. Does it need to be reflected in the Payment Method response model?

From Assumptions and Scope:

"To access an SRC Profile for a customer, an SRC payment handlers will need to manage customer identity information. How a payment handler does so is out of scope for this SRC Payment Method definition."

Given that many merchants sites and the browser will know the identity of the user and be able to provide this to the payment handler it seems short-sighted to make this out of scope.

At a minimum the merchant could provide user hints that avoids the user needing to pick from multiple profiles.

From the goals:

"At transaction time, if the merchant accepts the SRC payment method and the browser implements it, the user will be able to pay with an issued card."

This suggests there is an expectation that browsers will need to do some form of additional implementation beyond the existing standardised APIs (Payment Request and Payment Handler).

I would have expected the goal to be the opposite, for SRC to work without needing special implementation.

Should this read "and the browser implements PR API and PH API"?

In the tokenization spec we defined a token usage type input parameter:
https://w3c.github.io/webpayments-methods-tokenization/index.html#tokenusagetype-enum

Some feedback we've heard:

• Card-on-file would be a nice-to-have, but not requirement for version 1.
• "Recurring" flag may not be meaningful for tokenizedCard or otherwise. Once card-on-file is created, merchant can use it in context of recurring.

Based on discussion on 31 March, there was a request that the payment method support custom data that is handed to SRCIs
https://www.w3.org/2020/03/31-wpwg-minutes.html

In previous conversations about 3DS through payment handlers we sought to identify what data would be needed (e.g., about the merchant) for a payment handler to initiate a 3DS call. Some analysis of AREQ data was done as part of trying to answer this question:
https://github.com/w3c/webpayments/wiki/3DSDataSources#data-about-the-merchant--transaction

Now, with SRC, it is at least possible that some input data is subsumed by an enrollment procedure that happens at another time.

The question remains open: what request data is required (or optional) to support 3DS flows initiated by a payment handler?

Ian

Here are the Basic Card response [1] fields (first) and the current corresponding SRC response names (second):

• cardholderName v. consumerFirstName and consumerLastName
• cardNumber v. accountNumber
• expiryMonth v. expirationMonth
• expiryYear v. expirationYear
• cardSecurityCode v. dynamicData
• billingAddress v. no corresponding field.

It would be great to align at least the first four. Also, do we need billingAddress for SRC?

[1] https://w3c.github.io/payment-method-basic-card/#basiccardresponse-dictionary

If some portion of SRC response data is encrypted, how are keys exchanged (between merchant/PSP and payment handler) for that?

Some option:

• Out of scope for the SRC payment method (e.g., because handled during onboarding).
• Provide key as input data.
• Provide link to key as input data.

In SRC there is an optional parameter serviceId that can be provided by DPA/Merchant to SRC Systems. The value identifies service or program that the checkout request relates to. This parameter is not listed as part of Request Data [1]. This is a gap.

[1] https://github.com/w3c/src/wiki#request-data-for-payment-handlers

The architecture doc says:

Furthermore, the "hasEnrolledInstrument" method enables merchants to determine whether the user can support SRC payments, especially valuable in a guest checkout scenario. Merchants do not have access to this type of information through other means.

but "hasEnrolledInstrument" remains controversial from a privacy perspective.

In "Common Payment Handler functionality", and elsewhere, the document talks about "SRC-I", but that is not defined.

In section Conumer Identity there is a list of three parameters related to requested details of the consumer. They map nicely to equivalent parameters specified in PaymentOptions dictionary of PR API.

I'd like to consider adding the following mapping between PR API PaymentOptions and SRC DpaTransactionOptions to the definition of payment method:

• requestPayerName maps to consumerNameRequested
• requestPayerEmail maps to consumerEmailAddressRequested
• requestPayerPhone maps to consumerPhoneNumberRequested

The question remains open whether the requested/required details should be included in the encrypted payload as per SRC specification or in PayerResponse.

The modal window approach improves security because the browser displays the payment handler origin, making phishing more difficult.

I'm hesitant to have the document say the above... we don't know how much it helps, as I don't know if anyone has user tested this.

From Security:

"We seek to reduce the likelihood of "bad actors" claiming to be SRC payment handlers."

Can you provide some more detail on this?

This assumes there is an entity(ies) that defines good and bad actors and another (possibly the same) that enforces that bad actors are excluded from the ecosystem.

The existing PH API architecture already supports the concept of whitelisting handlers at the discretion of the payment system operator. This is then enforced by the browser who gets the whitelist from the manifest.

Is there a suggestion that this system is not sufficient for SRC and if so why?

If we have a common payment handler that speaks (through SRCIs) with SRC systems, it could be interesting for that payment handler to be able to get (silently, but with user consent) token updates for card on file use cases.

In my mind this is a sort of "v2" feature.

At our 24 July 2019 call [1] we talked about going into more detail on user journeys with SRC payment handlers, for example:

• User enrolls card
• User selects enrolled card to pay
• User has three cards issued by three different banks; what authentication will be required to display cards? Will three authentications be required?

We plan to create more detailed flow diagrams to help answer these questions.

[1] https://www.w3.org/2019/07/24-wpwg-minutes.html

Section Assurance contains AssurancePreference. I believe it should match threeDsPreference attribute of DpaTransactionOptions.

The values for ThreeDsPreference are:

• NONE
• SELF
• ONBEHALF

We dropped supportedTypes from Basic Card due to implementation challenges. Does the SRC ecosystem make it easier for payment handlers to know definitively the type of a card (credit, debit, prepaid)? If so, should we add this parameter to the SRC payment method?

SRC 0.9 defines a payloadTypeIndicator (summary, full, payment, non_payment). Do we need to represent this information in the payment method response data?

Ian

We have discussed different response payload options related to card data:

• Token with cryptogram
• Token without cryptogram (does this amount to something like Basic Card?)
• Reference so that PSP can retrieve token with cryptogram

Presumably we need a request parameter for some subset of these options.

The flow diagrams show 3 possible implementations of SRC using PR an PH API.

The 2nd flow titled "Flow Diagram with Browser as Aggregator of Card Metadata" is a poor approach and would lead to endless interoperability issues if implemented.

The requirement for browsers to bind themselves to a closed and proprietary ecosystem so tightly is unprecedented and makes then forever beholden on changes to that ecosystem over which they have no control.

Will the interface between the browser and the SRC Systems be standardized by the WG?

If so, can other systems use the same interfaces to register their non-card instruments with the browser?

Or, will cards always be surfaced on the payment sheet as a priority over other instruments which must be aggregated behind a payment handler?

We have agonized in the group over issues related to prioritization and ordering of payment methods and display of payment instruments. This approach appears to segregate things into non-SRC payments which are subject to the user-centric rules the WG has defined, and SRC payments where the ordering and priority is imposed on the browser by SRC Systems or, at best, defined outside the WG.

I would advise those working on this integration to abandon this option asap.

If there is a desire to surface instrument level detail on the payment sheet this can be done via PH registration as had been discussed in the PH task force previously.

In SRC specification 1 there is a concept of custom data that can be passed from DPA to SRC System as customDataInput and returned from SRC System back to DPA as customDataOutput. Both parameters are defined as a JSON Object without strict schema defined.

Should SRC Payment Method support the concept? If so, then data model would need to be updated to include:

• customInputData defined as JSON Object in Request Data
• customOutputData defined as JSON Object in Response Data

Would you expand the SRC acronym in the title of https://github.com/w3c/src/blob/gh-pages/src-prapi.md? Or at the very least, expand it in the first two sentences?

Do we need a request parameter for transactionType? (e.g., Purchase, P2P).

Web App Manifest supports platform platform information. Do we need additional information about the browser (e.g., "Firefox on MacOS")?

Note that platform is related to "ExternalApplicationResource", not a general thing. Also, anything Browser/OS specific should be avoided (at all costs).

In the tokenization spec [1] we distinguished the use case where the payee receives a "full" payload from the use case where the payee receives only a token reference id (and uses that reference on the back end to fetch the full data).

I assume we still wish to represent both use cases. How does this impact our response data model?

[1] https://w3c.github.io/webpayments-methods-tokenization/

The draft SRC model calls for both:

• accountNumber, expirationMonth, expirationYear
• panBIN, panExpirationMonth, panExpirationYear

Are both needed?

In the proposal, the merchant can optionally specify an SRC-I (that is included in by the common payment handler).

1. What is the (error) behavior if the browser cannot reach the SRC-I? Does the payment request fail?
2. If the SRC-I is indeed optional for the merchant to provide, what is the expected behavior when absent? If this is not an error, what party determines who the SRC-I will be? If it is the SRC system, how does the SRC system communicate that to the payment handler?

I propose we add an assumption that the merchant has already onboarded into the SRC system by the time this payment method is used. That will also allow for out-of-band key exchange.

Some of the usability benefits are "In Chromium browsers". Don't get me wrong, I'm a bit fan and use Chrome a lot... but I'm worried that mentioning particular user experiences will shape the overall expectation for how the experience should be (limiting the ability to innovate at the UX level).

From interoperability:

"We want to create a single SRC payment method that works across multiple SRC systems (e.g., card brand). Because a merchant may not accept payments through all SRC systems, the merchant must be able to indicate which SRC systems it accepts so that the browser can show corresponding payment handlers."

What does a "single SRC payment method" mean? Given that the next sentence implies that merchants will need to have explicit relationships with each SRC system what does a single SRC payment method provide? Is it simply a common data model?

If that is the case, our architecture explicitly supports the use case of merchants expressing a relationship to a payment system through URL-based payment methods where the payment systems is also the owner of the origin used in the URL.

Why is there an aversion to using URL-based payment methods for each SRC system?

The draft SRC data model includes some masked response data for display: maskedEmailAddress, maskedPhoneNumber, maskedCountryCode.

There was a proposal to return the complete (unmasked) data with user consent. Further comment: "Consumer consent may be explicit / implicit depending on DCF policy."

Could we have the arc document as a standalone markdown document... otherwise, difficult to send changes to it.

In the draft today there are three options for dynamic data:

• None. This intends to address the use case where the merchant does not want dynamic data. Question: Does this mean that accountNumber is a PAN?
• Limited. This is for cases where the dynamic data is most likely a few digits (e.g., dynamic cvv I think).
• Full. This is for more advanced alphanumeric data.

Are these the right labels? Do we need a system that supports greater extensibility?

Ian

Is there a single parameter we can specify (e.g., assuranceData) in the response, and define it to be SRC-system specific?