The Day I Learned About Short Polling (Thanks to Mobile Money Payments)

So, I was implementing payments in my app when I ran into a very real problem.

Here’s the setup: most mobile money providers these days have implemented STK Push. That’s where, once you provide the phone number for payment, the owner of that number gets prompted to enter their PIN, and the money is sent to the requesting business or entity.

In my case, I was integrating with MoMo by MTN. The flow was simple in my head:

• •

  Customer goes to the payment screen.

• •

  They enter the number they want to pay with.

• •

  My app triggers an STK push to that number.

• •

  They enter their PIN on their phone.

Sounds straightforward… but here’s where I went wrong.

Rookie Move #1

Before, when the user entered their number and clicked Pay, I would immediately move them to the next screen.

I know, I know — rookie behaviour.

The problem? I had no idea if the payment had succeeded or not. If it failed, my app still happily acted like all was fine.

At the time, I knew this wasn’t right… But I didn’t know how to fix it.

Enter the Senior Engineer

I asked my senior engineer how they handled payment confirmation.

He simply said:

"

“We just short poll the DB.”

"

I nodded and moved on like I understood. Spoiler: I did not.

What is Polling, Anyway?

If you Google it, “poll” means to record the opinion or vote of.

In systems, polling is a method where you periodically check a source for updates. It’s like asking: “Hey, has anything changed yet?” over and over at set intervals.

In our case, the database is our source of truth.

Here’s the flow I settled on:

1. •

   When a payment starts, I create a DB record with a status = PENDING.

2. •

   If MTN sends a callback saying the payment succeeded, I update the status to SUCCESSFUL. If it fails — or if too much time passes — it becomes FAILED.

3. •

   On the frontend, after the user clicks Pay, instead of moving to the next screen, I show a loading animation.

4. •

   In the background, the frontend keeps calling a check payment status endpoint until it gets a final answer.

Short Polling vs Long Polling

• •

  Short Polling: The client sends requests to the server at regular intervals (e.g., every 2 seconds) asking for updates. Simple to implement, but can put unnecessary load on the server if done too often.

• •

  Long Polling: The client sends a request, but the server keeps the connection open until there’s an update. When the server responds, the client immediately sends another request. This reduces unnecessary requests and feels almost “real-time” without needing WebSockets.

My First Implementation

To start, I went with short polling:

• •

  Timeout of 2 seconds between checks.

• •

  Maximum of 3 attempts.

• •

  If all attempts fail, I show a “Try again” error message.

Is it perfect? Absolutely not. Is it fault-tolerant? Barely. But it works for now — and I can improve it later by adding better retries, error handling, or even switching to long polling.