No meu dia a dia trabalhando com integrações de adquirentes e provedores, eu já ouvi essa frase dezenas de vezes:

Mas já não estamos tokenizando? Se não armazenamos o PAN diretamente, por que isso ainda importa?

E é aqui que começa a confusão.

Muita gente mistura:

Token interno da empresa
Tokenização de bandeira (Visa, Mastercard etc.)

Eles não são a mesma coisa, e entender essa diferença muda completamente sua visão de como tudo funciona.

Hoje eu quero te explicar, de forma prática e sem marketing, como funciona a tokenização de bandeira, o que acontece por trás dos panos e quais decisões arquiteturais você precisa tomar.

Primeiro: o problema real

Quando você armazena um PAN (Primary Account Number, o número do cartão), você entra direto no mundo do PCI DSS (Payment Card Industry Data Security Standard).

Isso significa:

Escopo de segurança enorme
Auditorias
Custos altos
Risco real de vazamento

A tokenização de bandeira surge para resolver exatamente isso: parar de trafegar e armazenar o número real do cartão.

Mas não é só mascarar. É trocar por outra coisa que funciona na rede.

O que é Tokenização de Bandeira?

É um processo em que a bandeira do cartão (Visa, Mastercard, ELO, etc.) substitui o PAN por um token que:

Parece um número de cartão
Funciona como um cartão
Mas não é o cartão real

Esse token é chamado de DPAN (Device Primary Account Number) ou simplesmente Network Token.

O cartão real é o FPAN (Funding PAN).

Vamos tentar simplificar

Pense no PAN como a chave da sua casa.

A tokenização de bandeira cria uma chave reserva:

Que abre apenas uma porta específica
Pode ser desativada a qualquer momento
Não revela a chave original

Se alguém roubar essa chave reserva, o dano é muito menor.

Quem participa do processo?

Uma tokenização de bandeira envolve:

Merchant / Plataforma
Gateway ou PSP
Adquirente
Bandeira (Visa, Mastercard, etc.)
Token Service Provider (TSP)

Normalmente, a própria bandeira opera o TSP.

Exemplos:

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

Como funciona por trás dos panos

Agora vamos para o que interessa.

1. Provisionamento do token

Fluxo simplificado:

O cliente informa o cartão.
O gateway envia o PAN para a bandeira via TSP.
A bandeira valida com o emissor.
A bandeira gera um token (DPAN).
O token volta para o ecossistema.

O ponto importante:

O merchant nunca mais precisa usar o PAN real.

Em muitos modelos modernos, o PAN nem passa pelo merchant (ex: checkout tokenizado direto no gateway).

2. O papel do EMV

Você já deve ter ouvido falar em EMV (Europay, Mastercard, Visa).

É o padrão que define como cartões com chip se comunicam.

Dentro do EMV, existem conceitos como:

Criptogramas
Dynamic CVV
Autenticação dinâmica

Na tokenização de bandeira, o token funciona junto com esses mecanismos para:

Gerar criptogramas únicos
Garantir que a transação não possa ser reaproveitada

Isso reduz drasticamente fraude por replay.

3. Durante a autorização

Quando a transação é enviada:

O merchant envia o token (DPAN)
A adquirente envia para a bandeira
A bandeira faz o detokenization mapping
O emissor recebe o PAN real

O emissor nem sempre sabe que houve tokenização, isso é transparente.

Diferença: Token do Gateway vs Token de Bandeira

Esse é um ponto que eu demorei a entender e quero tentar te ajudar a compreender.

Tipo	Quem gera	Onde funciona	Segurança
Token do Gateway	PSP	Só naquele PSP	Reduz escopo, mas depende do PSP
Token Interno	Sua empresa	Só no seu sistema	Você ainda pode estar no escopo PCI
Token de Bandeira	Visa/Mastercard	Funciona na rede inteira	Reduz risco estrutural

O token de bandeira é nativo da rede de pagamentos.

Benefícios reais

Além da segurança, existem ganhos estratégicos:

Atualização automática de cartão (Account Updater integrado)
Maior taxa de aprovação
Tokens por dispositivo (menos fraude)
Possibilidade de controlar domínio de uso

E aqui entra uma boa prática de arquitetura:

