DPL, 2024 - 2026

Request to Pay over App and USSD

Led delivery of Request to Pay: a merchant requests money from a customer, who can pay from a push notification or a USSD prompt, and can never pay twice.

Company

DPL

Role

Software Engineer, led Request to Pay delivery

Period

2024 - 2026

Stack

.NET, Microservices

4,000+merchants adopted Request to Pay

Paid oncewhichever channel the customer uses

how it workshow it works

Two channels to pay, one payment that counts

Pick a step to replay it

The problem

Merchants needed to collect payments from customers on any phone, smartphone or not. Sending every request down two channels at once raised the obvious risk: a customer paying on both.

What I built

Built the merchant flow: enter the customer's MSISDN, confirm the name through a name-check API, set the amount, and send
Delivered each request to the customer twice, as a push notification in the app and as a USSD prompt, so it also reaches phones without data
Made payment idempotent: the first payment settles the request, and any second attempt, on either channel, gets an 'already paid' business exception
Closed the USSD loop with a callback that updates the request record in the database once the USSD payment completes

Stack.NET, Microservices, USSD, Push notifications and Idempotency

Bulk Push Notification Scheduler

Messaging at scaleDPL, 2024 - 2026

Bulk Push Notification Scheduler

Built the scheduler behind bulk push campaigns: 700-800k notifications per run in 6-8 minutes, read in chunks and sent with controlled parallelism to Android (FCM) and Huawei devices.

700-800knotifications per run

Built with.NET, Schedulers, Semaphore and FCM

Read case study