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.

Example

const currencyAmount = {
  currency: 'USD',
  value: 250.00
};

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

const details = ...

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.
• Payment handlers MAY provide add-card functionality.
• Browser (or other mediator) add-card functionality MAY be used if available.
• Browsers MAY discover and install default payment handlers based on supportedNetworks.
• 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; //Defined via the encryption specification
};

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.

Note on PCI Scope

While recommendations around PCI compliance are out of scope for this document, the list below provides some indication of the impact that using this spec may have on your PCI compliance. Please review with your organization's compliance officers.

• Payment handlers are deemed to be within the Cardholder Data Environment (CDE). Therefore, payment handler implementations MUST be PCI-DSS compliant.
• Merchants receiving tokenized payment credentials MAY 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 MUST BE PCI-DSS compliant.

More about PCI scope in relation to Tokenization can be found in the PCI Tokenization Guidelines Supplement.

Editor's notes

Changes anticipated based on Peter Saint-Andre review

• Add links to referenced specs

Changes anticipated based on Adrian Hope-Bailie review

• PMI 'token'
• Change TokenizedCardRequest to TokenRequest
• Change TokenizedCardResponse to TokenResponse
• Change cardholderName to payerName
• Change lastFourOfFPAN to paymentInstrumentLabel
• Change card to payment instrument or account in flow diagram.