Network Tokens
Product Overview
Network tokens represent a significant advancement in payment processing. They serve as unique digital identifiers, replacing sensitive card details such as the Primary Account Number (PAN) with alphanumeric strings. Businesses seek secure payment methods that maximize checkout conversion rates and enhance the overall customer experience. Network tokens help meet both of those goals.
VGS simplifies payment management by automatically converting stored card numbers (PANs) into secure network tokens. If a customer's card is lost, stolen, or replaced, VGS receives updates from the card networks and automatically updates the tokens, ensuring uninterrupted payments without customer intervention.
Concept of Tokenization
Tokenization emerged as part of the evolution of payment security and the need to protect sensitive cardholder data in an increasingly digital world. In the early stages, tokenization was used as a data protection mechanism. Companies began using tokens to replace sensitive card information, like Primary Account Numbers (PANs), to enhance security.
Fueled by the rapid growth of e-commerce, mobile payments, and digital wallets transactions, major card networks introduced network tokens. These tokens replace sensitive PANs with unique identifiers, significantly reducing fraud and marking a major advancement in payment security.
Token Lifecycle Management
In order to ensure cardholder data was not only safe but also ready for use, the networks and issuers integrated lifecycle management into the ecosystem. Lifecycle management ensures that the card data linked to a network token is updated whenever the underlying card or token data changes.
Phases of a Token Lifecycle
Create a token - this is the first step and can have one of the following two outcomes:
Active: the network token has been successfully provisioned and is ready for use
Failed: the network token provisioning attempt was unsuccessful. Follow the instructions from the error message documentation to determine if retrying the attempt is appropriate.
Lifecycle events - once tokens are created, their state can be modified by the issuer or network. Review the Network Token Events for more information about these states.
Updated: the token or underlying card data has changed
Suspended: The network token has been temporarily suspended by the issuing card network (e.g., Mastercard, Visa). This typically occurs when new cards are being issued and may be followed by any of the other statuses.
Activated: The network token has been reactivated after being suspended or updated
Deleted: The network token has been removed via the API
Types of Tokens
Understanding Network Tokens Types: From Device Wallets to Controlled Commerce
The landscape of digital payments underwent a transformation with the introduction of network tokens in 2015, spearheaded by device-based wallets such as Apple Pay and Google Pay. Today, payment networks exert granular control over these tokens through domain controls. These configurations, set at the network level, determine precisely where, when, and how a network token can be used, thereby defining its context and the platform on which it is used.
Though terminology varies across networks, current network tokens broadly fall into these evolving categories, each subject to increasingly stringent domain controls:
Device Tokens (Apple Pay or Google Pay: These tokens enhance the security of digital commerce, specifically for mobile wallets.
Secure Element (SE) Tokens: Predominantly used with Apple Pay, SE tokens convert sensitive card credentials into a secure digital format. They are provisioned to a secure element in the cloud, primarily facilitating secure in-store contactless payments.
Host Card Emulation (HCE) Tokens: Similar in purpose to SE tokens, HCE tokens are largely associated with Google Pay. They tokenize card credentials and are provisioned as both cloud and device-bound. These tokens enable both in-store contactless payments and convenient in-app shopping experiences.
Card-on-File (COF) Tokens: Designed to safeguard sensitive customer data for online merchants while enabling innovative shopping experiences. COF tokens are provisioned to the cloud and restricted to a specific merchant. They are utilized for both online and in-app purchases, supporting flexible payment options like Buy Now, Pay Later (BNPL), installment plans, and subscription services.
eCommerce (Enabler) Tokens: These tokens streamline and secure the checkout process for consumers across a diverse range of merchants and wallets. They can be provisioned as cloud based and/or device-bound. Unlike Card-on-File Tokens, eCommerce Network Tokens were built to be passed from one entity to another. For instance, the token can be tied to a single Enabler (e.g. a wallet) that is then allowed to share the token to other merchants or platforms for their own processing.
Wallet Enablement: For online transactions, digital wallets like Google Pay, PayPal, and others utilize eCommerce Network Tokens to pass their tokens through to the underlying merchants.
Additional Merchant Use Cases: These tokens can also be used for various other use cases online and in-app purchase channels, including retail, fast food, rideshare services, and more.
VGS's Role in Streamlining Different Network Token Type Adoption
Token Service Providers (TSPs) must undergo a rigorous certification and testing process to support these diverse token types. VGS has successfully completed the necessary certifications for both eCommerce and COF token implementations, where applicable and supported by the networks. A Token Requester's enabled token types are determined by the network, aligning with its intended use case. While COF is the most common token type, any alternative requires network discussion and approval. VGS simplifies the integration process for Token Requesters, making it easier for them to support either or both COF and eCommerce token types. VGS continues to evaluate and develop to the latest specifications from the networks, including new innovative network token types.
Network Tokens via CMP
As customer accounts are activated for network tokens after onboarding with networks. The customer has two paths for facilitating Network token enrollment.
On-Create Enrollment
This is the default setting. When a card object is created, the system automatically processes and activates the network token services enabled for the account. A webhook notification is sent with the result of the network token provisioning, whether it succeeds or fails.
Manual Enrollment:
With manual enrollment, card creation does not automatically trigger network token creation. The customer must explicitly invoke the network token individual service endpoints to create network tokenization. For greater control, clients can opt for a "manual" configuration, which creates a basic card object without automatic processing. This allows for granular control over service invocation using dedicated endpoints:
Manual Network Token Provisioning endpoint:
POST /cards/{CardID}/network-tokensProvides flexibility to control when Network Tokens are created.
Use this endpoint to provision Network Token on individual cards after creation.
A confirmation response with the network token provisioning result is returned immediately in the synchronous response.
A webhook notification is sent upon a successful network token is created.
Enrollment-Type/Provisioning-Method: Manual.
Network Token Deletion endpoint:
DELETE /cards/{CardID}/network-tokensThe Network Token status is marked as deleted in VGS systems.
The Network Token becomes invalid and stops receiving updates.
Enrollment-Type/Provisioning-Method: The network token may have been provisioned to a card either:
Manually, via the
/network-tokensendpoint after card creation using the manual method , orAutomatically, if created using the
oncreatemethod during card registration.
Once a network token is deleted for a card:
Cryptogram requests (
POST /cards/{CardID}/cryptogram) are no longer allowed.The network token will no longer receive any lifecycle updates.
The deleted network token is inactive and cannot be used for any payment transactions.
When retrieving the card object (
GET /cards/{CardID}), the Network Token object will no longer be present in the response.
Limitations
America Express (Amex)
VGS currently supports only Direct merchants. OptBlue merchants are not supported.
For high provision success rate, clients are encouraged to add cardholders phone number or email address.
Discover
Duplicate card capability not supported with Discover card. Tokens should not be retried if they are already provisioned.
Transacting with Network Tokens
To perform a transaction with network tokens, a cryptogram is needed. A network token cryptogram is a unique, one-time encrypted code generated for each transaction using a network token. It serves as a crucial security measure to authenticate and secure the transaction.
With Network token being created and mapped to the card ID , Customers need to invoke the Request Cryptogram endpoint to get the cryptogram which can be be used by the Customers in their authorization requests with their respective PSPs.
Endpoint: POST /cards/{CardID}/cryptogram
Types of Cryptograms
TAVV (Token Authentication Verification Value):
This is the most common type of network token cryptogram, used across most networks.
Up to 32 characters.
Some networks require the transaction type when generating.
DTVV (Dynamic Token Verification Value):
A short cryptogram resembling a 3-digit CVV.
Unique to Visa.
Must be explicitly enabled by VGS. Contact [email protected] to enable.
Cryptogram Fetch - Best Practices:
Always generate a new, one-time-use cryptogram for each authorization.
Do not store cryptograms after use.
Ensure submitted values (TAVV/DTVV, ECI) remain unchanged during authorization.
Key Features
Synchronous Cryptogram Generation: Receive network tokens via Crypto request instantly within the API response.
Cryptogram Validity: Cryptogram is valid for 24 hours.
Webhook Integration: Not applicable
Last updated