Cancellation policies and processes

Predict the unpredictable

Be prepared for the unexpected, reassuring customers that you are on their side. We don’t know what the travel situation will be like in the future. That’s why we need more flexibility now than ever before. Relaxed cancellation policies and the possibility to make changes to the booking are currently the most important booking factors especially for bookings made far ahead. If you can provide this, travelers will book with you.

Make it easy

Show the cancellation policy clearly on the website. Begin your relationship with customers by offering high-quality customer service. It matters not only what you do but also how quickly you do it. Meet customer’s expectations by replying promptly – use messaging tools such as ready templates, automatic replies, and online chat. Provide a self-cancellation service using the new Viator cancellation endpoints.

Offer support, create loyalty

Listen to your customers and resolve their problems. By being flexible and understanding of the customer’s needs, you will make them want to come back. Even if they find better deals somewhere else, they will prefer to book comfortably with you. They will also recommend you to their friends. Apply flexible cancellation policies, provide excellent customer support and see how great it works!

Technical operations – verifying the refund amount

Cancellation policy type: cancellationPolicy.type

• • Standard cancellation policy = “STANDARD”
  • Custom cancellation policy = “CUSTOM”
  • All sales final policy = “ALL_SALES_FINAL”

Cancellation policy in text format: cancellationPolicy.description

Example: ”description”: “For a full refund, cancel at least 24 hours before the scheduled departure time.”

Checking the refund amount: cancellationPolicy.refundEligibility

• • dayRangeMin
  • dayRangeMax
  • percentageRefundable
  • startTimestamp*
  • endTimestamp*

* Returned only post booking – in response to /bookings/book, /bookings/status

Cancellation policy logic explained

All cancellation policies described above are in the local supplier’s time zone.

Cancellation process: traveler-initiated cancellations

All booking cancellations (except for those requested after the date of travel, or those triggered by the tour operator) must now be performed via the API by following the steps listed below. A full breakdown of our cancellation workflow can be found in our API documentation.

1. Checking cancellation reasons

All cancellation reasons can be retrieved from the /bookings/cancel-reasons endpoint:

Cancellation reasons rarely change, that’s why this data should be cached. We recommend refreshing the list of cancellation reasons -monthly. If you would like to use a placeholder cancellation reason, we request that you use “I canceled my entire trip”, as using other reasons may trigger internal processes with our suppliers.

2. Verifying the refund amount

The /bookings/{booking-reference}/cancel-quote endpoint must be used before processing the cancellation in order to get a cancellation quote – the exact amount that will be refunded in case of a cancellation.

While all bookings with future travel dates will return a CANCELLABLE status, this does not guarantee that they are refundable. The actual refund depends on supplier policies based on their time zones. Always review the refundAmount or refundPercentage returned in the /cancel-quote response and communicate this to the traveler before proceeding with the cancellation.

The booking-reference used for this request is generated in the response to /bookings/book service (bookingRef ) and it has the following format: BR-123456789.

The response above indicates that the booking can be canceled, however a refund will not be provided (“refundAmount”: 0.00,“refundPercentage”: 0.00,).

Please note:

1. It is possible to cancel booking requests made for manual confirmation type products where the booking status is “PENDING”.  However, in case of bookings with the “PENDING”status, the following fields will return a value of 0:  itemPrice, refundAmount and refundPercentage. This is because no fees have been charged for bookings that have not been “CONFIRMED” yet.
2. The response will always return “status”: “CANCELLABLE” if it’s before the activity start time however this doesn’t mean that the booking is refundable. In order to check if the refund will be provided it’s necessary to verify values returned for the refundAmount and refundPercentage.

3. Canceling a booking

Once the refund amount has been verified and agreed, the cancellation must be processed using the /bookings/{booking-reference}/cancel endpoint:

The booking has been canceled only when the “ACCEPTED” status has been returned in the response to this endpoint.

In case of a “DECLINED” status returned in the response, a relevant reason why the cancellation has been declined will be provided as well:

• “ALREADY_CANCELLED”: The booking has already been cancelled
• “NOT_CANCELLABLE”: The booking cannot be canceled because the product start time was in the past (see section Post-travel cancellations <link goes here>)

Feel free to check this section of our API documentation for additional information.

Please note: all merchant partners are required to process cancellations via the API. This flow is optional for affiliate partners.

Partial refunds

In case of partial refunds (custom cancellation policy), it’s essential to verify the refund due based on values returned under dayRangeMin and dayRangeMax and relevant percentageRefundable.

