The Problem We Were Actually Solving
We were trying to build an e-commerce platform that could sell online courses to anyone, anywhere in the world. Sounds simple enough, right? But the reality is that many African countries are blocked from using the likes of PayPal and Stripe due to internal banking policies, anti-money laundering laws, and other regulatory hurdles. It's a classic case of what I like to call a "platform restriction" – where a payment processor restricts access to certain countries due to their internal policies, regardless of a user's individual intentions.
What We Tried First (And Why It Failed)
Our initial solution was to use a payment gateway aggregator like Stripe Connect, which promised to "unlock" payments in restricted countries. We thought we could just "route" payments through a different gateway, bypassing the restrictions. But, as it turns out, this approach had a significant flaw – it introduced latency and increased the risk of failed transactions. When payments failed, our system would send a generic error message, which was a poor user experience.
The Architecture Decision
We eventually had to abandon the aggregator approach and opt for a different payment processor that allowed us to accept payments directly in Nigeria. After some trial and error, we settled on a small payment processor called PayStack, which had a very low transaction failure rate and offered more granular error handling. We also had to build custom error handling in our system to handle specific PayStack error codes, which required us to negotiate with their support team to get more detailed information.
What The Numbers Said After
Rolling out PayStack in Nigeria increased our course sales in the country by 30% within the first month. More importantly, our system error rate decreased to 0.2%, down from 3% when we were using the aggregator approach. Our customers were happy, too – they no longer saw generic error messages and could complete transactions much faster. PayStack's robust API and better customer support were key to our success.
What I Would Do Differently
If I were to do this again, I would prioritize integration with more local payment processors from the get-go. We spent too much time trying to force-fit global payment processors that didn't account for our unique situation. I would also invest more time in building relationships with local payment processors and getting more detailed information about their error codes and latency characteristics.
Top comments (0)