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

Release summary

POS app v3.0.14 (tag v3.0.14, 24 August 2026) is a small, targeted release on top of v3.0.13, delivered as a single squashed commit covering five Jira tickets with no database migrations. It was superseded two days later by v3.0.14.1, which carries the same fixes plus a follow-up to the Date of Birth change; see the separate 3.0.14.1 notes.

The headline items are:

• HRP: mobile card payments can no longer be recorded under a different payment method, which was the root cause of the "Reversed" entries HRP saw in the OCC portal.
• Blenheim Palace: the basket is cleared when returning to the home screen so one customer's details cannot be merged into another customer's booking; one QR code per booking on printed receipts; and Date of Birth no longer flagged as mandatory when editing an existing customer.

A minor internal fix removing a stray progress reset from the refund flow is also included. No Admin or product configuration changes are required.

Items in this release

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

Jira: CORE-9064 | FD: 5650

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. 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). Repeat 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. QA passed on axceptPro on 24 August; Stripe testing was deferred until a Stripe build was available.

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 | FD: none

Reported during the 19 August Blenheim UAT call. 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, leaving the wrong lead booker name and email against a pass. 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. QA passed on 24 August.

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

Jira: EXN-220 | FD: none

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. EXN-212 covered the same request and was closed as a duplicate. 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. QA passed on 24 August. One test order containing an annual pass, a privilege pass and a day ticket printed two QR codes; Blenheim confirmed one QR per booking as acceptable, and a separate ticket was raised because scanning a booking QR does not yet indicate which booking is being redeemed.

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

Jira: EXN-195 | FD: none

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. In this build Date of Birth is optional when editing an existing customer, 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. 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; change name plus other details together; 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. QA passed on 24 August. Two observations from that run: on an entitlement product the field remained marked mandatory and Save was blocked until a date was entered, and on HRP removing a stored date on POS gave no warning where Reservations does. Both fed into the follow-up in 3.0.14.1.

Also included

• Removed a redundant progress reset from the refund flow. Internal only, no customer-facing change.

Points to check before publishing

• This tag was replaced by v3.0.14.1 on 26 August. If a client environment is on 3.0.14, upgrading to 3.0.14.1 or later is the recommended path; the 3.0.14.1 notes describe what changed.
• Stripe builds were not tested for CORE-9064 at the time of QA sign-off.