The Problem We Were Actually Solving
We wanted to build an online store that could cater to customers worldwide, without having to set up a separate credit card processing account for each country. Sounds reasonable, right? However, what we soon discovered was that the traditional platforms we relied on had geo-restrictions in place that made it impossible to process transactions in countries like Somalia or Syria.
What We Tried First (And Why It Failed)
We initially thought that using a third-party service like Gumroad or Payhip would bypass these restrictions. But, as it turned out, these services still relied on the same credit card processing gateways that we were trying to circumvent. We were essentially playing a game of whack-a-mole, where we would use one service to get around the restrictions, only to find another service that had similar limitations. It was a frustrating and time-consuming process that ultimately led us to question the viability of these services for our use case.
The Architecture Decision
It was then that we decided to take a different approach. We would build our own payment processing system using a combination of APIs from local banks and a custom-built payment gateway. This would allow us to process transactions in countries that were previously off-limits to us. But, we knew that this approach would come with its own set of challenges, including increased complexity and a higher risk of errors.
What The Numbers Said After
After implementing the new payment processing system, we saw a significant increase in transaction volumes from previously restricted countries. In fact, our sales from these regions increased by over 300% within the first six months. While this was a welcome development, we also saw a corresponding increase in error rates and customer complaints. It quickly became apparent that our new system was not foolproof and required constant monitoring and maintenance.
What I Would Do Differently
In retrospect, I would have approached this problem with a more nuanced understanding of the trade-offs involved. While building our own payment processing system was necessary for our use case, it came at a significant cost in terms of complexity and resources. If I were to do it again, I would have explored alternative payment processing solutions that offered more flexibility and fewer restrictions. Perhaps a service like M-Pesa or Dwolla, which offers payment processing in emerging markets, would have been a better fit for our needs. Ultimately, the key takeaway from this experience was that there is no one-size-fits-all solution for e-commerce platforms, and that the decision to build versus buy (or in this case, both) should be based on a thorough analysis of the trade-offs involved.
Top comments (0)