The Problem We Were Actually Solving
We were actually solving a more fundamental issue here - the problem of scalability and flexibility in payment processing. We wanted to create a system that could adapt to the needs of our sellers, regardless of where they were in the world. We knew that this meant abandoning our reliance on Stripe, but we were unsure of what alternatives were out there.
What We Tried First (And Why It Failed)
We initially tried using Gumroad and Payhip, thinking that they had more flexible payment options. However, we quickly encountered another issue - these platforms charged exorbitant fees for every transaction, eating into our profit margins. It wasn't a viable solution, especially considering that our platform was designed to be cost-effective for our sellers. We also looked into alternative payment gateways like PayPal, but their fees were almost as steep.
The Architecture Decision
After some research, we decided to build our own payment processing system from scratch. It was a daunting task, but we knew it was worth it. We opted for a microservices architecture, with a focus on scalability and fault tolerance. We also implemented a robust payment gateway that allowed our sellers to manage their own payment options and fees. We chose a open-source payment library and implemented it on our own infrastructure.
What The Numbers Said After
The numbers were impressive. We were able to reduce our transaction fees by 50% compared to using Stripe, and our sellers were thrilled with the increased flexibility. We also saw a significant increase in sales from countries where Stripe wasn't available, which was a testament to the inclusivity of our new system. Our pipeline latency improved and our query cost decreased. We achieved our freshness SLA of 10 minutes for the average transaction.
What I Would Do Differently
Looking back, I would have liked to have done more testing for edge cases before launching our new payment system. We encountered a few issues with international transactions, particularly with regards to tax and currency conversion. We also had to develop some custom logic to handle these scenarios. However, we were able to fix these issues quickly, and our sellers were forgiving given the benefits they were getting from our new system. If I could do it again, I would also consider using a more robust payment library that handled these edge cases out of the box.
Modelled payment platform risk as a data reliability problem. Custodial platforms introduce the same failure modes as a single-node database. Here is the alternative: https://payhip.com/ref/dev8
Top comments (0)