Skip to main content
Network tokens are payment credentials issued directly by card schemes — Visa, Mastercard, American Express — as replacements for the actual card number (PAN). Instead of the raw PAN, transactions use a scheme-issued Token PAN (TPAN) scoped to a specific card and merchant context. Both Guardian and Commerce support network tokens. Lifecycle management — including updates when cards expire or are re-issued — is handled automatically by the platform.
Hellgate is a certified Token Service Provider (TSP) with the card schemes. As part of enabling network tokens, we register and onboard your business with the schemes on your behalf — so you receive scheme-issued tokens without holding your own token requestor certification or managing scheme enrollment yourself.
Benefits
  • Higher authorization rates — scheme-recognized tokens are treated as lower-risk and authorize at higher rates than raw PANs
  • Reduced fraud — tokens are scoped to a specific merchant and cannot be reused outside that context
  • Lower interchange fees — some schemes offer preferential rates for network token transactions
  • PSP portability — a single network token can be used with multiple PSPs
  • Fully managed onboarding — as a certified TSP, Hellgate handles scheme registration and merchant onboarding for you

Flows

These flows show how a network token is created and used across a card’s lifecycle, with Hellgate shown as a single actor. The exact API calls depend on the product — see Guardian and Commerce for how each one provisions network tokens.

Create a Network Token

When you tokenize a card, Hellgate requests a network token from the card scheme. The scheme provisions a TPAN bound to the card and your merchant, which Hellgate associates with the token.

Store Credentials at Checkout

When a merchant wants to store a card on file, the first authorization can run on the raw card number (FPAN) and the network token is provisioned only after that authorization succeeds. Provisioning a network token calls out to the card scheme and can add noticeable latency, so it should not be wired directly into the checkout path — authorize on the FPAN first to keep checkout fast, then provision the network token out of band once the payment is approved.

Customer Initiated Transaction (CIT)

When a cardholder is present at checkout, a cryptogram must be requested before authorization. The cryptogram is a one-time proof of token ownership that your PSP uses to validate the transaction.

Merchant Initiated Transaction (MIT)

For recurring charges where the cardholder is not present — subscriptions, installments, deferred billing — the scheme manages the TPAN lifecycle automatically. Most processors do not require a new cryptogram for MIT, simplifying the authorization flow.
MIT cryptogram requirements vary by processor. Check your PSP’s documentation for their specific requirements for recurring network token transactions.

Supported Schemes

  • Visa
  • Mastercard
  • American Express
  • Discover (coming soon)
  • Diners Club (coming soon)

Guardian and Commerce

Both products support network tokens, but handle the relationship to PCI tokens differently:
GuardianCommerce
ProvisioningExplicit — provisioned separately from PCI tokensAutomatic — provisioned when you create a Commerce token (if enabled for your account)
Token lifecycleIndependent — PCI token and network token lifecycles are separateUnified — network token lifecycle is aligned with the Commerce token

Guardian: Network Tokens

Provisioning sources, cryptogram types, and API usage.

Commerce: Network Tokens

Automatic provisioning, cryptogram request workflow, and PSP integration.

Get Started

Get Access to Network Tokens

Enable network tokens for testing and production. Add-on feature — requires activation.

Network Token Testing

Test provisioning and cryptogram generation with the built-in Network Token Sandbox.