Tokenized Card

Tokenized Card Payment Method

Status: Draft

Overview

Payment networks such as Mastercard, Visa, and American Express provide tokenization services for credit cards and debit cards. The intention of tokenization is to ensure that a consumer's primary account number (PAN) is not exposed to potentially insecure merchant environments. To increase the security of payment processing, merchants —or their Payment Service Providers (PSPs)— may use tokens along with cryptographically generated dynamic data.

This document describes a payment method that provides EMV-like security in a BasicCard-like payment request flow. The payment handler does so by leveraging Payment Networks, Token Service Providers and Tokenized Payment Method Credentials. For more information about these concepts, see EMVCo on Payment Tokenization.

The term Network Token is still being discussed and may be replaced with a more informative and indicative term like Tokenized Card.

Request Example

const methodData = [{
  supportedMethods: ["tokenized-card"],
  data: {
    supportedNetworks: ['mastercard','visa', 'amex', 'discover', 'jcb','unionpay'],
    supportedTypes: ['credit','debit'],
    keyProviderURL: 'https://pspKeyProvider.example/tokenizedCardPublicKey', // See TokenizedCardRequest dictionary
  }
}];

const details = {
  displayItems: [
    {
      label: "Sub-total",
      amount: { currency: "USD", value: "55.00" },
    },
    {
      label: "Sales Tax",
      amount: { currency: "USD", value: "5.00" },
    },
  ],
  total: {
    label: "Total due",
    // The total is USD$65.00 here because we need to
    // add shipping (below). The selected shipping
    // costs USD$5.00.  
    amount: { currency: "USD", value: "65.00" },
  },
};

new PaymentRequest(methodData, details);

Payment Method Identifier

The standardized payment method identifier for this specification is tokenized-card

Payment Method Properties

Given that the this payment method provides Network Tokenized payment credentials, there are certain key considerations for the various participants:

• Payment handlers MUST be able to access the services of one or more Token Service Providers.
• Tokenized payment credentials MUST be encrypted.
• Token Service Providers MAY require KeyProviders to register/onboard.
• Payment handler implementations MAY provide out-of-band provisioning functionality.

TokenizedCardRequest dictionary

The TokenizedCardRequest dictionary shares supportedNetworks and supportedCardTypes with basic-card. Note that other information (such as the total) is passed through the Payment Request API itself.

dictionary TokenizedCardRequest{
             sequence<DOMString>       supportedNetworks; // Defined in Basic Card
             sequence<CardType>        supportedCardTypes; // Defined in Basic Card
             required DOMString        keyProviderURL; 
};

keyProviderURL

keyProviderURL defines a key URL that will expose a public key trusted by the Token Service Provider. The keyProvider, therefore, becomes the effective requestor of the tokenized-card from a Token Service Provider's perspective.

While out of scope for this document, each Token Service Provider may require on-boarding for KeyProviders to cover:

• Mechanisms to establish trust
• Mechanisms to establish supported cryptogram format
• Any other program specific requirements

TokenizedCardResponse dictionary

dictionary TokenizedCardResponse {
  required   DisplayData              displayData;           
             EncryptedTokenizedCard   encryptedTokenizedCard
};

dictionary DisplayData{
//Display data is returned unencrypted

//At least one of the following two hints should be available
conditional DOMString       displayMaskedCard;   //Provider-specific masked format using (*) for mask
conditional DOMString       displayLast4;        //Most common display requirement

//All of the following hints may be displayed
required    DOMString       displayExpiryMonth;  //actual expiry month of the card 
required    DOMString       displayExpiryYear;   //actual expiry year of the card
required    DOMString       displayNetwork;      //actual network of the card
};


dictionary EncryptedTokenizedCard{
  required  DOMString     encryptedTokenizedCard //encrypted TokenizedCard
};

//Data inside the encryptedTokenizedCard will be in the following format

dictionary TokenizedCard {
  required DOMString       cardNumber;    //token. this is not FPAN - not fit for display
  required DOMString       expiryMonth;   //may be dynamic - not fit for display
  required DOMString       expiryYear;    //may be dynamic - not fit for display
  required DOMString       cryptogram;    //dynamic data
  optional DOMString       typeOfCryptogram;   // required for Tokenized card -new - UCAF/IC
  optional DOMString       eci;           //electronic commerce indicator
  optional DOMString       trid;          // new - some TSPs may send this value
};

Flow: Checkout with Registered Payment Handler

Notes

---

Note on Encryption

NOTE: This construct is still under discussion and may evolve to be materially different from what is presented above.

Encryption is a REQUIRED feature of this payment method. We expect this proposal to follow a subset of the emerging web payments encryption proposal.

Discussions on key-providers for tokenized payment credentials are still underway. However, it may be necessary for the key-provider to hold separate keys for each TSP or Payment Network by onboarding with each TSP or Payment Network. Each TSP or Payment Network may have its own mechanisms and processes that the key-provider will need to adhere to. As an example, a TSP or Payment Network may require that the key be signed by the TSP or Payment Network's Certificate Authority.

FAQ

How will users add and remove payment instruments to the payment handler?

That is an implementation detail, whether the browser or third-party implements the payment handler.

Can browsers discover and install default payment handlers based on supportedNetworks?

Just-in time registration of payment handlers is under discussion.

How does the payment handler communicate with the Token Service Provider?

That is out of scope for this proposal (but will be necessary in the ecosystem to enhance inteorperability).

What is the relation between this payment method and PCI compliance?

The Web Payments Working Group does not have a formal position on the question. Please see PCI Tokenization Guidelines Supplement and consult with your organization's compliance officers.

As part of its ongoing work, the Web Payments Working Group seeks to confirm certain assumptions:

• Payment handlers fall in the Cardholder Data Environment (CDE) and are subject to relevant rules.
• Merchants receiving tokenized payment credentials might not need to be PCI-DSS compliant.
• Merchants receiving encrypted tokenized payment credentials do not need to be PCI-DSS compliant.
• Key-providers for encryption need to be PCI-DSS compliant.

Editor's notes

Changes anticipated based on Peter Saint-Andre review

• Add links to referenced specs
• Fix diagram terminology to align with spec text

Changes anticipated based on Adrian Hope-Bailie review

• (Not yet certain)

FAQs

• Once stable, move to the Payment Request FAQ