Conformidade PCI para desenvolvedores de aplicativos: a versão curta e dolorosa

A conformidade PCI (as regras de segurança da indústria de cartões de pagamento para quem lida com dados de cartão) é o preço cobrado pelas palavras "aceita cartão de crédito". A versão curta: se dados de cartão passarem pelo código que você escreveu ou pelos servidores que você opera, você herda um padrão de segurança com centenas de controles, um atestado anual (uma declaração formal assinada de que você cumpre o padrão) e consequências intermediadas pelo seu processador de pagamentos. A versão dolorosa da conformidade PCI para desenvolvedores de apps: a maioria descobre isso depois que o checkout já está pronto.

Uma observação antes dos detalhes. Os números de versão, datas e regras dos questionários abaixo estavam precisos na data de publicação; o padrão evolui, portanto trate os detalhes como um panorama do momento.

O que é conformidade PCI, afinal?

O PCI DSS (Padrão de Segurança de Dados da Indústria de Cartões de Pagamento) é uma obrigação contratual, não uma lei. As bandeiras de cartão o impõem aos bancos e processadores de pagamento, que por sua vez o impõem aos comerciantes e aos softwares que esses comerciantes executam. A versão atual é a 4.0.1, e a última onda de seus novos requisitos tornou-se obrigatória em 31 de março de 2025¹. O padrão abrange 12 famílias de requisitos, desde segurança de rede e criptografia até controle de acesso e registros de log, divididas em centenas de controles individuais².

Nenhum órgão regulador baterá à sua porta. Em vez disso, as consequências chegam de forma comercial: multas repassadas pelo seu banco credenciador (o banco que liquida os pagamentos com cartão para o comerciante), taxas de processamento mais altas e, no pior dos casos, a perda da capacidade de aceitar cartões. Após um vazamento de dados, os custos de investigação forense e de reemissão de cartões seguem o mesmo caminho.

Por que "só adicionar pagamentos" coloca seu app inteiro no escopo?

O escopo é o ponto central. O PCI DSS aplica-se a todo sistema que armazena, processa ou transmite dados do titular do cartão, além de tudo o que estiver conectado a esses sistemas. A validação funciona como uma escada, e cada degrau é dramaticamente mais pesado que o anterior²:

• SAQ A (Questionário de Autoavaliação A): os pagamentos são totalmente terceirizados para um provedor em conformidade e os dados do cartão nunca tocam seus sistemas. É o questionário mais curto.

• SAQ A-EP: seu site nunca toca nos dados do cartão, mas controla como os clientes chegam ao formulário de pagamento. Uma grande parte do padrão completo agora se aplica aos seus servidores web.

• SAQ D: os dados do cartão passam por qualquer coisa que você tenha desenvolvido, mesmo que brevemente ou sem armazenamento. Trata-se, na prática, de todo o padrão, documentado e atestado anualmente.

O primeiro degrau também não significa "nada". Em janeiro de 2025, o PCI Security Standards Council removeu os requisitos de script da página de pagamento do SAQ A, mas adicionou uma condição de elegibilidade: você deve confirmar que seu site não é suscetível a ataques de script que possam afetar seu sistema de e-commerce¹. Até mesmo o nível totalmente terceirizado exige que você defenda a página que hospeda o formulário de pagamento de terceiros.

Acima de seis milhões de transações com cartão por ano, a autoavaliação termina completamente e começa uma auditoria presencial feita por um QSA (um assessor externo certificado)².

É possível contornar pagamentos presenciais apenas programando?

Não. Os pagamentos presenciais são onde a escada se transforma em uma parede. Transações presenciais (com cartão presente) exigem hardware certificado: leitores físicos aprovados no programa de laboratório PTS do Conselho, executando firmware aprovado e configurados por meio de um processador de pagamentos. Transformar um smartphone em leitor apenas com software cai sob um padrão diferente, o Mobile Payments on COTS (MPoC), que certifica o provedor da solução, e não o que você desenvolveu.

Essa é uma fronteira que a geração de código por IA não consegue cruzar. Um modelo pode criar uma tela de checkout convincente em uma tarde; Você consegue criar um POS com o Lovable ou Replit? e Vibe Coding em um ponto de venda mostram onde esses projetos empacam. Nenhum código gerado cria um leitor certificado, um contrato de credenciamento ou um atestado de conformidade, não importa quanto tempo o modelo programe sem supervisão. A conformidade também é um motivo recorrente pelo qual apps de pagamento criados por vibe coding são rejeitados na App Store.

Como os desenvolvedores realmente reduzem o escopo do PCI?

Você não tenta atender a mais requisitos; você projeta a arquitetura para que haja menos com o que estar em conformidade:

• Nunca deixe um PAN (o número do cartão principal) tocar no seu código. Use os campos de pagamento hospedados pelo seu processador para que os dados do cartão sigam do navegador do cliente diretamente para o processador.

• Armazene tokens, não cartões. A tokenização (substituir o número do cartão por uma string de referência inútil se for roubada) evita que cartões salvos e reembolsos arrastem seu banco de dados para dentro do escopo.

• Para vendas presenciais, use leitores certificados do seu processador para que os dados do cartão fluam do leitor para o processador sem passar pelo seu app.

• Mantenha a página de pagamento simples. Todo script de terceiros nela se torna algo sobre o qual você precisará prestar contas.

Feito da forma correta, seu app orquestra uma venda sem nunca ter a posse dos dados do cartão, e o questionário continua curto. Feito de forma errada, um único recurso de conveniência ("só registrar o corpo completo da requisição nos logs") converte você silenciosamente para o SAQ D.

Então, quão dolorosa é a conformidade PCI para desenvolvedores de apps?

Dolorosa na proporção de quanto dado de cartão seu código toca, e é por isso que a estratégia vencedora é não tocar em nada. O padrão não se importa se uma equipe de devs escreveu seu app ou se uma IA o gerou em uma tarde; escopo é escopo. Antes de lançar qualquer coisa que aceite cartão, faça uma pergunta: um número de cartão pode em algum momento passar pelo código que escrevi? Se sim, prepare o orçamento para uma auditoria. Se não, mantenha assim.

Essa arquitetura é a mesma que o Final utiliza. Um checkout construído no Final, seja por meio de prompts no Build ou criado pela sua própria IA via MCP, processa seus pagamentos através do Final Pay: um processador de pagamentos e terminais certificados lidam com os dados do cartão, de forma que o fluxo em si nunca detém um número de cartão. Onde o Final Pay está disponível aborda o lado prático, e Conectando o Tap to Pay a um fluxo de POS com IA mostra como é a aceitação de cartões quando a camada de conformidade já está estruturada por baixo.