// Case studySaaS● archived

Cashske

Payment automation for mobile-wallet cash — a transfer lands on a phone and the customer's order is credited seconds later, with nobody watching.

2023 Egypt Fintech · Payment automation

FintechPaymentsMobile money

Build something similar

// By the numbers

3
Codebases: 5
Product surfaces: AR · EN
Interface languages: 2
Auth layers

// The problem

What the business was up against

A small Egyptian merchant selling online in 2023 had no good way to take money. Card gateways were expensive and gated behind KYC that a young business could not clear, so the practical alternative was the one their customers already used: mobile wallet transfers. That worked, but only manually. The transfer arrived as an SMS on somebody's phone, and a person had to read it, find the matching order, decide whether the amount was right, and credit the customer by hand. It did not scale past a few dozen orders a day, it ran only while someone was awake, and every step of it was a place to make a mistake. The payment rail existed and worked fine — what was missing was everything between the notification and the order.

// Overview

A payment-reconciliation platform for merchants who could not get a card gateway. Mobile wallets were already how their customers paid — the gap was that a wallet transfer landed as a text message on a phone, with no connection to the order waiting online. Cashske closed that gap: a companion Android app watched the receiving phone, a parser pulled the amount and sender out of the bilingual notification, and the backend matched it to an order and credited it in real time. Three codebases — a Node.js API, web dashboards for merchants and administrators, and the Flutter app that made the whole thing work.

// Architecture

How it's put together

01Detection

Companion App

Flutter Android — watches the receiving phone

Notification Parser

Bilingual extraction of amount, sender, reference

Offline Queue

Hive-backed retry until delivery is confirmed

02Application layer

REST API

Merchants · transactions · payments · keys

Merchant Dashboard

Balance, history, configuration

Admin Console

Accounts, payments, abuse tooling

03Data

MongoDB

Merchants, transactions, balances, configuration

04Integrations

PerfectPanel

Credits the end customer in the merchant's panel

Kashier

Hosted checkout for balance top-ups

Transactional Email

Verification and account mail

The companion phone is the sensor; the API is the only thing that decides whether an order gets credited.

// Engineering decisions

The calls that shaped it

The handful of decisions that determined how this system behaves — and what each one bought.

01
A bridge over an existing rail, not a new one
Becoming a payment processor means licensing, settlement and holding other people's money. Cashske deliberately did none of that — the wallet transfer goes directly from customer to merchant on the telecom's rail, and the platform only observes that it happened and tells the store. Reconciliation rather than processing is what made the product buildable by a small team, and it is the distinction the whole design follows from.
02
The receiving phone is the integration point
There was no API for incoming wallet transfers, so the only reliable signal was the notification the wallet itself sends. A companion Android app running on the phone that receives those messages became the sensor — an unglamorous integration, but the one that actually existed, and building against the real rail beat waiting for an official one.
03
Parse the notification bilingually, or parse nothing
Wallet notifications arrive in Arabic or English depending on the sender's handset and provider, with the amount, sender and reference formatted differently in each. The parser had to handle both to be useful at all, so bilingual extraction was a requirement of the core loop rather than a localisation task layered on afterwards.
04
Assume the phone will lose connectivity
The sensor is a consumer handset on a mobile network, so dropped connections are the normal case, not the failure case. Confirmed transfers queue locally in Hive and drain when the network returns, and a periodic sweep re-checks for messages that arrived while the service was down — because a payment that is detected but never delivered is indistinguishable, to the customer, from one that was never detected.
05
Meet merchants inside the software they already sell from
Most target merchants ran PerfectPanel, so the platform integrates with it natively and credits the end customer's balance there directly — no glue code on the merchant's side. A REST API with its own key-based auth covers everyone running something custom. Integrating into the incumbent tool is what made adoption a configuration step instead of a development project.
06
Prepaid fees, so the platform never holds merchant money
Merchants top up a balance and a configurable per-transaction fee is deducted from it as payments reconcile, with card top-ups handled through a hosted Kashier checkout. Keeping the platform's revenue entirely separate from the payment flow meant customer money never sat in an account Cashske controlled.
07
Where the next version would have gone
A later design review identified the parts that needed hardening before scale: a double-entry ledger with atomic balance mutation, reference-code verification so a transfer is matched rather than inferred from an amount, signed webhooks for merchant callbacks, and migration onto official wallet rails as they opened up. That work was specified but not built — the company wound down first. Naming it is more useful than pretending the first iteration was the finished one.

// Highlights

Signature capabilities

Automatic transfer detection

A companion app on the phone receiving wallet notifications reports confirmed transfers to the backend as they arrive, replacing a person reading messages and crediting orders by hand.

Bilingual notification parsing

Amount, sender and reference are extracted from wallet notifications written in either Arabic or English, formatted differently by each provider — the core loop of the product.

Delivery that survives a dropped connection

Confirmed transfers queue on the device and drain when the network returns, with a periodic sweep catching anything that arrived while the service was down.

Native PerfectPanel crediting

For merchants on PerfectPanel, the end customer's balance is credited directly in their own panel, making adoption a configuration step rather than an integration project.

REST API for custom stores

Merchants running their own storefront integrate over a documented API with its own key-based authentication, separate from the dashboard's user sessions.

Administrative and abuse tooling

A role-based console for accounts, transactions and payments, including shared-address analysis across accounts, blocking, manual balance adjustment and a global configuration system.

// Features

Business feature set

The functional scope delivered across every part of the product.

Payment reconciliation

Automatic detection of incoming wallet transfers
Bilingual Arabic and English notification parsing
Real-time crediting of the matching order
Periodic reconciliation sweep for missed notifications
Transaction history with search

Merchant dashboard

Balance and transaction overview
Top-up by card or wallet transfer
API key management
PerfectPanel, domain and currency configuration
Device management for companion phones
Usage analytics and charts

Companion app

Background service on the receiving phone
Offline retry queue with guaranteed delivery
Live balance and searchable history
Device registration and management
Right-to-left Arabic interface

Administration

Account and merchant management
Payment and top-up oversight
Shared-address analysis and blocking
Manual balance adjustment
Role-based administrator accounts
Global configuration and messaging

// Outcome

What changed operationally

Documented outcomes from the delivered system. Where exact figures are confidential, the operational change is stated instead.

Manual payment checking replaced by automatic detection and crediting
Merchants without card-gateway access able to take online payments on the rail their customers already used
Real-time crediting into PerfectPanel, or into a custom store over a REST API
Offline-tolerant delivery from the companion app, with a reconciliation sweep for missed notifications
Prepaid per-transaction fee model with card top-ups through a hosted checkout
Administrative console with account, transaction and abuse-management tooling
Three codebases and five product surfaces delivered and operated together
Right-to-left Arabic across every merchant-facing surface

// Constraints

What we had to work within

No official API for incoming wallet transfers — the notification was the only available signal
The sensor is a consumer Android phone on a mobile network, so connectivity is unreliable by default
Wallet notifications arrive in Arabic or English, formatted differently by provider
Target merchants could not clear card-gateway KYC — that exclusion was the reason the product existed
Merchants ran an existing panel product, so integration had to be configuration, not development
Small team across backend, web and mobile simultaneously

// My role