No mundo dos pagamentos de cartão não presente, o foco já não está mais na "autenticação com fricção". As bandeiras estão liderando uma nova tendência, em que o 3DS deixa de ser o protagonista e a segurança passa a ser definida pelo contexto, não pelo challenge.
É o uso cada vez mais frequente da autenticação silenciosa, baseada em token, criptograma e dados contextuais.
VDCAP — Visa Digital Commerce Authentication Program
O VDCAP é um programa criado pela Visa para validar e proteger transações tokenizadas no ambiente Card-Not-Present (CNP) — especialmente em apps, carteiras digitais e plataformas de e-commerce.
Quando a Visa marca a transação como "autenticada"
Se a transação:
- For tokenizada (provisionada pelo VTS — provisionamento realizado por um Token Requestor registrado)
- Tiver um TAVV válido
- Estiver com campos específicos preenchidos (Field 34, 56, 111)
- O emissor estiver habilitado
…a Visa marca automaticamente a transação como autenticada, mesmo sem challenge 3DS.
Campos críticos para elegibilidade VDCAP
Field 60.8 = 07 e Field 63.6 = 7 são essenciais para que a Visa identifique a transação como potencialmente elegível ao VDCAP, mesmo antes de aplicar a Tag 89 no Field 111.| Campo | Valor | Descrição |
|---|---|---|
| Field 34 | Token PAN | Token provisionado via VTS |
| Field 56 | Token Cryptogram (TAVV) | Criptograma do token — prova de presença do dispositivo |
| Field 60.8 | 07 | Indica transação tokenizada e elegível para VDCAP |
| Field 63.6 | 7 | Sinaliza o canal digital da transação |
| Field 111 / Tag 89 | Gerado pela Visa | Indicador de autenticação VDCAP — NÃO deve ser enviado pelo adquirente |
Benefícios do VDCAP
- Menos fricção no checkout
- Maior taxa de aprovação
- Menos chargebacks
- Proteção do emissor preservada
BASE II — o que fazer quando Tag 89 = 1
Se o adquirente recebe Tag 89 = 1 na autorização, ele deve propagar essa informação no arquivo de clearing (BASE II) para garantir que a transação seja reconhecida como protegida no ciclo de disputa.
TAF — Token Authentication Framework (Mastercard)
O TAF é o mecanismo da Mastercard que define a validade da autenticação com base em UCAF + metadata do token.
Através dele é possível avaliar se uma transação CNP com token pode ser considerada autenticada e garantir liability shift para o emissor.
Elementos obrigatórios para elegibilidade TAF
| Campo | Valor / Tipo | Descrição |
|---|---|---|
| Token | Provisionado via MDES | Token Mastercard Digital Enablement Service |
| DE 48.61 | UCAF válido | Universal Cardholder Authentication Field — criptograma do token |
| DE 22 | 81, 91, 80, etc. | Entry Mode — indica o canal de captura da transação |
| DE 63.2 | Canal específico | Channel-specific indicators (In-App, Web, etc.) |
SCOF — Secure Card on File Program (Mastercard)
O SCOF é um programa da Mastercard que registra e certifica o uso seguro de cartões armazenados digitalmente — os chamados cards on file: cartões que ficam salvos em apps, wallets, navegadores ou plataformas de e-commerce.
Objetivos do SCOF
- Registrar o token e seu comportamento esperado (file-based, one-click, recurring)
- Definir a elegibilidade para liability shift
- Evitar exposição do PAN, com uso obrigatório de tokens MDES
- Reduzir risco em transações recorrentes ou salvas
- Permitir autenticação sem fricção via token e dados contextuais
Critérios de elegibilidade SCOF
Para que uma transação seja elegível ao SCOF, ela precisa:
- Ser tokenizada via MDES, com:
- TRID (Token Requestor ID) — identificação do requestor do token
- Token Reference ID — identificador único do token
- UCAF (Criptograma) — prova criptográfica da autenticação
A jornada completa: do salvamento do cartão à autorização
Merchant salva o cartão
O PAN vira token via MDES. O token é provisionado com TRID, Token Reference ID e UCAF.
Token registrado no SCOF Directory
Canal de uso (web, app, recurring), Token Requestor ID e nível de confiança (assurance level) são registrados.
Usuário faz pagamento com cartão salvo/tokenizado
O sistema (app ou site) prepara a requisição com o token.
Geração do UCAF
O sistema gera um UCAF contendo: criptograma baseado no token, assurance level e metadata do canal.
Autorização com TAF ativo
O adquirente envia a transação com DE 22 (entry mode: 91, 81…), DE 48.61 (UCAF criptografado) e DE 63.2 (canal/contexto).
Verificação Mastercard
O token está registrado no SCOF? O UCAF é válido e consistente? O assurance level é suficiente para isenção de 3DS?
Comparação: VDCAP (Visa) vs TAF/SCOF (Mastercard)
| Aspecto | VDCAP (Visa) | TAF/SCOF (Mastercard) |
|---|---|---|
| Serviço de token | VTS (Visa Token Service) | MDES (Mastercard Digital Enablement Service) |
| Criptograma | TAVV (Token Auth Verification Value) | UCAF (Universal Cardholder Auth Field) |
| Campo de autenticação | Field 111 / Tag 89 | DE 48.61 |
| Campo de canal | Field 60.8 e 63.6 | DE 22 e DE 63.2 |
| Quem gera o indicador | A Visa (Tag 89 gerada pela rede) | O adquirente (DE 48.61 enviado com UCAF) |
| Liability shift | Sim, para o emissor | Sim, para o emissor |
| Dispensa 3DS | Sim, quando elegível | Sim, quando elegível |