DRAFT for review/approval (feedback to-date implemented)
Overview of Network Tokenization
Network tokenization replaces static Primary Account Numbers (PANs) with dynamic, merchant-specific tokens issued by schemes such as Visa and Mastercard. Each token is tied to a specific merchant and often contextually bound via network metadata, ensuring the token only works within the intended context. As a result, even if a card expires, is replaced, or reissued, the token remains valid and ensures uninterrupted recurring payments for stored-card transactions.
Many tokenized transactions, especially those initiated by cardholders, are secured with a cryptogram – a one-time, scheme-generated encrypted value. The cryptogram includes data such as the token, merchant ID, transaction details, and other contextual information. It is validated by the card issuer during authorization. Without a valid cryptogram, the transaction is declined, even if the token itself is valid. This mechanism helps prevent misuse, replay fraud, and unauthorized transactions.
Together, tokens and cryptograms provide business benefits:
- Improved approval rates – Dynamic, scheme-issued tokens maintain issuer trust, reduce declines, and boost payment success.
- Enhanced security – Tokens replace sensitive PANs. One-time cryptograms guard against replay fraud, leading to fewer fraud incidents and chargebacks.
- Reduced processing costs – Tokenized transactions may have lower interchange fees in certain regions, thus reducing the expense of false declines and fraud mitigation.
- Improved cash flow stability – Fewer disputes mean more predictable revenue and increased confidence for both merchants and cardholders.
- Streamlined compliance – Network tokens eliminate the need to store PANs, reducing PCI DSS audit scope and easing compliance efforts.
Major card networks are transitioning to universal tokenization making token use the expected global standard. Nuvei supports the shift both as a direct acquirer (Visa/Visa Token Service [VTS]), Mastercard/Mastercard Digital Enablement Service [MDES]) and as a Payment Service Provider (PSP) through regional acquirers such as Barclays, WorldPay, and AIB. Whether Nuvei’s direct channels or PSP partners are used, tokenized payments are fully supported and processed within Nuvei’s secure infrastructure.
Internal Network Token
Nuvei’s Internal Network Token solution streamlines card-based transactions by handling the entire token lifecycle while allowing merchants to continue using standard PANs. When a transaction is initiated and no token exists in Nuvei’s database, the transaction proceeds using the PAN. Nuvei then conducts an initial fraud check and only if the transaction is assessed as low risk does Nuvei request and store a network token from the card scheme. The flow ensures that tokens are issued solely in secure, compliant scenarios.
Once a token exists, all future payments are routed using the network token and the token’s one-time, scheme-generated cryptogram. Tokens are automatically updated if a card is reissued or expires, maintaining payment continuity for subscriptions and stored card use without disruption to the merchant or customer. As a direct acquirer for Visa and Mastercard, and with a Payment Service Provider (PSP) through providers such as Barclays, WorldPay, and AIB, Nuvei processes network token transactions through its global and partnered acquiring infrastructure.
Network Token to PAN Cascading
To further enhance authorization resilience, merchants can enable Network Token to PAN cascading. In this setup, when a transaction is submitted after the network token is provisioned, Nuvei first attempts authorization using the stored token. If that attempt is declined and cascading criteria are met, Nuvei automatically retries the transaction using the original PAN. This strategy delivers optimal security and fraud prevention via tokenization, while retaining fallback reliability to maximize approval rates.
External Network Token
The External Network Token model empowers merchants to provision and manage tokens using services such as VTS, MDES, or third-party providers. Tokens and one-time cryptograms are sent to Nuvei via REST API v1.0. Nuvei, acting as the processor and optionally as the acquirer (Visa/Mastercard) or through PSPs (Barclays, WorldPay, AIB), validates and processes token-based transactions while the merchant retains control over token lifecycle events.
Cryptogram Requirements
Each cryptogram is unique to a single payment transaction and cannot be reused, regardless of whether the transaction is approved or declined. This one-time-use cryptogram is generated to verify and secure that specific transaction alone. Even if the network token itself remains the same, a new cryptogram must be provided by the merchant for every subsequent transaction attempt. This process protects against unauthorized reuse, reinforcing the security and integrity of tokenized payments.
For a customer-initiated transaction (CIT), cryptograms are mandatory for Sale and Auth. For a merchant-initiated transaction (MIT), cryptograms are needed on the first authorization or if the merchant is enrolled in an Account Funding Transaction (AFT) program.
External Network Token to PAN Cascading
To maximize authorization success, Nuvei supports External-Network-Token-to-PAN cascading. If a merchant submits both network token details and a PAN in the same request, Nuvei first attempts the token transaction. If the scheme or issuer declines the attempt and cascading conditions are met, Nuvei automatically retries the authorization using the PAN. This dual approach not only strengthens fraud protection through network-issued tokens and cryptograms, but also minimizes failed transactions via fallback.
Network Token as a Service (NTaaS)
Nuvei’s Network Token as a Service allows merchants to adopt an API-first approach, optimizing token usage without fully managing the token lifecycle. Available via REST API v2.0 , NTaaS offers flexible implementation models: Merchant-Managed Token Storage and On-Demand Token Retrieval.
Merchant-Managed Token Storage
In this model, merchants request and store network tokens using Nuvei’s APIs. After provisioning, Nuvei notifies the merchant of lifecycle events, such as card reissues or expirations, ensuring token records remain valid. The merchant maintains responsibility for secure token storage and lifecycle decisions.
On-Demand Token Retrieval
The On-Demand Token Retrieval option minimizes the merchant’s PCI and storage burden: merchants store only the Payment Token ID whereas Nuvei handles token retrieval and cryptogram generation at the time of transaction. This approach ensures the merchant never store sensitive data, while still benefiting from token lifecycle updates. The model simplifies compliance and eases operational complexity.
Network Tokenization Comparison
Feature | Internal Network Token | External Network Token | Network Token as a Service | ||||
---|---|---|---|---|---|---|---|
Token Requestor | Nuvei (via VTS/MDES*) | Merchant or third-party | Nuvei (via VTS/MDES*) | ||||
Lifecycle management | Fully managed by Nuvei | Done externally | Fully managed by Nuvei | ||||
Endpoint integration | Cashier / REST API 1.0 and REST API 2.0 | REST API 1.0 | REST API 2.0 | ||||
Token to PAN cascading | Yes | Yes | Not relevant | ||||
PCI data scope | Low | Medium | Low with on-demand option High with Merchant-Managed option |
||||
Acquirer support | Nuvei direct acquiring, AIB, WorldPay, Barclays | Nuvei direct acquiring, AIB, WorldPay, Barclays | Not relevant | ||||
Target merchant | Full-service merchant | Advanced merchant | Advanced merchant | ||||
*Visa Token Service (VTS); Mastercard Digital Enablement Service (MDES) |
Examples
Payment (Deposit)
When the merchant provides the network (card scheme) token and the cryptogram, include the following in the /payment
request or the /initPayment
request:
card
class containing:expirationMonth
– The network token’s expiration month.expirationYear
– The network token’s expiration year.externalToken
class containing:networkTokenNumber
networkTokenCryptogram
(optional)tokenAssuranceLevel
(optional)tokenRequestorId
(optional)
Example Non-3DS /payment
Request
{ "sessionToken": "<sessionToken from /getSessionToken>", "merchantId": "<your merchantId>", "merchantSiteId": "<your merchantSiteId>", "clientRequestId": "<unique request ID in merchant system>", "clientUniqueId": "<unique transaction ID in merchant system>", "amount": "200", "currency": "USD", "paymentOption": { "card": { "expirationMonth": "12", "expirationYear": "2025", "externalToken": { "networkTokenNumber": "4008370896662369", "networkTokenCryptogram": "ejJRWG9SWWRpU7I1M28DelozSXU=", "tokenAssuranceLevel": "3", "tokenRequestorId": "2" } } }, "billingAddress": { "email": "[email protected]", "country": "US" }, "deviceDetails": { "ipAddress": "<customer's IP address>" }, "timeStamp": "<YYYYMMDDHHmmss>", "checksum": "<calculated checksum>" }
Example 3DS /initPayment
Request
{ "merchantSiteId": "<your merchantSiteId>", "merchantId": "<your merchantId>", "sessionToken": "<sessionToken from /getSessionToken>", "clientRequestId": "<unique request ID in merchant system>", "currency": "USD", "amount": "200", "paymentOption": { "card": { "expirationMonth": "12", "expirationYear": "25", "externalToken": { "networkTokenNumber": "4008370896662369", "networkTokenCryptogram": "ejJRWG9SWWRpU7I1M28DelozSXU=", "tokenAssuranceLevel": "3", "tokenRequestorId": "2" }, "threeD": { "methodNotificationUrl": "<methodNotificationURL>", "platformType": "01" } } } }
Example 3DS/payment
Request
{ "sessionToken": "<sessionToken from /getSessionToken>", "merchantId": "<your merchantId>", "merchantSiteId": "<your merchantSiteId>", "clientRequestId": "<unique request ID in merchant system>", "timeStamp": "<YYYYMMDDHHmmss>", "checksum": "<calculated checksum>", "currency": "USD", "amount": "200", "relatedTransactionId": "<transactionId returned from initPayment>", "paymentOption": { "card": { "expirationMonth": "12", "expirationYear": "25", "externalToken": { "networkTokenNumber": "4008370896662369", "networkTokenCryptogram": "ejJRWG9SWWRpU7I1M28DelozSXU=", "tokenAssuranceLevel": "3", "tokenRequestorId": "2" }, "threeD": { "methodCompletionInd": "U", "version": "<3DS version>", "notificationURL": "<notificationURL>", "merchantURL": "<merchantURL>", "platformType": "02", "v2AdditionalParams": { "challengePreference": "01", "deliveryEmail": "<email address>", "deliveryTimeFrame": "03", "giftCardAmount": "1", "giftCardCount": "41", "giftCardCurrency": "USD", "preOrderDate": "20220511", "preOrderPurchaseInd": "02", "reorderItemsInd": "01", "shipIndicator": "06", "rebillExpiry": "20200101", "rebillFrequency": "13", "challengeWindowSize": "05" }, "browserDetails": { "acceptHeader": "text/html,application/xhtml+xml", "ip": "192.168.1.11", "javaEnabled": "TRUE", "javaScriptEnabled": "TRUE", "language": "EN", "colorDepth": "48", "screenHeight": "400", "screenWidth": "600", "timeZone": "0", "userAgent": "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47" }, "account": { "age": "05", "lastChangeDate": "20190220", "lastChangeInd": "04", "registrationDate": "20190221", "passwordChangeDate": "20190222", "resetInd": "01", "purchasesCount6M": "6", "addCardAttempts24H": "24", "transactionsCount24H": "23", "transactionsCount1Y": "998", "cardSavedDate": "20190223", "cardSavedInd": "02", "addressFirstUseDate": "20190224", "addressFirstUseInd": "03", "nameInd": "02", "suspiciousActivityInd": "01" } } } }, "billingAddress": { "firstName": "John", "lastName": "Smith", "address": "221B Baker Street", "city": "London", "country": "GB", "email": "[email protected]" }, "shippingAddress": { "firstName": "John", "lastName": "Smith", "address": "221B Baker Street", "city": "London", "country": "GB", "email": "[email protected]" }, "deviceDetails": { "ipAddress": "<customer's IP address>" } }
Example 3DS /payment
Request with Liability Shift
{ "sessionToken": "<sessionToken from /getSessionToken>", "merchantId": "<your merchantId>", "merchantSiteId": "<your merchantSiteId>", "clientRequestId": "<unique request ID in merchant system>", "timeStamp": "<YYYYMMDDHHmmss>", "checksum": "<calculated checksum>", "relatedTransactionId": "<transactionId returned from initPayment>", "currency": "USD", "amount": "200", "transactionType": "Auth", "paymentOption": { "card": { "expirationMonth": "12", "expirationYear": "25", "externalToken": { "networkTokenNumber": "4008370896662369", "networkTokenCryptogram": "ejJRWG9SWWRpU7I1M28DelozSXU=", "tokenAssuranceLevel": "3", "tokenRequestorId": "2" }, "billingAddress": { "firstName": "John", "lastName": "Smith", "address": "22 Main Street", "city": "London", "country": "GB", "email": "[email protected]" }, "deviceDetails": { "ipAddress": "<customer's IP address>" } } } }
Example 3DS /payment
Request – External MPI
{ "sessionToken": "<sessionToken from getSessionToken>", "merchantId": "<your merchantId>", "merchantSiteId": "<your merchantSiteId>", "clientRequestId": "<unique request ID in merchant system>", "amount": "200", "currency": "USD", "clientUniqueId": "<unique transaction ID in merchant system>", "paymentOption": { "card": { "expirationMonth": "12", "expirationYear": "25", "externalToken": { "networkTokenNumber": "4008370896662369", "networkTokenCryptogram": "ejJRWG9SWWRpU7I1M28DelozSXU=", "tokenAssuranceLevel": "3", "tokenRequestorId": "2" }, "threeD": { "externalMpi": { "eci": "2", "cavv": "ejJRWG9SWWRpU2I1M21DelozSXU=", "dsTransID": "9e6c6e9b-b390-4b11-ada9-0a8f595e8600" } } } }, "billingAddress": { "email": "[email protected]", "country": "US" }, "deviceDetails": { "ipAddress": "<customer's IP address>", "deviceManufacturerIdentifier": "iPhoneX" }, "userDetails": { "country": "US" }, "timeStamp": "<YYYYMMDDHHmmss>", "checksum": "<calculated checksum>" }
Payout (Withdrawal)
When the merchant provides the network (card scheme) token, include the following in the /payout
request:
cardData
class containing:expirationMonth
– The network token’s expiration month.expirationYear
– The network token’s expiration year.
externalToken
class containing:networkTokenNumber
networkTokenCryptogram
(optional)tokenAssuranceLevel
(optional)tokenRequestorId
(optional)
Example /payout
Request
{ "merchantId": "<your merchantId>", "merchantSiteId": "<your merchantSiteId>", "clientRequestId": "<unique request ID in merchant system>", "clientUniqueId": "<unique transaction ID in merchant system>", "userTokenId": "<unique customer identifier in merchant system>", "cardData": { "expirationMonth": "12", "expirationYear": "25" }, "externalToken": { "networkTokenNumber": "4000020951595032", "tokenAssuranceLevel": "3", "tokenRequestorId": "2" }, "currency": "USD", "amount": "200", "deviceDetails": { "ipAddress": "<customer's IP address>" }, "customData": "", "timeStamp": "<YYYYMMDDHHmmss>", "checksum": "<calculated checksum>" }
Unreferenced Refund
For information about how to perform a refund with a network (card scheme) token for transactions that were not settled by Nuvei, see Unreferenced Refunds with a Network Token.
Network Token to PAN Cascading
A merchant can use UPOs. Under paymentOption
, include the userPaymentOptionId
. For the networkTokenNumber
and networkToken
, send the externalToken
(including the expirationMonth
) under card
. Details are extracted from the paymentOptionId
and the paymentOptionId"
is sent to the gateway for the fields.
- If only the
networkToken
is sent, theexpirationMonth
andexpirationYear
must be included undercard
. - If either the
cardNumber
or theuserPaymentOptionId
is sent, theexpirationMonth"
andexpirationYear
of the token must be included in theexternalToken
class.
Auth/Sale
This section provides information about token to PAN cascading for Auth/Sale.
Auth/Sale with externalNetworkToken (only)
Merchant to REST 1.0 | Result |
---|---|
| Processed as a regular external network token transaction. |
Auth/Sale with externalNetworkToken and PAN
Merchant to REST 1.0 | Result |
---|---|
| Attempt to send the token first and cascade to PAN if needed. |
Auth/Sale with externalNetworkToken and PAN by UPO
Merchant to REST 1.0 | Result |
---|---|
| Attempt to send the token first and cascade to PAN if needed. |
Settle/Void
This section provides information about token to PAN cascading for Settle/Void.
Merchant to REST 1.0 | Result |
---|---|
| Done based on the related transaction. |
Refund
This section provides information about token to PAN cascading for Refund.
Merchant to REST 1.0 | Result |
---|---|
| Online refund is done with the token. There is no cascading. |