We've resolved an issue where some RazorPay bookings were not being confirmed after a successful payment.

What was happening? In certain cases, guests who navigated away, refreshed the page, or pressed the back button during the RazorPay payment process would have their payment processed but their booking not confirmed. This was because the frontend was not sending the final request to the booking confirmation API when the payment flow was interrupted by a page navigation.

What's been fixed? Guests are now kept on the payment processing page while their RazorPay transaction completes, preventing accidental navigation away before the booking is confirmed. This ensures the confirmation API is reliably called after a successful payment, so bookings are completed as expected.

Who does this affect? Properties using RazorPay as their payment gateway through IBE+.

Summary

This Beta release includes two fixes and one new feature enhancement. Partners are encouraged to validate these changes in Beta and report any issues via standard support channels.

New Features

Guest Classifications — New Endpoints

New endpoints have been added to support full management of guest classifications, enabling retrieval, assignment, replacement, and removal of classifications on a guest record. 

New endpoints:

• GET /guestClassifications — Retrieve available classification types SwaggerHub ↗
• GET /guests/{id}/classifications — Get classifications assigned to a guest SwaggerHub ↗
• POST /guests/{id}/classifications — Add a classification to a guest SwaggerHub ↗
• PUT /guests/{id}/classifications — Replace the full classification set for a guest SwaggerHub ↗
• DELETE /guests/{id}/classifications/{classificationId} — Remove a specific classification from a guest SwaggerHub ↗

Fixes & Improvements

Pencil Reservation — Dynamic Pricing Rate Consistency

• Issue: When a rate type was applied to a pencil reservation via the API, the quoted rate was not being preserved. If dynamic pricing changed before the pencil was converted to Unconfirmed/Confirmed, the reservation would be re-quoted at the new rate — producing a different rate than originally presented to the guest.
• Fix: Applying a rate type to a pencil reservation via the API now correctly preserves the quoted rate and occupancy snapshot. The rate will be retained when the pencil is subsequently converted.
• Endpoints affected: PATCH /reservations/{id}, PUT /reservations/{id}/status

Reservation Hold — 404 Error on Create

• Issue: When creating a new reservation hold via the API, a 404 Not Found error was returned despite the hold record being successfully created.
• Fix: POST /reservations/{id}/holds now returns the correct 200 OK response with the hold record payload upon successful creation.
• Endpoint: POST /reservations/{id}/holds

Notes

• Release Date: April 8, 2026 Beta only
• Dependencies: None
• There is no impact to Live environments.
• Please report any issues through standard support channels: https://rmsapi.zendesk.com/hc/en-gb/requests

We have resolved an issue in the RMS Booking Engine (IBE+) where Google tag data was not being recorded upon booking confirmation.

Previously, Google tags were failing to fire on the confirmation page after a guest completed payment. This meant that transaction data - including booking conversion events - was not being captured in your connected Google Analytics account, resulting in incomplete or missing reporting data.

This issue has now been fixed. Google tags will fire correctly on the confirmation page, ensuring that all transaction and conversion data is accurately recorded as expected.

We have resolved an issue in the RMS Booking Engine (IBE+) where the Area URL modifier was not functioning correctly when check-in and check-out dates were not included in the URL.

Previously, when a guest landed on the booking engine via a URL containing only an Area parameter (without dates), the Area filter would be dropped once the guest manually selected dates and clicked Search - resulting in all categories being displayed rather than only those mapped to the specified area.

This issue has now been resolved. The Area filter will now persist correctly in both scenarios: when dates are included in the URL, and when a guest manually selects dates after landing on the page. Only categories mapped to the specified Area ID will be displayed, as intended.

If you have any questions or require further assistance, please reach out to our support team.

What was the issue?

For IBE+ bookings where guests paid via RMS Pay, staff were unable to process refunds directly from within RMS (9+). Attempting to do so returned an error, leaving teams with no option but to manually intervene at the payment gateway level — a time-consuming workaround that also carried financial risk if not actioned promptly.

What's been fixed?

