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

Release summary

POS app v3.0.14.1 (tag v3.0.14.1, 26 August 2026) is a rebuild of the 3.0.14 line on top of v3.0.13. It contains the same five Jira tickets as v3.0.14, delivered as individual commits rather than the single squashed 3.0.14 commit, plus a follow-up to the Date of Birth work (EXN-195, PR #694) that makes customer detail validation aware of the product being edited. Seven commits, no database migrations.

The headline items are unchanged from 3.0.14:

• HRP: mobile card payments can no longer be recorded under a different payment method, the root cause of the "Reversed" entries in the OCC portal.
• Blenheim Palace: basket cleared when returning to the home screen; one QR code per booking on printed receipts; Date of Birth handling on customer edit.

What is new in 3.0.14.1 is the Date of Birth follow-up: the requirement now depends on the product and entitlement status of the order being edited, required-field messages have been added for phone, email, country, address and postcode, and validation errors are cleared selectively so unrelated warnings are not lost. 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 (3.0.14 build); Stripe testing was scheduled once 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 (3.0.14 build).

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 (3.0.14 build). Blenheim confirmed one QR per booking as acceptable; a separate ticket was raised because scanning a booking QR does not yet indicate which booking is being redeemed.

Date of Birth validation on customer edit now reflects the product and entitlement status of the order

Jira: EXN-195 | FD: none

The original 3.0.14 change made Date of Birth optional when editing any existing customer, following the ticket's stated rule. QA on that build found that entitlement products still enforced the field, and that removing a stored date on an HRP entitlement booking on POS gave no warning where Reservations does. The 3.0.14.1 follow-up (PR #694) reworks the contact details validation so the Date of Birth requirement is resolved from the selected product, the order details and the entitlement status across the purchase, edit, amendment and membership flows, rather than being a blanket rule. Edit flows now refresh product information and validate preloaded customer details more reliably, with catalogue product details preferred and a fallback when they are unavailable. Required-field messages have been added for phone, email, country, address and postcode, and validation errors are now cleared selectively so that fixing one field does not remove unrelated mandatory-field warnings. Postcode and Gift Aid error handling has been tightened as part of the same change. Testing: repeat the full EXN-195 test set on this build. On a non-entitlement product (standard admission or event) edit the name, leave Date of Birth empty and save; confirm no mandatory marker and no pre-applied highlight. On an entitlement product (membership, patronage, voucher) confirm the Date of Birth behaviour matches what the product requires and that a missing or invalid date is highlighted where required. Enter an invalid date and confirm validation fires; enter a valid date and confirm it saves. Confirm the Save button reflects the form's validity and that the new required-field messages appear for phone, email, country, address and postcode when those are mandatory. Regression: the normal add-ticket flow with Date of Birth is unchanged. Following this build, the developer asked for all EXN-195 test cases to be re-run, and QA reported on hrp-update that Date of Birth was no longer required and had disappeared from the Customer Details panel; that observation, together with the entitlement cases, was carried forward and addressed in the 3.0.15 line.

Points to check before publishing

• The Jira QA sign-offs for CORE-9064, EXN-220 and EXN-245 were recorded against the 3.0.14 build on 24 August. The code for those items is the same in 3.0.14.1, but the EXN-195 rework touches shared contact details validation, so a regression pass on 3.0.14.1 is advisable before quoting these as verified on this tag.
• The EXN-195 regression noted on hrp-update on 26 August (Date of Birth missing from the Customer Details panel) was open when this tag shipped.
• The context dump records v3.0.14's single squashed commit as not present in the 3.0.14.1 history; the fixes are present as individual commits, so an environment moving from 3.0.14 to 3.0.14.1 loses nothing functionally.
• Stripe builds were not tested for CORE-9064 at the time of QA sign-off.