Si desarrolla su propia herramienta que interactúa con los pagos, ¿quién asume el riesgo de cumplimiento?

Usted. No la IA que generó el código, no su proveedor de hosting y no su proveedor de pagos. En el momento en que una herramienta que usted desarrolló interactúa con los pagos, el riesgo de cumplimiento recae sobre su empresa, y permanece allí sin importar cuántos proveedores que cumplan con la normativa conecte. Lo que sí puede cambiar es la magnitud de ese riesgo, y la diferencia entre una herramienta personalizada bien diseñada y una descuidada es enorme.

¿Por qué el riesgo recae sobre usted y no sobre sus proveedores?

La aceptación de tarjetas funciona mediante una cadena de contratos. Las redes de tarjetas establecen las reglas, su adquirente (el banco que liquida las ventas con tarjeta por usted) las hace cumplir y su acuerdo de comercio se las transmite a usted. El reglamento es PCI DSS, el estándar de seguridad de datos de la industria de tarjetas de pago, y se aplica a cualquier empresa que almacene, procese o transmita datos de titulares de tarjetas (números de tarjeta y los detalles asociados). La versión actual es la 4.0.1. (Los números de versión y los detalles del programa son precisos a la fecha de publicación; considere los detalles específicos como una instantánea).

Sus proveedores tienen obligaciones respecto a sus propios sistemas, y un proveedor de pagos que cumpla con la normativa reduce drásticamente su parte del trabajo. Pero nada de lo que haga un proveedor transfiere la responsabilidad. El PCI Security Standards Council es explícito al señalar que la decisión de si debe validar el cumplimiento corresponde a las marcas de tarjetas y a su adquirente, y su respuesta, estipulada en su acuerdo de comercio, es afirmativa. Cada año, alguien de su empresa firma una certificación que declara que su entorno cumple con el estándar. Esa firma es suya, no de su proveedor.

¿Qué cambia en el momento en que su propio código interactúa con los datos de la tarjeta?

El alcance. El esfuerzo de cumplimiento se mide en función del alcance: cada sistema que interactúa con los datos de los titulares de tarjetas, además de todo lo que esté conectado a él, entra dentro del estándar.

Un comercio cuyos pagos son gestionados en su totalidad por un proveedor que cumple con la normativa y sus dispositivos certificados realiza la validación mediante un breve cuestionario de autoevaluación (una lista de verificación anual) de unas pocas decenas de preguntas. Un comercio cuyo propio software gestiona números de tarjeta entra en el nivel más estricto, que refleja la mayor parte del estándar completo: más de doscientos requisitos que abarcan análisis de vulnerabilidades trimestrales, pruebas de penetración, controles de acceso, registro de actividad y políticas de seguridad formales¹.

¿Ese formulario de checkout que una IA le escribió en una tarde? Si acepta números de tarjeta, su servidor web, su base de datos, su laptop de administración y el Wi-Fi de su tienda son candidatos a entrar en el alcance. Y, de todos modos, no puede limitarse a presentar el cuestionario corto de forma discreta. Elegir un nivel para el que no es elegible no reduce su riesgo; significa que el documento que firmó es incorrecto, lo cual suele salir a la luz en el peor momento posible, justo después de una brecha de seguridad.

¿Cuánto cuesta realmente equivocarse?

La aplicación de las normas es contractual, por lo que suele aparecer en su estado de cuenta de procesamiento. Muchos procesadores facturan una tarifa recurrente por incumplimiento cada mes hasta que realice la validación. Después de una brecha de seguridad, los costos se acumulan: una investigación forense obligatoria que usted debe pagar, costos de reemisión de tarjetas y sanciones crecientes transmitidas a través de su adquirente, que suelen situarse en un rango de entre 5,000 y 100,000 USD al mes (según los baremos de sanciones publicados por los asesores de cumplimiento de PCI). En casos graves, una empresa puede perder por completo la capacidad de aceptar tarjetas.

Para un pequeño comercio, el costo más pesado es más silencioso que cualquier multa: gestionar un programa de seguridad real requiere un tiempo que usted planeaba dedicar a dirigir su negocio.

¿Cómo crear herramientas personalizadas sin asumir el alcance de los datos de las tarjetas?

Mantenga su código fuera de la ruta de la tarjeta. Su herramienta personalizada debe coordinar la venta: crear el carrito, aplicar descuentos, calcular el total del pedido y enviar el importe a cobrar. La tarjeta en sí solo debe entrar en contacto con un terminal certificado (hardware de pago validado para gestionar tarjetas) o con la página de pago alojada de su proveedor, cualquiera de los cuales la transmite directamente a un procesador de pagos (la empresa que mueve el dinero). Su herramienta recibe de vuelta un resultado, aprobado o rechazado, además de un token (un número de referencia que no sirve de nada a quien intente robarlo).

Esta división es todo el argumento a favor de la arquitectura POS headless: pantallas personalizadas en la parte superior, infraestructura de pago certificada por debajo. También es la razón por la que los checkouts generados por IA se ven de maravilla en las demostraciones pero se estancan en producción, y por la que un formulario web es la respuesta incorrecta para el débito con tarjeta presente como Interac: los pagos en persona corresponden a hardware certificado, tanto técnica como contractualmente.

Final está diseñado en torno a este límite exacto. Los flujos que usted cree, ya sea que los diseñe mediante instrucciones propias o que conecte su propia IA a través de MCP, controlan las pantallas, los carritos y los catálogos. Los datos de las tarjetas van desde el hardware del terminal certificado hasta un procesador de pagos a través de Final Pay, y nunca entran en el flujo que usted creó. Personalizado donde lo personalizado es seguro, estandarizado donde reside la responsabilidad.

Entonces, ¿quién asume el riesgo de cumplimiento?

Usted, y siempre será así. La verdadera decisión es cuánto alcance asume, y esa es una elección de arquitectura, no de papeleo. Antes de lanzar una herramienta que interactúe con los pagos, hágase una pregunta: ¿puede mi código llegar a ver un número de tarjeta? Si la respuesta es afirmativa, el programa de cumplimiento es responsabilidad suya. Si es negativa, conserva la flexibilidad de un desarrollo personalizado con una fracción de la carga de trabajo. Si está evaluando ese tipo de desarrollo ahora, comience con las señales de que ha superado la capacidad de su POS estándar.