Payments · ETL · Offline-first POS platform

An offline-first Android POS that keeps selling when the connection dies

Client: ETL, a Dublin company Product: the Android POS application and the white-label platform behind it

Connectivity in the shops and markets fails routinely, and the hardware is whatever the field actually holds. Offline is the normal case in this system, not the error case.

PURPLEDECKS · EST. 2012 · 53.7°N 7.8°W · IRELAND · EU

Outcome

Our longest client relationship. Still live, still trading.

Thirteen client brands have run on the one codebase across its life. It sells its voucher stock with no connection, syncs when one returns, and prints on the printers already in the shops.

Purpledecks built the offline-first Android POS (EPOS) platform that sells prepaid vouchers and airtime through shops, markets and bazaars in Algeria and other African markets, and has maintained it since 2014.

The Android application, the offline sales engine, the printing system and the white-label machinery behind thirteen branded apps are ours.

The platform, the distribution business, the markets and the operator relationships are ETL's, and the brands belong to ETL and its distributors. We built the software.

The constraint

In 2014, ETL, a Dublin company, was tendering for a distribution contract in Algeria: selling prepaid phone credit through thousands of small retail points. They came to Purpledecks through a referral, to help win it. The brief sounded simple. A tablet app that sells vouchers and prints receipts.

The field said otherwise. Connectivity in the shops and markets fails routinely. The hardware is whatever is actually out there, and ETL's own device analysis showed it was older than anything a spec sheet would choose. Within months of first deployment, the system met an Android 4.0 tablet nobody had planned for.

So the design centre moved. Offline is not the error case in this system. Offline is the normal case, and a connection is a bonus.

What Purpledecks built

Selling with no connection

The device holds pre-provisioned voucher stock locally. Each voucher on the device can be sold with no connectivity at all. When a connection returns, sales sync back: queued locally, uploaded in batches, and removed only when the server confirms them.

Sold once, never twice

A voucher is consumed the moment it is sold, so it cannot be selected again. Uniqueness is enforced at the database level. And server-side operations commit in two steps, so a half-finished transaction never lands as a duplicate sale.

The voucher exists before the printer does

Voucher formats are pre-created on the device. Per-product templates are fetched and stored ahead of any sale, and the layout is fully built in memory before a single byte reaches a printer. The thermal typography is hand-set to fixed-width columns, 57, 60 or 80 characters, with per-product layout rules.

Printing on what the shops already use

Bluetooth, USB and network printing run on vendor-agnostic ESC/POS, Arabic codepages included, so the platform is not tied to any one printer manufacturer. A fourth path prints A4 PDF through the system print framework. In the early years the same job was done over serial cable.

Android 4.x to 15, one codebase

The same application has run from Android 4.x to Android 15, on phones, tablets and dedicated POS hardware, multilingual including Arabic and French. There is still a workaround in the code for an Android 4.0 USB printing bug, carrying its Google issue number. That is what keeping a system alive actually looks like. More than 170 releases over its life.

The mechanisms above are ours. The catalogue, the stock and the commercial rules that run through them are ETL's.

The voucher point-of-sale app on a rugged tablet in a counter stand, with a small thermal printer beside it feeding a printed voucher slip into a hand.
The point-of-sale app on a counter unit, printing a voucher.

One white-label voucher management system, thirteen brands

Thirteen brands have run on this codebase across its life: Ooredoo, currently in operator acceptance testing, DZGO, Thabet Vouchers (Ethiopia), Juice, ACE, Proserve, Startech, Condor, CAPS, StarBrands and IRIS, with El Djazira Telecom and NMPI now retired. Every one of them is ETL's or its distributors'. Purpledecks' client is ETL.

Each brand differs only in its identity, its backend and its Firebase project. The logic, the printing and the product catalogs are shared and driven from the server. A new brand is configuration and assets, not a new app: one white-label POS, thirteen identities.

The platform runs on point-of-sale hardware from Condor, the Algerian electronics manufacturer, and once shipped under Condor's own brand. It was delivered alongside BMB, a regional systems integrator, and it integrates with mobile operator top-up rails.

This is what a white-label voucher management system looks like when it has had to survive the real world since 2014: carrying whichever brand the build is given, on whatever hardware the field actually holds.

Straight answers

Can a POS system work without internet?

Yes, if offline is the design centre rather than a fallback. The platform Purpledecks built for ETL holds its voucher stock on the device, sells with no connection, and syncs when one returns. So a POS does not need the internet to trade, provided it was designed not to. One that merely tolerates offline is a different, weaker thing.

How do offline POS systems work?

Three mechanisms. Stock or catalog data held locally, so the sale completes on the device. A durable local queue for completed transactions. And a sync path that uploads when connectivity returns and deletes only on confirmed receipt. The system Purpledecks built does all three, with double-sale protection on top.

How do you stop a voucher being sold twice offline?

Consume it at the moment of sale, so it cannot be selected again. Enforce uniqueness in the local database. And commit server-side operations in two steps, so an interrupted transaction never lands twice. That is how Purpledecks built it, in a system that has run in the field since 2014.

What is electronic voucher distribution (EVD)?

The distribution of prepaid credit, airtime top-ups, vouchers and e-pins, from an operator or supplier down through distributors to retail points, electronically rather than on scratch cards. The systems that run it are the quiet infrastructure of prepaid markets. The platform on this page is one of them, built and maintained by Purpledecks.

What is a voucher management system?

The software that manages voucher stock, allocation, sale and reconciliation across a distribution network. The Purpledecks-built platform on this page is one, white-labelled: thirteen brands have run on the same codebase.

What kind of printers does a voucher POS need?

The ones the shops already use. That is why the platform Purpledecks built speaks vendor-agnostic ESC/POS over Bluetooth, USB and network, and prints A4 through the system print framework when no receipt printer is present.

Can one app carry many brands?

Yes. Thirteen brands have run on this one codebase across its life, each with its own identity and backend, none with its own fork. Purpledecks built the white-label machinery that makes a new brand configuration rather than a new app.

Next

This system was never rebuilt. It was maintained: through printer generations, Android generations and brand launches, by the same firm, since 2014.

If you have a system that has to keep working when the connection dies, or a platform that has to carry many brands without forking, that is the shape of work we do. Talk to the senior engineers who would do the work.

Start a conversation More of our work →

Technical review by Brian Egan, founder.

Purpledecks is a senior software engineering firm based in Ireland, in the EU, working since 2012. We build and rescue software that has to work.