Check out the latest features, improvements, and product updates from RMS
We fixed an issue where a promo code that excludes a package could show a lower total in search results, then add that cost back in once the booking was added to the cart. Guests now see a consistent, accurate total the whole way from search to checkout.
We have released an update to the RMS Stripe app (version 0.0.8) that resolves an issue where some properties using the RMS Stripe integration were receiving a "permission denied" error when creating a token or processing payments. The error was caused by incorrect API permissions in the RMS Stripe app, which prevented certain payment operations from completing. This has now been corrected. Action required: To complete the update, you will need to log in to your Stripe Dashboard. Once logged in, Stripe will present you with a re-consent prompt asking you to approve the updated app permissions. Please review and accept these permissions to restore full functionality. This is a standard Stripe security step — it ensures you have visibility and control over any changes to the permissions granted to third-party apps connected to your account. Customers will then have to recreate a new restricted key that will have the new permissions applied. Once you have approved the updated permissions, no further action is required. If you do not see the re-consent prompt or continue to experience issues with your Stripe connection, please contact our support team.Customers will then have to navigate to RMS>Setup/PropertyOptions/PropertyInformation>Property Set Up>Payment Gateway and select Copy Stripe Keys.
Resolved an issue where a CC token description entered immediately after token creation was not being saved. Users were required to exit and reopen the CC Token screen before the description field would persist values correctly.
When a vault token is created the token will be stored with the 'date to remove' set at the departure date of the reservation. If the reservations departure date is changed to a future date the 'date to remove' will be updated. If the reservations departure date is changed to a later date the 'date to remove' will not be changed. If a departure date fails to pass through on amendment the system will update the 'date to remove' to be current + 2 years as a fail safe. Vault tokens are then removed from use +14 days from the 'date to remove'.
Fixed an issue where Purchase and Conversion tracking dropped off when a guest paid with a 3DS-verified card. Tracking parameters now persist through the card issuer's authentication redirect, so conversions are recorded correctly.
We now have the ability to create a map with multi-location waypoints, to enable guests browsing a split-site property (multiple park areas under one listing) to see on-map indicators pointing to the other areas, making it clear these are separate locations they can jump between
Guests booking a Site (RV, motorhome, caravan) now see their selected vehicle Type and Length on the booking confirmation page, in the confirmation email, and in the reservation record - so the details they booked with are the details on file.
Fixed an issue where the minimum length of stay message shown to guests didn't reflect the lowest length of stay actually required to book, which could make a bookable stay look unavailable.
This Live release promotes the v10.26.202.1 Beta, which includes two bug fixes addressing reservation cancellation handling and owner record completeness for areas within interconnecting rooms.
Included in this Live release:
This Beta release delivers two bug fixes: one resolving a reservation cancellation error when no sundry is configured on a cancellation policy rule, and one correcting incomplete owner records returned for areas within an interconnecting room.
Fixed an issue where PUT /reservations/{id}/status returned a 400 error — "Cancellation Fee: no Sundry is configured on the Cancellation Rule or in Account Options" — when a cancellation policy rule was set up but no sundry had been configured. Reservations can now be cancelled successfully in this scenario. A cancellation charge will only be posted if the policy rule is met and a valid sundry is configured.
PUT /reservations/{id}/statusFixed an issue where GET /areas/{id}/owner returned incomplete owner records for areas that form part of an interconnecting room. Only the interconnecting (parent) area was returning the full owner history; the underlying individual areas returned only a single owner record. The endpoint now returns all applicable owner records for each area, including historical entries.
GET /areas/{id}/owner