# Tokenisation carte

> Tokenização de cartão (DPAN, network tokens)

Substituição do PAN (os 16 dígitos do cartão) por um token específico ao lojista, à carteira ou ao dispositivo. Limita a exposição do número real e aumenta a taxa de autorização.

_Categoria: securite_

---

## Definição

A **tokenização de cartão** substitui o PAN (o número de cartão de 16 dígitos) por um **token**: uma cadeia equivalente, porém diferente, de uso restrito a uma carteira, um dispositivo, um lojista ou um canal.

O token não tem valor algum se for roubado fora de seu contexto. É um dos principais blocos de segurança do pagamento com cartão moderno, impulsionado pelas bandeiras (Visa Token Service, Mastercard MDES) e adotado em toda parte: Apple Pay, Google Pay, Click to Pay e vaults de PSPs.

## Os 3 tipos de token

| | DPAN (Device PAN) | Merchant token | Vault token do PSP |
|---|---|---|---|
| Emitido por | Bandeira | Bandeira | PSP adquirente |
| Vinculado a | Um dispositivo | Um lojista | Uma conta de PSP do lojista |
| Uso | Apple Pay / Google Pay | Click to Pay, assinaturas | Todos os pagamentos por esse PSP |
| Padrão | EMVCo | EMVCo | Proprietário |

Os network tokens (DPAN + merchant tokens) são padronizados pela EMVCo; os vault tokens do PSP são proprietários.

## Por que tokenizar

- **Segurança**: em caso de vazamento de dados do lojista, os tokens roubados são inutilizáveis em outro lugar; o PAN real nunca é armazenado.
- **Taxa de autorização**: +2 a +5 pontos com os network tokens, pois a bandeira garante ao scoring do emissor a legitimidade do token.
- **Ciclo de vida do cartão**: se o cartão for reemitido, o token permanece válido (a bandeira faz o remapeamento internamente) — fim do churn de assinaturas em cartões vencidos.
- **PCI-DSS mais leve**: deixar de armazenar PANs reduz o escopo de auditoria.

## Como funciona

1. O portador digita o PAN (ou adiciona o cartão a uma carteira).
2. O lojista ou a carteira solicita um token à bandeira (VTS para a Visa, MDES para a Mastercard).
3. A bandeira gera um token único, vinculado a um contexto preciso.
4. O lojista armazena apenas o token.
5. No pagamento, ele transmite o token à bandeira.
6. A bandeira destokeniza do lado do emissor — o PAN nunca é exposto fora do emissor e da bandeira.
7. O emissor autoriza com base no token e no contexto.

## Apple Pay / Google Pay

O DPAN é o token mais difundido: no cadastro, seu cartão vira um DPAN exclusivo do seu iPhone; cada transação envia um criptograma dinâmico + DPAN; trocar de iPhone gera um novo DPAN. O emissor sabe que é Apple Pay e trata a autenticação forte do cliente (SCA) como já validada — daí uma taxa de autorização mais alta e uma taxa de fraude mais baixa.

## Click to Pay

Iniciativa conjunta de Visa + Mastercard + Amex + Discover para padronizar o checkout de e-commerce via merchant tokens: o portador se cadastra uma vez, é reconhecido por e-mail/telefone em qualquer site Click to Pay, escolhe seu cartão e confirma — o lojista recebe um token, não o PAN. A adoção na Europa é gradual desde 2023, mas a experiência ainda é desigual por falta de coordenação rápida entre as bandeiras.

## O que a tokenização não é

- **Não é criptografia**: um token não é um PAN criptografado (decifrável), mas um identificador independente mapeado do lado da bandeira.
- **Não é um cartão virtual**: um cartão virtual tem seu próprio PAN; um token é um alias do PAN principal.
- **Não é o fim do PCI-DSS**: o lojista que manuseia um PAN na digitação continua parcialmente no escopo.
- **Não é universal**: nem todos os lojistas ainda suportam a tokenização de bandeira; os vaults de PSPs (Stripe, Adyen) a generalizam no backend.

## No ecossistema PSD2

A tokenização de bandeira se integra nativamente ao 3DS2: o lojista transmite o token e o ACS aplica um scoring muitas vezes mais generoso em frictionless, dada a segurança reforçada. É um dos motores da queda contínua da fraude com cartão no EEE.

```mermaid
flowchart LR
    PORTEUR["Portador"]
    PAN["PAN real<br/>(16 dígitos)"]

    subgraph TOKENS["Tokens"]
        DPAN["DPAN<br/>(Apple Pay, Google Pay)"]
        MERCH_TOK["Merchant token<br/>(Click to Pay)"]
        VAULT["Vault token<br/>(Stripe, Adyen)"]
    end

    subgraph SCHEME["Bandeira (VTS / MDES / CB)"]
        TOKENIZE["Serviço de tokenização"]
        DETOKEN["Destokenização do lado do emissor"]
    end

    EMETTEUR["Emissor"]
    MERCH["Lojista / carteira / dispositivo"]

    PORTEUR --> PAN
    PAN -->|"Tokenização"| TOKENIZE
    TOKENIZE --> DPAN
    TOKENIZE --> MERCH_TOK
    TOKENIZE --> VAULT
    TOKENS --> MERCH
    MERCH -->|"Paga com token"| SCHEME
    SCHEME --> DETOKEN
    DETOKEN --> EMETTEUR
```

## Exemplos concretos

- **Apple Pay / Google Pay**: DPAN sistemático em 100% das transações, reconhecido por todos os emissores.
- **Click to Pay**: implantação gradual desde 2022, forte adoção em alguns grandes lojistas, ainda moderada na França.
- **Vault Stripe**: o token `pm_xxx` armazena os cartões dos clientes e executa as assinaturas; a Stripe cuida da tokenização de bandeira nos bastidores.
- **Assinatura do Spotify**: na reemissão de um cartão, o network token é atualizado automaticamente, sem interrupção do pagamento.
- **Taxa de autorização**: +2 a +5 pontos com os network tokens, ou seja, +1 a +3% de faturamento nas assinaturas.
- **PCI-DSS**: armazenar apenas tokens permite mirar o SAQ-A (o mais leve), contra o SAQ-D para quem armazena PANs.
- **Limitação**: a cobertura dos network tokens não é uniforme entre as bandeiras; a CB implanta gradualmente seu suporte EMVCo.

## Fontes

- [EMVCo Payment Tokenisation Specification](https://www.emvco.com/specifications/?show=Tokenisation) — EMVCo
- [Visa Token Service](https://usa.visa.com/products/visa-token-service.html) — Visa
- [Mastercard Digital Enablement Service (MDES)](https://developer.mastercard.com/product/mdes-digital-enablement) — Mastercard

---

Fonte: https://openfinanceguide.com/pt-br/glossary/tokenisation-carte