Booking.com: I Paid Twice

A guest pays for a hotel reservation through Booking.com. The next morning they receive a message from the hotel, sent through the Booking.com platform, displaying the correct reservation details, asking them to verify their payment because of a banking issue. They pay again. The link is fraudulent. The hotel never sent the message.

This pattern has a name in the operator community. It is called "I Paid Twice" because that is the subject line of an email a defrauded guest sent the hotel afterwards.

The intrusion occurs at the hotel, not at Booking.com. An infostealer reaches the receptionist's machine through a phishing email impersonating Booking.com support. The credentials are exfiltrated, sold or used directly to access the hotel's partner portal, and from there the attacker speaks to the guest using the platform's authentic messaging channel: a message from the hotel, on the platform they trust, with details only the hotel could know.

The structure of this attack is a chain of delegated trust. The guest trusts the platform, and the platform trusts the hotel partner. The hotel trusts the receptionist's email client; the receptionist trusts a sender who appears to be the platform. Each link is rational in isolation, but the chain itself is unverifiable from any single position inside it.

Platforms that run on partner ecosystems consolidate the trust signal at the platform layer and distribute the security responsibility at the partner layer. This works as a business model. As a security architecture it produces the exact pattern observed here: high trust at the visible end, weakest controls at the operational end, no actor in the middle who can see the whole.

Each link in the chain assumes that someone else is doing the verification. That assumption is sufficient.