Cualquiera que gestione subscription billing o pagos recurrentes con cartão está automáticamente en scope para el PCI DSS. La razón es estructural: para cobrar una cartão en ausencia del titular (pago recurring), el comércio deve conservar una referência a los dados de cartão que permita la autorização futura. Esta referência, quer seja un PAN en claro o un token, determina el perímetro de conformidade. La card-on-file tokenization es la respuesta técnica que permite gerir suscripciones escalables sin construir un vault propietario.
Suscripciones e PCI DSS: por qué estás automáticamente en scope
Una subscrição exige que el comércio conserve una referência a la cartão del cliente para cargarla periódicamente sin una nueva autorização explícita del titular. Esto se define en el PCI DSS como escenario card-on-file: la cartão está "en archivo" en el comércio. Si el comércio conserva el PAN directamente, todos los sistemas que acceden a ese archivo estão en scope. Si el comércio conserva el token de un vault certificado, el scope se reduz a los componentes que envían el token al vault para obter la autorização.
Un error frecuente es pensar que usar un PSP para los pagos recurrentes elimina las obrigações PCI. Si el PSP conserva la cartão e el comércio usa sus propios tokens internos para gerir los pagos, el comércio sigue en scope para la gestão de esos tokens e para el fluxo que los envía al PSP. La reducção efectiva del scope depende de como está estructurada la integração técnica e de qué dados transitan realmente por la infraestrutura del comércio.
Tokenização card-on-file para el subscription billing
Con la card-on-file tokenization de PCI Proxy EU, el fluxo para las suscripciones funciona así: en el momento del primer registro, el cliente introduce los dados de cartão en la payment page hospedada por PCI Proxy EU. El sistema devuelve al comércio un token persistente vinculado a esa cartão. El comércio armazena el token en su propia base de dados junto al perfil del cliente e al plan de subscrição. En los vencimientos posteriores, el comércio envía el token a PCI Proxy EU, que recupera el PAN e lo transmite al PSP para la autorização.
Este enfoque permite al comércio gerir la lógica de billing (cálculo de importes, gestão de periodos, notificaciones de vencimiento, reintentos en caso de fallo) en sus propios sistemas sin tocar nunca el PAN. La base de dados del comércio contiene únicamente tokens, identificadores de cliente e dados del plan: ninguno de estos elementos constituye un dato sensible PCI. La flexibilidade en la lógica de billing se mantiene íntegra porque el token es persistente e pode reutilizarse para un número ilimitado de autorizaciones posteriores.
Qué sigue siendo responsabilidade del comércio con la tokenização
La tokenização no elimina todas las obrigações PCI del comércio. Los componentes que envían el token a PCI Proxy EU para la autorização (servidor aplicativo, job scheduler, sistema de billing) permanecen en scope para la parte conectada a la API del vault. Estos sistemas devem ter controles de acceso apropiados, logs de los accesos a las API, gestão segura de las credenciales API e procedimientos documentados para la rotação de las claves de autenticação. El SAQ aplicable en este escenario es tipicamente el SAQ D para Comerciantes, mas con un número de sistemas en scope muito reducido respecto a una arquitectura sin tokenização.
También la gestão de las cartões caducadas exige un proceso definido: quando una cartão caduca, el comércio deve ter un fluxo para actualizar el token con la nueva cartão del cliente (vía redirect a una nueva payment page) o para activar la cancelação de la subscrição. PCI Proxy EU soporta actualizaciones automáticas de cartões para las redes que las ponen a disposição, reduciendo el churn involuntario sin requerir que el cliente vuelva a introducir manualmente los dados.
Preguntas frecuentes
Puedo usar el token de PCI Proxy EU para reprocesar una subscrição fallida?
Sí, el token es persistente e pode usarse para intentos de cargo posteriores enquanto la cartão subyacente sea válida en el vault. Si un cargo falla por cartão caducada, el token se vuelve inutilizable para nuevas autorizaciones. El comércio deve activar un fluxo de atualização de cartão: PCI Proxy EU soporta el Account Updater para las redes que lo permiten, o el comércio pode enviar al cliente un enlace para actualizar manualmente los dados.
Como gestiono la atualização de los dados de cartão en una subscrição?
El fluxo estándar prevé el envío de una notificação al cliente con un enlace a la payment page de PCI Proxy EU para introducir los nuevos dados de cartão. Una vez completado, el sistema emite un nuevo token que el comércio asocia al perfil del cliente existente. El token antiguo queda invalidado. Este proceso no exige ninguna modificação a la lógica de billing del comércio: apenas se actualiza el ID del token en la base de dados.
El mandato SEPA elimina las obrigações PCI DSS?
Sí, mas apenas si los pagos recurrentes se gerem exclusivamente mediante domiciliação bancaria SEPA (SDD). El mandato SEPA no usa dados de cartão sino IBAN, que no entra en el perímetro PCI DSS. Sin embargo, si la empresa acepta tanto SEPA como cartão de crédito para las suscripciones, los pagos con cartão siguen en scope PCI. Muchas empresas usan los dos instrumentos en paralelo, por lo que el SEPA no elimina las obrigações PCI mas pode reduzir el volumen de transações con cartão en scope.
Suscripciones sin PAN en tu stack: tú gestionas la lógica de billing, nosotros custodiamos los 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