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

Release summary

POS app v3.0.13 (tag v3.0.13, 17 August 2026) consolidates everything shipped on the 3.0 line since v3.0.10.2, taking in the 3.0.10, 3.0.10.3, 3.0.11 and 3.0.12 increments. It covers 16 Jira tickets across 27 commits with no database migrations. Blenheim Palace received this build on 21 August; several of the earlier items had already reached BP-UAT (pos-3.0.10, 3 July) and HRP-UAT (pos-3.0.10, 30 July).

The headline items are:

• Name field validation on the POS terminal brought into line with the web journeys, closing the HRP support case on lost name validation (CORE-8829) for the terminal channel.
• Three security hardening items from the pentest gap analysis: encrypted credentials, an encrypted local database, and screenshot protection on sensitive screens.
• A set of Blenheim Palace MVP items around passes: beneficiary names shown at redemption, family pass upgrades keeping their passholders, suspend and reinstate with a reason logged to the reservation notes, no automatic Gift Aid receipt, and the incorrect promo warning on voucher-purchased tickets removed.
• Operational fixes: the print stage no longer hangs silently when the printer is unavailable, the Change product button shows correctly for long-validity date products during amendment, and Force offline mode now works on first launch.

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

Items in this release

Name fields on POS now reject digits and special characters, matching the web booking journeys (HRP)

Jira: V3-203 (related: CORE-8829, V3-194) | FD: 4943

HRP reported that first and last name fields on B2C and Reservations had lost their validation and were accepting numbers. That was fixed on the web (CORE-8829 in 2.9.3 hotfix 6.5, reconciled into 3.2.1 under V3-194), but the PAX A920Pro terminal is a separate app and still accepted values such as 555556. POS now applies the same rule: a name must contain at least one letter and may only contain letters (including accents), spaces, apostrophes, hyphens and full stops; it may not start or end with an apostrophe, hyphen or full stop, and double full stops are rejected. Membership names need two or more characters; patron names may be a single letter. This applies to lead customer, passenger, membership member, patron and payment-screen customer detail fields. Vehicle plate, address, town, postcode, phone and date of birth are unchanged and still accept numbers. Follow-up commits in 3.0.13 extended the rule to custom fields and corrected the patron and additional member cases. Testing: attempt to enter John99, 99John, Henry 8, 123, John*, Test@, -John and John. in each name field and confirm an error is shown and Next or Submit is blocked; confirm John, José, Anne-Marie, O'Brien, Van Der Berg and Dr. Michael are accepted; confirm membership names reject a single letter and patron names accept one; confirm the numeric fields listed above still accept digits. QA passed on 12 August, with two observations raised: the rule was not yet applied to Beneficiary details on Blenheim Palace, and Adult Member 2 on a patronage rejected a single letter where the lead patron accepted one.

Printing no longer hangs silently on "Printing Receipt" when the printer is unavailable

Jira: CORE-9035 | FD: none

On a mobile build with no working PAX printer, completing an order launched the print screen which then sat on "Printing Receipt" indefinitely: no error, no snackbar, no Retry, and both queued print items silently discarded when the operator pressed Back. The underlying cause was a printer initialisation failure (missing native library) followed by a toast raised off the main thread, both swallowed by the print guard. The print flow now surfaces the existing error path: error text on the print screen, an error snackbar, a Retry button and the Send email fallback. Testing: the printer-unavailable state could not be reproduced on hardware because the printer is built into the desktop device, so QA ran regression only. On desktop and MPOS confirm a normal order prints ticket and receipt, Send email, Print receipt and Print tickets all work, a Gift Aid order prints the Gift Aid statement, and a refund prints the refund receipt. QA passed regression on 13 August.

Change product button now shows during amendment for long-validity date products

Jira: CORE-9012 | FD: none

During the amendment flow the Change product button was hidden for date booking-unit products whose validity spans more than one day (for example a 30-day pass), because the check only looked at the start date rather than the validity window. The check now uses the full window (start date to start date plus validity), so the button stays visible while today falls inside it. Products with a blank or unparseable validity fall back to single-day behaviour; open and time products are unchanged. Testing: on a Blenheim pass product, amend an order whose booked date is a few days ago but still within validity and confirm Change product is visible; amend one whose validity has fully expired and confirm it is hidden; confirm a single-day date product booked in the past still hides the button and one booked for today or later still shows it; confirm open products always show it. QA passed on 28 July. One case, an expired pass whose expiry date had been edited manually so that start plus validity was still in the future, showed the button and was parked for separate discussion with product.

