Skip to content

POS Delivery Roadmap

This roadmap keeps the standalone POS product country-neutral. Kenya is the first procurement and certification profile, not the definition of the POS domain. Provider brands, tax authorities and country validation rules belong in opt-in adapters selected by each store's operating profile.

Current position

The repository, service/database boundary, web portals, Android client, merchant credentials, terminal enrollment, POS-owned retail data, provider ports, remote TEST environment, cash/refund/receipt UAT and the Core merchant-collection contract are implemented. A real POS-to-Core create/status/cancel lifecycle has passed. The remaining pilot blockers are:

  1. customer-approved capture followed by provider-confirmed refund through the POS adapter;
  2. physical handheld printer and scanner acceptance on the exact purchased firmware;
  3. governed merge of the draft Core contract pull request, followed by the explicitly held legacy-Core POS extraction and a serialized rollout; the standalone POS mainline is merged and its source-exact images are published;
  4. one-time GHCR package-owner configuration granting mozacalabs/emali2-pos Write under each package's Manage Actions access, followed by a successful repository-token publisher retry;
  5. production identities, data stores, secrets, monitoring, provider credentials and rollback rehearsal.

Phase 1 — TEST pilot acceptance

Required before pilot sign-off

  • Complete one real customer-approved Emali-app payment and full refund.
  • Prove no captured payment can lack its Core transaction binding.
  • Re-run cancellation, denial, expiry, timeout and capture-wins-race cases.
  • Buy one conditional CS30 evaluation unit, or an equivalent Android 11+ terminal, only after the seller passes the acceptance demonstration.
  • Run 25-receipt, paper-out, reconnect, sleep/wake and marked-reprint tests.
  • Qualify EAN-13, Code 128 and QR scanning through the exact scanner contract.
  • Capture sanitized hardware evidence in the acceptance report.
  • Keep the POS service and database independently backed up and restore them without a platform database.
  • Close all current CI, security, migration, API-contract and rollback gates.

Pilot outcome

One merchant can operate a proof-bearing Android, browser or hardware terminal, sell from POS-owned inventory, collect cash or an Emali customer-app payment, issue a receipt, refund through the original tender, close the shift and reconcile without direct Core code or database access.

Phase 2 — Kenya reference deployment

This phase begins only after Phase 1 is accepted. It must not change generic sale, tender, receipt or fiscal domain types.

M-PESA/Daraja adapter

  • Obtain the pilot merchant's approved Daraja application, shortcode, passkey, callback domain and settlement/reversal operating process.
  • Complete sandbox STK Push, callback signature, query-after-timeout, conflicting-callback, duplicate-callback and reconciliation tests.
  • Keep KES/MSISDN/shortcode rules inside MPESA_DARAJA.
  • Do not record an M-PESA tender as captured until the provider callback or authoritative query supplies matching captured evidence.
  • Do not enable reversal/refund until the merchant's approved Daraja workflow and result callbacks have been certified operationally.

KRA eTIMS adapter

  • Decide OSCU versus VSCU from the merchant's actual online/offline invoicing model; the implemented reference adapter is OSCU, while VSCU remains a separate future adapter.
  • Complete KRA sandbox onboarding, taxpayer/branch/item mapping, sale, cancellation, credit-note, outage and reconciliation cases.
  • Complete KRA self-integrator or third-party certification before production.
  • Treat “eTIMS ready” hardware or seller marketing as no certification evidence.
  • Keep fiscalizationRequired=false until the merchant and adapter are approved.

Kenya operational gates

  • Confirm merchant/provider contracts and settlement ownership.
  • Complete data-controller/processor, retention, incident and cross-border controls, including required ODPC registrations.
  • Obtain final written hardware quotations with VAT, delivery, warranty, replacement parts and exact SKU/firmware.

Phase 3 — Production foundation

  • Provision a separate production POS PostgreSQL cluster, object storage, encryption keys and immutable backup/WAL archive.
  • Provision production-only OAuth clients, audiences, roles and exact client-organization-store bindings; prefer private_key_jwt for machine identities.
  • Remove transitional shared-secret authentication after a rehearsed key rotation and rollback window.
  • Deploy immutable source-attested images through the reviewed manual workflow.
  • Add SLOs and alerts for API availability, outbox age, pending electronic tenders, callback failure, reconciliation age, fiscalization quarantine, backup freshness and terminal fleet health.
  • Run restore, point-in-time recovery, lost-terminal recovery, provider outage and rollback drills before accepting live money.
  • Scale the production API above zero only after every gate passes.

Phase 4 — Multi-country expansion

Each new country supplies configuration plus adapters; it does not fork the POS domain.

  • Add a store operating profile for ISO country/currency, locale, timezone, fiscalization and provider capability bindings.
  • Implement a new MobileMoneyPort, card/acquirer, fiscalization or receipt delivery adapter behind a stable provider code.
  • Add provider conformance tests for initiation, terminal states, duplicate delivery, unknown outcome, refund/reversal and reconciliation.
  • Prove a non-Kenyan store starts and trades without loading Daraja or KRA configuration.
  • Maintain the same POS API and event contracts for Emali and third-party POS clients.

Product increments after launch

Priority Increment Why it matters
v1.1 Customer receipt delivery preferences and verified resend Reduces paper dependence without exposing receipt capabilities
v1.1 Promotions, richer customer history and branch operations polish Improves day-to-day retail value
v1.1 Production provider-statement adapters, alert routing and acknowledgement history Shortens unresolved-payment handling
v1.2 Exact-firmware built-in printer adapters and richer lane diagnostics Converts transport acceptance into truthful device confirmation
v1.2 Cash-drawer controls, scanner setup and receipt-template refinement Completes countertop-lane ergonomics
v2 Signed outbound webhooks and accounting/ERP export Removes polling for external systems
v2 Ecommerce sync, BOPIS, purchase orders and supplier workflows Extends POS into omnichannel operations
v2 Certified card-present/acquirer production integration Adds card acceptance without exposing PAN/PIN to POS

Nice to have, not launch blockers

  • QR-based customer identification and loyalty enrollment.
  • Electronic shelf-label and weighing-scale adapters.
  • Multi-language cashier prompts beyond locale formatting.
  • Offline-safe promotion evaluation from signed policy snapshots.
  • Fleet remote-assistance diagnostics with explicit merchant consent.
  • Forecasting, shrinkage analysis and reorder recommendations.
  • Customer display and kitchen/order-routing screens.

These features must not delay the customer-approved payment/refund proof, physical hardware acceptance, certification or production security gates.

Strategic differentiators

  • Emali-native merchant collection using the customer's registered approval device.
  • The same safe POS API for Emali clients and existing third-party POS/ERP systems.
  • Loyalty as an operational tender without confusing it with platform money.
  • A strict split between POS retail truth and regulated wallet/card ledgers.
  • Country adapters that can be added without locking the product to Kenya.
  • Unified merchant operations across backoffice, countertop and handheld channels.