PCI DSS y pasarela cripto sin custodia

Primero los criterios de PCI DSS: qué cuenta como exposición de datos de tarjeta

PCI DSS parte de una pregunta sencilla: ¿el flujo de pago toca datos del titular de la tarjeta? Si la respuesta es no, puede que PCI DSS ni siquiera entre en juego para ese flujo. Si la respuesta es sí, el alcance puede crecer rápido, incluso por una sola llamada a la API o un solo ticket de soporte.

Aquí, la prueba se centra en los datos del titular de la tarjeta. Eso suele significar el número de cuenta principal, a menudo llamado PAN, además de datos de autenticación sensibles relacionados, como el CVV. Un flujo que almacena, transmite o puede afectar la seguridad de esos datos es el tipo de flujo que le importa a PCI DSS.

La custodia de criptomonedas no es el factor decisivo. Una pasarela de pagos cripto sin custodia puede seguir estando cerca de datos de tarjeta dentro de una pila de pago más amplia, y eso cambia la pregunta de inmediato. La expresión “sin custodia” suena concluyente. No lo es; por eso conviene preguntar desde el inicio cuándo aplica PCI DSS a pagos cripto.

Para un comercio, esto importa porque una sola página de pago puede ocultar dos actividades muy distintas. Una factura en cripto quizá nunca vea un número de tarjeta. Un botón de respaldo con tarjeta en la misma página puede cambiar el panorama de cumplimiento en un solo paso.

Comparación lado a lado: pasarela cripto sin custodia vs. manejo de datos de tarjeta

Compare dos flujos. En el primero, un cliente paga en cripto, la pasarela genera una dirección de wallet, espera confirmaciones y envía un webhook firmado cuando llega el pago. En el segundo, el mismo proceso de compra también acepta tarjetas, quizá mediante un formulario incrustado o una redirección a un procesador de tarjetas.

El primer flujo puede quedar fuera del alcance de PCI DSS para esa actividad cripto. El segundo puede llevar al comercio, al operador de la pasarela o a ambos a obligaciones de PCI DSS si algún dato de tarjeta toca sus sistemas. Esa diferencia no es cosmética. Es el punto central.

El checkout híbrido es común, y el checkout híbrido tarjeta y criptomonedas PCI exige revisar todo el entorno. Una tienda puede ofrecer USDC al pagar y, al lado, una opción con tarjeta porque los clientes quieren elegir, o porque finanzas quiere menos pedidos fallidos. En cuanto aparece la vía de tarjeta, la pregunta de PCI debe hacerse para todo el entorno, no solo para el carril cripto.

Un detalle importa más que la marca: ¿dónde entra el número de tarjeta en la pila? Si los datos de tarjeta entran en una página del comercio, un script del navegador, un panel de soporte o un iframe de pago alojado que sigue formando parte del dominio del comercio, el alcance de PCI puede ampliarse. Si nunca entra en esos sistemas, el alcance puede seguir siendo más reducido.

El límite decisivo: solo pago cripto, sin captura de tarjetas

Este es el caso que muchos comercios realmente quieren. La pasarela solo crea una dirección cripto, detecta el pago en blockchain, firma webhooks y marca el pedido como pagado. Sin PAN. Sin CVV. Sin formulario de tarjeta. En esa configuración, una pasarela de pagos cripto sin custodia es una pasarela de pagos cripto sin custodia, sujeta a PCI DSS solo si los datos de tarjeta aparecen en otra parte del flujo.

Esa frase no es una trampa. Es el límite. Si el checkout cripto del comercio nunca recopila datos de tarjeta y la pasarela nunca maneja datos de tarjeta, PCI DSS no aplica a ese flujo cripto por sí solo.

Piense en una tienda de bienes digitales que acepta 0.05 BTC o 120 USDT por un pedido. La pasarela confirma el pago en cadena, se desbloquea el pedido y el cliente nunca escribe un número de tarjeta. PCI DSS no tiene nada que revisar en ese intercambio exacto.

