O buy now pay later e o PCI é um dos domínios onde a cadeia de responsabilidade PCI DSS é mais complexa de mapear. Os modelos BNPL como a Klarna, a Scalapay, a Afterpay e os seus concorrentes europeus envolvem vários intervenientes numa única transação: o comerciante, o fornecedor BNPL, a rede de cartões e, em alguns casos, também um adquirente separado. Perceber quem gere os dados de cartão e quem responde pela conformidade PCI DSS neste ecossistema é fundamental para qualquer comerciante que ofereça pagamentos diferidos.
BNPL e PCI DSS: a cadeia de responsabilidade
Nos modelos BNPL mais difundidos, o fornecedor (Klarna, Scalapay, etc.) atua como financiador: paga ao comerciante o montante total no momento da compra e gere a relação de crédito com o consumidor para as prestações seguintes. O consumidor pode pagar as prestações com cartão de crédito ou débito e, nesse caso, os dados de cartão transitam pela plataforma do fornecedor BNPL. O comerciante recebe apenas o valor da encomenda, sem ver os dados de cartão do consumidor relativos às prestações.
Isto significa que, para o componente BNPL puro, o comerciante fica fora do fluxo de dados de cartão: o perímetro PCI DSS dessa transação pertence ao fornecedor BNPL, não ao comerciante. No entanto, se o comerciante também aceitar pagamentos com cartão tradicionais em paralelo (o que acontece quase sempre), o seu perímetro PCI mantém-se ativo para esses fluxos. O erro habitual é assumir que integrar um BNPL elimina por completo as obrigações PCI: apenas as reduz para as transações processadas através desse canal específico.
O comerciante BNPL: que dados de cartão toca realmente
Existem variantes do modelo BNPL onde o comerciante está mais envolvido nos dados de cartão. Nos modelos "merchant-financed BNPL" ou nas soluções white-label, o comerciante pode gerir diretamente o fracionamento sem um fornecedor BNPL externo. Nestes casos, o comerciante tem de armazenar ou ter acesso aos dados de cartão para as prestações seguintes, e o perímetro PCI expande-se significativamente. A tokenização card-on-file torna-se necessária para gerir estas prestações sem expor os dados de cartão nos sistemas do comerciante.
Mesmo nos modelos BNPL com fornecedor externo, existem cenários onde o comerciante toca dados de cartão de forma indireta: integrações personalizadas que transmitem dados ao fornecedor BNPL através dos servidores do comerciante, plataformas de e-commerce que recolhem os dados antes de os reencaminhar para o BNPL, ou sistemas de analítica que registam informação de pagamento. Qualquer um destes cenários pode ampliar o perímetro PCI do comerciante embora o modelo de negócio seja BNPL.
Como a tokenização simplifica o BNPL
Para os comerciantes que oferecem BNPL interno ou white-label, a tokenização é a solução natural para gerir as prestações seguintes de forma conforme. O dado de cartão é recolhido uma vez, é tokenizado, e o token é usado para cobrar cada prestação. O comerciante nunca armazena um PAN em claro, o perímetro PCI reduz-se apenas ao token, e as prestações são processadas através do vault que destokeniza e transmite ao PSP. O modelo é idêntico ao do recurring billing padrão, com o acréscimo da lógica de fracionamento no sistema do comerciante.
Para os comerciantes que usam fornecedores BNPL externos como a Klarna ou a Scalapay, a tokenização continua a ser útil para o canal de cartão tradicional paralelo. Dispor de um único vault que faça a gestão tanto dos tokens do canal de cartão como das possíveis integrações BNPL internas simplifica a arquitetura global e reduz o número de perímetros PCI a gerir. O merchant pci compliance gere-se muito mais facilmente com um único ponto de agregação de dados de cartão.
Perguntas frequentes
Se usar a Klarna ou a Scalapay, continuo a ter obrigações PCI DSS?
Depende de como está construída a integração e de que outros métodos de pagamento aceita. Se a integração BNPL for um "redirect" puro (o consumidor é redirecionado para a plataforma do fornecedor para introduzir os dados de cartão) e não aceitar cartões tradicionais, o seu perímetro PCI é mínimo. Se também aceitar cartões tradicionais ou se a integração fizer com que os dados transitem pelos seus servidores, o perímetro PCI mantém-se ativo.
O fornecedor BNPL cobre totalmente a minha responsabilidade PCI?
O fornecedor BNPL cobre a sua parte da infraestrutura, não a sua. Se a sua integração técnica fizer com que os dados de cartão transitem pelos seus sistemas antes de os enviar ao fornecedor, está em scope PCI para essa parte. Leia com atenção a documentação técnica da integração e verifique como são geridos os dados de cartão no fluxo concreto.
Como funciona a gestão de chargebacks num pagamento BNPL tokenizado?
Num modelo BNPL tokenizado, o chargeback é gerido ao nível da cobrança individual de cada prestação. O token usado em cada prestação é destokenizado pelo vault, a transação é contestada junto do PSP com o PAN original, e o processo de chargeback segue as regras normais da rede de cartões. O vault mantém o registo completo de cada destokenização para sustentar a prova em caso de litígio.
Oferece BNPL interno ou white-label e quer gerir as prestações em conformidade com o PCI DSS sem armazenar 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