Prepaid Water Vending.
Pay by M-Pesa, get your water token by SMS in seconds.
Water vendors were collecting prepaid payments and issuing meter tokens by hand. Customers waited, tokens went to the wrong meters, and nobody could reconcile payments against water sold.
M-Pesa in, meter token out, SMS delivered.
A multi-client platform. A customer pays to the vendor's paybill, the system generates a Stronpower meter token and texts it to them. Vendors see customers, meters, tokens and payments in their own portal.
Every vend is a background job that retries.
M-Pesa confirmation callbacks queue a Celery task that asks Stronpower for a token and sends it by SMS. Failures retry with exponential backoff, and credentials are encrypted in the database.
Choices that made it hold up.
Retry with exponential backoff
If Stronpower or the SMS gateway is slow, the vend retries on a growing delay instead of failing.Why: a paid customer must always get a token
One meter, one customer
The system refuses to link a meter to two customers.Why: tokens were reaching the wrong meters
Encrypt vendor credentials
Stronpower and M-Pesa credentials are encrypted at rest per client.Why: many vendors share one platform
Usage alerts and leak detection from meter readings.
Have an idea or a system to build?
Tell me what you need. I'll reply within a day with questions, a rough approach, or a time to talk.