There is a special kind of corporate absurdity that appears only after a company has already been warned by reality. My case began with a WhatsApp message claiming that my credit card had to be verified for a hotel reservation made through Booking.com. It was not one of those lazy scams that collapses under its own spelling. This one had context. It referred to a real booking, used the right emotional pressure and led to an external website dressed up as a reservation process. It did not need my trust. It only needed a few seconds in which I might think: perhaps this is simply how ths travel platforms works now.
That is what makes this category of fraud so dangerous. It feeds on fragments of truth: a hotel name, a booking date, a familiar platform, a threat that something might go wrong unless the customer acts quickly. In my case, the complete booking information was true. Once criminals have enough real information, the scam no longer needs to look brilliant. It only needs to look plausible.
Booking.com has publicly been in this territory before. In April 2026, the company reportedly informed customers that unauthorised third parties had accessed reservation information, including names, email addresses, phone numbers, addresses, booking details and messages exchanged with accommodations, although not financial data. That distinction may matter legally and technically, but it is only half-comforting. A scammer does not necessarily need the credit card number at the start. Reservation data is the instrument used to obtain it. Booking.com reportedly reset affected reservation PINs, which is a rather clear sign that the company understands those PINs are not decorative admin trivia.
This is where the platform’s responsibility begins. Whether the weakness sits inside Booking.com itself, a hotel account, a partner system, a stolen property login or some compromised device in the accommodation chain is not the customer’s first concern. The customer booked through Booking.com. The scam arrived with Booking.com context. The trust being exploited was Booking.com trust. A platform cannot collect commission on the front end and then become a helpless observer when its ecosystem is used to attack its customers.
So I did what customers are always told to do. I did not follow the suspicious link, did not enter credit card details and went through the official Booking.com channels. That should have been the boring part of the story. Instead, it became the more revealing one.
The Booking.com support experience appears built almost entirely around ordinary booking problems: cancellations, date changes, payments, refunds, accommodation questions. That is understandable for a travel platform, until the issue is no longer a travel inconvenience but a security incident connected to a booking. The official “Contact us” page made the problem almost comically visible. It showed the usual reassuring options: “Manage your booking”, “Contact the property”, “Send us a message” and “Call us”. But the two options that sounded most relevant, “Send us a message” and “Call us”, are static text blocks rather than usable contact paths. No visible button, no case form, no obvious way into a security report. The only functional escape route was the “Go to the Help Center” button, which led straight back into the normal booking-support machinery.
That machinery may be useful if the problem is a room category, a refund or a missing breakfast. It is rather less impressive if the problem is criminal misuse of reservation data. What I could not find was a clear, visible way to report phishing, suspected misuse of booking information, a compromised accommodation account or an external website abusing Booking.com reservation context. The system behaved as if every customer problem must eventually be translated into ordinary booking administration. Convenient for process design, perhaps. Disastrous for security.
After too much searching, I eventually managed to send Booking.com a message through the smartphone app. The option existed, but it felt hidden. It was buried behind booking support, under a form that first asked for a confirmation number and PIN code, with a secondary option labelled “Don’t have a booking? Tell us about your issue.” That was the hidden doorway. A customer trying to report a cyber incident had to approach it sideways, as if the platform had designed every problem to fit the administrative shape of a booking. For a company handling millions of reservations, that is poor design. Phishing reports should be collected quickly, cleanly and structurally, not after the customer has completed a small administrative endurance test. One might almost think Booking.com had not recently dealt with a major data breach involving reservation information. Because if that had happened, one might expect cyber abuse to appear somewhere in the customer journey as a category worth acknowledging. Does Booking.com have a CISO? Presumably. Is that person on holiday? Still? And for how long exactly?
In the end, I reported the phishing site myself to Google Safe Browsing and Microsoft Security Intelligence, hoping that browser warnings or security filters might prevent other customers from walking into the same trap. Which is absurd. I am the customer, not Booking.com’s unpaid incident response department. A global travel platform that knows its reservation data is being abused should have a fast internal route for containment: validate the URL, report it to blocklists, warn affected users and coordinate with the accommodation. Instead, the customer gets the privilege of doing damage control while the platform searches for the correct booking-support drawer.
Then came the official response via email. It looked legitimate: Booking.com branding, customer service sender, polite template, reassuring corporate tone. But it was not really a response to my message. It did not acknowledge the reported scam or the suspected misuse of reservation context. It simply dropped me into a standard information request. That would already be poor enough. But the process contradicted itself. I had reached support through a path designed for cases where the customer may not have a booking at all. Booking.com’s answer then demanded precisely the information that, by its own logic, might not exist: confirmation number, email address, accommodation name, check-in and check-out dates, and the reservation PIN.
The PIN is where the story stops being merely annoying and becomes professionally embarrassing. A customer reports a phishing attempt involving real reservation details. The reported scam asks the customer to trust an external channel and verify payment information. Booking.com’s official response then asks the customer to send the confirmation number and reservation PIN by ordinary email. Worse, Booking.com’s own traveller safety page appears to normalise exactly this distinction: reservation ID and PIN may be requested by Customer Service. This is not a minor support flaw. It is security awareness training written backwards.
Of course, the reservation PIN is not a credit card CVV and it is not the password to the Booking.com account. That defence is technically true and practically weak. Together with the confirmation number, the PIN helps identify and access the reservation context. It gives legitimacy to whoever has it, and may allow that person to modify or even cancel the booking. In a phishing case where real reservation details may already be circulating, asking for the remaining access detail by email is exactly the wrong habit to create.
The email added one more small compliance flourish. Below the customer service signature, it displayed a “Privacy Policy” reference that, in this message, appeared not to link anywhere. For a neighbourhood sausage stand, that would be sloppy. For a global travel platform handling names, travel dates, contact details, booking histories and payment context, it is harder to excuse. Corporate compliance is supposed to show up precisely in these dull places: templates, links, escalation paths and the operational details customers actually touch. Booking.com may have privacy policies, safety pages and carefully worded statements somewhere on its website, but if the real customer process reduces them to decorative footer furniture, the lesson from the breach has apparently not travelled very far.
The larger problem is behavioural. Banks, payment providers and every half-serious security awareness campaign teach users that passwords and PINs are personal. Support should not need them, should not know them and should certainly not ask for them through ordinary email. Users are also told to distrust urgency, external links and unexpected verification requests, because those are the basic mechanics of phishing. Then the official platform arrives in a normal email and blurs the line it should be defending. At that point, Booking.com is not merely failing to protect the user. It is teaching the user that dangerous behaviour is official policy.
That is the failure here. Not that scammers exist. They will always follow valuable data and weak processes. The failure is that a major travel platform, after public incidents involving reservation data, still appears to treat customer-facing security reporting as an awkward subcategory of booking support. Payments are streamlined, reservations are polished, upsells are optimised, but when a customer tries to report a cyber incident, the experience suddenly becomes archaeological. Safety pages do not fix that. Security is what happens when the customer actually needs help.
A breach is bad, but the real danger begins when criminals can use real and relevant reservation data to make their scams more convincing. That is precisely why the response after such an incident matters. If a company has already seen this pattern and still asks customers to send two key reservation access details together through ordinary email, this is no longer bad luck. It is operational incompetence. The lesson has not been learned where it matters most: in the process the customer actually touches. Support should reduce uncertainty, create a safe path and help contain the damage. At Booking.com, support still seems to mean support for the booking machine, not for the customer standing in front of it after the trust has already been abused.
But again, what do I know?
//Alex
alexreusch 