O setor da hotelaria é um dos mais complexos do ponto de vista da conformidade PCI DSS para hotéis. Um hotel recolhe dados de cartão através de múltiplos canais: site web, OTA, telefone, walk-in na receção, fax e até correio eletrónico. Cada canal tem um perfil de risco diferente e frequentemente o pessoal de front desk gere manualmente números de cartão em situações para as quais não existe um procedimento seguro definido. O resultado é um perímetro PCI extenso, difícil de controlar e com riscos operacionais concretos.
Os canais de recolha de dados de cartão num hotel: onde se escondem os riscos
O check-in presencial com TPV certificado é o canal mais controlado. O risco concentra-se nos restantes: reservas telefónicas em que o pessoal transcreve manualmente o número de cartão, emails com ficheiros anexos que contêm formulários de autorização, faxes com dados de cartão em claro (ainda habituais em alguns segmentos de mercado corporativo), e sistemas de reservas que guardam os dados de cartão no PMS (Property Management System) sem encriptação adequada.
O PMS é um ponto de risco crítico: muitos sistemas disseminados no setor hoteleiro armazenavam historicamente dados de cartão na base de dados sem cumprir os requisitos PCI. A verificação da configuração do PMS é muitas vezes a primeira coisa que um QSA solicita a um hotel. Se o PMS não estiver certificado PCI ou não se integrar com um sistema de tokenização, todo o sistema e os servidores em que é executado fazem parte do CDE, com as correspondentes obrigações de segurança da infraestrutura.
Reservas telefónicas e cartão de garantia: o problema MOTO
As reservas com cartão de garantia obtidas por telefone enquadram-se na categoria MOTO (Mail Order / Telephone Order). Este canal é especificamente considerado de alto risco pelo PCI DSS porque o pessoal tem acesso direto ao número de cartão durante a chamada. O Requisito 3.3 da norma proíbe expressamente a gravação de áudio de sessões em que se transmitem dados de cartão, embora muitos hotéis gravem as chamadas para fins de qualidade sem verificar o impacto na conformidade.
A solução técnica para o canal MOTO é a utilização de um sistema de IVR seguro ou de uma página de pagamento mediante ligação que permite ao cliente introduzir os dados de cartão de forma autónoma sem que o operador os veja. A PCI Proxy EU permite implementar este fluxo: o operador inicia a sessão de pagamento, o sistema envia uma ligação segura ao cliente que introduz os dados diretamente no vault, e o operador recebe apenas o token de confirmação. O pessoal nunca vê o PAN.
Como a PCI Proxy EU resolve o problema da hotelaria
A PCI Proxy EU centraliza a recolha e o armazenamento dos dados de cartão de todos os canais num único vault certificado. Para o canal online, a payment page hosted recolhe os dados diretamente sem que transitem pelo backend do hotel. Para o canal telefónico, o sistema de ligação de pagamento elimina a exposição do operador. Para as garantias de cartão conservadas para o no-show, o token substitui o PAN no PMS: o PAN original permanece no vault e apenas pode ser recuperado para cobranças efetivas.
O resultado é um CDE reduzido aos únicos componentes que comunicam com as API do vault, em vez de toda a infraestrutura do hotel. O PMS que apenas vê tokens já não está no âmbito para a componente de armazenamento de dados. As reservas telefónicas geridas mediante ligação segura ficam fora do âmbito MOTO crítico. O perímetro a proteger reduz-se a alguns endpoints API com controlos de acesso documentados, geríveis com recursos de TI normais sem especialização em segurança de pagamentos.
Perguntas frequentes
O hotel deve conservar os dados de cartão para as garantias por no-show?
O hotel tem frequentemente um requisito de negócio legítimo para conservar um cartão de garantia até ao check-out ou durante um período predeterminado. O PCI DSS permite o armazenamento do PAN se estiver protegido com encriptação ou tokenização, com uma política de retenção documentada. A solução correta é armazenar o token no PMS e o PAN no vault certificado. Conservar o PAN em claro ou de forma inadequadamente protegida no PMS para este fim não é conforme.
As reservas através de OTA como a Booking.com transferem a responsabilidade PCI?
Depende do modelo. Se a OTA cobra o pagamento e transfere ao hotel apenas a comissão líquida (modelo de agência), o hotel não toca dados de cartão e a responsabilidade PCI para essa transação é da OTA. Se, pelo contrário, a OTA transmite os dados de cartão ao hotel para a cobrança direta, o hotel entra no âmbito para esse cartão. Muitas OTA utilizam sistemas de pagamento virtuais (cartão de crédito virtual) para este fim, com implicações PCI distintas que devem ser geridas caso a caso.
Um PMS certificado PCI reduz as obrigações do hotel?
Sim, se o PMS estiver certificado PCI DSS como fornecedor de serviços e o hotel utilizar corretamente as funcionalidades certificadas. O AOC do fornecedor do PMS cobre a sua própria infraestrutura, mas não automaticamente os sistemas do hotel que se integram com o PMS. O hotel deve verificar que a sua implementação fique dentro do perímetro coberto pela certificação do fornecedor, o que geralmente exige um diálogo direto com o fornecedor do PMS e muitas vezes a participação de um QSA.
Zero risco PCI desde a receção até à faturação: um vault para todos os canais. Descubra a 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