In my day-to-day work with acquirer and provider integrations, I've heard this phrase dozens of times:

But aren't we already tokenizing? If we don't store the PAN directly, why does this still matter?

And this is where the confusion begins.

Many people mix up:

Internal company token
Network tokenization (Visa, Mastercard, etc.)

They are not the same thing, and understanding this difference completely changes your view of how everything works.

Today I want to explain to you, in a practical and marketing-free way, how network tokenization works, what happens behind the scenes, and what architectural decisions you need to make.

First: the real problem

When you store a PAN (Primary Account Number, the card number), you go straight into the world of PCI DSS (Payment Card Industry Data Security Standard).

This means:

Huge security scope
Audits
High costs
Real risk of leakage

Network tokenization arises to solve exactly this: stop transmitting and storing the real card number.

But it's not just masking. It's exchanging it for something else that works on the network.

What is Network Tokenization?

It is a process in which the card network (Visa, Mastercard, ELO, etc.) replaces the PAN with a token that:

Looks like a card number
Works like a card
But is not the real card

This token is called DPAN (Device Primary Account Number) or simply Network Token.

The real card is the FPAN (Funding PAN).

Let's try to simplify

Think of the PAN as the key to your house.

Network tokenization creates a spare key:

That only opens a specific door
Can be deactivated at any time
Does not reveal the original key

If someone steals this spare key, the damage is much smaller.

Who participates in the process?

A network tokenization involves:

Merchant / Platform
Gateway or PSP
Acquirer
Network (Visa, Mastercard, etc.)
Token Service Provider (TSP)

Normally, the network itself operates the TSP.

Examples:

Visa Token Service (VTS)
Mastercard Digital Enablement Service (MDES)

How it works behind the scenes

Now let's get to what matters.

1. Token provisioning

Simplified flow:

The customer enters the card.
The gateway sends the PAN to the network via TSP.
The network validates with the issuer.
The network generates a token (DPAN).
The token returns to the ecosystem.

The important point:

The merchant never needs to use the real PAN again.

In many modern models, the PAN doesn't even pass through the merchant (e.g., tokenized checkout directly in the gateway).

2. The role of EMV

You must have heard of EMV (Europay, Mastercard, Visa).

It is the standard that defines how chip cards communicate.

Within EMV, there are concepts such as:

Cryptograms
Dynamic CVV
Dynamic authentication

In network tokenization, the token works together with these mechanisms to:

Generate unique cryptograms
Ensure that the transaction cannot be reused

This drastically reduces replay fraud.

3. During authorization

When the transaction is sent:

The merchant sends the token (DPAN)
The acquirer sends it to the network
The network does the detokenization mapping
The issuer receives the real PAN

The issuer doesn't always know that there was tokenization, it's transparent.

Difference: Gateway Token vs. Network Token

This is a point that took me a while to understand and I want to try to help you understand.

Type	Who generates	Where it works	Security
Gateway Token	PSP	Only in that PSP	Reduces scope, but depends on the PSP
Internal Token	Your company	Only in your system	You may still be in PCI scope
Network Token	Visa/Mastercard	Works on the entire network	Reduces structural risk

The network token is native to the payment network.

Real benefits

In addition to security, there are strategic gains:

Automatic card update (integrated Account Updater)
Higher approval rate
Tokens per device (less fraud)
Ability to control usage domain

And here comes a good architectural practice:

Always model your system to support multiple types of token.

Don't assume you'll only have PAN or only network token.

Risks and architectural decisions

Here's what few people talk about.

1. Lock-in

If you leave the tokenization 100% coupled to your PSP, you may get stuck.

Good practice:

Store enough metadata for migration.
Model the payment instrument entity decoupled from the provider.

2. Multiple tokens for the same card

The same card can have:

One token per device
One token per merchant
One token per wallet

Don't treat the token as a global customer identifier.

3. Security is still your responsibility

Even using a token:

Mandatory end-to-end TLS
Segregation of environments
Logs without sensitive data
Encryption at rest

Token does not eliminate secure engineering.

Ideal logical flow in modern architecture

I usually think like this:

Customer sends card
Backend calls tokenization service
Service returns:

token
last4
brand
expiration
token_reference_id

You only store:

token
metadata
vault reference

And the PAN? Never touches your database.

Where is this used in practice?

Apple Pay
Google Pay
Click-to-Pay
Saved credentials for recurrence
In-app payments

All use network tokenization underneath.

However, we cannot talk about tokenization without talking about two super important components.

What About the Cryptogram? And the ECI?

If you've come this far thinking that tokenization ends with the DPAN, there's still an important piece missing.

When we talk about network tokenization, especially in wallets like Mercado Pago, Apple Pay and Google Pay, two fields become critical:

Cryptogram
ECI

Cryptogram (or EMV Cryptogram)

The cryptogram is a dynamic cryptographic value generated with each transaction.

It is born within the EMV (Europay, Mastercard, Visa) context, the same standard used by chip cards, and works as cryptographic proof that:

The token is valid
The transaction is legitimate
The credential has not been copied

Let's try to simplify again?

If the token is the spare key to the house, the cryptogram is like a digital signature that proves that the key was used at that exact moment, and is not a copy.

Technically:

It is generated with symmetric keys stored securely
It is validated by the network
Prevents replay attack

Without a valid cryptogram, the transaction may be denied or suffer a downgrade in liability.

ECI (Electronic Commerce Indicator)

The ECI indicates the security level of the transaction.

It signals to the network and the issuer:

If there was strong authentication
If the transaction came from a wallet
If it is traditional e-commerce
If there is a liability shift

In short:

The ECI helps define who assumes the risk of fraud.

Incorrect ECI can mean:

Loss of liability shift
More chargebacks
Higher perceived fraud rate

And here is the critical point:

Token without cryptogram and correct ECI is only half the solution.

Why didn't I go into so much detail here?

Because cryptogram and ECI deserve their own article.

They impact:

Approval rate
Risk
Chargeback
Configuration in the acquirer
Mandatory fields in the integration

And this is exactly where many teams go wrong, not in the tokenization itself, but in the way they send the authentication data.

In the next article I can break down:

Difference between ARQC and AAV
How the cryptogram is validated
How the ECI impacts the liability shift
Common integration errors

What you should take away from this

If you are a junior or mid-level developer, understand this:

Tokenization is not just "masking numbers".
Network token is network infrastructure, not a gateway feature.
Poorly thought-out architecture here generates pain in future migration.
Security is not optional, it is structural.

At the end of the day, network tokenization is about:

Reducing risk, increasing approval, and maintaining architectural flexibility.

And if you work with payment methods, sooner or later you will need to understand this in depth, not only to integrate, but to design it right from the start.