"Check applied promo" warning no longer shown when scanning tickets purchased with a gift voucher (Blenheim Palace)

Jira: EXN-71 | FD: none

Scanning a ticket bought with a gift voucher on the A920Pro displayed "Ticket is valid. Check applied promo before redeeming." A gift voucher is a payment method, not a promotion, so the warning was misleading and slowed gate staff down. Entitlement-based promotions arising from voucher redemption no longer trigger the warning; a genuine promotional discount still does, including where a voucher and a promo are both present. Testing: purchase an annual pass gift voucher, redeem it against a pass and scan the resulting ticket via both search and redeem on MPOS, confirming "Ticket is valid" with no promo warning; scan a pass with no promo and confirm no change; scan a pass bought with a discount code and confirm the promo warning still appears. QA passed on 23 July.

Beneficiary names shown when selecting, redeeming, cancelling and suspending passes (Blenheim Palace)

Jira: EXN-88 (parent EXN-72) | FD: none

The Redeem Tickets screen listed only ticket type, code and scan count, so on a family annual pass labelled "Adult, Adult, Child, Child" gate staff could not tell which pass belonged to which person. POS now displays the beneficiary's first and last name on each ticket line when selecting, redeeming, cancelling, suspending and reviewing redeemed passes. Where name capture is enabled but no name has been recorded, the line shows "Name not captured" rather than being blank. The Reservations side of this was delivered separately under EXN-72 in v3.4.0. Testing: on MPOS and desktop, open a booking with several named passholders and confirm names appear when selecting, redeeming, cancelling and suspending; open a booking with no beneficiary names captured and confirm the placeholder. QA passed on 23 July.

Family annual pass upgrade on the E700 no longer clears passholder details via the Search User step (Blenheim Palace)

Jira: EXN-74 | FD: none

When upgrading a family annual pass on the E700, the operator was prompted to search for the customer; selecting the account then loaded the Customer Booking Information screen with every passholder field empty. The Search User step should not appear during an amendment at all, because the original customer cannot be changed and the search action was wiping the existing customer. Mobile was unaffected because it never shows that step in the amendment flow. The step is now suppressed during amendments, and search restoration only applies to non-edit transactions. Testing: on desktop POS, open a family pass order (two adults, two children) and upgrade it to a Privilege Play Pass, confirming existing beneficiary and passholder details remain and the upgrade completes; repeat for a single pass and for a pass with partial beneficiary details; confirm a new sale still opens user search, and that booking on behalf of another user still restores the search step outside edit mode. QA passed on 23 July.

Suspend and reinstate a pass with a reason, logged to the reservation notes (Blenheim Palace)

Jira: EXN-152 | FD: none

Blenheim asked for a visible audit trail when a pass is suspended, reinstated or has its validity changed. POS now shows a unified confirmation dialog for suspend, reinstate and cancel actions. Suspend and reinstate take an optional reason; cancel requires one and blocks confirmation until a non-blank reason is entered. On completion a note is written to the reservation in the form Ticket type (customer name) suspended or reinstated, with the reason appended where given, saved after the action succeeds and before the reservation view refreshes. The previous cancel confirmation dialog has been replaced by the unified one. Testing: open a booking with a suspendable pass, suspend it with and without a reason and confirm the pass status and note text; attempt to use the suspended pass and confirm it is rejected; reinstate with and without a reason; on a multi-pass or bundle booking suspend one member and confirm only that row changes and the note names the correct ticket and customer; on cancel, confirm the Confirm button stays disabled for blank or whitespace reasons and that closing the dialog takes no action; check both A920Pro and E700 layouts. QA passed on 20 to 21 August. Note that cancellation currently records only the reason rather than the full formatted note; this was agreed as out of scope and raised separately.

Gift Aid receipt no longer printed automatically for Blenheim Palace

Jira: EXN-154 | FD: none

