OTA Chargebacks: Who Responds When the Hotel, Booking Platform and Cardholder Differ?

OTA chargebacks are card disputes on bookings made through an online travel agency, like Booking.com or Expedia. The business that took the payment answers the case. The hotel often holds the key records.

This guide builds on our travel chargeback playbook and merchant of record guide. It shows how to trace the payments behind one booking.

OTA Chargebacks Start With the Notice Recipient

Start with the case notice. Note the merchant account, payment ID, amount, currency and date. Find out what that payment bought and who collected it. Then link it to the booking, the hotel and the stay dates.

A guest may complain to both the hotel and the OTA. Yet only one payment may be in dispute. A virtual card charge between the OTA and the hotel can also be disputed on its own. So the business that gets the complaint may not own the formal case.

Name two owners. The case owner answers the dispute in the merchant account that got the notice. The evidence owner is the hotel or supplier that can confirm the facts. A request to “deal with the chargeback” is not enough. Both sides need to know the charge, the deadline and who supplies which proof.

Who Is the Merchant of Record in an OTA Chargeback?

The merchant of record is the business whose merchant account processed the card charge. That business gets the chargeback and must answer it. In an OTA booking, it can be the OTA, the hotel, or each one for a different part of the trip.

Card scheme guidance points to the OTA when it takes the full payment. A UK Financial Ombudsman Service decision quotes card scheme guidance from May 2020. The scheme said it would view the OTA “as the merchant of record, and an agent of the travel supplier.”

That view held no matter what terms the cardholder saw. By taking payment for the full service, the OTA takes on chargeback risk if the service is not provided. The decision names the scheme only as “M”. Treat it as one scheme’s view, and check your own network rules.

For the hotel, the point is simple. If the OTA collected the guest’s money, the OTA usually owns the guest’s dispute. The hotel still has to supply stay records when asked. If the hotel charged the guest’s card itself, the hotel owns that case.

Map the Actual Collection Model

One OTA can use more than one payment model. Check the booking, the payment record and your agreement. Do not judge the model from the logo on the confirmation email.

This table shows how to investigate. It does not set contract liability. Confirm each setup on its own. Virtual cards are also used in corporate travel and other settings. A virtual card alone does not tell you the deal behind it.

Booking.com’s Connectivity Payments API documentation shows why scope matters. The API serves set Payments by Booking.com setups. It keeps payment and payout data apart from booking records. Do not assume it covers every pay-at-property booking. API access also does not decide who is liable for a dispute.

How Booking.com and Expedia Collect Payment

Booking.com and Expedia both offer a model where the OTA collects and a model where the hotel collects. The model decides whose charge the guest sees.

A guest’s bank statement shows the charge from whoever collected. So a Booking.com chargeback or an Expedia chargeback filed by a guest usually starts with the OTA when the OTA collected. The hotel’s VCC charge is a separate payment between the hotel and the OTA. On Booking.com, the VCC cardholder name is always “(Agent)”, not the guest.

Booking.com Virtual Card Rules That Affect Disputes

VCC timing matters when a guest disputes early. Booking.com’s virtual credit card guide sets when you can charge and for how long.

Charge only the rate the guest paid. Some fees, like city tax, may not be on the card. Collect those from the guest and keep that receipt apart. If you waive a fee after you charge the VCC, refund the same card. A charge on the wrong card makes the payment trail harder to explain.

Separate the Guest and Supplier Payment Chains

Make one row for each payment: guest charge, supplier charge, OTA fee, refund and settlement change. Keep the processor or payout reference and the business on each side. Link rows through the booking, but keep each one separate.

Hypothetical example. An agency collects $1,200 from the guest for a package. It pays the hotel $850 with a virtual card. After a canceled stay, the guest disputes the agency’s $1,200 charge. The hotel’s $850 VCC record may help the agency recover from the hotel. But it is not the same payment as the guest’s charge.

The agency’s response must cover what the guest bought and any remedy. A hotel refund to the agency does not prove the guest got a refund. And a guest refund does not prove the hotel settlement was fixed.

Do not add $1,200 and $850 and call $2,050 “guest chargeback exposure.” They are two legs of one simple example. Report each business’s real payments and duties. Do not merge overlapping flows into one headline loss.

Request the Supplier Facts the Claim Needs

Read the claim before you ask the hotel for evidence. Match the request to the dispute type:

• Cancellation: the booking terms and messages.
• Room quality: the room sold, its real condition and the hotel’s response.
• Unauthorized payment: a review of that payment.

A full folio can be useful background. But it may not answer the main question.

Ask for facts the hotel can verify: stay dates, room type booked, changes, what services were open, arrival and departure, complaints and remedies given. Note the source and time zone. Separate the date an event happened from the date staff logged a later note.

Use this request in your approved supplier channel. Fill in the real case details. Do not send unrelated guest data or payment credentials.

