.png)
3DS2 é o protocolo de autenticação de pagamentos online que analisa até 100 dados da transação em segundos e decide, em tempo real, se o portador do cartão precisa ser desafiado ou se a cobrança passa de forma silenciosa, sem fricção para o comprador.
A versão 2.2 do protocolo separa dois momentos: a autenticação forte na primeira cobrança e a aprovação das seguintes por referência.
Para recorrência, essa distinção é tudo.
Pagamentos recorrentes com cartão movimentaram R$ 141,9 bilhões em 2025, crescimento de 34% sobre 2024, segundo a ABECS. E a cada ciclo rejeitado por falha de autenticação, a perda não é uma cobrança. É o churn forçado de um assinante que sequer sabe o que aconteceu.
CIT, MIT e a série recorrente
O protocolo 3DS 2.2 divide a recorrência em dois tipos de transação. A CIT (Customer Initiated Transaction) é a primeira cobrança, feita com o comprador presente: o emissor recebe os dados, avalia o risco e decide entre autenticação silenciosa ou desafio (OTP, biometria, token bancário).
A MIT (Merchant Initiated Transaction) é tudo que vem depois. Toda cobrança subsequente disparada pela plataforma, sem o comprador na tela. Segundo o Normativo 31/2024 da ABECS, as MITs ficam isentas de nova autenticação desde que referenciem o ID da CIT original, e esse mecanismo pode ser combinado com network token para garantir fluidez e segurança em toda a cadeia recorrente.
Aliás, tem um detalhe que o nome "isenção" esconde: a MIT não é autenticada de forma independente. Ela é aprovada na sombra da CIT. Se a CIT for mal configurada, a sombra é ruim. E todas as MITs seguintes carregam esse problema, ciclo a ciclo, sem nenhum alerta explícito no dashboard.
Onde a conversão cai
O problema raramente está no protocolo.
Está em como a CIT é enviada. Campos obrigatórios ausentes, dados de dispositivo inconsistentes, geolocalização imprecisa: cada desvio do padrão EMVCo reduz a qualidade do sinal que o emissor usa para classificar a transação como baixo risco. Emissor com sinal de baixa qualidade faz uma de duas coisas: desafia o comprador na primeira autenticação, adicionando fricção que eleva abandono no checkout, ou rejeita diretamente, contaminando a referência de toda a série recorrente.
Os dados são verificáveis. Segundo a ABECS, transações autenticadas com 3DS apresentam taxa de aprovação de 86%, contra 80% das não autenticadas. Na experiência do PagBank, reportada em webinário da ABECS, a aprovação com 3DS foi 6% superior às transações sem autenticação. O Banco Inter registrou 11 pontos percentuais a mais na autorização de compras autenticadas entre agosto de 2022 e agosto de 2023, num período em que a adoção do protocolo estava sendo expandida.
Cada ponto percentual em uma base recorrente de R$10M/mês equivale a R$100k em cobranças aprovadas ou rejeitadas. Multiplicado pelos ciclos mensais, esse número não aparece isolado em nenhum dashboard. E é exatamente por isso que a maioria das operações convive com o problema meses a fio sem identificar a causa.
Isso dito: 3DS não é garantia de aprovação universal. O emissor ainda aplica regras próprias de risco, e há cenários em que uma CIT bem configurada é desafiada ou negada por política do banco. O que o protocolo garante é que a operação tenha a melhor chance possível, com o sinal mais limpo possível. Mais do que isso, nenhum protocolo promete.
O Normativo 31/2024 da ABECS
A ABECS publicou o Normativo 31/2024 em 21 de agosto de 2024. O documento determina que emissores, credenciadoras e PSPs devem responder a requisições de autenticação baseadas no protocolo 3DS em conformidade com as especificações da EMVCo e com os parâmetros mínimos definidos para o mercado nacional.
Para operações de recorrência e card on file, o normativo é direto: é recomendável realizar autenticação 3DS no momento do cadastramento do cartão ou na primeira compra. Nas transações seguintes, a tokenização assegura a segurança do processo e novas autenticações não são necessárias, salvo quando o emissor identifica risco excessivo, como transações concentradas ou consecutivas.
O normativo prevê que MITs podem ser reconhecidas como exceção à obrigatoriedade via pedido ao Fórum de Segurança e Prevenção a Fraudes da ABECS. Mas operar recorrência sem a CIT autenticada tem um custo prático que a exceção regulatória não elimina: a cadeia de aprovação fica sem âncora, e o índice de aprovação reflete isso, silenciosamente, ciclo a ciclo.
Antifraude e 3DS integrados
Na plataforma white label da Barte, o antifraude e o 3DS trabalham juntos desde a CIT. Empresas de pagamentos que operam com nossa plataforma não precisam conectar soluções separadas para autenticação e avaliação de risco: os dois funcionam integrados desde o início da série recorrente.
O antifraude que usamos não é genérico. É calibrado por vertical, pelo perfil da carteira de cada empresa que opera com a gente. A diferença é concreta: um motor genérico que bloqueia um perfil de usuário legítimo pode estar destruindo a referência de uma série recorrente inteira sem deixar log claro. O nosso reduz falso positivo e mantém a aprovação mais consistente ao longo dos ciclos.
Teste isso na sua operação: quando uma MIT é rejeitada hoje, você consegue identificar em menos de 5 minutos se o problema está na referência da CIT, no ID da transação original ou na ausência de network token? Se a resposta depender de abrir mais de um sistema, há débito técnico crescendo na operação recorrente.
Três pontos para o próximo ciclo
O primeiro é garantir que todos os campos obrigatórios da CIT estão sendo enviados no padrão EMVCo. O 3DS 2.2 autentica transações recorrentes desde que os campos estejam completos, conforme documentação técnica publicada pela ABECS. Campo ausente degrada a autenticação. E a referência quebrada não aparece até o emissor rejeitar.
O segundo é vincular network token à CIT autenticada. A combinação de autenticação e tokenização garante que as MITs tenham referência verificável para o emissor, sem exigir nova presença do comprador e sem depender da estabilidade do PAN ao longo do tempo.
O terceiro ponto é o mais ignorado: retry genérico sem diagnóstico deteriora o índice de aprovação a cada ciclo. Rejeições de MIT precisam de código de erro específico e workflow ativo de resolução que identifique se a falha é de referência, de tokenização ou de política do emissor.
O problema que não tem nome não tem conserto.
Perguntas frequentes sobre 3DS2 em pagamentos recorrentes
O que é 3DS2? 3DS2 é o protocolo de autenticação de pagamentos online que analisa até 100 dados da transação em segundos para decidir se o comprador precisa de um desafio ou se a cobrança passa de forma silenciosa. É o padrão estabelecido pela EMVCo e adotado pelo Normativo 31/2024 da ABECS para o mercado brasileiro.
Pagamentos recorrentes precisam de 3DS2 em toda cobrança? Não. A autenticação forte ocorre na primeira transação, a CIT. As cobranças seguintes, as MITs, ficam isentas desde que referenciem o ID da CIT original e, de preferência, estejam combinadas com network token. Esse é o modelo estabelecido pelo protocolo 3DS 2.2.
O que acontece se a CIT for configurada incorretamente? Se os campos obrigatórios da CIT estiverem incompletos ou inconsistentes com o padrão EMVCo, o emissor não terá referência confiável para aprovar as MITs subsequentes. O resultado é rejeição em cadeia ao longo de toda a recorrência.
O Normativo 31 da ABECS obriga 3DS em recorrências? O normativo recomenda autenticação 3DS no cadastro do cartão ou na primeira compra para operações de card on file e recorrência. Para MITs, a tokenização substitui a necessidade de nova autenticação. O normativo permite exceções para MITs via pedido ao Fórum de Segurança e Prevenção a Fraudes da ABECS.
Quer estruturar sua operação recorrente com antifraude e 3DS integrados, com processamento online na sua marca? Fale com nosso time em whitelabel.barte.io.
.png)
.png)
.png)
.png)
.png)
.png)
