Autenticação via 3DS
Guia completo do protocolo 3-D Secure na Pagar.me v5 — proteção, liability shift e fluxos.
Documentação legada do Pagar.me v5
Um guia completo sobre o protocolo de segurança que protege suas vendas online, aumenta a aprovação e elimina chargebacks por fraude.
O que é 3DS?
O 3DS (3-D Secure) é um protocolo de segurança criado pelas bandeiras (Visa, Mastercard, Amex…) para confirmar que quem está fazendo uma compra online é realmente o dono do cartão. O nome "3D" vem dos três domínios que se comunicam: a loja, o processador de pagamento e o banco emissor.
Analogia simples
Quando uma transação passa pelo 3DS, o banco analisa dezenas de dados em milissegundos: dispositivo, localização, histórico de compras, padrão de comportamento. Em seguida, decide se a identidade está confirmada. Em parte das vezes isso acontece em segundo plano, sem nenhuma interrupção na experiência de compra.
Por que ativar?
Liability Shift
Com o 3DS ativo, a responsabilidade por chargebacks por fraude passa do lojista para o banco emissor. Não há mais prejuízo financeiro caso a transação tenha sido aprovada com 3DS e tenha sido reportada uma contestação por fraude.
Mais aprovações
Bancos confiam mais em transações autenticadas. Compras que seriam recusadas "por precaução" — como compras de maior valor — passam a ser aprovadas.
Menos chargebacks
Com a autenticação como prova de que o banco validou o portador, o volume de contestações fraudulentas pode cair significativamente.
Menos custo operacional
Cada chargeback custa tempo, dinheiro e taxa de disputa. Reduzir chargebacks com 3DS é economizar diretamente na operação.
Sem 3DS vs. Com 3DS
| Situação | Sem 3DS | Com 3DS |
|---|---|---|
| Compra fraudulenta aprovada | ❌ Lojista paga | ✅ Banco paga |
| Aprovação em transações de valor alto | ❌ Menor | ✅ Maior |
| Risco de chargeback por fraude | ❌ Alto | ✅ Baixo |
Como funciona na prática
Do clique em "Pagar" até a aprovação, o 3DS age em segundo plano em alguns segundos. O processo pode seguir dois caminhos:
Frictionless Flow (sem desafio)
A maioria das transações segue esse caminho. O banco analisa os dados em background e aprova a autenticação sem nenhuma interação com o cliente.
Cliente → Loja → Adquirente → Bandeira → Emissor (analisa) → ✅ aprovado
↓ (em segundos)
Cliente vê: "Pagamento aprovado"
Challenge Flow (com desafio)
Quando o emissor não consegue autenticar pelos dados, ele desafia o cliente a confirmar a identidade — geralmente via app do banco, OTP por SMS ou senha.
Cliente → Loja → Adquirente → Bandeira → Emissor (desafia) → 🛡 OTP/senha
↓
Cliente confirma → ✅ aprovado
Versões do 3DS
| Versão | Status | Observações |
|---|---|---|
| 3DS 1.0 | ⛔ Descontinuada | Senha por SMS; UX ruim, alta abandono |
| 3DS 2.1 | ⚠ Em descontinuação | Inicial 2.x; menos sinais de risco coletados |
| 3DS 2.2 | ✅ Recomendada | +90 sinais de risco, melhor frictionless rate |
Perguntas frequentes
O 3DS é obrigatório? Não em todos os casos, mas é fortemente recomendado para todas as transações de cartão online. Em alguns segmentos (Brazil PSD2-like) está caminhando para obrigatório.
Funciona em recorrência? Sim — o cobrança inicial com 3DS gera um Recurring Token que pode ser usado nas cobranças seguintes sem desafio.
E em wallets (Apple Pay / Google Pay)? Wallets já fazem autenticação via biometria do dispositivo, equivalente a 3DS. Não há challenge adicional.
Migração para a API Unificada
Jornada: 3DS e tokenização
Etapa 1 de 6