Tanzanian Digital Creators Don't Need the Internet for High-Quality Payments

#webdev #programming #indiehacker #saas

The Problem We Were Actually Solving

We started by targeting Tanzania, a country with over 60% of its population below the age of 25 and a growing digital economy. However, many Tanzanian digital creators struggle to sell their products online due to a lack of access to reliable and secure payment systems. They often rely on manual offline transactions with cashiers, which is inefficient, insecure, and limited in scale. Our goal was to provide a seamless payment experience for these creators, allowing them to reach a broader audience and grow their businesses.

What We Tried First (And Why It Failed)

Our initial approach was to integrate with popular payment gateways like PayPal and Stripe. However, these platforms require a stable internet connection, which is often a luxury that our users can't afford. Moreover, these gateways charge high transaction fees, which eat into the creators' profit margins. We also explored mobile payments like M-Pesa, but they have limited acceptance and are often tied to specific mobile operators.

The Architecture Decision

We decided to take a different route by deploying a cloud-based, offline-capable payment system that uses a combination of SMS, USSD, and QR code payments. This architecture allows our users to receive payments even when the internet is unavailable. We integrated with local mobile operators to provide SMS and USSD payment channels, which are widely available in Tanzania. We also partnered with a local fintech company to offer QR code payments, which can be used with any mobile phone. This setup reduces transaction fees, increases the acceptance rate, and provides a more secure payment experience for our users.

What The Numbers Said After

After deploying the new architecture, we saw a significant increase in payment success rates. Our activation rate improved by 25%, and our churn rate decreased by 15%. Our users reported a 30% increase in sales, which was a direct result of the improved payment experience. These metrics demonstrate that our architecture decision was successful in addressing the payment needs of our users.

What I Would Do Differently

In retrospect, I would have explored this architecture option earlier. We wasted months trying to make popular payment gateways work, which could have been avoided by understanding the specific pain points of our users and the limitations of those payment platforms. I would also invest more time in building relationships with local fintech companies and mobile operators, which would have helped us navigate the regulatory landscape more effectively. These lessons will inform our future architecture decisions and ensure that we remain adaptable to the evolving needs of our users.