Travel Booking Fraud: Device Signals for Flights and Hotels

Travel is a strange place to fight fraud. The product is expensive, delivered instantly, and often consumed within hours. A stolen card used to book a flight leaving tonight has turned into a boarding pass before the cardholder notices. At the same time, the honest customers look unusual by design: they’re abroad, on hotel Wi-Fi, using a VPN, paying with a card from home, booking at the last minute because their plans changed.

Rules built for domestic ecommerce decline those customers. Rules loose enough to let them through let fraud through too. Device signals are how you get out of that bind.

The main patterns

Last-minute bookings on stolen cards

The classic. A fraudster with card details books a ticket or a room close to the travel date, often for someone else who pays them a discounted price in cash. The short lead time is the point: by the time a chargeback arrives, the trip has happened. Stolen card detection at checkout covers the card side; in travel, the device side is often the stronger signal, because one fraudster books for many travelers from the same machine.

Loyalty account takeover

Miles and hotel points are spendable currency, and members often check their balances rarely. An attacker logs in with stuffed or phished credentials, redeems points for a ticket or gift cards, or transfers them out. The member notices weeks later. Loyalty points account takeover goes deep on this.

Seat spinning and inventory holds

Bots start bookings that hold seats or rooms, let the hold expire, and start again. The reasons vary: blocking competitors, holding inventory for resale, or nudging availability to move prices. It’s the travel version of denial-of-inventory bots, and it shows up as many bookings started and very few finished from a small number of devices.

Fare and availability scraping

Aggressive scraping of fares and availability loads your search systems and feeds competitors or resellers. Not fraud exactly, but it competes with real customers for capacity.

Why strict geolocation rules fail

Many fraud rulebooks lean on location. “Decline if the IP country differs from the card country.” “Challenge VPNs.” In travel, these misfire constantly:

• A traveler books a hotel in Lisbon from an airport in Bogotá with a card issued in Toronto. Three countries, all legitimate.
• Business travelers connect through corporate VPNs that exit in another country.
• Hotel and airport Wi-Fi often routes through providers that look like datacenters.
• Travelers book for family members whose names don’t match the cardholder.

You can’t hold location to a domestic standard. You can still use it as context, alongside signals that don’t depend on where the traveler happens to be.

Device signals that travel well

The device a person books from is far more stable than their location. A real traveler uses the same phone or laptop at home and abroad. A fraudster booking for a stream of buyers uses the same machine for all of them.

With Prynt, identify on search, checkout and login, and fetch the event server-side before you confirm anything:

const event = await prynt.getEvent(requestId);   // @prynt/node
const ss = event.smartSignals;

const signals = {
  decision: event.decision,                        // allow | challenge | block
  accountsOnDevice: event.accountsOnDevice.count,  // your accounts seen on this device
  automation: ss.bot?.result || ss.tlsFingerprint?.result,
  anonymized: ss.vpn?.result || ss.proxy?.result || ss.residentialProxy?.result,
  tampering: ss.tampering?.result,
};

Some signals that work well in travel:

• Repeat device across many bookings and names. One device booking for many different passengers in a short period, with different cards, is the most reliable fraud tell in travel. Store visitorId on every booking and count.
• Device new to the account. For a logged-in member, compare the device with the account’s history. The deviceSpread signal flags an account seen on more than five devices in 24 hours.
• Impossible travel, applied carefully. impossibleTravel flags a device appearing in more than one country within an hour. For travelers that can happen across a border crossing, so treat it as a reason to step up, not to decline.
• Automation and tampering. Seat spinners and scrapers show up as headless browsers, automation frameworks and non-browser TLS fingerprints, wherever they connect from.
• Location spoofing, where the browser’s reported timezone and language disagree with the network in ways that suggest hiding rather than traveling. Timezone and locale mismatch explains the difference.

Putting it together

A layered policy for a booking flow might look like this:

Situation	Response
Known device for the member, nothing else unusual	Book, even from abroad or on a VPN
New device for the member, clean environment	Book; send a confirmation to the account’s email
New device, redeeming points or changing contact details	Step up: one-time code to the registered email or phone
Device has booked for many passengers on different cards this week	Hold for review, especially for departures within 48 hours
Automation or tampering on booking starts	Challenge with prynt.challenge() or block
Prynt decision is block	Decline

The first row is the point. A member on their usual phone should be able to book from anywhere without friction. Location only becomes decisive when the device is also unfamiliar.

Short lead times deserve their own rules

The most expensive fraud is close to departure. It’s reasonable to apply a stricter policy to bookings for travel in the next day or two, such as review for any new device with a new card, while keeping the default policy loose for bookings weeks out, when you have time to catch problems before the trip.

Report what happens

Chargebacks in travel arrive after the trip. When they do, report them so the device is recognized next time: POST /v1/outcomes with the label chargeback and the booking’s requestId. The next booking from that device carries the KNOWN_ABUSER reason code. If the fraudster was on a shared hotel or airport network, label by visitorId rather than requestId so you don’t flag the network’s IP for everyone else.

For the account side, the account takeover page covers login protection; for a traveling audience, treat VPN and proxy signals as context rather than a verdict. Start by storing visitorId on every booking; the first time you group last month’s chargebacks by device, you’ll see how few machines were behind them.