What does it mean?
This feature introduces a Temporary Booking status, designed to modernize our process, ensure better capacity management, and improve integration with third-party channels (OTAs).
The concept of a Temporary Booking is an important step that reserves inventory before the booking is fully confirmed or paid for, effectively acting as a 'Hold.'
Goal: To align our booking process with market standards, especially for synchronous (inline webhook) API integrations.
The hold mechanism: When a booking is started, capacity is reserved with the status TEMPORARY across all connected systems and subsystems. This prevents double-booking while confirmation is pending.
Time limit: A timer (typically 45 minutes for API bookings) begins immediately. The booking must be completed within this window.
-
Confirmation/Deletion:
If successful (e.g., confirmation is retrieved, or payment is made), the status changes to BOOKED.
If the timer expires, the payment fails (future feature), or the booking is canceled, it is automatically DELETED, and capacity is released immediately.
Current Implementation (Phase 0)
Currently, this feature is only active for:
API bookings coming from TourCMS
AND when an inline webhook (synchronous notification webhook) is in place.
In this initial phase, the Temporary Booking is specifically used to manage the time required to retrieve a necessary external reference (e.g., from Vienna City Card or Vienna Pass via AVS) and transmit that back to TourCMS.
Note on Process: For this API-only phase, the process is two steps: 1) Create Temporary Booking (Capacity is reserved) and 2) Confirm or Delete (Based on the external reference outcome). The step for gathering customer data/payment is bypassed for now.
What should I do?
To enable Temporary Bookings for your eligible TourCMS API integrations, you must update your inline webhook URL as follows:
Locate your existing inline webhook URL in TourCMS.
Add
?temporaryBookingProcess=trueto the end of the URL. This is a provisional, once the temporary booking is enabled for all the channels in future stages of the implementation, then it won’t be necessary to add this parameter.
This parameter is a provisional requirement. It is currently necessary to ensure temporary bookings function correctly. In future implementation stages, once temporary bookings are enabled across all sales channels, this parameter will be automatically handled and will no longer be required.
Example: https://api.palisis.com/tp/v1/tcms/webhook/notification/ABCD/EFGHI?temporaryBookingProcess=true
⚠️ Important: This is a fictional webhook URL provided for example purposes only. Do not use it.
Channel |
Trigger for "Temporary" Status |
Recommendation |
OTAs (via TourCMS) |
An unconfirmed booking is received via the inline webhook. |
This inherently resolves previous capacity synchronization issues. Ensure your external platform’s expiry time aligns with the hold time you want to grant the OTA. |
How to identify a Temporary Booking?
Temporary Bookings are clearly marked throughout our system to distinguish them from confirmed reservations.
Booking List & Manifest: They are visible on both the main Booking List and the Manifest, where they will be explicitly designated as 'Temporary'.
Booking list page
Booking detailed view
Manifest
Departures Page: Temporary bookings also appear on this page reserving the corresponding seats.
Reporting: Temporary Bookings are not included in standard Reporting or Cash Settlements.
Caveats
Please note the following technical and operational considerations regarding Temporary Bookings:
Area |
Consideration |
Ticket inventory |
Capacity is genuinely reserved on all subsystems while the booking is in the TEMPORARY status. |
Fiscal requirements (Blackbox) |
Temporary Bookings are excluded from national Blackbox (fiscalisation) processes until they are fully CONFIRMED. This ensures compliance by only reporting completed sales. API bookings (unredeemed vouchers in Palisis) are excluded from fiscalization. |