El buy now pay later pci es uno de los ámbitos donde la cadena de responsabilidad PCI DSS es más compleja de mapear. Los modelos BNPL como Klarna, Scalapay, Afterpay y sus competidores europeos involucran a múltiples actores en una sola transacción: el comercio, el proveedor BNPL, la red de tarjetas y en algunos casos también un adquirente separado. Entender quién gestiona los datos de tarjeta y quién responde del cumplimiento PCI DSS en este ecosistema es fundamental para cualquier comercio que ofrezca pagos aplazados.
BNPL y PCI DSS: la cadena de responsabilidad
En los modelos BNPL más extendidos, el proveedor (Klarna, Scalapay, etc.) actúa como financiador: paga al comercio el importe total en el momento de la compra y gestiona la relación crediticia con el consumidor para las cuotas posteriores. El consumidor puede pagar las cuotas con tarjeta de crédito o débito, y en ese caso los datos de tarjeta transitan por la plataforma del proveedor BNPL. El comercio recibe únicamente el saldo del pedido, sin ver los datos de tarjeta del consumidor para las cuotas.
Esto significa que, para el componente BNPL puro, el comercio queda fuera del flujo de datos de tarjeta: el perímetro PCI DSS para esa transacción pertenece al proveedor BNPL, no al comercio. Sin embargo, si el comercio también acepta pagos con tarjeta tradicionales en paralelo (lo que ocurre casi siempre), su perímetro PCI sigue activo para esos flujos. El error habitual es asumir que integrar un BNPL elimina completamente las obligaciones PCI: las reduce solo para las transacciones procesadas a través de ese canal específico.
El comercio BNPL: qué datos de tarjeta toca realmente
Existen variantes del modelo BNPL donde el comercio está más involucrado en los datos de tarjeta. En los modelos "merchant-financed BNPL" o en las soluciones white-label, el comercio puede gestionar directamente el fraccionamiento sin un proveedor BNPL externo. En estos casos, el comercio debe almacenar o tener acceso a los datos de tarjeta para las cuotas posteriores, y el perímetro PCI se expande significativamente. La tokenización card-on-file se vuelve necesaria para gestionar estas cuotas sin exponer los datos de tarjeta en los sistemas del comercio.
Incluso en los modelos BNPL con proveedor externo, existen escenarios donde el comercio toca datos de tarjeta de forma indirecta: integraciones personalizadas que transmiten datos al proveedor BNPL a través de los servidores del comercio, plataformas de e-commerce que recopilan los datos antes de reenviarlos al BNPL, o sistemas de analítica que registran información de pago. Cualquiera de estos escenarios puede ampliar el perímetro PCI del comercio aunque el modelo de negocio sea BNPL.
Cómo la tokenización simplifica el BNPL
Para los comercios que ofrecen BNPL interno o white-label, la tokenización es la solución natural para gestionar las cuotas posteriores de forma conforme. El dato de tarjeta se recopila una vez, se tokeniza, y el token se usa para cargar cada cuota. El comercio nunca almacena un PAN en claro, el perímetro PCI se reduce únicamente al token, y las cuotas se procesan a través del vault que destokeniza y transmite al PSP. El modelo es idéntico al del recurring billing estándar, con la adición de la lógica de fraccionamiento en el sistema del comercio.
Para los comercios que usan proveedores BNPL externos como Klarna o Scalapay, la tokenización sigue siendo útil para el canal de tarjeta tradicional paralelo. Disponer de un único vault que gestione tanto los tokens del canal de tarjeta como las posibles integraciones BNPL internas simplifica la arquitectura global y reduce el número de perímetros PCI a gestionar. El merchant pci compliance se gestiona mucho más fácilmente con un único punto de agregación de datos de tarjeta.
Preguntas frecuentes
Si uso Klarna o Scalapay, ¿sigo teniendo obligaciones PCI DSS?
Depende de cómo esté construida la integración y de qué otros métodos de pago aceptes. Si la integración BNPL es un "redirect" puro (el consumidor es redirigido a la plataforma del proveedor para introducir los datos de tarjeta) y no aceptas tarjetas tradicionales, tu perímetro PCI es mínimo. Si también aceptas tarjetas tradicionales o si la integración hace que los datos transiten por tus servidores, el perímetro PCI sigue activo.
¿El proveedor BNPL cubre completamente mi responsabilidad PCI?
El proveedor BNPL cubre su parte de la infraestructura, no la tuya. Si tu integración técnica hace que los datos de tarjeta transiten por tus sistemas antes de enviarlos al proveedor, estás en scope PCI para esa parte. Lee con atención la documentación técnica de la integración y verifica cómo se gestionan los datos de tarjeta en el flujo concreto.
¿Cómo funciona la gestión de contracargos en un pago BNPL tokenizado?
En un modelo BNPL tokenizado, el contracargo se gestiona a nivel del cargo individual de cada cuota. El token usado para cada cuota es destokenizado por el vault, la transacción se disputa ante el PSP con el PAN original, y el proceso de contracargo sigue las reglas normales de la red de tarjetas. El vault mantiene el registro completo de cada destokenización para respaldar la evidencia en caso de disputa.
¿Ofreces BNPL interno o white-label y quieres gestionar las cuotas de forma conforme con PCI DSS sin almacenar datos de tarjeta? Descubre PCI Proxy EU.