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

Previous Releases

Mobile and Desktop POS + Scanning release notes - 3.0.0 (Version 3 Candidate)

Mobile and Desktop POS + Scanning release notes - 3.0.1

Mobile and Desktop POS + Scanning release notes - 3.0.2

Mobile and Desktop POS + Scanning release notes - 3.0.3

HRP - Ability to manually redeem tickets scanned at wrong time keeping location permissions

Jira: CORE-8763

This tickets fixes the issue raised as part of CORE-8441, ability to manually redeem tickets scanned at wrong time at select locations.

The backend:

Access ticket expiry dates via the TicketV3 API—the expiry_date field is now included in ticket responses, allowing you to see when each ticket expires.

POS:

Updated behaviour

• With Settings → Allow Manual Redemption on (not in fast-scan flow), Redeem is available when at least one ticket can be redeemed under override rules: not fully redeemed, not suspended/upgraded, correct location, and allowed sub-location — time interval is not required for override.
• Wrong location or sub-location still blocks manual redemption; time warnings may still display.
• Fast scanning does not use manual redemption override.
• Partially redeemed tickets past expiry_date are treated as expired for booking status, auto-redeem, and “anything could be redeemed” unless all-day ticket or other valid redeemable items apply.
• Session logs include allowManualRedemption.

Rules

Manual override redemption is allowed when:

• Allow Manual Redemption is enabled, and flow is not fast scan, and
• Ticket is not upgraded, suspended, or fully redeemed, and
• Location is valid and scan permission is granted for that ticket.

Manual override does not bypass wrong location or sub-location.

Partially redeemed multi-use ticket is not redeemable when:

• expiry_date is in the past (local time), and all-day override does not apply, and nothing else in the booking can be redeemed.

Edge case

Backend may return REDEEMED with remaining uses while expiry_date has passed; POS now aligns expiry with expiry_date, not status alone.

Summary

Staff at the correct gate can manually redeem time-failed scans without weakening location controls; expired partial multi-use tickets are handled consistently.

POS - applying promo issue

Jira: CORE-8792

What was wrong

On the payment screen, a promotion could appear on the booking while the amount to pay did not include the discount. Staff could also see a misleading message when removing a promotion.

What you will see now

When a promotion applies successfully, the total updates to the discounted amount and a clear “Promotion is applied” message is shown. Removing a promotion updates the total and shows “Promotion removed”. Payment options use the updated total, and invalid or offline cases show the appropriate message.

HRP UAT (V3) POS Membership: upgrading an integrated Direct Debit membership charges wrong price and loses Direct Debit flag

Jira: CORE-8798

What was wrong

When staff upgraded or changed a membership that was already on Direct Debit, the till could charge the standard (non–Direct Debit) price and lose the Direct Debit payment type on the updated membership.

What you will see now

Upgrading or changing an existing Direct Debit membership keeps Direct Debit and applies the correct pricing when no payment-method choice is shown.

The following items are internal to Expian and/or cannot be tested by customers.

Support different clients per build

Jira: CORE-8673

What’s new

• On internal QA builds (expianqa, demo), the login screen shows which API environment and client are selected (same information as in Settings).
• While choosing environment or client before tapping Next, that information updates immediately so you can confirm the right backend before signing in.
• After sign-in, on those same internal builds, the top bar shows the active client and a short API host (for example HRP Test, expianqa.expian.io/) so support can see what the till is using during the session.
• On scanning and desktop, this appears as a subtitle under the main toolbar title; on mobile, it appears as an extra line under the toolbar (sales shift id stays visible where applicable).

Why

Internal and UAT testing needs visible confirmation of environment and client without opening Settings on every step.

How to use

1. On an internal QA build, open the app → pick Environment (and Client if shown).
2. Check the lines at the top of the login screen — they should match your dropdown choices before you tap Next.
3. Sign in → on the main screen, check the toolbar for client and API host.
4. You can still confirm the same details in Settings at any time.

Important

• Production client builds (for example Blenheim, HRP production) do not show this extra login block or toolbar text — only builds marked as internal QA/demo.
• Changing environment or client still clears local data and requires sign-in again, as before.
• Device setup (serial, printers, card reader) is still kept when switching environment or client.

What you need to do

No Admin changes. Use the internal QA APK your team provides (expianqa or demo). Re-login after switching environment or client.

POS - refactor GoCity access

Jira: CORE-8793

• Enhanced the security architecture for integrations with third-party services by preparing backend-managed authentication and communication flows.
• Refactored the integration layer to support seamless transition between data sources and backend services.
• Removed sensitive information from local application storage and logging mechanisms to strengthen data protection.
• Improved build and deployment processes by introducing environment-specific secret management, ensuring credentials are only available where required.