Network Tokens

Network Tokens

Product Overview

Network tokens represent a significant advancement in payment processing. They act as unique digital identifiers that replace sensitive card details like the Primary Account Number (PAN) with alphanumeric strings. Businesses want secure payments that maximize conversion and improve 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.

The difference between Network Tokens and Card Object

The Card Management Platform is designed to support enrolling a "Card Object" on a per-account basis so that the Cards can be managed effectively at an account level. Each Card Object has a different Card ID. Network Tokens can be activated on the account-level. When Network Tokens are enabled on an account, VGS will be able to provision a Network Token for each card stored.

A provisioned network token is mapped to the Card ID. VGS receives updates for Network Tokens from the card networks. Although the information for the Network Token may change based on these updates, the Card ID will always remain the same.

Types of Tokens

Understanding Network Tokens Types: From Device Wallets to Controlled Commerce

The landscape of digital payments transformed with the introduction of network tokens in 2015, spearheaded by device-based wallets like 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, defining its context and platform of use.

Though terminology varies across networks, current network tokens broadly fall into these evolving categories, each subject to increasingly stringent domain controls:

• Device Tokens: 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 more use eCommerce Network Tokens to pass through their tokens to 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 customers accounts are activated for network tokens after onboarding with networks. The customer has 2 paths as to how the Network token enrollment is facilitated.

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. Customer must explicitly invoke 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-tokens

  • Provides 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-tokens

  • The 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-tokens endpoint after card creation using the manual method , or

    • Automatically, if created using the oncreate method 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.

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