Release Notes – v3.2.5-rc1

21 July 2026 (d2efef3)

Ticket booking limits could be exceeded by typing a quantity Case #5471 | V3-290

On the booking journey, a customer could exceed the per-ticket-type limit set in the admin portal by highlighting the quantity box and typing a number, instead of using the “+” button. The “+” button correctly stopped at the limit, but a typed value went through to checkout — which is how, for example, six of a limit-of-four ticket type were booked.

What has changed. The quantity box now caps typed values at the configured limit, keeping the input, basket and ticket total in step. We have also tightened the back-end validation and added handling for more edge cases, so that limits are applied more consistently — including where the on-screen control is bypassed (for example a shared link) — across all sales channels. Existing bookings already above a limit can still be amended or cancelled — they just cannot be increased further — and membership, patron and voucher allowances that permit higher quantities continue to work as before.

Testing Guidance

Check your configured limits first. Because these limits are now applied more consistently across every channel, please review your admin-portal per-ticket-type limits.

The main risk here is not that it fails — it’s that it now works more strictly. It's possible some over-limit combinations that slipped through before will now be caught, so if a channel’s configured limit is stricter than your operation actually needs, staff who had been able to exceed it may start seeing a “maximum quantity reached” message. That is the system applying your configured limit correctly, but it may be a surprise if the configuration is tighter than expected. Please make sure each channel’s limits reflect how you actually operate before we go to production.

Not new in v3. This is a pre-existing issue — the same behaviour was present on the previous (v2.9) platform, not something introduced by the move to v3.

Newsletter sign-up wording updated to match 2.9

V3-208

The marketing-preferences opt-in at checkout now reads “Sounds great, sign me up”, restoring the shorter wording used on the previous platform. HRP environments only; no other change to the checkout.

Release Notes – v3.2.5-rc2

27 July 2026 (86455f2)

Unable to cancel order

V3-283

Fixed an issue where certain bookings (primarily those made by Irish Trade Partners) could not be cancelled, with users receiving a "Something went wrong" error when clicking Continue to payment during the cancellation flow.

Duplicate promo box appearing on B2C journey / UI issue

V3-257

Fixed a UI issue on mobile devices where two promo/voucher code input boxes were displayed at the checkout stage on the customer details page.

Reservations user is unable to edit a Lead Patron's details or a Joint Patron's details without entering a DOB

V3-256

Fixed an issue where editing customer details on a patronage required a Date of Birth to be entered, despite DOB not being a mandatory field for Patrons. The save button was greyed out with an error until a DOB was provided.

Mid-Year Upgrades are providing 1 month extensions in some cases

V3-246

Fixed an issue where mid-year membership upgrades on automatic renewal terms incorrectly extended the expiry date by one month beyond the original, rather than retaining the original expiry date.

HRP Data Warehouse - Webhook Replay Issue

CORE-8079

Webhook replay is now targeted and isolated from live traffic. Replays previously broadcast to every listening webhook (causing consumers to re-ingest data they already held) and shared queue ordering with live webhook deliveries (a large replay could delay live events by minutes or hours). A replay must now name its destination: POST /webhooks/replay requires a webhook_url that exactly matches a registered, enabled webhook, and only that webhook receives the replayed events. Replay traffic is processed separately so it can no longer hold up live deliveries, and long replays now checkpoint and continue automatically instead of timing out.

Release Notes – v3.2.5-rc3

31 July 2026 (9ac7b9e)

HRP - Mooring Product not generating tickets

CORE-9036

Ticket Generation: Resolved a critical bug where Mooring products were failing to generate tickets upon purchase. Customers will now receive their mooring tickets as expected. CORE-9036: HRP - Mooring Product not generating tickets

HRP - Hampton Court Palace Mooring Product showing as Kingston-Upon-Thames Mooring

CORE-9039:

Product Labeling: Fixed a display error where the "Hampton Court Palace Mooring" product was incorrectly showing as "Kingston-Upon-Thames Mooring." The correct location is now displayed throughout the booking journey.