El buy now pay later pci es uno de los ámbitos onde la cadena de responsabilidade PCI DSS es mais compleja de mapear. Los modelos BNPL como Klarna, Scalapay, Afterpay e sus competidores europeus involucran a múltiples actores en una sola transação: el comércio, el fornecedor BNPL, la red de cartões e en algunos casos também un adquirente separado. Entender quem gere los dados de cartão e quem responde del conformidade PCI DSS en este ecossistema es fundamental para cualquier comércio que ofrezca pagos aplazados.
BNPL e PCI DSS: la cadena de responsabilidade
En los modelos BNPL mais extendidos, el fornecedor (Klarna, Scalapay, etc.) actúa como financiador: paga al comércio el importe total en el momento de la compra e gere la relação crediticia con el consumidor para las cuotas posteriores. El consumidor pode pagar las cuotas con cartão de crédito o débito, e en ese caso los dados de cartão transitan por la plataforma del fornecedor BNPL. El comércio recibe únicamente el saldo del pedido, sin ver los dados de cartão del consumidor para las cuotas.
Esto significa que, para el componente BNPL puro, el comércio queda fuera del fluxo de dados de cartão: el perímetro PCI DSS para esa transação pertenece al fornecedor BNPL, no al comércio. Sin embargo, si el comércio também acepta pagos con cartão tradicionales en paralelo (lo que ocurre quase sempre), su perímetro PCI sigue activo para esos fluxos. El error habitual es asumir que integrar un BNPL elimina completamente las obrigações PCI: las reduz apenas para las transações procesadas através de ese canal específico.
El comércio BNPL: qué dados de cartão toca realmente
Existen variantes del modelo BNPL onde el comércio está mais involucrado en los dados de cartão. En los modelos "merchant-financed BNPL" o en las soluciones white-label, el comércio pode gerir directamente el fraccionamiento sin un fornecedor BNPL externo. En estos casos, el comércio deve armazenar o ter acceso a los dados de cartão para las cuotas posteriores, e el perímetro PCI se expande significativamente. La tokenização card-on-file se vuelve necesaria para gerir estas cuotas sin exponer los dados de cartão en los sistemas del comércio.
Incluso en los modelos BNPL con fornecedor externo, existen escenarios onde el comércio toca dados de cartão de forma indirecta: integraciones personalizadas que transmiten dados al fornecedor BNPL através de los servidores del comércio, plataformas de e-commerce que recopilan los dados antes de reenviarlos al BNPL, o sistemas de analítica que registran informação de pago. Cualquiera de estos escenarios pode ampliar el perímetro PCI del comércio embora el modelo de negocio sea BNPL.
Como la tokenização simplifica el BNPL
Para los comerciantes que ofrecen BNPL interno o white-label, la tokenização es la solução natural para gerir las cuotas posteriores de forma conforme. El dato de cartão se recopila una vez, se tokeniza, e el token se usa para cobrar cada cuota. El comércio nunca armazena un PAN en claro, el perímetro PCI se reduz únicamente al token, e las cuotas se procesan através del vault que destokeniza e transmite al PSP. El modelo es idéntico al del recurring billing estándar, con la adição de la lógica de fraccionamiento en el sistema del comércio.
Para los comerciantes que usan fornecedores BNPL externos como Klarna o Scalapay, la tokenização sigue siendo útil para el canal de cartão tradicional paralelo. Disponer de un único vault que gestione tanto los tokens del canal de cartão como las posibles integraciones BNPL internas simplifica la arquitectura global e reduz el número de perímetros PCI a gerir. El merchant pci compliance se gere mucho mais fácilmente con un único punto de agregação de dados de cartão.
Preguntas frecuentes
Si uso Klarna o Scalapay, sigo teniendo obrigações PCI DSS?
Depende de como esté construida la integração e de qué otros métodos de pago aceptes. Si la integração BNPL es un "redirect" puro (el consumidor es redirigido a la plataforma del fornecedor para introducir los dados de cartão) e no aceptas cartões tradicionales, tu perímetro PCI es mínimo. Si também aceptas cartões tradicionales o si la integração faz que los dados transiten por tus servidores, el perímetro PCI sigue activo.
El fornecedor BNPL cubre completamente mi responsabilidade PCI?
El fornecedor BNPL cubre su parte de la infraestrutura, no la tuya. Si tu integração técnica faz que los dados de cartão transiten por tus sistemas antes de enviarlos al fornecedor, estás en scope PCI para esa parte. Lee con atenção la documentação técnica de la integração e verifica como se gerem los dados de cartão en el fluxo concreto.
Como funciona la gestão de contracargos en un pago BNPL tokenizado?
En un modelo BNPL tokenizado, el contracargo se gere a nivel del cargo individual de cada cuota. El token usado para cada cuota es destokenizado por el vault, la transação se disputa ante el PSP con el PAN original, e el proceso de contracargo sigue las reglas normales de la red de cartões. El vault mantiene el registro completo de cada destokenização para respaldar la evidencia en caso de disputa.
Ofreces BNPL interno o white-label e quieres gerir las cuotas de forma conforme con PCI DSS sin armazenar dados de cartão? Descubre 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