DEV Community

Cover image for Building Payment Infrastructure for the Unbanked: Why I Had to Ditch Traditional Platforms
pretty ncube
pretty ncube

Posted on

Building Payment Infrastructure for the Unbanked: Why I Had to Ditch Traditional Platforms

The Problem We Were Actually Solving

I was tasked with building a payment system for freelance workers in Nigeria, where traditional platforms like PayPal are not available. The existing solutions were either too expensive or unreliable, resulting in a significant loss of earnings for the workers. My goal was to design a system that could handle payments efficiently and securely, without relying on these conventional platforms. After conducting research, I realized that the problem was not just about payment processing, but also about providing access to financial services for the unbanked population. I had to consider the limitations of the local banking system, the high cost of transactions, and the lack of trust in digital payment methods.

What We Tried First (And Why It Failed)

Initially, we attempted to use a popular open-source payment gateway that supported multiple payment methods. However, we soon discovered that it was not optimized for the local market, and the transaction fees were prohibitively high. We also encountered issues with the gateway's API, which was not designed to handle the unique requirements of the Nigerian payment system. For example, the gateway did not support the Nigerian Naira currency, and the payment processing times were slow due to the lack of direct connections with local banks. We spent several weeks trying to customize the gateway, but ultimately, we realized that it was not the right solution for our needs. The error rates were high, with a failure rate of 30% due to invalid transactions, and the average transaction processing time was 5 seconds, which was unacceptable for our use case.

The Architecture Decision

After evaluating several alternatives, we decided to build a custom payment system using a combination of local payment methods, such as bank transfers and mobile money, and a lightweight, cloud-based architecture. We chose to use Rust as the programming language for our system, due to its emphasis on performance, reliability, and security. We designed a microservices-based architecture, with separate services for payment processing, transaction management, and reporting. We also implemented a caching layer using Redis to improve performance and reduce the load on our database. The decision to use Rust was not taken lightly, as it required a significant investment in training and development. However, the benefits of using Rust, including its memory safety features and performance capabilities, outweighed the costs.

What The Numbers Said After

After deploying our custom payment system, we saw a significant improvement in transaction success rates, with a failure rate of less than 5%. The average transaction processing time was reduced to 1 second, and the system was able to handle a high volume of transactions without any issues. We also observed a reduction in transaction fees, with an average cost per transaction of 1.5% compared to 3.5% with the previous gateway. The system's performance was impressive, with a latency of 50ms and a throughput of 500 transactions per second. We used tools like Prometheus and Grafana to monitor our system's performance and identify areas for optimization. The allocation counts showed that our system was using an average of 100MB of memory per transaction, which was significantly lower than the previous gateway. The profiler output indicated that the majority of the time was spent on database queries, which we were able to optimize further by implementing a connection pooling mechanism.

What I Would Do Differently

In retrospect, I would have liked to have spent more time researching the local payment landscape and understanding the unique requirements of the Nigerian market. We encountered several surprises along the way, including the need to support multiple languages and the complexity of the local banking system. I would also have liked to have invested more in testing and quality assurance, as we encountered several issues during the deployment phase. Additionally, I would have considered using a more established payment platform, such as Stripe or Paystack, which have a stronger presence in the African market. However, our custom solution has given us the flexibility to adapt to the changing needs of the market and to provide a more tailored experience for our users. The experience has taught me the importance of understanding the local context and being prepared to adapt to unexpected challenges. I have learned to appreciate the value of a well-designed system, and I will carry this lesson with me in my future engineering endeavors.

Top comments (0)