El setor de la hostelería es uno de los mais complejos desde el punto de vista del conformidade PCI DSS para hoteles. Un hotel recoge dados de cartão através de múltiples canais: site web, OTA, telefone, walk-in en recepção, fax e incluso correo electrónico. Cada canal tem un perfil de riesgo diferente e con frecuencia el personal de front desk gere manualmente números de cartão en situaciones para las que no existe un procedimiento seguro definido. El resultado es un perímetro PCI extenso, difícil de controlar e con riesgos operativos concretos.
Los canais de recogida de dados de cartão en un hotel: onde se esconden los riesgos
El check-in presencial con TPV certificado es el canal mais controlado. El riesgo se concentra en los demás: reservas telefónicas en las que el personal transcribe manualmente el número de cartão, correos electrónicos con archivos adjuntos que contienen formularios de autorização, faxes con dados de cartão en claro (ainda habituales en algunos segmentos de mercado corporativo), e sistemas de reservas que guardan los dados de cartão en el PMS (Property Management System) sin encriptação adecuado.
El PMS es un punto de riesgo crítico: muchos sistemas extendidos en el setor hotelero almacenaban históricamente dados de cartão en la base de dados sin cumprir los requisitos PCI. La verificação de la configuração 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 tokenização, todo el sistema e los servidores en que se ejecuta forman parte del CDE, con las correspondientes obrigações de segurança de la infraestrutura.
Reservas telefónicas e cartão de garantía: el problema MOTO
Las reservas con cartão de garantía obtenidas por telefone 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 tem acceso directo al número de cartão durante la chamada. El Requisito 3.3 del estándar prohíbe expresamente la grabação de audio de sesiones en las que se transmiten dados de cartão, embora muchos hoteles graben las chamadas con fines de calidade sin verificar el impacto en el conformidade.
La solução 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 dados de cartão de forma autónoma sin que el operador los vea. PCI Proxy EU permite implementar este fluxo: el operador inicia la sesión de pago, el sistema envía un enlace seguro al cliente que introduce los dados directamente en el vault, e el operador recibe únicamente el token de confirmação. El personal nunca ve el PAN.
Como PCI Proxy EU resolve el problema de la hostelería
PCI Proxy EU centraliza la recogida e el armazenamento de los dados de cartão de todos los canais en un único vault certificado. Para el canal online, la payment page hosted recoge los dados directamente sin que transiten por el backend del hotel. Para el canal telefónico, el sistema de enlace de pago elimina la exposição del operador. Para las garantías de cartão conservadas para el no-show, el token reemplaza al PAN en el PMS: el PAN original permanece en el vault e apenas pode 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 infraestrutura del hotel. El PMS que apenas ve tokens ya no está en el ámbito para la parte de armazenamento de dados. Las reservas telefónicas gestionadas mediante enlace seguro quedan fuera del ámbito MOTO crítico. El perímetro a proteger se reduz a unos pocos endpoints API con controles de acceso documentados, gestionables con recursos IT normales sin especialização en segurança de pagos.
Preguntas frecuentes
El hotel deve conservar los dados de cartão para las garantías por no-show?
El hotel a menudo tem un requisito de negocio legítimo para conservar una cartão de garantía hasta el check-out o durante un período predeterminado. El PCI DSS permite el armazenamento del PAN si está protegido con encriptação o tokenização, con una política de retenção documentada. La solução correcta es armazenar el token en el PMS e 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 através de OTA como Booking.com transfieren la responsabilidade PCI?
Depende del modelo. Si la OTA cobra el pago e transfiere al hotel únicamente la comisión neta (modelo de agencia), el hotel no toca dados de cartão e la responsabilidade PCI para esa transação es de la OTA. Si en cambio la OTA transmite los dados de cartão al hotel para el cargo directo, el hotel entra en el ámbito para esa cartão. Muchas OTA utilizan sistemas de pago virtuales (cartão de crédito virtual) para este fin, con implicaciones PCI distintas que devem gestionarse caso por caso.
Un PMS certificado PCI reduz las obrigações del hotel?
Sí, si el PMS está certificado PCI DSS como fornecedor de serviços e el hotel utiliza correctamente las funcionalidades certificadas. El AOC del fornecedor del PMS cubre su propia infraestrutura, mas no automáticamente los sistemas del hotel que se integran con el PMS. El hotel deve verificar que su implementação quede dentro del perímetro cubierto por la certificação del fornecedor, lo que generalmente exige un diálogo directo con el vendedor del PMS e a menudo la participação de un QSA.
Cero riesgo PCI desde la recepção hasta la faturação: un vault para todos los canais. 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