Aun así, conviene mantener honestos los sistemas cercanos. Un comercio puede usar el mismo panel de administración para pedidos cripto y pedidos con tarjeta, y ese panel compartido puede volverse relevante si expone datos del titular de la tarjeta o informes relacionados con tarjetas. Un solo panel puede sostener dos historias de cumplimiento.

Para los comercios que planifican integraciones, la vía más limpia es la separación. Mantenga la ruta de pago cripto aislada de cualquier vía de captura de tarjeta. Si además necesita un procesador de tarjetas, trátelo como un flujo distinto, con sus propios controles y su propia revisión de proveedor. Si quiere un punto de referencia técnico para construir esa parte, la documentación para desarrolladores, API de pasarela de pagos cripto es el lugar para comprobar los objetos de pago y el comportamiento de los webhooks.

El disparador oculto de PCI: checkout alojado, campos de tarjeta incrustados y redirección

El alcance de PCI suele aparecer por la puerta de entrada, no por el libro mayor. Una página de checkout alojada puede recopilar datos de tarjeta. También pueden hacerlo los campos de tarjeta incrustados, las bibliotecas de JavaScript, los widgets de redirección, los servicios de tokenización e incluso las herramientas de chat o soporte que pueden ver lo que el cliente escribe.

Esos detalles importan porque a veces los comercios asumen que “solo redirigimos” significa “estamos fuera del alcance”. Ese razonamiento es arriesgado. Si la redirección sigue pasando datos de tarjeta por su página, su código o sus registros, PCI DSS puede seguir siendo relevante. Si un campo de terceros está incrustado en su sitio, el entorno del navegador aún necesita revisión.

El soporte al cliente es un punto ciego frecuente. Un agente de soporte que pide al cliente que lea de nuevo los datos de la tarjeta por chat, correo electrónico o un formulario de ticket crea exposición fuera de la página de pago. Un solo formulario pasado por alto puede ampliar el alcance. Un solo PAN copiado puede hacer lo mismo.

Los scripts del navegador merecen especial cuidado. Una biblioteca de pagos que se carga en la página puede leer más de lo que el comercio pretendía si no está estrictamente controlada. Por eso los comercios deberían revisar cualquier checkout alojado, iframe o script del lado del cliente antes de asumir que el entorno cripto permanece separado.

Si el sitio también acepta tarjetas en otros productos, una revisión de seguridad debería cubrir ambos flujos juntos. Nuestro artículo sobre mejores prácticas de seguridad para pasarelas de pagos cripto es útil aquí, porque el alcance de PCI suele depender de los mismos hábitos operativos que mantienen limpias las páginas de pago desde el principio.

Comercio vs. operador de la pasarela: ¿de quién es la responsabilidad de PCI?

La responsabilidad de PCI sigue a los datos del titular de la tarjeta, no a las etiquetas de marketing. El comercio que captura la tarjeta, el operador de la pasarela que aloja los campos de tarjeta, el procesador que recibe la transacción y el proveedor de hosting que ejecuta la pila pueden tener cada uno un papel.

Para un checkout puramente cripto, el operador de la pasarela quizá nunca toque datos de tarjeta. En ese caso, las obligaciones de PCI para ese flujo específico pueden no existir. Para un checkout mixto, el papel del operador depende de dónde entra el PAN, quién lo almacena y qué sistemas pueden afectar su seguridad.

Los comercios a menudo preguntan quién debe validar el cumplimiento. La respuesta es: quienquiera que esté dentro del alcance por manejar datos del titular de la tarjeta. Eso puede significar solo el comercio, solo el proveedor de la pasarela o ambos, según la arquitectura y los contratos.

El hosting también forma parte del panorama. Un servidor que almacena registros relacionados con tarjetas o sirve un formulario de pago no es solo “infraestructura”. Puede convertirse en parte del entorno PCI si los datos de tarjeta pueden llegar hasta él. Por eso el operador, el comercio y cualquier procesador deberían mapear el flujo antes de que alguien rellene un cuestionario de cumplimiento.

