-
Notifications
You must be signed in to change notification settings - Fork 7
Home
The Web Payments Working Group is looking into creating a payment method to enable EMV® Secure Remote Commerce through the Payment Request Ecosystem.
When a payment handler implements the Basic Card specification, there is simple collection, storage, and returning of raw card data.
A payment handler for an SRC payment method would enhance security through authentication of the cardholder and tokenization of card data. This payment method implies more elaborate flows than basic card and consequently more stakeholder involvement (e.g., authentication by issuing banks, tokenization by token service providers, etc.). In the text below, the SRC role of "Digital Card Facilitator (DCF)" is carried out by a payment handler.
For more details, please see SRC information from EMVCo, including an SRC FAQ.
For additional background information and relevant draft specifications, see WPWG's previous 3-D Secure 2 (3DS) discussion and previous tokenization discussion.
This is a draft. This document is for discussion only and does not represent consensus.
Note: If the Working Group resolves to take up this work on the Recommendation Track, we expect to solicit early review by W3C's Technical Architecture Group (TAG) and Privacy Interest Group (PING) in particular.
- At transaction time, if the merchant accepts the SRC payment method and the browser supports it (at least) through Payment Request and payment handlers, the user will be able to pay with an issued card. The user would either select a card previously enrolled in the SRC system or have the option to enroll one.
- When the browser displays one or more SRC payment handlers in the sheet, the browser should display individual cards for selection (that is, instruments registered by the payment handler).
- The experience of accessing registered or default payment handlers should be seamless.
- The experience of selecting a previously enrolled card or enrolling a new one should be seamless.
- 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. (See the model used in Basic Card.)
- We seek to reduce the likelihood of "bad actors" claiming to be SRC payment handlers.
- We want merchants to be able to express a variety of preferences regarding assurance / authentication, including, but not limited to, 3-D Secure 2 (3DS).
- We want to enable a flow where the payment handler initiates the assurance process on behalf of the merchant.
- 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.
- Issue 5 suggests there may be use cases where the merchant has information about customer identity that it might wish to pass on to the payment handler.
- The merchant has already onboarded into SRC systems prior to the usage of this payment method. See issue 13. In particular:
- How keys are exchanged (during onboarding or at other times) to enable the encryption of part of the payload is outside the scope of this payment method. See issue 10 regarding encryption and key exchange.
- Regarding 3DS:
- In this wiki we focus on the use cases where 3DS flows are initiated by payment handlers. 3DS flows can also be initiated by merchants or PSPs. This payment method definition does not intend to address such flows.
- 3DS can be used both within and independent of an SRC flow. At its 4 September 2019 meeting, the Card Payment Security Task Force resolved to focus on the use case of 3DS when used as part of an SRC flow. Once we have a solid understanding of that use case, and if we are aware of other payment methods that wish to leverage 3DS, we can return to the question of factoring out 3DS support. At such a time we may return to previous work on a 3DS module.
- A short string identifier (such as 'basic-card') can used for a standardized payment method. We have not yet established whether we prefer a short string identifier or a URL. We expect other design considerations to drive the choice.
- While a short string identifier could reduce effort for developers, Chrome has indicated that they have made certain assumptions for standardized payment methods. We need to review those assumptions and the cost of making changes to accommodate new functionality for this (and any other payment methods).
- Another idea that was mentioned is to define a short string identifier (such as 'src') that browsers map internally to a URL.
- In the Payment Request ecosystem, browsers display registered payment handlers for the payment methods accepted by the merchant. When there are no registered payment handlers, the browser may display candidate payment handlers that the user may register "on the fly." The Chrome implementation leverages the payment method manifest to display candidate payment handlers identified by the owner of a payment method. In order to fulfill the goal of there always being a payment handler for a payment method with no owner or where the owner has not specified a default, a desired capability is that the browser offer one or more candidates to the user. This can be viewed as a "browser-internal payment method manifest." Such a mechanism is not specific to SRC.
- There is an expectation that a payment handler will not receive Payment Request API events (such as
canMakePayment) before registration. The Payment Handler API leaves the details of registration —and establishing user consent— to the user agent; see section 8.2. In the case where the browser offers an SRC payment handler from its internal manifest, there may be a variety of ways to establish user consent. - Chrome today supports a 'skip-the-sheet' functionality under some considerations. This contributes to a streamlined payment experience. However, if the merchant requests shipping address or contact information, Chrome does not enable 'skip-the-sheet'. Although it is not directly related to SRC, it is worth noting payment handler issue 337, which proposes that some data collection can be delegated to a payment handler, enabling more opportunities to 'skip-the-sheet'.
- The payment method definition needs to support 3DS as one assurance flow, but also allow for other flows that an SRC system might support.
We could take multiple approaches to limiting the risk of "bad actor" SRC payment handlers.
- Whitelist: We could use a payment method manifest so that the browser only shows the user those Digital Card Facilitators that have been certified through various SRC systems. This approach has some appeal because it leverages the existing infrastructure.
- Blacklist: Browsers can help to blacklist malicious payment handlers (e.g., via the safe browsing database).
- At the current time, there seems to be a preference for relying more on the blacklist for several reasons:
- There is not yet definitive information about DCF certification processes.
- For a single SRC payment method, it is not clear which entity would manage and host the single payment method manifest.
- There might be a significant cost to maintaining a dedicated payment method manifest over a long period of time.
- Even if there were a payment method manifest, it would not likely specify default payment handlers, so it would not help address (through just-in-time registration) the user experience goal.
See issue 4 which seeks more rationale for the above.
- Any browser that supports the SRC payment method MUST make available to the user a "default" payment handler when there is not yet a registered SRC payment handler. Specification note: We anticipate including this requirement in the SRC payment method specification.
- For some parameters below we provide as a convenience to the reader the values defined in the SRC API version 1.0. For authoritative information, please see the (EMVCo SRC API 1.0)[https://www.emvco.com/wp-content/plugins/pmpro-customizations/oy-getfile.php?u=/wp-content/uploads/documents/EMVCo-Secure-Remote-Commerce-Specifications-API-1.0.pdf].
STATUS: This is a VERY EARLY DRAFT of a data model for an SRC payment method. It represents no consensus and is likely to change.
- supportedNetworks. See the basic card definition
- supportedTypes (credit, debit, prepaid)? See issue 6.
Note: This data is defined in EMVCo specifications.
Payee identification is achieved from two sources:
- Data made available by the browser to the payment handler (in Payment Handler API), namely the origin of the web page the user is visiting ("topOrigin") and the origin that called Payment Request API ("paymentRequestOrigin"). This distinction allows support for the case where Payment Request is called from an iframe.
- Data provided by the origin that called Payment Request API, which has additional knowledge about the identity of the payee. This is to handle use cases when the payee origin is neither the topOrigin nor the paymentRequestOrigin, such as when a third party hosts a checkout page for the payee.
This payment method defines the following parameters:
- payeeIdentifier (string), an optional SRC-specific identifier for the payee
- payeeName (string), used for display of the payee identity to the user (or other similar purposes)
- payeeCategoryCode (string).
- payeeCountryCode (optional)
Here is the outline of an algorithm for a payment handler to map browser-supplied and requestor-supplied data to SRC fields:
- Set srcInitiatorId to the paymentRequestOrigin made available through Payment Handler API.
- Set srciDpaId to payeeIdentifier if provided, otherwise set to topOrigin made available through Payment Handler API.
- Set dpaPresentationName to payeeName.
- Set payeeCategoryCode to merchantCategoryCode
- Set payeeCountryCode to merchantCountryCode
Note: We can, of course, rename parameters for better alignment with SRC names.
- consumerEmailAddressRequested
- consumerNameRequested
- consumerPhoneNumberRequested
SRC defines an identifier generated by the SRCI for each transaction. Here is the outline of an algorithm for a payment handler to map browser-supplied data to the relevant SRC field:
- Set srciTransactionId to the id attribute of Payment Request API.
Thus, there is no payment method-specific parameter for transaction id; it is provided as part of using Payment Request API.
- transactionType (string) This optional parameter can have an impact on backend processes and may affect the response data. It is not likely to affect the user interface. For background see issue 7. For convenience we include here the enumeration values defined in SRC API 1.0:
- PURCHASE
- BILL_PAYMENT
- MONEY_TRANSFER
- DISBURSEMENT
- P2P
- cardOnFile (boolean). When this optional parameter is present and
true, indicates a payee expectation that a returned token will be stored for future uses. This parameter may be used by an SRC system to optimize the returned token. Note that some SRC systems may ignore this parameter, and others may carry out the same or similar optimizations based on information independent of this parameter. For background, see issue 8. - payloadTypeIndicator (enum). See issue 18. For convenience we include here the enumeration values defined in SRC API 1.0:
- SUMMARY: The Checkout API call should not return any encrypted Payload object. Instead, the client can use Payload API to retrieve the Payload object presenting srcCorrelationId as a reference.
- PAYMENT - The encrypted Payload object should contain only payment credentials, but no other data such as Consumer details nor address.
- NON_PAYMENT - The encrypted Payload should contain only non-payment personal data such as Consumer details and shipping address when requested by the Merchant/DPA
- FULL - The encrypted Payload should contain both payment credentials and personal data.
- dynamicDataPreference (ordered list of strings). An list of SRC-defined dynamic data type identifiers. The first identifier in the list represents the merchants first choice, the second represents the second choice, etc. This parameter is optional; its absence indicates the payee wants no dynamic data. See issue 9 and also dynamicDataType below.
- dpaShippingPreference
- dpaAcceptedShippingCountries
- assurancePreference (optional)
- Modeled on 3DS preference discussion
- assuranceInputData (3dsRequestorId, acquirerId, acquirerMid). See also issue 22.
- dynamicDataType
- propose name change: dynamicDataPreference; see below for dynamicDataType in response
- enumeration: none, limited, full. See issue 14 regarding naming.
Note: At the 12 June 2019 task force call we discussed the overall shape of the response data. There we agreed to at least these members: identification, encrypted data, displayable data, assurance data. We also agreed to discuss further the inclusion of event history and custom output data.
- This identifier is unique to a given SRC system. It is assigned during an initial request and used in future message to link them to the initial request.
- The Payload element is defined in section 2.1.27 of the SRC API v 1.0.
- It encrypts the following type of information:
- Card or token data
- Dynamic data
- Consumer details
- Shipping address
Note: See payloadTypeIndicator in the request data for how to use srcCorrelationId to request token details from a gateway or other entity on the backend rather than in the response data of this payment method.
Note: This displayable data is expected to be a subset of the different "Masked" data elements from SRC:
- 2.1.23 MaskedAddress
- 2.1.24 Masked Card
- 2.1.25 Masked Consumer
- 2.1.26 MaskedConsumerIdentity
See issue 11 about what subset of that should be returned in the response. Current candidates are:
- maskedEmailAddress. Masked version of consumerEmailAddress (string)
- maskedPhoneNumber. Masked version of consumerPhoneNumber (string)
- countryCode. The countryCode part of the billing address associated with the card (string)
- panBin
- panLastFour
- panExpirationYear
- panExpirationMonth
See also issue 12 on whether the payment handler can (with user consent) providing complete data rather than masked data.
- How is assurance data returned? See issue 16
- How is event history returned? See issue 19
- Is custom data supported and how it's represented in response data? See issue 20
Note: Although we are not likely to make user experience requirements part of a specification, we include these topics for discussion to improve our chances of implementations creating the best possible user experience.
See UX Assumptions and Requirements
- Multiple user identities and their interactions must be considered:
- With the merchant
- With the browser (e.g., with Google for Chrome)
- With the payment handler
- Potential sources of identity:
- User has established identity directly with the payment handler (e.g., name/password, WebAuthn)
- Payment handler can look for other identity information in the environment (e.g., via the Credential Management API)
- Hints from the merchant? (This might involve payment method request data.) Are merchants supportive of this? What privacy issues does this raise?
- When browsing the Web involves multiple identities (e.g., a home computer where multiple people have distinct payment handler identities), what, if anything needs to be done at the level of W3C APIs (e.g., security/privacy consideration)?
- EMVCo 3DS2 relies on JS in the browser. Are there other possibilities beyond that such as a new browser API?
- Display of instrument information in the sheet
- User experience when more than one payment handler is available