RMS Pay refunds for IBE+ bookings can now be processed directly from within the reservation in RMS, just as you'd expect. Both full refunds and partial refunds are supported. When a refund is submitted, it communicates with RMS Pay, returns the funds to the guest's original payment method, records the transaction in the reservation ledger, and updates the balance — all in one smooth step.

If a refund attempt fails at the gateway, the system will now correctly prevent the refund from being recorded, keep the original payment intact, and display an error message so your team knows what's happened.

What do you need to do?

Nothing — this fix is automatic. Refunds for RMS Pay transactions made through the new Booking Engine can now be processed directly from the reservation in RMS as normal.

What was the issue?

When a property configured specific card types in Online Options (for example, Visa and Mastercard only), the new Booking Engine was not respecting that configuration for RMS Vault payments. Guests could still complete a booking using a card type that wasn't assigned - such as Amex or Diners - bypassing the intended payment restrictions entirely.

What's been fixed?

The Booking Engine now correctly validates card types against your Online Options configuration at the point of payment. Only card types that have been assigned to the IBE will be accepted. If a guest enters a card type that isn't configured, the card field will be flagged and they won't be able to proceed with that card.

This applies to both desktop and mobile.

What does this mean for your guests?

The checkout experience remains smooth for guests using an accepted card - they'll see clear visual confirmation that their card is valid. Guests using an unsupported card type will be prompted to use an accepted alternative before completing their booking.

Do you need to do anything?

No action is required. Just make sure your accepted card types are correctly configured in Online Options - the Booking Engine will handle the rest.

What was the issue?

For properties using the Book by Area category setup with the "Show area on confirmation email" option not enabled in Online Options, an internal Area ID number was incorrectly appearing on the booking confirmation page and confirmation email when a guest booked via the rates listing. 

What's been fixed?

The Booking Engine no longer shows the area name or ID when the toggle is not activated in Online Options when the categories are setup to be book by area. The behavior is now consistent with what you'd expect based on your Online Options settings.

What do you need to do?

Nothing - this fix is automatic. If you have "Show area on confirmation email" not enabled in Online Options and your category is set to Book by Area, your guests will now see the correct area name in their confirmation communications.

Summary

This Beta release includes two fixes. Partners are encouraged to validate these changes in Beta and report any issues via standard support channels.

Fixes & Improvements

NPS Results Report — 500 Error Resolved

• Issue: A 500 error was being returned for the reports/npsResults endpoint in Beta and Test environments.
• Fix: The endpoint no longer returns a 500 error and now processes requests as expected.
• Endpoint: POST /reports/npsResults — SwaggerHub ↗
• Note: This issue was environment-specific and had no impact on Live environments.

Transaction Receipt — Incorrect HTTP Status for Transient Errors

• Issue: When a transient database error occurred during payment processing, the API was returning a 400 Bad Request response. This incorrectly signalled a client-side validation error, causing payment workflows to fail rather than retry the request.
• Fix: Transient errors of this nature now return a 503 Service Unavailable response, correctly signalling to clients that the request should be retried.
• Endpoint: POST /transactions/receipt — SwaggerHub ↗
• Note: Partners should ensure their integration retries on 503 responses where applicable.

Notes

• Release Date: March 11, 2026 Beta only
• Dependencies: None
• There is no impact to Live environments.
• Please report any issues through standard support channels: https://rmsapi.zendesk.com/hc/en-gb/requests

When searching with a guest count higher than a rate table's maximum occupancy, the booking engine was displaying categories as simply Unavailable — leaving guests with no way forward and no explanation.

This has been fixed. IBE+ now intelligently handles over-occupancy scenarios by offering guests the option to split across multiple rooms where available, or surfacing a clear message explaining the limitation when it isn't. No more mystery dead ends. 🎉

Previously, it was possible to save a reservation with a Tariff Type that was not assigned to the selected Company when creating a booking. The system showed a warning but still allowed the reservation to save, which could lead to incorrect rate usage and under-quoting.

This has now been corrected. When Use Rate Types for Companies is enabled and a user attempts to save a reservation where the selected Tariff Type is not assigned to the chosen Company the reservation will not save.

Help article