Qualquer pessoa que faça a gestão de faturação por subscrição ou pagamentos recorrentes com cartão está automaticamente no âmbito do PCI DSS. A razão é estrutural: para cobrar um cartão na ausência do titular (pagamento recorrente), o comerciante tem de conservar uma referência aos dados de cartão que permita a autorização futura. Esta referência, seja um PAN em claro ou um token, determina o perímetro de conformidade. A tokenização card-on-file é a resposta técnica que permite gerir subscrições escaláveis sem construir um vault proprietário.
Subscrições e PCI DSS: porque está automaticamente no âmbito
Uma subscrição exige que o comerciante conserve uma referência ao cartão do cliente para o cobrar periodicamente sem uma nova autorização explícita do titular. Isto é definido no PCI DSS como cenário card-on-file: o cartão está "em arquivo" no comerciante. Se o comerciante conservar o PAN diretamente, todos os sistemas que acedem a esse arquivo estão no âmbito. Se o comerciante conservar o token de um vault certificado, o âmbito reduz-se aos componentes que enviam o token ao vault para obter a autorização.
Um erro frequente é pensar que usar um PSP para os pagamentos recorrentes elimina as obrigações PCI. Se o PSP conservar o cartão e o comerciante usar os seus próprios tokens internos para gerir os pagamentos, o comerciante continua no âmbito para a gestão desses tokens e para o fluxo que os envia ao PSP. A redução efetiva do âmbito depende de como está estruturada a integração técnica e de que dados transitam realmente pela infraestrutura do comerciante.
Tokenização card-on-file para a faturação por subscrição
Com a tokenização card-on-file da PCI Proxy EU, o fluxo para as subscrições funciona assim: no momento do primeiro registo, o cliente introduz os dados de cartão na payment page alojada pela PCI Proxy EU. O sistema devolve ao comerciante um token persistente associado a esse cartão. O comerciante armazena o token na sua própria base de dados junto ao perfil do cliente e ao plano de subscrição. Nos vencimentos posteriores, o comerciante envia o token à PCI Proxy EU, que recupera o PAN e o transmite ao PSP para a autorização.
Esta abordagem permite ao comerciante gerir a lógica de faturação (cálculo de montantes, gestão de períodos, notificações de vencimento, novas tentativas em caso de falha) nos seus próprios sistemas sem nunca tocar no PAN. A base de dados do comerciante contém unicamente tokens, identificadores de cliente e dados do plano: nenhum destes elementos constitui um dado sensível PCI. A flexibilidade na lógica de faturação mantém-se íntegra porque o token é persistente e pode ser reutilizado para um número ilimitado de autorizações posteriores.
O que continua a ser responsabilidade do comerciante com a tokenização
A tokenização não elimina todas as obrigações PCI do comerciante. Os componentes que enviam o token à PCI Proxy EU para a autorização (servidor aplicacional, job scheduler, sistema de faturação) permanecem no âmbito na parte ligada à API do vault. Estes sistemas devem ter controlos de acesso apropriados, registos dos acessos às API, gestão segura das credenciais API e procedimentos documentados para a rotação das chaves de autenticação. O SAQ aplicável neste cenário é tipicamente o SAQ D para Comerciantes, mas com um número de sistemas no âmbito muito reduzido relativamente a uma arquitetura sem tokenização.
Também a gestão dos cartões caducados exige um processo definido: quando um cartão caduca, o comerciante deve ter um fluxo para atualizar o token com o novo cartão do cliente (através de redirecionamento para uma nova payment page) ou para ativar o cancelamento da subscrição. A PCI Proxy EU suporta atualizações automáticas de cartões para as redes que as disponibilizam, reduzindo o churn involuntário sem exigir que o cliente volte a introduzir manualmente os dados.
Perguntas frequentes
Posso usar o token da PCI Proxy EU para reprocessar uma subscrição falhada?
Sim, o token é persistente e pode ser usado para tentativas de cobrança posteriores enquanto o cartão subjacente for válido no vault. Se uma cobrança falhar por cartão caducado, o token torna-se inutilizável para novas autorizações. O comerciante deve ativar um fluxo de atualização de cartão: a PCI Proxy EU suporta o Account Updater para as redes que o permitem, ou o comerciante pode enviar ao cliente uma ligação para atualizar manualmente os dados.
Como faço a gestão da atualização dos dados de cartão numa subscrição?
O fluxo padrão prevê o envio de uma notificação ao cliente com uma ligação para a payment page da PCI Proxy EU para introduzir os novos dados de cartão. Uma vez concluído, o sistema emite um novo token que o comerciante associa ao perfil do cliente existente. O token antigo fica invalidado. Este processo não exige qualquer modificação à lógica de faturação do comerciante: apenas se atualiza o ID do token na base de dados.
O mandato SEPA elimina as obrigações PCI DSS?
Sim, mas apenas se os pagamentos recorrentes forem geridos exclusivamente através de débito direto SEPA (SDD). O mandato SEPA não usa dados de cartão mas sim IBAN, que não entra no perímetro PCI DSS. No entanto, se a empresa aceitar tanto SEPA como cartão de crédito para as subscrições, os pagamentos com cartão continuam no âmbito PCI. Muitas empresas usam os dois instrumentos em paralelo, pelo que o SEPA não elimina as obrigações PCI mas pode reduzir o volume de transações com cartão no âmbito.
Subscrições sem PAN na sua stack: você gere a lógica de faturação, nós guardamos os dados de cartão. Descubra a PCI Proxy EU.
Precisa de apoio na conformidade PCI?
A nossa equipa ajuda a mapear o seu CDE, escolher o SAQ adequado e implementar tokenização com residência de dados na UE.
Contacte-nos