Optimization Protection

Network tokenization

Network tokenization uses a payment network's token provider to tokenize card information, and re-tokenize selected wallet tokens, browser tokens, and third-party network tokens into card on file network tokens for various payment brands, allowing you to process payment transactions without the need to de-tokenize. This token can be used for subsequent transactions related to the initial payment, including clearing, settlement, refunds, and dispute processing.

The following table lists the types of network tokenization supported by the various payment brands:

Tokenization capabilities by card brand
Payment brand	Tokenize card information	Re-tokenize wallet tokens	Re-tokenize browser tokens	Re-tokenize third-party tokens
American Express	Yes	No	No	No
Discover	Yes	No	No	No
Mastercard	Yes	Yes (Paze wallet only)	No	No
Visa	Yes	Yes	Yes	Yes

How network tokenization works

At a high-level, the tokenization process is comprised of the following steps:

The consumer enters their payment information into the your system.
You tokenize the credentials using the Tokenization API and get the token.
- If you are re-tokenizing a wallet token, use the Wallet Decryption API to decrypt the token before tokenizing.
You request a cryptogram for the token.
The token is then used by the consumer to process the payment.

Before you begin

To set up and configure your network tokenization, you’ll need to obtain a token requestor identifier (TRID) from a payment network to generate requests for token provisioning using either one of these two methods:

Request a TRID independently by connecting with the payment network.
Contact your J.P. Morgan implementation specialist for help obtaining a TRID.

You can work with your J.P. Morgan implementation specialist to associate the provisioned TRIDs with a processing entity within our system.

Token provisioning

The token provisioning process secures sensitive payment information and validates your entity with your TRID. A network token with both of these values will be generated for an applicable card. Once activated, you can use this token as part of a payment transaction. Apple Pay tokens cannot be tokenized.

You have the option of generating tokens after a successful authorization, which reduces latency from consumer interactions.

Tip

For Mastercard processing, tokenize the payment method before authorizing the transaction, as Mastercard requires subsequent transactions to use the same payment method that initiated the recurring relationship. This requires you to provision a token and request a cryptogram for the initial transaction. Subsequent transactions can occur with only the Mastercard Digital Enablement Service (MDES) token.
When using tokens with 3-D Secure transactions, tokenize the card information before sending it to the 3DS request.

Token requirements

The following table lists the conditional and required fields for tokenization by payment brand:

Required and conditional fields for tokenization by payment brand
Payment brand	Required fields	Conditional fields
American Express	`cardNumber` `cardExpiry`	Provide one of the following fields: `accountholderEmail` or `accountholderTelephone` `deviceIPAddress` (required when the cardSource field is not ONFILE)
Discover
Mastercard	`cardNumber` `cardExpiry`	For tokenizing Paze wallet tokens to card on file network tokens, you must provide `tokenProvisioningVerificationValue`. Use the Wallet Decryption API to get the Paze token and `tokenProvisioningVerificationValue`.
Visa	`accountholderEmail` `accountholderReference` `cardNumber` `cardExpiry` `deviceLocale`	The same required fields apply for tokenizing wallet tokens, browser token, and third-party network tokens to card on file network tokens.

Note

Apple Pay tokens cannot be re-tokenized.
Re-tokenization is only available for Visa and Mastercard tokens.
- For Mastercard, only Paze wallet tokens can be re-tokenized.

Tokenization approval status

The tokenizationApprovalStatus field displays the status of the network tokenization request. The following table shows the values for this field:

Approval status field values
Approval status	Description
`APPROVED`	The tokenization decision was approved and the token is ready for processing.
`AUTH_REQUEST`	The tokenization request was approved, but additional identity and verification (ID&V) processes are required to activate the token.
`DECLINED`	The tokenization request was declined.

Tip

If you perform an e-commerce tokenization, then the AUTH_REQUEST is handled in the same manner as APPROVED.

Once consumer authentication is complete, the tokenization response will contain the accountholderValidation object. This provides information about the method used for consumer validation. The available validationMethods are:

SMS
EMAIL
BANKING_APP
CUSTOMER_CARE
CALL_TO_USER
CUSTOMER_CARE_WEBSITE

Token cryptograms

Cryptograms are provided during payment authorization requests as proof of token validation. The following table highlights the transaction types that require cryptograms:

Transaction types requiring cryptograms
Transaction type	Cryptogram required?	Description
One-time cardholder initiated	Yes	A unique transaction that is initiated by the cardholder.
One-time client initiated (e.g., unscheduled transaction)	No	Transactions initiated by you, where the credentials are on file, but there is no predefined sequence for the transaction.
Installment transaction	No	A series of transactions that utilize stored credentials and represent an agreement where the cardholder permits you to initiate future transactions over a period for a single purchase. The initial transaction must carry a token cryptogram when initiated with a token. Subsequent actions do not require a cryptogram.
Split shipment	No	You receive an order for multiple items that are shipped separately, and each item is uniquely authorized. The initial transaction must carry a token cryptogram when initiated with a token. Subsequent actions do not require a cryptogram.

Required data for cryptogram requests

The table below lists the required fields for specific card networks for cryptogram requests:

Required fields for cryptogram requests by card brand
API field	American Express	Mastercard	Visa
`tokenCryptogramType`	Dynamic card security code (DCSC)	Universal Cardholder Authentication Field (UCAF)	Token authentication verification value (TAVV) Dynamic token verification value (DTVV)
`randomNumber`	N/A	Required	N/A
`amount`	Required	N/A	N/A
`transactionType`	N/A	N/A	Required
`initiatedBy`	N/A	N/A	Required
`electronicCommerceIndicator`	Required	Required	Required
`tokenAuthenticationValue`	Required	Required	Required

Tip

Cryptograms are one-time use only and are intended to be used during authorizations. Attempting to reuse a cryptogram results in an authorization decline from the payment network.