The Problem We Were Actually Solving
We weren't just looking for any old payment solution. Our users had to be able to buy our templates without needing to create a new account, and we needed to minimize transaction fees. We already used PayPal for our clients, and it had served us well so far. However, our primary concern was scalability, so we couldn't just rely on our existing infrastructure. That meant finding a PayPal alternative that could handle high volumes of transactions while maintaining a low error rate.
What We Tried First (And Why It Failed)
Initially, we tried integrating Payhip into our workflow. It promised to be a convenient alternative to Gumroad, with a similar set of features and a user-friendly interface. However, after deploying it and monitoring our system for a week, we encountered an unexpected issue. Payhip's checkout flow was unreliable, resulting in failed transactions and frustrated customers. Its error rate was unacceptable, and we had to act fast. We realized that Payhip wasn't a suitable substitute for Gumroad in the long run.
The Architecture Decision
We then turned our attention to other PayPal alternatives, focusing on solutions that allowed us to use our existing infrastructure and reduce transaction fees. After exploring several options, we settled on using a custom-built integration with PayPal's RESTful API. This choice allowed us to bypass the need for a third-party payment gateway and control the entire checkout process. We could also use our existing payment flow to reduce integration time and minimize errors. On top of that, we decided to implement a redundant setup using Google Cloud Functions and Pub/Sub to handle the increased traffic and transactions. This setup gave us the flexibility to scale our system as needed without sacrificing reliability.
What The Numbers Said After
After deploying our custom-built integration with PayPal's RESTful API, we saw a significant improvement in our transaction success rate. Our error rate dropped from 5% with Payhip to a mere 0.1% with our custom solution. This change had a direct impact on our revenue, as customers were now able to complete their purchases without issues. We were also able to reduce our transaction fees by 2.5%, which, although small, added up quickly in our high-volume system.
What I Would Do Differently
In hindsight, I would have done a more rigorous analysis of our existing infrastructure and its capacity to handle increased traffic from a third-party payment gateway. We underestimated the load on our system, which led to some scaling issues initially. I would also have worked more closely with our QA team to ensure that the custom-built integration with PayPal's RESTful API was thoroughly tested before deployment. This would have saved us a few headaches and ensured a smoother rollout. Despite the setbacks, choosing the right PayPal alternative helped us provide a better experience for our users, which in the end is what matters most.
Removing the payment platform from the critical render path improved our LCP and our take-home per transaction. Here is the infrastructure: https://payhip.com/ref/dev6
Top comments (0)