mPOS Ticketing Platform for Travel Technologyon Android
Selling a ticket on a handheld device at a tour stop is a different problem from selling one at a counter. Kansoft rebuilt the mPOS platform for Android hardware fragmentation, intermittent connectivity and PCI DSS requirements, reaching 95% device compatibility and cutting latency by 30%.
A point of sale that moves, and often loses signal.
Palisis provides travel technology to tour, attraction and transport operators across a global customer base. Its mobile point of sale is used by staff in the field: on a boat, at a bus door, at the entrance to an attraction, on whatever Android hardware the operator bought.
That deployment reality is the whole problem. The platform has to behave identically on a dozen device classes, in direct sunlight, with a card reader paired over Bluetooth and no reliable network, while handling card payments to PCI DSS standards.
Architecture diagram for this engagement is being drawn.
Five constraints a mobile POS faces that a counter POS never does.
Any one of these on its own is manageable. Together they decide whether an operator can actually sell a ticket when a customer is standing in front of them.
Inconsistent experience across devices
Screen sizes, resolutions and ambient lighting vary widely across operator hardware, and an interface tuned for one device became unusable on another.
Latency and battery drain
High API latency slowed transactions and drained batteries on devices expected to last a full operating shift, while offline-first sync requirements added their own load.
Android hardware fragmentation
Card readers, barcode scanners and printers from different manufacturers behave differently across Android versions, and every incompatibility is a sale that cannot be completed.
Payment security on a handheld
Transaction data and API credentials had to be protected to PCI DSS standards on devices that leave the premises and connect over networks nobody controls.
No visibility when something broke
Without centralised logging or performance telemetry, a failure in the field was reported by a frustrated operator rather than detected, and diagnosis started from nothing.
Engineer for the worst device on the worst connection.
A platform that performs well on a flagship phone with full signal tells you nothing. We set the baseline at the hardware and conditions operators actually have, then built the compatibility and observability needed to keep it there.
Discovery and alignment
Stakeholder workshops to define requirements, device coverage targets and the success metrics the platform would be measured against.
Adaptive experience layer
Reusable responsive UI components with 48x48 dp touch standards, built to hold up across screen sizes, resolutions and outdoor lighting.
Performance engineering
Threshold-based API orchestration to cut unnecessary requests, with an offline-first architecture using local caching and automatic sync when connectivity returns.
Compatibility and security
A device compatibility framework validated across card readers, scanners and printers, alongside AES encryption, token-based authentication and server-side credential handling for PCI DSS.
Chosen for offline operation and payment security.
Every choice answers the same question: what happens when the device is in the field, the network is gone, and a customer is waiting to pay.
From a platform that depended on the device to one that works on all of them.
Four measured changes between the previous mPOS build and the platform now in use across the operator base.
Four changes that mattered as much as the numbers.
Compatibility and latency are the measurable results. What they add up to is a platform an operator can deploy without first checking which hardware it tolerates.
Hardware stopped being a blocker
A compatibility framework covering card readers, scanners and printers means onboarding an operator does not start with a list of devices that will not work.
Sales continue without a network
Offline-first operation with local caching and auto-sync means a lost connection delays reconciliation, not the transaction in front of the customer.
Payment security is structural
AES encryption, token-based authentication and server-side credential handling put PCI DSS readiness into the architecture rather than the deployment checklist.
Failures surface before complaints do
Centralised logging and real-time analytics cut issue resolution time by 40%, because diagnosis now begins with data rather than a phone call.
How the work was shaped.
Integration-heavy platforms, built for field conditions.
A mobile POS is mostly integration work: payment gateways, ERP and CRM systems, and a long tail of Bluetooth hardware that each behave slightly differently. Doing that well requires treating device compatibility as a tested framework rather than a support burden, and treating payment security as an architectural constraint from the first design decision. Understanding the travel workflows underneath — booking, ticketing, in-transit payment — is what keeps those engineering choices aligned with how operators actually sell.
Related Case Studies
Xamarin to .NET MAUI Migration for Manufacturing Mobile Apps
A cement manufacturer moved three business-critical apps from end-of-life Xamarin to .NET MAUI in roughly 15 days each, all at UAT inside four weeks.
Procurement Modernization for Manufacturing on .NET 6 and Angular
A cement manufacturer re-engineered its ASP.NET Web Forms procurement platform into a .NET 6 and Angular stack on Azure, keeping every workflow intact.
Angular Frontend Modernization for Travel Tech from Google Web Toolkit
A travel technology platform moved its back office from Google Web Toolkit to Angular module by module, with both systems live and no disruption.