Skip to content

Home

Jump to bottom
ianbjacobs edited this page May 2, 2019 · 98 revisions

This was the repo of the Tokenization Task Force (of the Web Payments WG) regarding tokenized card payments. The task force created two draft documents:

In 2018, discussion Card Payment Security Task Force.

Mission

STATUS: This is a draft mission statement. Questions? Ian Jacobs ij@w3.org

Tokens in use for card payments today include:

  • Tokens issued by payment service providers to merchants. After the merchant (or their Payment Service Provider (“PSP”)) has collected user credentials - for example, credit card number ("PAN" - Primary Account Number) and expiration date - the credentials are stored in a secure vault and the merchant receives a token for subsequent business activities. These are often called Security Tokens but may also be known as Merchant Tokens, Acquirer Tokens, or Gateway Tokens.
  • "Network" Payment Tokens as defined by the EMVCo Payment Tokenisation Specification – Technical Framework.

While these mechanisms increase security, there are a number of limitations in today's ecosystem, including:

  • Tokens stored on physical cards or proprietary mobile apps are not readily available for commerce on the Web.
  • Security Tokens offered by PSPs for tokenization require bilateral arrangements with merchants. Small merchants may not be willing to invest in these services. Diversity of these APIs can increase integration costs, especially for those merchants who engage in commerce in many countries or who wish to make use of multiple PSPs within any given country. Without a standard way to communicate with PSPs, there is also a high cost to switching Security Token providers.

Goals

  • Using the Basic Card Payment method with Payment Request API primarily offers usability advantages (and thus is expected to increase conversions). However, Basic Card data includes unencrypted PANs. The Task Force seeks to "do better than Basic Card" by reducing exposure of cardholder PANs in payment flows. This is expected to reduce fraud and the scope of merchant PCI DSS compliance.
  • The Task Force also seeks to leverage existing tokenization solutions supported by networks, merchants, issuers, acquirers and PSPs, so that merchants and PSPs can more easily process payments using these existing solutions.

Thus the opportunities for merchants relate to:

  • Reduced PCI DSS scope
  • Improved security
  • Easier integration

Who Benefits from this Effort

  • Consumers: Consumers will benefit from reduced fraud and increased privacy protection.
  • Merchants: This is expected to reduce fraud and PCI DSS scope and increase competition among Payment Service Providers.
  • Payment Service Providers: This is expected to reduce fraud by expanding the use and access to tokenization solutions and scale business by making it easier to interact with more merchants.
  • Payment Systems/Payment Networks: Broader adoption of tokenization solutions may help reduce fraud.
  • Issuers: Issuers may benefit from the reduced fraud due to broader adoption of tokenization solutions.

Note that the end user experience is not expected to change materially when switching from traditional card payments to those enabled through the deliverables of this task force.

Scope

  • The focus of this task force is on the secure communication of card information. The task force is not discussing tokens that represent anything other than card payment credentials.
  • The task force does not seek to define a new token format (e.g., "reusable tokens across gateways").
  • The task force does not seek to favor a particular token format.
  • The task force is not focused on gateway tokens, although it has discussed them. Today gateway tokenization typically happens after the merchant (or gateway) has received a PAN. Initial discussion suggests that there may not be significant interest by gateways in "user side tokenization", and thus there does not seem to be a need for a shared gateway tokenization payment method. However, any party can define a payment method, and if the Task Force perceives patterns among such payment methods, it could revisit the question of gateway token harmonization.
  • The task force is not looking to define a merchant to gateway (back end) protocol.

High Level Description of Deliverables

NOTE: THIS DOES NOT YET REPRESENT TASK FORCE CONSENSUS.

Encrypted Card Payment Method

Payment gateways (or other parties calling Payment Request API) would use PKI to enable payment apps (including, ideally, user agents) to encrypt Basic Card Payment data so that only the receiving gateway can decrypt it. This has the potential to lower assessment costs for merchants seeking to reduce their PCI DSS exposure.

Questions:

  • Are there gateways interested in consuming these encrypted blobs?
  • Encrypt PAN alone or the entire Basic Card data in the PR API response?
  • In theory a merchant could refer to multiple gateways, but, for simplicity, should we focus on one initially?
  • Should merchant pass a gateway key or a reference to such a key (to be fetched by the payment app that does the encryption)? We can leverage existing certificate mechanisms to increase security.
  • Although it makes sense to start with an encryption feature for one payment method specification, we should monitor this pattern for potential elevation to a PR API feature (in v2).

Tokenized Card Payment Method

Network token interoperability suggests that there will be a benefit to eliminating the integration cost of merchants (or their gateways) receiving tokens from a diverse ecosystem of payment apps. The Tokenized Card Payment Method specification is designed to make it easier for network tokens to circulate on the Web.

FAQ

Does this work mean merchants will not need business relationships with PSPs?

No, we expect merchants will still have business relationships with PSPs and need to manage back end integration. This task force seeks to make it easier for merchants and PSPs to work together by reducing the friction of communicating tokens on the Web.

What is the relationship to EMVCo standards?

This task force is focused on making it easier to bring tokenization for payments to the Web, including EMV Payment Tokens. This task force does not plan to define a token format and takes into account the EMVCo Payment Tokensiation Specification – Technical Framework. A payment token based upon EMVCo Specifications is a reversible token generated at the issuer level. This means that the reversible token can be securely mapped back to its original card account number by the provider of the payment token and authorised entities only. It is used as part of the payment chain and, when submitted in a transaction to the payment system, would cause a payment to occur.

The tokenization process happens in the background in a manner that is typically invisible to the consumer and transacting merchant. Such tokens could be used by merchants or digital wallet operators, and can be stored in EMV chip cards, NFC devices and on cloud. The payment tokens may be restricted to specific domains. For example, a token may be usable only within the e-commerce acceptance channel at a specific merchant. An additional payment token capability is the ability to unlink the token from the original card account number in case that token is either no longer needed, or a mobile device or card has been reported as lost or stolen. Payment tokens will be of particular value in card-not-present transactions, as well as in mobile devices and other form factors.

What is the relationship to PCI?

See: Additional Security Requirements for Token Service Providers (EMV Payment Tokens)

Related Conversations

Strong Authentication

Beyond reducing merchant PCI DSS scope, there is some interest in fostering strong authentication to achieve transaction approval rates on the Web similar to "card present rates". This will involve strong authentication technologies, such as the work of the Web Authentication Working Group. The task force may continue to discuss how to make use of a payment method specification to enable merchants to favor payments by systems that can demonstrate they have performed strong authentication of the user.

3DS in Payment Apps

The task force has also mused about whether Payment Request API could enable 3-D Secure (“3DS”) authentication on the user side, from a user's payment app.

Resources

Meetings

Clone this wiki locally