El sector de la hostelería es uno de los más complejos desde el punto de vista del cumplimiento PCI DSS para hoteles. Un hotel recoge datos de tarjeta a través de múltiples canales: sitio web, OTA, teléfono, walk-in en recepción, fax e incluso correo electrónico. Cada canal tiene un perfil de riesgo diferente y con frecuencia el personal de front desk gestiona manualmente números de tarjeta en situaciones para las que no existe un procedimiento seguro definido. El resultado es un perímetro PCI extenso, difícil de controlar y con riesgos operativos concretos.
Los canales de recogida de datos de tarjeta en un hotel: dónde se esconden los riesgos
El check-in presencial con TPV certificado es el canal más controlado. El riesgo se concentra en los demás: reservas telefónicas en las que el personal transcribe manualmente el número de tarjeta, correos electrónicos con archivos adjuntos que contienen formularios de autorización, faxes con datos de tarjeta en claro (todavía habituales en algunos segmentos de mercado corporativo), y sistemas de reservas que guardan los datos de tarjeta en el PMS (Property Management System) sin cifrado adecuado.
El PMS es un punto de riesgo crítico: muchos sistemas extendidos en el sector hotelero almacenaban históricamente datos de tarjeta en la base de datos sin cumplir los requisitos PCI. La verificación de la configuración del PMS es a menudo lo primero que solicita un QSA a un hotel. Si el PMS no está certificado PCI o no se integra con un sistema de tokenización, todo el sistema y los servidores en que se ejecuta forman parte del CDE, con las correspondientes obligaciones de seguridad de la infraestructura.
Reservas telefónicas y tarjeta de garantía: el problema MOTO
Las reservas con tarjeta de garantía obtenidas por teléfono se encuadran en la categoría MOTO (Mail Order / Telephone Order). Este canal es específicamente considerado de alto riesgo por el PCI DSS porque el personal tiene acceso directo al número de tarjeta durante la llamada. El Requisito 3.3 del estándar prohíbe expresamente la grabación de audio de sesiones en las que se transmiten datos de tarjeta, aunque muchos hoteles graben las llamadas con fines de calidad sin verificar el impacto en el cumplimiento.
La solución técnica para el canal MOTO es el uso de un sistema de IVR seguro o de una página de pago mediante enlace que permite al cliente introducir los datos de tarjeta de forma autónoma sin que el operador los vea. PCI Proxy EU permite implementar este flujo: el operador inicia la sesión de pago, el sistema envía un enlace seguro al cliente que introduce los datos directamente en el vault, y el operador recibe únicamente el token de confirmación. El personal nunca ve el PAN.
Cómo PCI Proxy EU resuelve el problema de la hostelería
PCI Proxy EU centraliza la recogida y el almacenamiento de los datos de tarjeta de todos los canales en un único vault certificado. Para el canal online, la payment page hosted recoge los datos directamente sin que transiten por el backend del hotel. Para el canal telefónico, el sistema de enlace de pago elimina la exposición del operador. Para las garantías de tarjeta conservadas para el no-show, el token reemplaza al PAN en el PMS: el PAN original permanece en el vault y solo puede recuperarse para cargos efectivos.
El resultado es un CDE reducido a los únicos componentes que se comunican con las API del vault, en lugar de a toda la infraestructura del hotel. El PMS que solo ve tokens ya no está en el ámbito para la parte de almacenamiento de datos. Las reservas telefónicas gestionadas mediante enlace seguro quedan fuera del ámbito MOTO crítico. El perímetro a proteger se reduce a unos pocos endpoints API con controles de acceso documentados, gestionables con recursos IT normales sin especialización en seguridad de pagos.
Preguntas frecuentes
¿El hotel debe conservar los datos de tarjeta para las garantías por no-show?
El hotel a menudo tiene un requisito de negocio legítimo para conservar una tarjeta de garantía hasta el check-out o durante un período predeterminado. El PCI DSS permite el almacenamiento del PAN si está protegido con cifrado o tokenización, con una política de retención documentada. La solución correcta es almacenar el token en el PMS y el PAN en el vault certificado. Conservar el PAN en claro o de forma inadecuadamente protegida en el PMS para este fin no es conforme.
¿Las reservas a través de OTA como Booking.com transfieren la responsabilidad PCI?
Depende del modelo. Si la OTA cobra el pago y transfiere al hotel únicamente la comisión neta (modelo de agencia), el hotel no toca datos de tarjeta y la responsabilidad PCI para esa transacción es de la OTA. Si en cambio la OTA transmite los datos de tarjeta al hotel para el cargo directo, el hotel entra en el ámbito para esa tarjeta. Muchas OTA utilizan sistemas de pago virtuales (tarjeta de crédito virtual) para este fin, con implicaciones PCI distintas que deben gestionarse caso por caso.
¿Un PMS certificado PCI reduce las obligaciones del hotel?
Sí, si el PMS está certificado PCI DSS como proveedor de servicios y el hotel utiliza correctamente las funcionalidades certificadas. El AOC del proveedor del PMS cubre su propia infraestructura, pero no automáticamente los sistemas del hotel que se integran con el PMS. El hotel debe verificar que su implementación quede dentro del perímetro cubierto por la certificación del proveedor, lo que generalmente requiere un diálogo directo con el vendedor del PMS y a menudo la participación de un QSA.
Cero riesgo PCI desde la recepción hasta la facturación: un vault para todos los canales. Descubre PCI Proxy EU.