Skip to content

Instead of Excuses, Mazzuma Just Does what Hubtel Don’t Care About

Posted in News

A few weeks ago, I took Hubtel’s API for a spin, and as nice as it was, I ended up vowing to myself I wouldn’t use it anymore, either for personal work or for clients. That was way before I found Mazzuma

It was clear Hubtel don’t use their own API (at least from a developer’s standpoint) and didn’t care about improving their own libraries developers could make use of. Some two months down the line and their documentation look the same as I found it.

For a 96-man company, one would expect their documentation to improve. But, duh!

In short, whatever concerns I had was BS to them, and their “Rethink Customer Care” was just a camouflage to get some PR points for themselves, when deep down, they laugh at me within their offices how dumb I am for thinking outside the box.

You can read all about my articles about my experience with Hubtel’s API, and all the ‘wise-insults’ a sockpuppet account, ‘Johnny Walker’, leveled on me.

The Problem

I want users of my AlwaysOn WiFi to generate their own vouchers. After paying with mobile money, their voucher is automatically generated for them.

The available solution from Hubtel was a mess, and complex, for the API consumer (the developer). The developer had to:

  • make the request
  • listen for a callback
  • listen for a callback
  • do something when the callback is in.

As much as the above steps seem simple, when you’re building a server API separate from the frontend part, there is no way to know the callback is in unless you poll some storage endpoint to see if the callback arrived.

Why server-frontend approach?

Well, I wanna take advantage of Angular’s Progressive Web App capabilities for the Payment Application.

If you don’t understand why I would wanna use Angular’s PWA, go burn the ocean!

For an idea of how I was doing it, see this server part: https://github.com/seanmavley/unifi-voucher-payment-server/blob/master/routes/index.js#L19-L156 

And the frontend part: https://github.com/seanmavley/unifi-voucher-payment-server/blob/master/routes/index.js#L19-L156

I share links to the pieces because they’re lengthy and cumbersome. Follow the links to peruse the code yourself.

The Solution (My simple suggestion)

Instead of sending a callback whatever, the developer waits on the line for a complete response from the first request – a success or a failure response.

That is ALL I SUGGESTED. THAT IS ALL I SUGGESTED.

Don’t let me go and come. Just gimme a response, success or failure. Just that was my suggestion. Nothing else.

Yet, Hubtel, with all their 96-man team, full of intellectuals and honorable, a company with branches in other parts of Africa, with many clients etc, managed to make it clear to me I am full of sh*t, and what I suggested was IMPOSSIBLE, giving unnecessary, unrelated reasons about how implausible my suggestion was/is.

I wasn’t asking Hubtel to launch a rocket into space.

I wasn’t asking Hubtel to cure Cancer with a line of code.

I wasn’t asking Hubtel to go bankrupt.

All I was saying is, instead of every developer implementing their own solutions for the callback, they should abstract that functionality so that we developers would only get a SUCCESS or FAILURE response, even if that meant waiting on the line for even up to a minute or slightly more.

My brethren and sistren, nothing more did I suggest ooh. Yet come and see. I was seen as the delusional, naysayer guy, who’s been denied employment at Hubtel, so whining to get back at them.

Wow.

Just like Elon destroyed Jeff Bezos, Mazzuma destroys Hubtel with a very streamlined, simple-to-the-core-skeleton implementation of what I suggested above, WHICH WORKS AMAZINGLY AND functioning NOW.

Lemme show you how Mazzuma destroyed Hubtel on this one.

Instead of giving excuses, Mazzuma just tried it and working nicely so far. I TRIED IT AND WORKING.

See a working example with Mazzuma API at buy.enjoywifi.today

Remember, the application is ‘hot’ and working, thus any valid transactions succeeded will enter my mobile money. Sharp! Consider it a donation!

Not sure Mazzuma did what I said. They probably had this implementation already long time ago, whiles I was wasting time with Hubtel’s distin.

Great minds think alike‘, they say.

How it works with Mazzuma

It is so simple, I’m gonna share the code snippets right here:

The above is all it takes to use the Mazzuma’s API

To see how all the pieces come together, see the server repository withMazzuma and the frontend part withMazzuma.

What Mazzuma did is NOT rocket science.

In summary

  • You make a request to Mazzuma’s API
  • Message is sent to mobile device
  • Either confirmed or denied
  • Mazzuma sends a complete response back.
    • If failed, response is undefined
    • If success, response is {"code":1,"status":"success","id":"XXXXX"}
  • Developer moves on to his/her life

I don’t know how Mazzuma is pulling this off. I don’t know what sorcery they have access to, that Hubtel’s 96-man team don’t possess.

In fact, I don’t care how they managed to pull this off. However, there’s one thing I can say for sure. Mazzuma doesn’t give unnecessary excuses. They might not have a 96-man company, however, they know how to be smart and think outside the box.

I couldn’t have implemented it simpler than what Mazzuma has done.

Now I can get to work receiving payments for voucher creations with my AlwaysOn WiFi.

The issue with Mazzuma?

Of course, nothing is perfect. I have a few issues with Mazzuma. However, whether they fix it or not, I personally don’t care, as the fixing of the issues below won’t in any way improve what the current implementation does.

In fact, I think it will be better I say, ‘nice-haves’, rather than issue.

Error messages:

Error messages should be a bit detailed. Not verbose, but a less than 25-word single-sentence detail. That’s all.

Fun Fact: As crazy as it is, an invalid request to Mazzuma’s API above results in a response, namely, "Sorry bro. :(" – Yeah, SERIOUSLY

Can’t say I don’t love the response, however, an extra field giving explanation about what actually happened to bro will be appreciated.

UPDATE: The error messages have been improved to include explanatory responses.

Conclusion

Go ahead and give the Buy AlwaysOn WiFi distin a try – powered by Mazzuma’s API – and lemme know what you think.

Find the Mazzuma Developer API documentation at https://developer.teamcyst.com.

In the coming days or weeks, I’ll be making a few improvements to the AlwaysOn Buy thing, for easier responses and feedback to users.