Supplier evidence request

Booking and stay: booking reference, hotel and affected dates.

Disputed payment: who collected it, amount, currency and a safe payment reference.

Guest claim: a short, accurate summary of the issue.

Records needed: the booking, service, message or remedy records that test that claim.

Context: source time stamps, the booking version that applied, known changes and any facts that cut the other way.

Handoff: named hotel contact, secure return channel and internal due date. The formal processor deadline stays with the case owner.

Keep the request in the case history. If the hotel cannot find a record, write that down. Do not fill the gap with a claim you cannot support. Chargeflow’s evidence source map gives a similar structure for internal data owners.

Check That an OTA Chargeback Request Is Real

Hotels sometimes get emails that claim to come from an OTA chargeback analyst. Some are real and some are phishing. Booking.com warns its partners that scammers copy its emails to steal usernames and passwords. Guest card data is a prime target.

Answer only through the OTA extranet or a contact you already trust. Never send guest card numbers or logins by email.

Handle Cancellations Across the Booking Channels

A guest may cancel through the OTA while the hotel’s system updates later. Keep the guest’s message, the OTA’s reply, the channel event and the hotel update as separate records. The last system status may not show what the guest was told at the time.

If the hotel canceled, record the affected service and the alternative or remedy offered. If the guest canceled, keep the booking’s terms and any exception you accepted. Do not call every unused OTA booking a no-show. Why the stay did not happen matters.

Use the hotel no-show guide for arrival and cancellation evidence. Use the hotel deposit guide when funds were collected before arrival. Both need a precise link to the payment, not just a generic OTA booking record.

Trace Refunds in Both Directions

Keep two ledgers: one for supplier remedies and one for guest remedies. Each should show the original payment, the approved amount, the instruction sent, its status and a reference. An instruction to refund does not prove the money moved.

For VCC setups, Booking.com’s payment and payout details documentation shows payout and virtual card data for each booking, where supported. Use the data and case notes you actually have. A payout status does not prove the guest’s card was refunded.

Under Payments by Booking.com, timing changes where a guest refund comes from. The Payments by Booking.com FAQs set out three cases.

The payout change is the supplier leg. The guest refund is a separate event with its own reference. Keep each in its own ledger.

Hypothetical continuation. The hotel returns $850 through the supplier payment route. The agency approves a $1,200 guest refund, but the refund fails. The supplier leg is done, while the guest remedy is still open. The agency’s response should not use the supplier credit as proof that the guest got $1,200.

If the guest payment is already in a formal dispute, the case and refund owners must agree on the next step. A separate refund made without checking the case can pay the guest twice. Let the processor workflow control the money decision.

Submit a Case the Reviewer Can Follow

The cover letter should name the disputed charge. It should explain the payment model in plain words. Do not make the reviewer piece together how the OTA, hotel, guest and virtual card issuer relate.

Use an exhibit index:

• The original sale.
• The booking terms.
• The hotel’s service facts.
• Guest messages.
• Completed remedies.

Say which payment each financial record belongs to. Never give a guest charge and a supplier settlement the same vague “payment refunded” label.

Record the final submission proof and the evidence version. If the hotel sends more records later, check whether the case stage allows another submission. A late hotel reply does not extend the processor deadline.

Close the Operational and Financial Loops

Match the guest case outcome to the real payment movements. Settle supplier credits, VCC balances and OTA fees under each agreement. Keep fees and principal apart. Do not count the same returned funds twice across booking and payment reports.

Review which supplier requests caused delays. Note which booking channels gave conflicting cancellation records. Use those findings to set service levels, data retention and exception rules. Compare cases with similar collection models when you judge results.

Chargeflow’s marketplace chargeback guide covers wider platform operations. For a hotel-level case, the hotel guide has the folio and stay-evidence checklist.

Connect the Role Map to Automation

Bring your real guest and supplier payment flows to any automation review. Confirm which merchant account is supported, which business submits evidence and how hotel records will be pulled in. A booking link and a payment link may expose different parts of the file.

Chargeflow for travel and Chargeflow Automation help travel merchants review evidence and response workflows. Test the handoff with an anonymized two-payment example before you roll it out across suppliers.

Related Travel Evidence and Automation Guides

• Airline Chargebacks: Flight, Ticket and Refund Evidence
• Cruise Chargebacks: Cancellations, Changes and Refund Evidence
• Best Travel Chargeback Management Software: A Buyer’s Guide
• Vacation Rental Chargebacks: Direct Bookings, Property Access and Condition Evidence
• Guided Tour and Activity Chargebacks: Itineraries, Waivers and Evidence

Sources checked October 20, 2026. Worksheets are our own frameworks. All case IDs, amounts and dates are made up. No real customer result or recovery forecast is implied. Check the current case, provider and rules before you submit.