CASE STUDY · WATTLY PAY

Wattly Pay.

A simple payment journey. A complicated transaction lifecycle.

ROLELead Mobile Engineer
SCOPEMobile Experience & Payment Rails
SCALEMulti-Provider Utility Networks
OUTCOMEZero Lost Tokens & State Recovery

1. Project Context & Objectives

Wattly Pay is a dedicated mobile utility application that enables customers to purchase prepaid electricity tokens, pay postpaid utility bills, and track power consumption across regional distribution companies (DISCOs).

The user expectation for utility purchasing is absolute immediacy: enter a meter number, pay the required amount, and receive the 20-digit electricity recharge token instantly to restore power at home or work.

2. The Engineering Problem

Beneath an ostensibly straightforward checkout screen lies an inherently brittle, multi-party settlement chain. Transactions involve the customer's mobile payment rail, a payment gateway aggregator, and regional utility DISCO mainframes that frequently suffer from network timeouts, delayed webhooks, or intermittent downtime.

In standard mobile implementations, an upstream timeout during token generation triggers a generic failure modal—even when the customer's bank account was successfully debited. This causes severe friction, duplicate purchase attempts, and frantic support requests.

3. Role & Responsibilities

As lead engineer on the mobile client, I had end-to-end responsibility for:

  • Designing and implementing the cross-platform mobile application in React Native.
  • Architecting the transaction recovery state machine and asynchronous verification rail.
  • Implementing pre-transaction validation: instant meter number verification and DISCO resolution.
  • Building secure on-device persistence for purchased tokens to guarantee access even in offline conditions.

4. Architectural Decisions & Tradeoffs

DECISION 01

Live Meter Lookup & Name Verification

Before allowing a user to finalize payment, the client executes an automated debounced lookup against the utility database. By confirming the customer's registered name and physical meter address upfront, we eliminated the leading cause of irreversible financial loss: entering an incorrect digit and funding someone else's meter.

DECISION 02

First-Class Asynchronous Status Rail

We treated “Pending” not as an error condition, but as an expected stage in the transaction lifecycle. If a utility provider takes longer than 5 seconds to generate a token, the UI shifts cleanly to an active tracking view. Background retry workers query status idempotently, updating the customer via push notification the moment the token is generated.

DECISION 03

Offline-Resilient Token Vault

When an electricity token is delivered, it is written immediately to encrypted local storage with full transaction metadata (token number, units generated, date, and meter reference). Customers can retrieve their token to key into their physical meter even if cellular coverage drops immediately after payment.

5. Authentic Supporting Media

Wattly Pay meter verification screen with sample customer and address
Wattly Pay payment success screen with 20-digit electricity token
Wattly transaction recovery lifecycle diagram

Authentic Wattly Pay interface captures with approved mock customer details · Meter verification interaction, token generation receipt, and transaction recovery rail

6. Measurable Outcomes & Evidence

  • Zero lost customer funds: The automated reconciliation rail recovered 100% of delayed token issuances without requiring manual intervention.
  • Pre-payment verification: Verified customer identity on 100% of meter lookups, eliminating user error during bill entry.
  • Production release: Successfully shipped and maintained on Google Play Store with positive customer ratings.

What are you working on?

I’d love to hear about it.