(V3) Mobile and Desktop POS + Scanning release notes - 3.0.15.2

Release summary

POS app v3.0.15.2 (tag v3.0.15.2, 3 September 2026) is a maintenance and stability release covering the changes since v3.0.14.1. It closes out 10 Jira tickets across HRP, Blenheim Palace and Design Museum, with 30 commits and no database migrations.

The headline items are:

• Two HRP support fixes: the POS promo pick list now only shows promos returned for the current market, and mobile card payments can no longer be mis-recorded under a different payment method (the cause of the "Reversed" entries seen in the OCC portal).
• A crash fix that affects all clients: an expired or unrefreshable session now logs the operator out cleanly instead of killing the app.
• A set of Blenheim Palace MVP fixes around booking amendment on the E700 and A920: basket clear-down between customers, beneficiary names on wallet passes, Back on the edit screen, Date of Birth no longer forced on edit, one QR code per booking, and Keep original time on by default.

Two hotfix increments are folded in: 3.0.15.1 (EXN-301 and an EXN-253 follow-up) and 3.0.15.2 (EXN-276 follow-up so Save works on amendments, plus restoring the Other booking details section and a market overview compatibility fix for the new backend).

No Admin or product configuration changes are required for any item in this release.

Items in this release

POS promo pick list now shows only the promos returned for the current market (HRP)

Jira: CORE-8990 | FD: 5382

HRP reported that the Select promotion list on POS showed expired promos, promos removed from the HRP market and promos without the POS channel ticked, making the list unwieldy for FOH staff. The list was being served from a locally cached full promotions catalogue that refreshed at most once every 24 hours and was never market, channel or expiry aware.

POS now calls the market promos endpoint (GET markets/{marketId}/promos) live each time the screen is opened, so the list reflects Admin and Reservations changes as soon as the screen is reopened. Applying a promo (typed, scanned or picked) is unchanged and invalid codes are still rejected at apply time. Note that POS does not filter locally; if a code still appears that Reservations hides, the market endpoint is returning it.

Testing: open Select promotion from a basket and confirm the list loads; compare it with the Reservations list for the same market; expire or unpublish a promo in Admin and reopen the screen on POS to confirm it drops off without waiting or syncing; confirm an invalid or expired code typed or scanned is still rejected. Offline, expect the existing no-internet error rather than a stale list.

Mobile card payments can no longer be recorded under the wrong payment method (HRP OCC portal "Reversed" payments)

Jira: CORE-9064 | FD: 5650

Issue: HRP saw payments flagged as "Reversed" in the OCC portal for redeemed tickets and memberships. Most were legitimate reversals, but order DVOZ11Y21URZ4 exposed a POS defect: on a mobile device, if the operator tapped another payment method (for example External or Cash) after returning from the payment app but before the card result arrived, the order was completed as that method with no payment ID, while the card had in fact been charged.

Fix: The app now waits for the terminal result before allowing a different payment method; tapping another method shows "Card payment is still in progress. Wait for the terminal result." The receiver for the terminal result is also kept alive for the whole session, so a result cannot be missed if staff move into the refund or split payment screens mid-transaction.

Testing: on an axceptPro mobile device, start a card payment and immediately tap Cash, Debit, External or Invoice; confirm the second tap is blocked with the toast and only one order records. Repeat with an approved and a declined result (on decline the lock releases and the operator can retry or pick another method).

Also works on Stripe tablet and Stripe mobile. Run a normal payment for each method to confirm no regression, and confirm the Transaction In Progress dialog has no Force close button.

App no longer crashes when a session expires and cannot be refreshed (Design Museum)

Jira: V3-351

Issue: Production Crashlytics on Design Museum desktop (3.0.1) showed a fatal AuthException on the OkHttp dispatcher thread.

Fix: Operators were left with a crash loop and typically had to clear app data or reinstall. AuthException now extends IOException so it is delivered normally and the operator is sent to the login screen. Unexpected errors during the 401/403 retry are treated as ordinary network errors rather than forcing a logout. The interceptor code is shared, so the fix applies to every client and flavour.