Sempre modele seu sistema para suportar múltiplos tipos de token.

Não assuma que você terá apenas PAN ou apenas network token.

Riscos e decisões arquiteturais

Aqui vai o que pouca gente fala.

1. Lock-in

Se você deixar a tokenização 100% acoplada ao seu PSP, você pode ficar preso.

Boa prática:

Armazene metadata suficiente para migração.
Modele entidade de instrumento de pagamento desacoplada do provedor.

2. Múltiplos tokens para o mesmo cartão

Um mesmo cartão pode ter:

Um token por dispositivo
Um token por merchant
Um token por wallet

Não trate token como identificador global do cliente.

3. Segurança ainda é sua responsabilidade

Mesmo usando token:

TLS obrigatório ponta a ponta
Segregação de ambientes
Logs sem dados sensíveis
Criptografia em repouso

Token não elimina engenharia segura.

Fluxo lógico ideal em arquitetura moderna

Eu costumo pensar assim:

Cliente envia cartão
Backend chama serviço de tokenização
Serviço retorna:

token
last4
brand
expiration
token_reference_id

Você armazena apenas:

token
metadata
referência de vault

E o PAN? Nunca toca no seu banco.

Onde isso é usado na prática?

Apple Pay
Google Pay
Click-to-Pay
Credenciais salvas para recorrência
Pagamentos in-app

Todos usam tokenização de bandeira por baixo.

Porem não podemos falar de tokenização sem falar de dois componentes super importantes.

E o Cryptogram? E o ECI?

Se você chegou até aqui achando que tokenização termina no DPAN, ainda falta uma peça importante.

Quando falamos de tokenização de bandeira, principalmente em wallets como Mercado Pago, Apple Pay e Google Pay dois campos passam a ser críticos:

Cryptogram
ECI

Cryptogram (ou EMV Cryptogram)

O cryptogram é um valor criptográfico dinâmico gerado a cada transação.

Ele nasce dentro do contexto EMV (Europay, Mastercard, Visa), o mesmo padrão usado por cartões com chip, e funciona como uma prova criptográfica de que:

O token é válido
A transação é legítima
A credencial não foi copiada

Vamos tentar simplificar novamente?

Se o token é a chave reserva da casa, o cryptogram é como uma assinatura digital que prova que a chave foi usada naquele exato momento, e não é uma cópia.

Tecnicamente:

Ele é gerado com chaves simétricas armazenadas de forma segura
É validado pela bandeira
Evita replay attack

Sem cryptogram válido, a transação pode ser negada ou sofrer downgrade de responsabilidade.

ECI (Electronic Commerce Indicator)

O ECI indica o nível de segurança da transação.

Ele sinaliza para a bandeira e para o emissor:

Se houve autenticação forte
Se a transação veio de wallet
Se é e-commerce tradicional
Se existe liability shift

Em resumo:

O ECI ajuda a definir quem assume o risco da fraude.

ECI incorreto pode significar:

Perda de liability shift
Mais chargeback
Maior taxa de fraude percebida

E aqui está o ponto crítico:

Token sem cryptogram e ECI correto é só metade da solução.

Por que eu não aprofundei tanto nisso aqui?

Porque cryptogram e ECI merecem um artigo próprio.

Eles impactam:

Taxa de aprovação
Risco
Chargeback
Configuração no adquirente
Campos obrigatórios na integração

E é exatamente aqui que muitos times erram, não na tokenização em si, mas na forma como enviam os dados de autenticação.

No próximo artigo eu posso destrinchar:

Diferença entre ARQC e AAV
Como o cryptogram é validado
Como o ECI impacta o liability shift
Erros comuns de integração

O que você deve levar disso

Se você é desenvolvedor júnior ou pleno, entenda isso:

Tokenização não é só “mascarar número”.
Token de bandeira é infraestrutura de rede, não feature de gateway.
Arquitetura mal pensada aqui gera dor em migração futura.
Segurança não é opcional, é estrutural.

No fim do dia, tokenização de bandeira é sobre:

Reduzir risco, aumentar aprovação e manter flexibilidade arquitetural.

E se você trabalha com meios de pagamento, cedo ou tarde você vai precisar entender isso a fundo, não só para integrar, mas para desenhar certo desde o início.