Handling reservations with status 'ER' or Unclosed transactions

Overview

This article is to emphasize and explain the necessary actions from HSP clients when a booking request didn't ended successfully with status 'OK'.

Once a Book-request is initiated to HSP, the system transmit this booking request to the respective supplier per the Package selection.

According to suppliers' best practice there is a booking time out of 180 seconds, which means booking process can take on supplier side up to 180 seconds and still it will be considered as successful reservation.

Important: make sure that you set 'booking timeout' of 180 seconds.

In cases where the booking request failed, either on the supplier or HSP side, specific handling is required to prevent untraceable (ghost) bookings. This is crucial to avoid situations where bookings are created successfully on the supplier side but not mirrored on the HSP side or on your side.

below are critical errors codes that HSP clients has to verify with supplier and handle:
Booking return code 'ER' - HSP clients has to verify in the supplier's system whether the booking was created or not, before sending any additional booking request for the same package, to prevent duplicated bookings

Booking response wasn't received (Unsaved transaction / Unclosed transaction) - see below explanation and action items.

Segment Statuses Handling

As mentioned in : Orders and Segment Statuses.

Some statuses are final, for example :

  • RJ - The booking request was rejected by the supplier.
  • OK - The booking has been confirmed.

In other statuses, the status is non-final - and a manual handling is required, for example:

  • PE - Pending. The reservation was confirmed on the supplier side, but when Check-Status requested - invalid status returned from the supplier.
  • ER - Error occurred during the booking attempt. Might be an outcome as a result of an unexpected booking response from the supplier, timeout error, connection close, or any other issue.

How to Handle ?

As a general rule, each segment's status explanation and handling will align with its respective status. When a booking is initiated, and the booking return a specific status, it becomes crucial to comprehend how to manage it and determine the necessary actions to undertake.

Non-Final Statuses with their handling:

StatusExplanationHandlingOutcome
PEPending.
The reservation was confirmed on the supplier side, but when Check-Status requested - invalid status returned from the supplier.
Requires manual handling and verification of the segment status on supplier's system.Status can be changed to : OK or RJ.
PFPayment Failed.
The Credit Card has been authorized on the full amount by the Payment Gateway, however, the commit step (actual charge) failed.
Applicable only for clients who are using one of the integrated Payment Gateways to process a credit card transaction.
Most of the payment gateways have their own transaction management panel, where you can locate the transaction, either by last 4 digits of the credit card or transaction id
(can be retrieved from the 'Manage Orders' screen on our Back-Office), and manually force the commit on the credit card.
Please note that the booking was actually created on the supplier side, thought payment hasn't been collected successfully.
Status can be changed to : OK or CX
ERError occurred during the booking attempt.
Might be an outcome as a result of an unexpected booking response from the supplier, timeout error, connection close, or any other issue.
Please verify in the supplier's system whether the booking was created or not, before sending any additional booking request for the same package, to prevent accidentally duplicated bookingsStatus can be changed to : OK or CX
PIPending InvoicingStatus can be changed manually to "OK" using our Back Office after checking with supplierStatus can be changed to : OK
CPCancellation Pending.
The supplier didn't approve your cancellation request.
Please send another check status request or cancellation request.Status can be changed to : CX or ERC
ERCthere was an error while trying to cancel the reservation.
Occurs when supplier returns un-expected reply for the cancellation attempt.
1. Retry Cancel - Attempt to cancel the booking on the supplier's side again, if successful - ERC will change to CX.
2. Mark as Cancelled - If the segment's status on our side is ERC while the booking has already been cancelled on the supplier's side, the client can now manually change the segment's status to CX. (This will not send a CancelBooking request!)
Status can be changed to : CX or CP
RQRequested. The package you requested is waiting for the supplier to confirm it.Please send another check status request or contact supplier to verify if created on suppliers side.Status can be changed to : OK or RJ

Unclosed Transactions Handling

As discussed in GLogs & Session Viewer, within this tool, HSP provides the "Failed Booking Transactions table".

This screen primarily presents two categories of errored sessions:

Supplier Error: This category includes warnings or fault messages originating from the supplier's system in response to a booking request sent by an HSP user. Supplier errors may stem from supplier service rules, internal supplier infrastructure issues, communication timeouts, and so forth.

Service Error: These errors are messages translated from supplier errors or generated based on internal logic within the HSP system. For instance, they may arise due to price changes detected during the booking attempt. To streamline the error handling process for clients and prevent an overwhelming number of errors to manage, we have provided translations for supplier errors.

Each unclosed transaction is highlighted with a red line, accompanied by the message, "X transactions require your attention!"

How to handle

To address transactions demanding your attention effectively, it is crucial to distinguish when the booking is initiated with the supplier and when it is not. To pinpoint unclosed transactions that require handling, it is necessary to examine the logs thoroughly to gain a precise understanding of the events that transpired.

Absence of HotelBook Response

When the "HotelBook response" is not present on the HSP side, it's important to ascertain whether the booking request to the supplier was indeed initiated.
If a booking request was indeed initiated with the supplier, it necessitates handling to verify whether the booking was successfully created or not on supplier side.
However, if no booking request was initiated with the supplier, there is no reason to suspect that any booking was generated, as there was no booking request sent. Hence, no further action or handling is required.

Absence of 'HotelBook response' - As a PreBook request sent to SUN - it requires handling.

Absence of 'HotelBook response' - As a PreBook request sent to SUN - it requires handling.

Absence of 'HotelBook response' - As no request sent to Suppliers - it doesn't requires handling.

Absence of 'HotelBook response' - As no request sent to Suppliers - it doesn't requires handling.

Empty HotelBook Response

When the "HotelBook Response" is received but it is empty, it is essential to examine the "OrderBookResponseErrors" & "TraceWithSupplierErrors" within this log section. Here, you will find details regarding the cause and error code responsible for the failure.
In the event that no error is returned, yet the response remains empty, please verify if any request was indeed sent to the supplier. If a request was sent, we recommend contacting the supplier to address the situation and manage any created booking, if applicable.
In other scenarios where an error is presented, it serves as an indication of the underlying issue causing the booking to fail - which doesn't requires handling.

Empty Book Response

Empty Book Response

Book response is empty - due to Supplie error (Error code and explanation are within the OrderBookResponseErrors)

Book response is empty - due to Supplier error (Error code and explanation are within the OrderBookResponseErrors)

How to change Booking status

Changing status, or in other words - handling and updating the current status can be done by several actions:

  • Check Status
    This function submits a request to retrieve the updated status and booking data and can be done by 2 approaches :
    1. Manage Orders screen.
    2. Check Status API request.
  • Manually change via Manage Orders
    Whenever a status in non-final, Hence, handling and updating is required - the status icon will be clickable - allowing you to click and confirm the new status.
    To do so - simply locate the segment in the Manage Orders screen. Then - click on the Status to change it, example :
Step 1 - click on the 'RQ' or other status (non-final)

Step 1 - click on the 'RQ' or other status (non-final)

Step 2 - after clicking on the status, confirm the status update

Step 2 - after clicking on the status, confirm the status update