Parte III · A defesa · Capítulo 11
Pagamento seguro
O meio de pagamento não é só uma taxa no contrato. Ele decide quem autentica o cliente, onde fica o número do cartão, quem analisa o risco e quem paga quando a venda é contestada. Este capítulo é um guia de escolha: o que ligar, o que evitar e o que perguntar antes de assinar ou renovar.
Em resumo
No e‑commerce, o meio de pagamento decide quem autentica o cliente, onde fica o número do cartão, quem analisa o risco e quem paga quando a venda é contestada. Contrate‑o pelo que ele faz no pedido difícil, não só pela taxa do pedido fácil, e decida em quais compras pedir a autenticação 3DS. A loja mantém o poder de segurar um pedido por critério próprio e de saber por que um cliente foi recusado.
- 1Cadastro
- 2Conta
- 3Checkout
- 4Pagamento
- 5Análise
- 6Expedição
- 7Retirada
- 8Atendimento
- 9Financeiro
- 10Pós‑venda
Em destaque, os pontos da operação de que este capítulo trata.
Ao final do capítulo, você consegue decidir
- Se a autenticação 3DS vale em todas as compras, só nas de mais risco ou em nenhuma, e o que guardar de cada uma.
- Por que o número do cartão não deve passar pelo servidor da loja, e o que isso muda na obrigação de segurança dela.
- Que perguntas fazer a quem oferece antifraude ou garantia contra contestação, e que respostas desconfiar.
- Que meios de pagamento oferecer, sabendo que risco cada um tira da loja e que risco deixa.
11.1Quem escolhe o meio de pagamento escolhe parte do risco
A conversa com o meio de pagamento costuma girar em torno de taxa e prazo de repasse. A mesma contratação, porém, define se a loja pode configurar a autenticação, onde fica guardado o número do cartão, que análise de risco vem junto e quem arca com o chargeback de fraude. O capítulo 3 explicou quem é quem no cartão; aqui a pergunta é o que a loja deve exigir de quem ela contrata.
Princípio do capítulo
Contrate o meio de pagamento pelo que ele faz no pedido difícil, não só pela taxa do pedido fácil. E deixe com a loja o que só a loja pode decidir: segurar um pedido por critério próprio e saber por que um cliente foi recusado.
11.2Autenticação 3DS: em todas, em algumas ou em nenhuma
O conceito está no capítulo 3: o emissor confirma, durante a compra, que quem paga é o titular, às vezes sem o cliente perceber, às vezes pedindo um código ou a biometria no aplicativo do banco. Quando a transação é autenticada, a responsabilidade pelo chargeback de fraude tende a passar para o emissor, com os limites descritos em “Autenticação 3DS”. A decisão que fica com a loja é em quais compras pedir essa autenticação.
| Escolha | O que ganha | O que custa | Faz sentido para |
|---|---|---|---|
| Em todas as compras no cartão | A proteção possível contra chargeback de fraude em todo o volume. Configuração simples, sem regra para manter. | Mais clientes passam pelo desafio, e parte desiste no meio, sem o celular à mão ou com o banco fora do ar. | Loja que vende muito produto fácil de revender e já sofre com fraude de cartão de terceiro. |
| Só em parte das compras, por regra de risco | Proteção onde a dúvida é maior, sem incomodar o cliente conhecido no pedido comum. | Alguém precisa definir e revisar a regra. O pedido que a regra deixou passar sem autenticação continua com o risco na loja. | A maioria das lojas pequenas e médias, desde que o meio de pagamento permita escolher. |
| Em nenhuma | Nenhum atrito adicional no pagamento. | Todo chargeback de fraude volta para a loja, sem a defesa que a autenticação daria. | Raramente. Só quando o produto e o histórico mostram fraude baixa e a loja aceita o risco por escrito. |
A regra de risco usa os critérios da análise de pedido: valor acima do habitual, cliente sem histórico, entrega para outra pessoa, categoria visada, várias tentativas de pagamento. Evite um corte de valor único e conhecido, que logo é contornado, como mostra o capítulo 10 em os sinais.
Atrito e conversão, medidos na sua loja
“Derruba a venda” e “resolve a fraude” podem ser verdade em lojas diferentes. Antes de mudar a configuração, peça ao meio de pagamento o relatório das últimas semanas com três números: quantas compras foram autenticadas sem desafio, quantas receberam desafio e, destas, quantas foram concluídas. Repita depois da mudança. Se o desafio derruba muitas compras de clientes conhecidos, a regra está larga demais.
O que guardar de cada compra autenticada
A transferência de responsabilidade só ajuda se a loja consegue mostrar que a autenticação aconteceu. Confirme que o painel guarda, pedido a pedido, o resultado da autenticação (autenticada, tentada, falhou, não realizada) e que esse dado pode ser exportado ou anexado à defesa de uma contestação. Uma compra em que o desafio falhou e a transação seguiu mesmo assim não tem a mesma proteção. O capítulo 13 mostra como usar essa informação na defesa.
Autenticado não quer dizer enviado sem olhar
A autenticação responde quem pagou, não para onde vai a mercadoria, e não cobre o “não recebi”. Com um sinal no pedido, a análise do capítulo 10 continua valendo.
11.3Tokenização e cartão salvo
O “salvar cartão para a próxima compra” ajuda a recompra. A questão é onde o cartão fica. Na tokenização, o número do cartão vai para o provedor de pagamento, que o guarda e devolve à loja um código substituto, o token. Nas compras seguintes, a loja envia o token e o provedor sabe qual cartão cobrar. O token, sozinho, não serve para comprar em outro lugar: se vazar do sistema da loja, não dá ao ladrão o número do cartão.
Guardar o número do cartão no banco de dados da loja transforma a loja num alvo: um único acesso indevido expõe todos os clientes que salvaram o cartão, e a responsabilidade por esse dado é dela, com as exigências da seção seguinte em grau máximo. O código de segurança do cartão não pode ser guardado nem por quem guarda o número: o padrão de segurança do setor proíbe manter esse código depois da autorização, mesmo cifrado.
- O que pedir: que o cartão salvo seja guardado pelo provedor, com token, e que a loja nunca veja mais que os últimos dígitos e a bandeira.
- O que conferir: que nenhum campo, relatório, planilha ou e‑mail interno traga o número completo do cartão. Se aparecer, é o primeiro problema a resolver.
- O que lembrar sobre fraude: cartão salvo numa conta invadida compra com um clique. Proteger o login, assunto do capítulo 6 em segundo fator, é parte de oferecer cartão salvo.
11.4PCI DSS na medida do lojista
O PCI DSS é o padrão de segurança de dados de cartão mantido pelo PCI Security Standards Council, conselho criado pelas bandeiras. Ele vale para quem armazena, processa ou transmite dados de cartão. Quem cobra a conformidade não é o conselho: são as bandeiras e, na prática, o credenciador ou o facilitador com quem a loja tem contrato. Por isso a primeira pergunta é para eles: o que vocês exigem da minha loja, em que formato e com que frequência?
O tamanho dessa exigência não se resume a um ponto. Conta se o número do cartão passa pelo servidor da loja, mas também de onde vêm a página ou os campos de pagamento que o cliente vê, que integração a loja usa e se ela cumpre os critérios de elegibilidade de cada questionário. Para comprovar a conformidade, lojas que se enquadram usam questionários de autoavaliação (os SAQ, na sigla em inglês), com tipos diferentes conforme o jeito de receber pagamento. No comércio eletrônico, o conselho descreve dois cenários que interessam ao lojista:
A página de pagamento vem inteira do provedor
O cliente é redirecionado para a página do provedor, ou a página do provedor aparece dentro da loja num quadro incorporado. O número do cartão vai direto do navegador do cliente ao provedor. É o cenário do questionário mais curto, desde que todos os elementos da página de pagamento venham do provedor validado e a loja cumpra as condições de elegibilidade vigentes, revistas em 2025. Uma delas muda conforme o arranjo: no quadro incorporado, a loja confirma que o próprio site está protegido contra scripts que possam atacar a página de pagamento, com técnicas próprias ou com confirmação do provedor; no redirecionamento, essa condição não se aplica.
A página de pagamento é montada pelo site da loja
Mesmo que o envio final vá para o provedor, é o site da loja que gera o formulário. O conselho considera esse arranjo mais exposto, porque quem invade o site pode alterar a página e copiar os cartões sem que o pagamento pare de funcionar. A lista de exigências é bem maior.
Se a loja recebe o número do cartão no próprio servidor ou o guarda, a obrigação cresce de novo, e já não cabe num questionário simples. Por isso a pergunta prática é: qual é a nossa integração, e qual validação o credenciador exige dela? Quem define o questionário, o formato e a frequência (em geral anual) é o credenciador ou a bandeira, não este livro. Os critérios estão no site do conselho e mudam com as versões do padrão: confira lá, e com o credenciador, antes de afirmar em que tipo a sua loja se encaixa.
Recomendação
O número do cartão nunca passa pelo servidor da loja. O cliente digita num formulário seguro do provedor, e o dado vai do navegador direto para ele. Mesmo assim, o site que abre esse formulário continua importando: quem invade a loja pode trocar o link ou o quadro de pagamento por um falso. Mantenha o acesso ao painel da loja protegido, assunto do capítulo 12.
Vale fora do site também: número de cartão ditado por telefone, mandado por mensagem ou anotado em papel põe a loja de volta no alcance do padrão. O capítulo 10 orienta a nunca pedir esses dados.
11.5Antifraude do meio de pagamento e serviços contratados
Quase todo meio de pagamento devolve alguma análise de risco com a transação, e há serviços que fazem a revisão inteira, às vezes com garantia: se a venda aprovada por eles for contestada como fraude, reembolsam a loja. O capítulo 10 apresentou esses tipos de ferramenta; aqui o foco é a contratação.
O que perguntar, e por quê
As perguntas estão no quadro da seção 11.7. Quatro delas pedem explicação:
- Como vocês explicam uma recusa? Sem o motivo, a loja não atende o cliente que reclama nem corrige uma regra errada. Quando a decisão é só automática, o cliente pode pedir revisão (LGPD, art. 20, como mostra o capítulo 10). “O modelo decidiu” não é resposta que se repasse.
- Quanto recusam, e como medem o cliente bom recusado? Pedido recusado nunca vira chargeback, então não aparece no relatório de fraude. Chargeback baixo conseguido recusando muito é cliente bom indo embora, o custo de recusar visto no capítulo 1. Peça os dois números juntos.
- A garantia exclui o quê? Em geral cobre chargeback por fraude em pedido aprovado por eles. Pergunte, por escrito, o que fica fora: “não recebi”, produto diferente, pedido alterado depois da aprovação, retirada na loja, valor acima de um teto, envio para endereço diferente do aprovado, despacho depois do prazo combinado, entrega sem rastreio ou sem comprovante.
- Que cobertura têm no Brasil? Ferramentas feitas para outros mercados podem ter poucos dados sobre CPF, CEP e telefone daqui, e não tratar Pix e boleto. O prazo de teste serve para conferir isso com os seus pedidos.
Três cuidados depois de contratar
- Regras envelhecem, as da loja e as do serviço. Revise de tempos em tempos o que está segurando pedidos.
- Desconfie da inteligência artificial que “resolve tudo”. Um sistema treinado com o passado erra quando o golpe muda, e quem frauda procura esse ponto cego. Peça recusas explicadas, não demonstração de painel.
- Mantenha uma regra manual de emergência. Sem depender do fornecedor, a loja põe em análise todos os pedidos de um tipo (um endereço, um produto) por horas ou dias. É o freio de mão para a noite em que chegam trinta pedidos iguais.
11.6Que meios oferecer, e que risco cada um deixa
Cada meio tira da loja um tipo de risco e deixa outros. O quadro resume para quem decide o que aparece no checkout.
| Meio | O risco que diminui | O risco que continua | Cuidado da loja |
|---|---|---|---|
| Cartão de crédito | Com autenticação, parte do risco de chargeback de fraude passa ao emissor. | Chargeback por fraude sem autenticação e por “não recebi” ou “veio diferente”. Teste de cartão no checkout. | Autenticação por regra, análise do pedido e registro de entrega. Teste de cartão no capítulo 4, em teste de cartão. |
| Parcelamento no cartão | Nenhum. É ferramenta de venda. | O do cartão, num valor maior: o parcelado facilita o pedido caro, o preferido do fraudador. Com recebíveis antecipados, o chargeback desconta o valor integral de uma vez da agenda da loja. | Mesma atenção ao pedido caro, parcelado ou à vista. |
| Carteira digital | Em geral o cartão já está tokenizado e o cliente se identificou no aparelho, o que dificulta o uso de número de cartão roubado. | Se a carteira usa um cartão, a contestação segue as regras do cartão. Celular ou conta invadidos compram como o dono. | Perguntar ao provedor se a compra por carteira conta como autenticada para fins de chargeback, e guardar esse dado. |
| Pix | Não há chargeback. Com o crédito confirmado no extrato, some o risco do cartão de terceiro. | Comprovante falso, devolução para outra chave, pedido de devolução pelo MED, pagamento feito por uma vítima enganada por terceiro. | Liberar só com crédito no extrato e devolver pela função de devolução do Pix recebido, no prazo do quadro do capítulo 3; com MED aberto, tratar pelo banco. |
| Boleto | Não há chargeback. O pedido só segue depois de compensado. | Comprovante de pagamento não compensado, boleto adulterado, pedido parado esperando compensação. | Status vindo do banco, nunca do comprovante (capítulo 3, em boleto). Boleto não tem estorno: a devolução é transferência só para conta do mesmo CPF ou CNPJ de quem pagou, com segundo aprovador e registro. Vale também para o Pix fora do prazo de devolução. |
| Link de pagamento enviado na conversa | Nenhum. Facilita a venda fora do site. | Todo o risco do cartão, às vezes sem a autenticação e a análise que o checkout da loja tem. | Confirmar com o meio de pagamento se o link usa autenticação e análise de risco. Pedido pago por link passa pela análise do capítulo 10 antes de sair. |
Oferecer Pix, inclusive com desconto, reduz a fraude com cartão de terceiro, mas não a de entrega. Num esquema comum, a vítima de um anúncio falso paga a loja e a mercadoria vai para o endereço que o fraudador indicou: o dinheiro é bom e a venda, ainda assim, termina em problema. O capítulo 8 descreve esse caso em triangulação. Pix confirmado responde à pergunta do pagamento; a do destino continua com a análise.
11.7Perguntas para fazer antes de contratar ou renovar
Leve o quadro para a reunião e peça as respostas por escrito. Resposta vaga numa linha é sinal de que aquele ponto vai doer depois.
| Tema | Pergunta | A resposta que serve |
|---|---|---|
| Autenticação | Posso ligar a 3DS em todas as compras, só por regra minha ou desligar? | Sim para as três, com a regra configurável pela loja. |
| Autenticação | Em que casos a compra autenticada transfere a responsabilidade pelo chargeback de fraude, e em que casos não? | Lista escrita, por bandeira, com as exceções (recorrência, autenticação falha, carteiras). |
| Autenticação | Onde vejo o resultado da autenticação de cada pedido, e consigo exportá‑lo? | No painel, por pedido, com exportação para a defesa. |
| Dados do cartão | O número do cartão passa pelo servidor da minha loja em algum momento? | Não. Vai do navegador direto ao provedor. |
| Dados do cartão | Quem guarda o cartão salvo, e o que a loja recebe? | O provedor guarda. A loja recebe um token, os últimos dígitos e a bandeira. |
| PCI DSS | O que vocês exigem da minha loja para conformidade, em que formato e com que frequência? Vocês são certificados? | Exigência clara, tipo de questionário indicado e comprovante de certificação do provedor. Se a loja roda numa plataforma pronta, peça também a ela o atestado de conformidade (AOC, na sigla em inglês) e guarde com o contrato. |
| Antifraude | Como vocês explicam uma recusa, para mim e para o cliente? | Motivo por pedido, em linguagem que o atendimento consiga usar. |
| Antifraude | Quanto do volume vocês recusam em lojas como a minha, e como medem o cliente bom recusado? | Números, com método. Recusa e chargeback apresentados juntos. |
| Antifraude | Consigo colocar pedidos em análise por critério meu, na hora? | Sim, pelo painel, sem depender do suporte. |
| Garantia | O que a garantia contra contestação cobre e o que exclui? | Exclusões por escrito, com teto de valor e prazos. |
| Cobertura | Como a análise usa dados brasileiros, e como trata Pix e boleto? | Fontes de dados do Brasil e regra própria para cada meio. |
| Teste | Há prazo de teste, e com que números vamos decidir se continua? | Período definido, comparação com o antes e indicadores combinados no início. |
| Contestação | Como chega o aviso de chargeback, com que prazo para defesa, e por onde envio as provas? | Aviso por canal fixo, prazo informado em cada caso e envio de documentos pelo painel. |
| Contestação | Há tarifa por chargeback? Quando o valor é descontado, e o que acontece se a venda já foi antecipada? | Tarifa por escrito e regra de débito na agenda de recebíveis. |
| Contestação | Em que situação vocês retêm parte do meu saldo, e a partir de que índice de chargeback há multa ou risco de encerrar o contrato? | Índice e regra de retenção por escrito, com aviso antes de reter. |
11.8Lista de verificação do capítulo
- A loja sabe em quais compras pede autenticação 3DS, e a regra foi escolhida, não herdada da configuração padrão.
- O painel guarda o resultado da autenticação de cada pedido, e o financeiro sabe onde encontrá‑lo.
- O cartão salvo fica com o provedor, com token, e o número do cartão não passa pelo servidor da loja, nem por telefone, mensagem ou papel.
- A loja sabe, pelo credenciador ou facilitador, o que precisa fazer para conformidade com o PCI DSS.
- A loja consegue pôr pedidos em análise por critério próprio, e alguém sabe acionar essa regra de emergência.
- As regras de risco têm data de revisão marcada.
- As respostas do quadro de perguntas, com as exclusões da garantia, a tarifa e a regra de retenção por chargeback, estão arquivadas junto com o contrato.
Este capítulo traz informação sobre padrões do setor e sobre a lei, não orientação jurídica nem certificação de conformidade. Para o enquadramento da sua loja, consulte o seu credenciador e quem cuida do jurídico dela.
FontesFontes e referências
- PCI Security Standards Council. Página “Merchants” (o PCI DSS se aplica a quem armazena, processa ou transmite dados de cartão; a exigência de validação é definida pelas bandeiras; dúvidas de validação vão ao credenciador ou à bandeira; os SAQ são ferramentas de validação para comerciantes elegíveis, com tipos diferentes por ambiente). Consulta em 11/11/2026.
- PCI Security Standards Council. FAQ nº 1291, “Why is SAQ A‑EP used for Direct Post while SAQ A is used for iFrame or URL redirect?” (no SAQ A, todos os elementos da página de pagamento vêm diretamente de provedores validados; no envio direto a partir de página gerada pelo site do comerciante, SAQ A‑EP) e FAQ nº 1292 (formulários gerados pelo site do comerciante, mais expostos). Consulta em 11/11/2026.
- PCI Security Standards Council. FAQ nº 1588, “How does an e‑commerce merchant meet the SAQ A eligibility criteria for scripts?”, fevereiro de 2025 (o critério de scripts vale para página de pagamento incorporada, como quadro, e não para redirecionamento; confirmação por técnicas dos requisitos 6.4.3 e 11.6.1 ou pelo provedor; o SAQ aplicável se confirma com o credenciador ou a bandeira). Consulta em 11/11/2026.
- PCI Security Standards Council. Blog, “Important Updates Announced for Merchants Validating to Self‑Assessment Questionnaire A” (revisão dos critérios de elegibilidade do SAQ A em 2025). Consulta em 11/11/2026.
- PCI Security Standards Council. Getting Started with PCI Data Security Standard (menção ao atestado anual dentro do SAQ). Consulta em 11/11/2026.
- PCI Security Standards Council. PCI DSS v4.0.1 (biblioteca de documentos), requisito 3.3.1 (dados sensíveis de autenticação, entre eles o código de segurança do cartão, não são mantidos após a autorização, mesmo cifrados). Consulta em 11/11/2026.
- PCI Security Standards Council. Information Supplement: PCI DSS Tokenization Guidelines, agosto de 2011 (token como substituto do número do cartão; em sistemas que guardam só o token, recuperar o número a partir dele não deve ser viável). Consulta em 11/11/2026.
- Visa. “3D Secure: your guide to safer transactions” (fluxos sem fricção e com desafio; transferência de responsabilidade em transações autenticadas). Consulta em 11/11/2026.
- Banco Central do Brasil. Guia de implementação dos procedimentos de devolução no Pix, com ênfase no Mecanismo Especial de Devolução, versão 4.4 (devolução pelo recebedor; prazos no quadro do capítulo 3). Consulta em 11/11/2026.
- Brasil. Lei nº 13.709, de 14 de agosto de 2018 (Lei Geral de Proteção de Dados Pessoais), art. 20 (revisão de decisão automatizada). Consulta em 11/11/2026.
- Saporta, Gilit; Maraney, Shoshana. Practical Fraud Prevention. O'Reilly Media, 2022. Cap. 3 (3‑D Secure e atrito), cap. 4 (tipos de ferramenta, avaliação com período de teste, cobertura regional, regra manual de emergência) e cap. 5 (explicabilidade e limites do aprendizado de máquina).
Revisado em novembro de 2026.