Blenheim asked to stop the automatic Gift Aid receipt print because it is long, carries the customer's name and email, and duplicates the declaration already included in the annual pass confirmation email. The Gift Aid receipt is now excluded from the automatic print queue for the Blenheim Palace market only; staff can still print it explicitly from the order complete screen. All other markets continue to queue it automatically when the order has active Gift Aid consent. This is market-specific, not a device setting. Testing: on desktop and MPOS in an HRP environment, place a Gift Aid order and confirm the Gift Aid receipt prints automatically; repeat on Blenheim Palace and confirm it does not print automatically but can be printed from the order complete screen. QA passed on 20 August.

Force offline mode now works during first app launch

Jira: EXN-144 | FD: none

The Force offline toggle had no effect if enabled during initial setup on a fresh install or after clearing app data. It now takes effect immediately and keeps the device offline until switched off, and normal connectivity detection resumes once it is disabled. Testing: clear app data or install fresh, enable Force offline, open a screen that checks connectivity such as customer details and confirm the app reports offline; disable and confirm connectivity returns; toggle repeatedly and confirm state tracks each change; confirm real Wi-Fi drops and restores are detected after disabling. Note that the toggle is intentionally not persisted across an app restart, because the app must be online to validate the session at launch; QA initially logged this as a failure and it was confirmed as expected behaviour. QA passed on 12 August.

Clearer button title for beneficiary details on the payment screen

Jira: EXN-147 | FD: none

At Yiannis's request, the payment screen button previously labelled "Other booking details" now reads "Beneficiary details" when the details are complete and "Beneficiary details are missing" when they are not, keeping its error styling in the missing state. Testing: open a booking in the payment flow and check the button title with complete and with missing beneficiary details, confirming it updates when the state changes and remains tappable in both. QA passed on 12 August.

Sensitive screens protected from screenshots and screen recording

Jira: CORE-9003 | FD: none

From the pentest gap analysis: no screen in the app applied FLAG_SECURE, so login, password setup, supervisor login and PIN entry could be screenshotted, screen-recorded or previewed in the recent apps switcher. Protection is now applied to those screens and dialogs; ordinary sales screens remain capturable. A small follow-up fix for the screen-recording flag is included in this tag. Testing: on the login, password setup and supervisor login screens attempt a screenshot (power plus volume down) and a screen recording and confirm they are blocked with the device's "couldn't capture" warning; confirm other screens still allow screenshots; open and dismiss protected dialogs repeatedly and rotate where supported. QA passed on 13 August.

Local database encrypted at rest

Jira: CORE-9007 | FD: none

From the pentest gap analysis: the local Room database holding customer PII, offline orders and tokenised payment metadata was plain unencrypted SQLite. It is now encrypted with SQLCipher, with the passphrase held in the Android Keystore rather than in code or preferences. Existing migrations run against the encrypted database across all build variants. No raw card data was ever stored (payments are tokenised) and the database was already excluded from adb backup; the exposure addressed here is rooted or physically extracted devices. Testing: there is no dedicated functional test; confirm logging in, data loading, logging out and back in, and switching environment all behave normally. QA passed on 12 August.

Access and refresh tokens no longer stored in plaintext

Jira: CORE-8901 | FD: none

OAuth access and refresh tokens were held in a plaintext DataStore. They are now stored encrypted. Testing: no separate test; general login, logout and user switching cover it. QA passed on 23 July.

Also included

The following changes shipped in this tag without a Jira ticket in the context above. Listed for completeness.

• EXPIAN-456 (PR #671): right margin on the Epson printer profile adjusted to stop text clipping.
• EXN-73 (PR #676): isTablet boolean resource added to support tablet and handset layout decisions.
• PR #675: OkHttp aligned to version 5.x for Stripe Terminal compatibility.
• Customer details no longer highlighted as captured when no email address is present.

Points to check before publishing

• Several items (CORE-8901, CORE-9012, EXN-71, EXN-74, EXN-88) carry POS-3.0.10 labels and were on BP-UAT from 3 July and HRP-UAT from 30 July, so clients on those builds have already seen them.
• V3-203: the QA observations about Blenheim beneficiary details and the Adult Member 2 single-letter case should be confirmed as tracked.
• CORE-9035: the printer-unavailable path itself was not exercised on hardware.