The Payment Problem No One Wants to Acknowledge

#webdev #programming #architecture #systems

The Problem We Were Actually Solving

It was a typical Monday morning call with our founding team, discussing the state of our freelance platform in certain markets. We were struggling to onboard creators in Nigeria, Pakistan, Ghana, Bangladesh, and dozens of other countries. They couldn't use Stripe, PayPal, or any of the popular payment gateways because of restrictions and sanctions. This created a significant friction point for our users and hindered our growth. I had a nagging feeling that we were stuck in a classic case of "engineering by exception" – focusing on a narrow set of success stories while ignoring the broader reality of our user base.

What We Tried First (And Why It Failed)

Initially, we attempted to use the likes of Paystack (Nigeria), Rupay (India), and other regional payment gateways. This seemed like a straightforward solution, but it quickly became apparent that the complexities of working with multiple local payment providers were far greater than we anticipated. Each had its unique set of requirements, fees, and quirks. We had to develop a custom integration for each provider, which added unnecessary complexity to our system. Our users still couldn't onboard because these payment gateways required a local business registration, which was impossible given our online-only nature. The system started to resemble a "patchwork quilt" – a mess of band-aids trying to fix the symptoms rather than addressing the root issue. We were chasing the next "solution" without truly addressing the fundamental problem.

The Architecture Decision

After months of experimenting with various payment gateways, we decided to pivot and adopt a system that worked with local bank transfers. This solved the problem of onboarding users in restricted countries by allowing us to bypass the payment gateways altogether. We integrated with local banks using APIs from vendors like Xendit (Indonesia) and Flutterwave (Africa). This approach had its own set of challenges, such as handling cash-based transactions and dealing with local exchange rates. However, it provided a scalable solution that didn't require us to create a bespoke integration for each country. We also implemented a sophisticated risk management system to detect and prevent potential money laundering and fraud attempts.

What The Numbers Said After

After migrating to this new architecture, our onboarding rates for users in restricted countries skyrocketed. Within a few months, we saw a 5x increase in onboarding rates, and revenue from these regions started to trickle in. The most notable metric was the reduced average payment processing time, which dropped from 7 days to under 2 days. This allowed us to move quickly and flexibly, adapting to the needs of our users in real-time. We also observed a significant reduction in chargebacks and disputes, likely due to the ability to verify payments directly with the users' local banks.

What I Would Do Differently

In hindsight, I would have taken a more systematic approach to gathering data and requirements from our users in restricted countries earlier on. We assumed we knew what our users needed, but this assumption proved to be incorrect. This lack of data led to a series of "solution-over-features" decisions, where we focused on implementing individual payment gateways rather than understanding the root cause of the problem. If I were to redo this project, I would invest more time in working closely with our users to establish clear requirements and prioritization. By doing so, we could have developed a more effective and flexible solution that truly addressed the payment problem no one wants to acknowledge.