Please note: percentageRefundable might be returned as 0 which means that no refund can be provided (this is usually the case when it’s close to the start time, or when the product has a non-refundable policy).

Post-travel cancellations

Traveler-initiated amendments

There are a few ways to make changes to an existing booking when requested by travelers:

Supplier-initiated amendments and cancellations

There might be situations when the booking gets amended/cancelled by the supplier due to operational issues, weather, scheduling changes, etc. 

1. Supplier-initiated amendments

If you are a merchant partner, we will advise you of the service change via email and it’s your responsibility to inform your customer about the same and confirm back to us whether the amendment has been accepted by the customer.

• When accepted, we will update the voucher details so that you can reissue a new voucher to your customer using API services.
• When the amendment is not accepted, we will cancel the booking and you will need to process the refund.

If you are an affiliate partner, you will not be consulted on amendment requests and will not receive Viator’s confirmation emails. You can use the /bookings/modified-since endpoint to retrieve all supplier-initiated amendments and update your booking records in internal and traveler-facing systems.

2. Supplier-initiated cancellations

Supplier-driven cancellations can be fully automated via the API, eliminating the need to rely on Viator’s email notifications. Using the /bookings/modified-since and /bookings/modified-since/acknowledge endpoints, partners can retrieve and process cancellation updates directly. 

For merchant partners, implementing this flow is mandatory to ensure that travelers are notified of cancellations promptly. Automation not only sets clear expectations but also improves the overall customer experience and reduces the risk of issues or complaints.

The /bookings/modified-since endpoint enables a proactive approach to booking management by allowing you to regularly poll for updates on your existing bookings, including post-travel cancellations. This endpoint will return cancellation and refund details for bookings within a specified timeframe. You can then use the /bookings/modified-since/acknowledge API endpoint to acknowledge that you have processed the cancellation(s). This acknowledgement will prevent Viator from triggering email notifications. 

The workflow used to pull supplier-side cancellations is explained in detail in this article.

API services mentioned above should be used for booking status checks as follows:

While booking access affiliate partners are not required to automate the flows for amendments and cancellations, it is strongly recommended if customers can view Viator booking status on the partner’s platform in addition to receiving status updates via email from Viator. Without automation, customers may become confused – for example, if they accept a booking amendment request from the supplier, or if a booking is canceled by the supplier and Viator notifies the traveler, but the partner’s platform continues to display outdated details or an incorrect booking status.

Managing communications

Please see below specific scenarios when Viator communicates with direct Viator travelers in regards to their bookings. We highly recommend that our merchant partners create the same communication flow for their customers. 

Under the column with notifications for the customer/merchant/supplier you can see when Viator sends communication to the relevant party about bookings made by merchant partners.

* Merchant partners do not receive any communication from Viator with the booking confirmation as this information should be retrieved by the partner using the API services.

** The scenario illustrated here refers to the situation when the customer initiates the cancellation directly with Viator. The Viator Customer Service team will contact the merchant partner to advise of the same and will process the cancellation when approved by the merchant partner. However the expectation is that the customer will contact the merchant partner directly in order to amend or cancel the booking.

*** The table illustrates the process applied to V.2 API – where partners don’t receive copies of emails sent to customers. Partners using the V.1 API receive a copy of the CLC email sent to the email address provided in the booking request.

Please note: Closed Loop Communication (CLC) is enabled when customer’s contact details are sent in the booking request.

• • email and phone in the communication object in the request body when making a call to /bookings/book service.

When Closed Loop Communication (CLC) is enabled, the supplier will be able to contact the end customer directly with any questions or additional information about the booking. 

When it’s disabled, the partner will be contacted by the supplier and responsible for passing the message to the customer (and forwarding the response to the supplier when necessary).

Note: 

• • To have a CC of each message a supplier sends to their customer sent to your (the partner’s) customer support email address (in case further assistance is required) you must include your customer support email address in the email field, after the customer’s email and separated from that address with a comma.
  • All supplier communication will be sent to the email included in the API booking request (communication.email). Only when the email address is not provided in the booking request, we will use the email address selected for supplier communication in the Partner Dashboard.

Please note: All affiliate partners with booking access are required to include only the customer’s contact details in the booking request. Under the contractual agreement with Viator, Viator acts as the merchant of record and provides customer support. As such, Viator is legally obliged to communicate directly with customers regarding their bookings and cannot pass this communication to third parties.

For additional information please check our guide Direct partner support for merchant partners.

Back to top ↑