What We Tried First (And Why It Failed)
Initially, we tried integrating Stripe with our payment processing system. Stripe's fees are competitive, but their payment flows are rigid and difficult to customize. We ended up with a convoluted workflow that required our creators to enter sensitive information multiple times. Needless to say, this led to a high abandonment rate and a significant increase in support tickets. We also experimented with PayPal, but their fees for Pakistani users were prohibitively expensive, and their APIs were clunky at best.
The Architecture Decision
We decided to switch to a local payment processor, JS Bank's ePay, which charges a flat 2.5% fee on all transactions. While not as seamless as international solutions, ePay allows us to circumvent the complexities of cross-border transactions and offers a more transparent pricing model. We also set up a custom payment flow that collects the required information in a single step, reducing the friction our creators experience.
What The Numbers Said After
After implementing the new payment processor, we saw a 30% reduction in payment failures and a 25% increase in successful transactions. The feedback from our creators was overwhelmingly positive, with many praising the simplicity and fairness of our payment system. While we still have our fair share of payment-related issues, the numbers suggest that our decision to move away from traditional payment gateways was the right one.
What I Would Do Differently
In hindsight, I would have done more research on the pricing models of local payment processors before settling on JS Bank's ePay. While their fees may seem reasonable, we could have potentially negotiated a better rate if we had presented a larger volume of transactions. I would also have explored more user-friendly payment gateways that offer more control over the payment flow. However, given the constraints we were working with, I'm satisfied with the outcome of our decision.
Top comments (0)