# JPMC-PDP Documentation from https://developer.payments.jpmorgan.com

# 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:

1. The consumer enters their payment information into the your system.

2. 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](/docs/commerce/optimization-protection/capabilities/wallet-decryption/how-to/decrypt-paze) to decrypt the token before tokenizing.

3. You request a cryptogram for the token.

4. The token is then used by the consumer to process the payment.

![Network tokenization process flow](/api/download/en/docs/commerce/optimization-protection/capabilities/tokenization/network-tokenization-cfs/TokenUtilProcFlow.png?type=image)

## 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.

> 
> - 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](/docs/commerce/online-payments/capabilities/online-payments/payment-enhancements/3d-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](/docs/commerce/optimization-protection/capabilities/wallet-decryption/how-to/decrypt-paze) 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. | 

> 
> - 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. | 

> 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 | Discover | 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 | 

> 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.
> 

## Network tokenization with 3-D Secure

When using 3-D Secure (3DS) authentication with network token transactions, you must provide the electronic commerce indicator (ECI) and a token cryptogram as part of the payment authorization request. Depending on the 3DS version used, be sure to validate other conditional and/or required data elements necessary for payment in the [3-D Secure](/docs/commerce/online-payments/capabilities/online-payments/payment-enhancements/3d-secure) section.

## Related

[Request a token](/docs/commerce/optimization-protection/capabilities/tokenization/how-to/request-tokens)  
 [Request a cryptogram](/docs/commerce/optimization-protection/capabilities/tokenization/how-to/request-cryptograms)   
 [Manage token lifecycle](/docs/commerce/optimization-protection/capabilities/tokenization/how-to/token-states)
 [3-D Secure](/docs/commerce/online-payments/capabilities/online-payments/payment-enhancements/3d-secure)