-
Notifications
You must be signed in to change notification settings - Fork 15
Tokenized Card
Status: Draft
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 likeTokenized Card
.
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.com/tokenizedCardPublicKey',
}
}];
const details = ...
new PaymentRequest(methodData, details);
The standardized payment method identifier for this specification is tokenized-card
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.
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
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 this document's scope, 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
dictionary TokenizedCardResponse {
required DisplayData displayData;
EncryptedTokenizedCard encryptedTokenizedCard
};
dictionary DisplayData{
//At least one of the following two should be available
//Display data is returned unencrypted
conditional DOMString displayMaskedCard; //Provider-specific masked format using (*) for mask
conditional DOMString displayLast4; //Most common display requirement
required DOMString displayExpiryMonth; //actual expiry month of the card - fit for display
required DOMString displayExpiryYear; //actual expiry year of the card - fit for display
required DOMString displayNetwork; //actual network of the card - fit for display
};
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
};
Encryption is a REQUIRED feature of this payment method and will 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.
This construct is still under discussion and may evolve to be materially different from what is presented above.
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 Tokenization Guidelines Supplement