Para los comercios que ejecutan sitios en WordPress, la arquitectura del checkout merece una revisión aparte. El artículo sobre aceptar pagos cripto en WordPress puede ayudar cuando el sitio necesita lógica de pago cripto sin arrastrar exposición innecesaria a tarjetas dentro de la misma pila de plugins.

Controles operativos que importan si los datos de tarjeta están cerca del flujo

Los entornos mixtos necesitan disciplina. Empiece con segmentación de red para que los sistemas que pueden tocar datos de tarjeta no estén en la misma red plana que todo lo demás. Luego limite el acceso por rol, no por comodidad. Una sola cuenta de administrador no debería verlo todo.

El registro de eventos importa, pero los logs pueden volverse un problema si capturan PAN o CVV por error. Las reglas de desarrollo seguro deberían impedir eso. El enmascaramiento, la redacción y la validación de entradas no son extras agradables; son la diferencia entre un historial limpio y un incidente de cumplimiento.

La gestión de proveedores también cuenta. Si un procesador, un proveedor de iframe, una herramienta de analítica o una plataforma de soporte puede ver datos de tarjeta, el comercio debe saberlo. Los contratos no sustituyen la revisión técnica. Un acuerdo firmado no puede impedir que un script del navegador recoja demasiado.

Mantenga los datos de tarjeta fuera de los sistemas del comercio siempre que sea posible. Ese principio por sí solo reduce la carga de PCI más que casi cualquier otra cosa. Una página de tarjeta alojada que nunca devuelve los números de tarjeta al comercio suele ser más fácil de gobernar que un formulario casero copiado de una plantilla antigua.

Algunos comercios también gestionan facturación SaaS junto con pagos cripto, lo que vuelve más difusas las fronteras del pago. Si ese es su caso, vea pasarela de pagos cripto para SaaS para la parte del modelo de pago, y luego mapee por separado la parte de tarjeta antes del lanzamiento.

Veredicto honesto: cuándo la respuesta es “no”, “quizá” o “sí”

Para una pasarela sin custodia y solo cripto, la respuesta suele ser “no” para ese flujo. Si la pasarela nunca toca datos del titular de la tarjeta, por lo general PCI DSS no es el marco relevante para el checkout cripto en sí. La razón es la separación limpia.

Para una pasarela cercana a un checkout con tarjeta o a datos de tarjeta almacenados, la respuesta pasa a ser “quizá” y a menudo se convierte en “sí” una vez que se inspecciona la arquitectura. El alcance exacto depende de dónde entra el dato de la tarjeta, si se almacena y si algún sistema puede influir en su seguridad. Un solo campo incrustado puede bastar.

Para un operador de pasarela o un comercio que procesa pagos con tarjeta, la respuesta es muy probablemente “sí.” Las obligaciones de PCI DSS probablemente aplican, aunque el mismo negocio también ofrezca pagos cripto. La cripto no cancela el cumplimiento de tarjetas. Simplemente convive junto a él.

Ese reparto importa para la planificación, el personal y la preparación de auditorías. Un equipo puede construir un checkout cripto sin custodia y aun así ser responsable de PCI DSS en otra línea de producto. Dos métodos de pago. Dos revisiones. Una sola empresa.

Tabla rápida de decisión para comercios e integradores

Antes de lanzar, mapee el flujo de pago en cinco pasos: punto de entrada, tipo de dato, punto de almacenamiento, ruta de transmisión y quién puede cambiar el código. Si algún paso incluye datos del titular de la tarjeta, PCI DSS merece una revisión completa. Si no, mantenga el flujo cripto separado y documente esa separación con claridad.

Para equipos que construyen programas con muchos pagos salientes junto con el checkout, el mapa de pagos puede complicarse rápido. El artículo relacionado sobre pagos cripto para programas globales de afiliados es útil para la parte de pagos salientes, porque las operaciones de payout y la aceptación de tarjetas no son el mismo problema de cumplimiento.

Un último punto práctico: haga la misma pregunta a cada plugin, widget y script que se cargue en la página de pago. Tres líneas de JavaScript pueden importar más que treinta líneas de texto de política. Mantenga esa página aburrida. Suele ser el resultado más seguro.