Cualquiera que gestione subscription billing o pagos recurrentes con tarjeta está automáticamente en scope para el PCI DSS. La razón es estructural: para cargar una tarjeta en ausencia del titular (pago recurring), el comercio debe conservar una referencia a los datos de tarjeta que permita la autorización futura. Esta referencia, ya sea un PAN en claro o un token, determina el perímetro de cumplimiento. La card-on-file tokenization es la respuesta técnica que permite gestionar suscripciones escalables sin construir un vault propietario.
Suscripciones y PCI DSS: por qué estás automáticamente en scope
Una suscripción requiere que el comercio conserve una referencia a la tarjeta del cliente para cargarla periódicamente sin una nueva autorización explícita del titular. Esto se define en el PCI DSS como escenario card-on-file: la tarjeta está "en archivo" en el comercio. Si el comercio conserva el PAN directamente, todos los sistemas que acceden a ese archivo están en scope. Si el comercio conserva el token de un vault certificado, el scope se reduce a los componentes que envían el token al vault para obtener la autorización.
Un error frecuente es pensar que usar un PSP para los pagos recurrentes elimina las obligaciones PCI. Si el PSP conserva la tarjeta y el comercio usa sus propios tokens internos para gestionar los pagos, el comercio sigue en scope para la gestión de esos tokens y para el flujo que los envía al PSP. La reducción efectiva del scope depende de cómo está estructurada la integración técnica y de qué datos transitan realmente por la infraestructura del comercio.
Tokenización card-on-file para el subscription billing
Con la card-on-file tokenization de PCI Proxy EU, el flujo para las suscripciones funciona así: en el momento del primer registro, el cliente introduce los datos de tarjeta en la payment page hospedada por PCI Proxy EU. El sistema devuelve al comercio un token persistente vinculado a esa tarjeta. El comercio almacena el token en su propia base de datos junto al perfil del cliente y al plan de suscripción. En los vencimientos posteriores, el comercio envía el token a PCI Proxy EU, que recupera el PAN y lo transmite al PSP para la autorización.
Este enfoque permite al comercio gestionar la lógica de billing (cálculo de importes, gestión de periodos, notificaciones de vencimiento, reintentos en caso de fallo) en sus propios sistemas sin tocar nunca el PAN. La base de datos del comercio contiene únicamente tokens, identificadores de cliente y datos del plan: ninguno de estos elementos constituye un dato sensible PCI. La flexibilidad en la lógica de billing se mantiene íntegra porque el token es persistente y puede reutilizarse para un número ilimitado de autorizaciones posteriores.
Qué sigue siendo responsabilidad del comercio con la tokenización
La tokenización no elimina todas las obligaciones PCI del comercio. Los componentes que envían el token a PCI Proxy EU para la autorización (servidor aplicativo, job scheduler, sistema de billing) permanecen en scope para la parte conectada a la API del vault. Estos sistemas deben tener controles de acceso apropiados, logs de los accesos a las API, gestión segura de las credenciales API y procedimientos documentados para la rotación de las claves de autenticación. El SAQ aplicable en este escenario es típicamente el SAQ D para Comercios, pero con un número de sistemas en scope muy reducido respecto a una arquitectura sin tokenización.
También la gestión de las tarjetas caducadas requiere un proceso definido: cuando una tarjeta caduca, el comercio debe tener un flujo para actualizar el token con la nueva tarjeta del cliente (vía redirect a una nueva payment page) o para activar la cancelación de la suscripción. PCI Proxy EU soporta actualizaciones automáticas de tarjetas para las redes que las ponen a disposición, reduciendo el churn involuntario sin requerir que el cliente vuelva a introducir manualmente los datos.
Preguntas frecuentes
¿Puedo usar el token de PCI Proxy EU para reprocesar una suscripción fallida?
Sí, el token es persistente y puede usarse para intentos de cargo posteriores mientras la tarjeta subyacente sea válida en el vault. Si un cargo falla por tarjeta caducada, el token se vuelve inutilizable para nuevas autorizaciones. El comercio debe activar un flujo de actualización de tarjeta: PCI Proxy EU soporta el Account Updater para las redes que lo permiten, o el comercio puede enviar al cliente un enlace para actualizar manualmente los datos.
¿Cómo gestiono la actualización de los datos de tarjeta en una suscripción?
El flujo estándar prevé el envío de una notificación al cliente con un enlace a la payment page de PCI Proxy EU para introducir los nuevos datos de tarjeta. Una vez completado, el sistema emite un nuevo token que el comercio asocia al perfil del cliente existente. El token antiguo queda invalidado. Este proceso no requiere ninguna modificación a la lógica de billing del comercio: solo se actualiza el ID del token en la base de datos.
¿El mandato SEPA elimina las obligaciones PCI DSS?
Sí, pero solo si los pagos recurrentes se gestionan exclusivamente mediante domiciliación bancaria SEPA (SDD). El mandato SEPA no usa datos de tarjeta sino IBAN, que no entra en el perímetro PCI DSS. Sin embargo, si la empresa acepta tanto SEPA como tarjeta de crédito para las suscripciones, los pagos con tarjeta siguen en scope PCI. Muchas empresas usan los dos instrumentos en paralelo, por lo que el SEPA no elimina las obligaciones PCI pero puede reducir el volumen de transacciones con tarjeta en scope.
Suscripciones sin PAN en tu stack: tú gestionas la lógica de billing, nosotros custodiamos los datos de tarjeta. Descubre PCI Proxy EU.