Se você criar sua própria ferramenta que lida com pagamentos, de quem é o risco de conformidade?
O selo PCI do seu provedor de pagamento não se transfere para você. Saiba quem realmente assume o risco de conformidade quando uma ferramenta própria lida com pagamentos, e a arquitetura que mantém os desenvolvimentos personalizados fora do escopo.
Você assume. Não a IA que gerou o código, não o seu provedor de hospedagem e não o seu provedor de pagamento. No momento em que uma ferramenta que você desenvolveu lida com pagamentos, o risco de conformidade fica com a sua empresa, e permanece lá, não importa quantos fornecedores em conformidade você conecte. O que você pode mudar é o tamanho desse risco, e a diferença entre uma ferramenta personalizada bem projetada e uma descuidada é enorme.
Por que o risco recai sobre você e não sobre seus fornecedores?
A aceitação de cartões funciona com base em uma cadeia de contratos. As bandeiras de cartão definem as regras, sua credenciadora (o banco que liquida as vendas com cartão para você) as aplica, e o seu contrato de credenciamento as repassa para você. O livro de regras é o PCI DSS, o padrão de segurança de dados do setor de cartões, e ele se aplica a qualquer empresa que armazene, processe ou transmita dados de portadores de cartão (números de cartão e os detalhes que os acompanham). A versão atual é a 4.0.1. (Os números de versão e os detalhes do programa estão precisos na data de publicação; trate as especificidades como um panorama do momento.)
Seus fornecedores têm obrigações em relação aos seus próprios sistemas, e um provedor de pagamento em conformidade reduz drasticamente a sua parcela de trabalho. Mas nada do que um fornecedor faça transfere a responsabilidade. O PCI Security Standards Council é explícito ao afirmar que a obrigatoriedade de validar a conformidade é decidida pelas bandeiras de pagamento e pela sua credenciadora, e a resposta delas, escrita no seu contrato de credenciamento, é sim. Todos os anos, alguém na sua empresa assina uma declaração atestando que o seu ambiente atende ao padrão. Essa assinatura é sua, não do seu fornecedor.
O que muda no momento em que seu próprio código lida com dados de cartão?
O escopo. O esforço de conformidade é medido pelo escopo: todo sistema que lida com dados do portador do cartão, além de tudo o que estiver conectado a ele, entra no padrão.
Um lojista cujos pagamentos são totalmente processados por um provedor em conformidade e seus dispositivos certificados realiza a validação com um questionário de autoavaliação curto (um checklist anual) de poucas dezenas de perguntas. Já um lojista cujo próprio software lida com números de cartão entra no nível mais complexo, que reflete a maior parte do padrão completo: bem mais de duzentos requisitos que cobrem varreduras trimestrais de vulnerabilidade, testes de invasão (penetration testing), controles de acesso, registros de log e políticas formais de segurança¹.
Aquele formulário de checkout que uma IA escreveu para você em uma tarde? Se ele aceitar números de cartão, seu servidor web, seu banco de dados, seu notebook de administração e o Wi-Fi da sua loja são todos candidatos a entrar no escopo. E você não pode simplesmente enviar o questionário curto de fininho. Escolher um nível para o qual você não é elegível não reduz seu risco; significa que o documento que você assinou está incorreto, o que costuma vir à tona no pior momento possível: logo após uma violação de dados.
Quanto custa, na verdade, fazer isso errado?
A aplicação das penalidades é contratual, por isso costuma aparecer no seu extrato de processamento. Muitas credenciadoras cobram uma taxa recorrente de não conformidade todos os meses até que você faça a validação. Após uma violação de dados, os custos se acumulam: uma investigação forense obrigatória paga por você, custos de reemissão de cartões e multas crescentes repassadas pela sua credenciadora, comumente citadas na faixa de US$ 5.000 a US$ 100.000 por mês (com base nas tabelas de penalidades publicadas por assessores de conformidade PCI). Em casos graves, uma empresa pode perder totalmente a capacidade de aceitar cartões.
Para um pequeno lojista, o custo mais pesado é mais silencioso do que qualquer multa: gerenciar um programa de segurança real consome um tempo que você planejava gastar administrando o próprio negócio.
Como criar ferramentas personalizadas sem assumir o escopo de dados de cartão?
Mantenha seu código fora do caminho do cartão. Sua ferramenta personalizada deve orquestrar a venda: montar o carrinho, aplicar descontos, somar o pedido e enviar o valor a ser cobrado. O cartão em si só deve interagir com um terminal certificado (hardware de pagamento validado para lidar com cartões) ou com a página de pagamento hospedada do seu provedor, que o envia diretamente para um processador de pagamentos (a empresa que movimenta o dinheiro). Sua ferramenta recebe de volta um resultado, aprovado ou recusado, além de um token (um número de referência que é inútil para quem o roubar).
Essa divisão é todo o argumento a favor da arquitetura de POS headless: telas personalizadas por cima, infraestrutura de pagamento certificada por baixo. É também por isso que checkouts gerados por IA funcionam perfeitamente em demonstrações, mas travam na produção, e por que um formulário web é a resposta errada para débito com cartão presente como o Interac: pagamentos presenciais devem ser feitos em hardware certificado, tanto técnica quanto contratualmente.
O Final é construído exatamente em torno desse limite. Os fluxos que você cria, seja por meio de comandos próprios ou ao conectar sua própria IA via MCP, controlam telas, carrinhos e catálogos. Os dados do cartão vão do hardware do terminal certificado para um processador de pagamentos por meio do Final Pay, e nunca entram no fluxo que você criou. Personalizado onde a personalização é segura, padronizado onde reside a responsabilidade.
Então, de quem é o risco de conformidade?
É seu, e sempre será. A decisão real é quanto escopo você assume, e essa é uma escolha de arquitetura, não de papelada. Antes de lançar uma ferramenta que lida com pagamentos, faça uma pergunta: meu código poderá algum dia ver um número de cartão? Se sim, o programa de conformidade é de sua responsabilidade. Se não, você mantém a flexibilidade de um desenvolvimento personalizado com uma fração do fardo. Se você está avaliando esse tipo de desenvolvimento agora, comece com os sinais de que você superou seu POS pronto para uso.
Perguntas frequentes
Usar um provedor de pagamentos em conformidade com o PCI torna minha empresa em conformidade?
Não. Um provedor em conformidade reduz a quantidade de trabalho que você precisa fazer, mas sua empresa ainda valida a própria conformidade todos os anos por meio do seu contrato de credenciamento. A responsabilidade nunca é transferida para um fornecedor.
Qual é a diferença entre o SAQ A e o SAQ D?
Ambos são questionários de autoavaliação do PCI DSS. Os níveis mais curtos se aplicam quando os pagamentos são totalmente terceirizados para um provedor em conformidade e hardware certificado. O SAQ D se aplica quando seus próprios sistemas processam dados de titulares de cartão e reflete a maior parte do padrão completo, incluindo varreduras, testes e políticas formais.
O código gerado por IA altera as minhas obrigações com o PCI?
Não. A norma se preocupa com quais sistemas manipulam os dados do titular do cartão, não com quem ou o que escreveu o código. Um checkout gerado por IA que aceita números de cartão coloca seus sistemas totalmente no escopo, exatamente como um código escrito à mão faria.
As pequenas empresas podem realmente ser penalizadas pela não conformidade com o PCI?
Sim, embora geralmente venha na forma de uma taxa mensal de não conformidade do seu processador de pagamentos, e não como uma multa de grande repercussão. As grandes penalidades normalmente ocorrem após uma violação de dados, juntamente com custos de investigação forense e reemissão de cartões.
O que é tokenização?
Substituir um número de cartão por um token de referência que é inútil fora do sistema de pagamento que o emitiu. Suas ferramentas podem armazenar e usar o token para reembolsos ou cobranças recorrentes sem nunca reter os dados reais do cartão.