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”, appeared to be 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 email. It looked legitimate: Booking.com branding, customer service sender, polite template, reassuring corporate tone. It asked me to reply with additional details: 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. It may help someone discuss the booking with support or the accommodation. 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. Users are constantly told not to send PINs, codes, passwords, payment details or access information through insecure channels. They are told to distrust urgency, external links and unexpected verification requests. Then the official platform arrives, in a normal email, and asks for a booking PIN. At that point, the company is not merely failing to protect the user. It is teaching the user that dangerous behaviour is sometimes official policy.
This is why the lack of a proper cyber reporting path matters. A mature process would not push a phishing report through the same funnel as a refund request. It would offer a visible security option inside the logged-in app and website. It would allow customers to submit suspicious links, WhatsApp numbers, screenshots and booking references without sending sensitive booking credentials by email. It would create a secure case inside the account, confirm whether the accommodation actually sent the message, explain whether the booking remains valid and escalate the matter to the relevant property or partner security team. None of that is exotic. It is basic platform hygiene.
Instead, the customer gets a support labyrinth followed by a template that normalises the very behaviour phishing relies on. That is the strange elegance of this failure. The scammer tries to make the customer trust an unofficial channel. The official company then demonstrates that unofficial-looking behaviour may indeed be part of the official process.
The obvious defence is that Booking.com has safety pages, warnings and advice. Fine. Many large companies have those. They are usually written in careful language, decorated with cheerful icons and placed somewhere between comfort and legal insulation. But security is not a page full of advice. Security is what happens when the customer actually needs help and the process either protects the customer or quietly hands the attacker a better script.
That is the real failure here. Not the existence of scammers, because criminals will always follow valuable data and weak habits. The failure is that a major travel platform, after public incidents involving reservation data, still appears to treat customer-facing security reporting as an inconvenient 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.
A breach is bad. A phishing campaign using real booking data is worse. But a company that has already seen this pattern and still asks customers to send booking PINs by email has moved beyond bad luck. It has entered the more interesting territory of institutional cluelessness.
The scammers are the criminals. That part is clear. But Booking.com should still ask itself an uncomfortable question: why does its official support process sometimes feel as if it was designed to make their work easier?
But again, what do I know?
//Alex
alexreusch 