HomeHelpConsultant GuideCancellation Requests

Cancellation Requests

Review, approve and deny client cancellation requests, including refund amounts, supplier cancellation and what happens to the money.

ConsultantConsultant AdminSuper AdminLast reviewed 25 Sept 2026

Was this article helpful?

Related Articles

Client Management

Add, edit, and organise your client database with contact details and travel preferences.

GDS Hotel Search

Search live hotel availability from RateHawk, pick a bookable room rate, and understand markup and the 40-minute rate hold.

GDS Flight Search

How the flight search form works, and why it returns no results today because no flight GDS is connected.

Previous

The Rate Lifetime Window

Next

Messaging Clients

When a traveller asks to cancel a booking, the request comes to you for a decision. Approving it cancels the booking with the supplier and moves real money; denying it leaves the booking in place. This article covers the review screen, what each decision does, and the failures you need to watch for.

Where cancellation requests appear

Open Bookings > Cancellations. The badge on that menu item counts the pending requests assigned to you and updates live. You also receive a high-priority Cancellation Request Received notification naming the requester, booking reference, destination, amount and reason, with a Review Request action that brings you here.

The booking itself is marked Cancellation Requested as soon as the request is raised, so it also shows up under that status filter in the Booking Queue.

The review screen

The page is headed Cancellation Requests and opens on Pending Only; switch the dropdown to All Requests to see resolved ones, and use the refresh icon to reload. Three counters sit at the top: Pending, Total, and Today (requests you approved today).

Each row shows:

  • The booking reference, the booking type (flight, hotel, car or package) and a status badge.
  • The requester's name, the destination, the booking total and the date requested.
  • The organisation, for corporate bookings.
  • The Reason the traveller chose — Change of Plans, Found Better Price, Travel Restrictions, Personal Emergency, Work Conflict, Health Issues or Other — plus any free-text detail they added.

Resolved rows show who approved or denied the request, when, and either the refund amount or the denial reason. Only pending rows carry the Approve and Deny buttons.

Tip: Consultants see and decide the requests for bookings assigned to them. Consultant admins and finance managers see and decide every request; a consultant admin can choose Assigned to me to narrow the list to their own bookings.
Card only held, not charged: approving a booking whose card payment was only held releases the hold, and the refund stays at R0 because no money was taken. If the release fails, the request says so; use Release the card hold on the request to try again. Trying again is safe: the hold is never released twice.

Approving a cancellation

  1. Click Approve. The Approve Cancellation dialog repeats the booking reference, customer and original amount.
  2. Set the Refund Amount (ZAR). It is pre-filled with the full booking total; enter 0 for no refund. The amount cannot be negative and cannot exceed the booking total — the server rejects anything higher.
  3. Add optional Notes about the refund.
  4. If the booking has a supplier order, a blue note warns that the system will attempt to cancel it via the supplier API automatically.
  5. Click Approve to process.

On approval, in this order:

  • The supplier booking is cancelled first. If that fails, nothing else happens — see the warning below.
  • If the supplier reports its own refund figure and it is lower than what you entered, your refund is clamped down to the supplier's figure. You can always refund the client more later; the supplier cancellation cannot be undone.
  • The request is marked Approved against your name, and the booking is set to Cancelled.
  • A reversal journal entry is written, the card payment is refunded through the gateway where one was captured, and the refund journal entry is written only once the money has actually moved.
  • The traveller is notified: “Your cancellation request for booking <ref> has been approved”, stating either the refund amount or that no refund applies.
Important: If the supplier cancellation fails or cannot be confirmed, the approval is refused entirely with “Supplier cancellation failed. Local cancellation was not approved; retry or escalate for manual supplier handling.” The request stays pending and no refund is issued. Retry, or arrange the cancellation with the supplier manually before approving again.

Denying a cancellation

  1. Click Deny. The dialog repeats the booking reference, customer and the reason the traveller gave.
  2. Write a Reason for Denial. It is mandatory and must be at least 10 characters — the button stays disabled until it is, and shorter text is rejected by the server too.
  3. A yellow note reminds you that the customer will be told the decision and your reason. Click Deny Request.

The request is marked Denied with your name, reason and timestamp, the traveller is notified, and the booking is taken out of the Cancellation Requested state and returned to an active status. For a booking-queue request that active status is Completed, so check the request afterwards if it had not actually been completed before the cancellation was raised.

Other things that can go wrong

  • The request was already resolved. Approving or denying a request that is no longer pending fails with “Request is already approved” or “Request is already denied”. Refresh the list.
  • PayU refused the refund. The supplier cancellation and the approval still stand, and no money was returned. TravelFlow does not send the refund again. Arrange it outside TravelFlow, by EFT, cash or bank transfer or in the PayU dashboard; finance then record it on the booking's invoice as an external settlement, which links it to this cancellation when it is no more than the approved refund still open. A larger refund, such as the whole card payment, is recorded without that link and the cancellation stays open. No refund journal entry is written for money that never moved.
  • PayU's answer was unclear. It is not yet known whether money was returned, so the card payment stays on hold and no second refund can be sent from it. From 15 minutes after the refund was last updated, press Check PayU on the request. It reads PayU's own list of refunds on the card payment and never sends a refund. One matching refund settles the request: a succeeded one is recorded with its refund journal entry, and a refused one releases the hold. Several possible refunds are listed; check them in the PayU dashboard, choose the one made for this request and type RECORD to record it. No matching refund releases the hold with no money returned: arrange the refund outside TravelFlow and have finance record it as an external settlement, or, if the client was already refunded in the PayU dashboard, record that refund instead of paying again. The same check is offered when an approval stopped before PayU's answer was saved. Do not submit another refund while you wait.
  • PayU confirmed the refund but its accounting did not finish. Use Recover refund accounting and type RECORD. It checks the saved PayU confirmation and posts the missing refund journal entry; it never sends another refund. If it says no PayU cash confirmation is saved, the card payment is still on hold: press Check PayU. Only the refund PayU confirmed, shown as succeeded for the approved amount, is recorded; anything else changes nothing, and you compare it in the PayU dashboard without refunding again.
  • A second request for the same booking. Travellers cannot raise one while another is pending, or on a booking that is already cancelled.
  • The refund exceeds the booking total. Rejected with the booking total quoted back to you.