PALMPAYClientWallet / Palm / Loyalty
CUSTOMER APP
PalmPay Client
iOS and Android distribution links are activated only after the production applications are published and approved.
PALMPAY MOBILE APPS
PalmPay in the hands of customers and store teams.
Two applications, distinct roles and controlled release paths for iOS and Android.
PALMPAYMerchantStore / Device / Operations
STORE APP
PalmPay Merchant
Request pilot access while production store listings and managed-distribution policies are finalized.
Until public store URLs are configured, use the onboarding form to request pilot, enterprise or managed-distribution access.
Request access
01
PalmPay Client
The customer-facing application.
Identity and consent
Start approved identity verification, review purpose, manage consent and see palm credential status.
Wallet and VA
Choose a merchant wallet, retrieve the assigned VA, initiate top-up and see reconciliation status.
Payment and loyalty
Review palm payment receipts, balances, points, expiry, vouchers and cross-merchant offers.
Security and recovery
Device binding, secure session, notification, lock/revoke, re-enrollment and assisted recovery.
02
PalmPay Merchant
The store and field-operations application.
Checkout visibility
See payment requests, authorization results, receipts and terminal status.
Store operations
Shift view, device alerts, permitted refund workflow, exceptions and escalation.
Loyalty execution
Apply approved voucher, campaign and points actions without changing central rules.
Role control
Cashier, supervisor and store manager permissions remain tenant and store scoped.
03
Release and store governance
No fake app-store claim.
Publication gates
Signed release, penetration test, privacy notice, support owner, crash monitoring and rollback plan.
Store metadata
Approved product name, screenshots, age rating, data safety/privacy disclosure and support URL.
Version policy
Minimum OS, supported devices, forced upgrade policy, end-of-support and vulnerability response.
Applications are products with their own security and support lifecycle
Data minimization
The app should request only permissions required by the approved feature set. Palm capture normally occurs on a dedicated terminal; the mobile app should not claim camera-based palm enrollment unless that mode is separately designed, tested and disclosed.
Device binding
Registration can bind the application session to a trusted device, passkey or approved authenticator. Sensitive actions such as palm credential revocation, high-value configuration or refund approval can require a fresh authentication or step-up check.
Release integrity
Every mobile release should have signed artifacts, controlled build provenance, dependency inventory, security test results, privacy disclosures, crash monitoring, staged rollout and rollback capability. Store metadata must remain consistent with the real production behavior.
Support and recovery
The app needs clear support ownership, account recovery, device replacement, lost-phone handling, session revocation, consent withdrawal, palm re-enrollment and transaction dispute routes. Customers should always have an alternative payment path.
Can customers pay without opening the app?
After approved enrollment and funding, checkout can use the palm terminal without presenting the phone. The app remains the channel for account, consent, wallet, receipts, loyalty and recovery.
Will both apps be public?
PalmPay Client may use public store distribution. PalmPay Merchant may use public, private, managed or enterprise distribution depending on the merchant operating model.
When should store badges appear?
Only after the real listing exists and the production URL, privacy disclosures, supported OS, screenshots and support process have been verified.
MOBILE-ID / TRUSTED PALMPAY
Request app access
Request app access
Mobile-ID will map the requested user group, distribution model, identity path and support requirements.