---
title: "Autenticação via 3DS (legado)"
url: "https://devcenter.stone.com.br/legacy-3ds"
image: "https://devcenter.stone.com.br/_og/d/c_Ocean.takumi,title_~QXV0ZW50aWNhw6fDo28gdmlhIDNEUyAobGVnYWRvKQ,props_eyJ0aGVtZSI6eyJtb2RlIjoibGlnaHQiLCJjb2xvcnMiOnsicHJpbWFyeSI6IiMzMEE2NkQifX19,p_Ii9sZWdhY3ktM2RzIg,s_Fp35oyhe3S0ZI6ix.png"
---

# 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

Esta página descreve um conceito da **Pagar.me v5** (versão clássica). Para projetos novos, explore o **[API Catalog](https://devcenter.stone.com.br/catalog)**.

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-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

pense no 3DS como o "chip + senha" do mundo físico — só que para compras online. Na maquininha, o chip e a senha confirmam que é você. No pagamento digital, o 3DS faz essa mesma verificação, na maioria das vezes de forma completamente invisível.

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?](#por-que-ativar)

### [Liability Shift](#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](#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](#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](#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](#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](#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)](#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.

```text
Cliente → Loja → Adquirente → Bandeira → Emissor (analisa) → ✅ aprovado
                                                    ↓ (em segundos)
Cliente vê: "Pagamento aprovado"
```

### [Challenge Flow (com desafio)](#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.

```text
Cliente → Loja → Adquirente → Bandeira → Emissor (desafia) → 🛡 OTP/senha
                                                    ↓
Cliente confirma → ✅ aprovado
```

## [Versões do 3DS](#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](#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

Na Stone, basta adicionar `"three_d_secure": { "required": true }` no body de [`POST /v1/charges`](https://devcenter.stone.com.br/reference-charges-create). O resto é automático.

---

**Jornada: [3DS e tokenização](https://devcenter.stone.com.br/legacy-3ds)**  
Etapa 1 de 6

[**Próxima etapa**Manual de integração 3DS](https://devcenter.stone.com.br/legacy-manual-integracao-3ds)

Siga a Stone nas redes sociais

[](https://www.facebook.com/stonepagamentos/)[](https://x.com/sejastone/)[](https://www.instagram.com/stone/)[](https://br.linkedin.com/company/stone-co)[](https://www.youtube.com/channel/UCk4L4JykgoDkN8YeuxkNqIQ)

© Stone Instituição de Pagamento S.A. CNPJ 16.501.555/0001-57

Av. Rebouças, 2880, 4º andar, Pinheiros, CEP 05.402-500 – São Paulo/SP

Instituição de pagamento autorizada pelo Banco Central do Brasil, nas modalidades de credenciadora e emissora de moeda eletrônica.