Testing: sign in, complete a sale and a scan and confirm normal behaviour; then invalidate the session (change the user's password or disable the user while the till is open) and trigger any authenticated action; expect the login screen, not a crash, with no need to clear app data. Confirm the Stripe reader still connects on desktop and that logging back in with valid credentials reaches the till.

Returning to the home screen now clears the basket so one customer's details cannot be written onto another customer's booking (Blenheim Palace)

Jira: EXN-245

Issue: Scanning a pass and tapping Edit added the booking to the basket; going back to the home screen did not clear it, so scanning a second, unrelated customer's pass and tapping Edit pre-populated the form with the first customer's details, and saving merged the two bookings.

Fix: Returning from the amendment flow to Booking details now clears the active basket and booking context, so every new scan starts a fresh transaction. The only exception is when a payment is actively being processed for the basket, in which case the basket is kept and the operator sees "Payment is being processed for this basket".

Testing: scan customer A, tap Edit, go back to home without saving, reopen the scanner and confirm the basket is empty; scan customer B and confirm the scan result and the Edit form both show B's details only; save and confirm nothing from A is carried across. Repeat several times in a row to simulate a live gate, and check both desktop and MPOS.

Editing a beneficiary's details keeps the beneficiary's name on the wallet pass instead of the lead booker's (Blenheim Palace, E700 and A920)

Jira: EXN-253

Issue: Amending a passholder's first and last name under Other booking details wrote the lead booker's name onto that passholder's wallet pass, on both POS-originated and B2C-originated annual pass bookings. Because Blenheim passes are name-checked at the gate, this made legitimate passes look shared or invalid.

Root cause: the amend path recreated customer rows with synthetic ticket-0 IDs rather than preserving the issued DVT ticket associations on PUT orders/{id}/customers, so the wallet update fell back to the lead booker.

Fix: Passholder edits now update the existing association row in place and preserve the issued ticket IDs. Editing the lead booker alone was already correct and is unchanged. The Other booking details section, which briefly went missing in 3.0.15.1, was restored in 3.0.15.2.

Testing: on an annual pass booking where lead booker and passholder differ, edit the passholder's name under Other booking details and save; confirm the Redeem Tickets panel and the wallet pass both show the new name.

Control: edit only the lead booker and confirm the pass is untouched. On a group booking edit one passholder and confirm only that pass changes. Repeat on the second device type.

Regression: check out a new annual pass entering passholder names at the Custom Fields step and confirm each saves against the correct ticket.

Pressing Back on Edit Membership Details no longer wipes the booking on screen (mobile POS)

Jira: EXN-301

Issue: On the A920 (phone layout), opening a booking, tapping Booking details, then Edit, and pressing the toolbar or hardware Back arrow returned to a blank Booking details screen with the Edit button gone, and the Scan Result screen behind it also emptied. The operator had to re-scan or re-search the booking, and destructive actions (Cancel Booking, Print Receipt, Send Email) remained tappable against an empty order. This was a regression from the switch to the newer contact details form, which was not on the allowlist of screens that preserve the scan result on Back.

Fix: Back now cancels the edit and returns to the fully populated booking. Saving works as before. Phone flow only; the tablet branch was not affected.

Testing: find a booking by scan or search, open Booking details, tap Edit, press Back using the toolbar arrow and again using hardware or gesture Back; confirm all booking fields, ticket status and action buttons are intact each time and any unsaved edit is discarded. Repeat with Save Changes and confirm the amendment applies. Also check Add booking notes and Edit custom fields return correctly, and spot-check the fast-scan route into this screen.

Date of Birth is no longer forced as mandatory when editing an existing customer (Blenheim Palace)

Jira: EXN-195

Issue: Editing a customer's name on POS highlighted Date of Birth as a missing mandatory field. In practice the save was not blocked, but the highlight was misleading and inconsistent with Reservations.

Fix: Date of Birth is now optional when editing an existing customer, for every product type, matching the Reservations behaviour. The rules for creating a customer at the point of purchase are unchanged and remain product-dependent; membership amendment and renewal flows and additional family members are out of scope for this ticket.

Testing: open an existing customer on a standard admission or event booking, change the name, leave Date of Birth empty and save; confirm the field shows "Date of Birth" with no mandatory marker and no pre-applied missing-DOB highlight. Repeat on an entitlement product (membership, patronage, voucher). Enter an invalid date and confirm validation still fires; enter a valid date and confirm it saves. Confirm the Save button still reflects other required fields such as name.

One QR code per booking on printed receipts (Blenheim Palace)

Jira: EXN-220 (EXN-212 covered the same request and was closed as a duplicate)

Blenheim asked for one QR code per booking on the POS printout rather than one per ticket, so gate staff scan once, bring up the booking, select who is present and redeem manually. For large groups this also saves paper.

Bookings in Blenheim's booking-level print mode now print a single QR code; the print button reads "Print Booking QR" in that mode and the print preference screen explains "Print by Tickets" versus "Print by Booking". Labels on the payment and print screens have been given consistent capitalisation ("Send Email", "Print Receipt", "Print Tickets"). Configurations set to per-ticket printing are unchanged.

Testing: in a Blenheim environment, complete a booking with several tickets and print; confirm a single QR code and unchanged receipt content. Repeat with a single ticket and with mixed ticket types. Scan the booking QR at the gate and confirm the booking opens for manual redemption. Regression: a per-ticket configuration should still print one QR per ticket with the "Print Tickets" button.

Keep original time (even if past) is on by default for Blenheim Palace amendments

Jira: EXN-276

Issue: Annual pass amendments at Blenheim need to keep the original start date, but the Keep original time (even if past) toggle defaulted to off when unset, so amendments dropped past start dates and staff assumed amendments were broken.

Fix: A new market flag (keepTimeOnAmendmentDefaultChecked, true for Blenheim) now supplies the default. Devices where staff had explicitly turned the toggle off keep that choice, and other venues that show the toggle (Roman Baths, Victoria Art Gallery) still default to off. The 3.0.15.2 follow-up fixed a knock-on defect where, with the toggle on, the booked option was replaced by null after the booking options response, so Save silently did nothing on date products; the booked option is now retained during amendment and, where an option cannot be resolved, the operator is told why Save cannot proceed rather than the tap being ignored.

Testing: on a Blenheim device with a fresh install or cleared preferences, open Settings then Sales and confirm the toggle is on; amend a past-dated annual pass and confirm the original start date is kept and Save completes. Turn the toggle off and confirm a past-dated pass cannot be amended (the calendar is greyed out with "No available times"), which is the intended pre-EXN-276 behaviour. Turn it back on and confirm keep behaviour returns.

Optional: confirm a non-Blenheim market still defaults to off.

Also included

The following changes shipped in the same tag but were not part of the Jira context above. They are listed here for completeness and should be confirmed against their tickets before being quoted to clients.

• EXN-242 (PR #693): configurable filtering of Change Product upgrade options, limiting upgrades to long-validity products priced at or above the current product, with the ability to hide selected product IDs from the upgrade list.
• V3-347 (PR #697): Design Museum membership walk-up ticket type resolution, so membership products present the correct walk-up ticket types and capacities, with the legacy fallback removed.
• PR #713: getMarketsOverview now includes unsellable products with improved network fallback, a compatibility fix for the new backend.
• Internal only: autotest updates (#666, #706) and printer unit test suite repairs (#704). No customer-facing change.