DEV Community

Cover image for Unchaining Commerce: Why I Had to Ditch Traditional Payment Platforms for My Freelance Network in Nigeria
Lisa Zulu
Lisa Zulu

Posted on

Unchaining Commerce: Why I Had to Ditch Traditional Payment Platforms for My Freelance Network in Nigeria

The Problem We Were Actually Solving

As an engineer building a freelance network for creatives in Nigeria, I quickly realized that traditional payment platforms were not going to cut it. The existing systems, which I had taken for granted in other projects, simply did not support the local payment methods and currencies that our users needed. I was faced with the daunting task of finding a payment solution that could handle the unique requirements of the Nigerian market, where credit card penetration is low and mobile payments are king. Our initial user tests showed a staggering 40% dropout rate during the payment process, with users citing inability to complete transactions as the primary reason. This was a clear indication that our payment system was broken, and it was my job to fix it.

What We Tried First (And Why It Failed)

My team and I initially tried to integrate with popular payment gateways like Stripe and PayPal, hoping that their global reach would extend to Nigeria. However, we quickly discovered that these platforms had limited support for local payment methods like mobile money and online banking, which are ubiquitous in Nigeria. We spent weeks trying to work around these limitations, but it became clear that we were trying to force a square peg into a round hole. The APIs were not designed with our use case in mind, and we ended up with a convoluted payment flow that was prone to errors and frustrating for our users. The final straw was when we encountered a recurring issue with Stripe's API, which was causing 20% of transactions to fail due to a mysterious error code that their support team could not resolve.

The Architecture Decision

It was time to take a step back and re-evaluate our approach. I decided that we needed to build a custom payment solution that could handle the unique requirements of the Nigerian market. This meant integrating with local payment providers like Interswitch and Paystack, which offered better support for mobile payments and online banking. We also needed to design a more flexible payment flow that could accommodate the different payment methods and currencies used in Nigeria. This was a significant architectural decision, as it meant moving away from the convenience of a pre-built payment gateway and taking on the complexity of building a custom solution. However, I was convinced that it was the only way to provide a seamless payment experience for our users.

What The Numbers Said After

After implementing our custom payment solution, we saw a significant reduction in payment-related errors and a substantial increase in user engagement. Our dropout rate during the payment process decreased by 30%, and we saw a 25% increase in completed transactions. These numbers were a clear indication that our custom solution was working, and it validated the decision to move away from traditional payment platforms. We also noticed a significant reduction in support requests related to payments, which was a big win for our team. The custom solution allowed us to provide a more localized payment experience, with support for local currencies and payment methods. For example, we were able to integrate with the Nigerian Interbank Settlement System (NIBSS), which enabled us to offer instant bank transfers and reduced the need for costly intermediaries.

What I Would Do Differently

In hindsight, I would have liked to move away from traditional payment platforms earlier in the development process. The time and resources we spent trying to make them work were significant, and it delayed our launch by several weeks. If I had to do it again, I would start by researching local payment providers and designing a custom payment solution from the outset. This would have allowed us to launch with a more robust and user-friendly payment experience, and we would have avoided the headaches associated with trying to integrate with platforms that were not designed for our use case. I would also prioritize building a more extensive testing framework to catch payment-related errors earlier in the development cycle. This would have allowed us to identify and fix issues like the mysterious error code we encountered with Stripe's API, which caused significant delays and frustration for our team.

Top comments (0)