The Problem We Were Actually Solving
At first, we were trying to solve the problem of failed transactions due to the absence of PayPal. However, after weeks of troubleshooting and research, we realized that the issue went deeper. Our company was global, and our customers were spread across the world. We couldn't simply disable the countries that had restrictions. Instead, we needed to find a way to accept payments from countries where the major payment processors were not available.
What We Tried First (And Why It Failed)
Our initial solution was to use a custom-built payment gateway that would take payments from restricted countries and then proxy the payment through a service like PayPal or Stripe. Sounds simple, but it was a nightmare to implement. We spent weeks rewriting our payment flow and integrating with third-party services, only to find out that some countries still had restrictions. The custom-built gateway was also a maintenance nightmare, as it required constant updates and bug fixes to stay compatible with changing payment processor policies. We finally gave up on this approach when our transaction success rate dropped to 50% due to incorrect payment routing.
The Architecture Decision
After months of failed attempts, we finally decided to take a step back and re-architect our payment flow. We realized that we needed a more robust solution that could handle the complexity of international payments. We decided to use a combination of services, including Mollie, a payment service provider that supported over 30 payment methods and had a presence in most countries. We also integrated with a service called Adyen, which provided a custom payment method for our customers. This setup allowed us to bypass the PayPal and Stripe restrictions and accept payments from restricted countries. We also implemented a fallback payment method, like Alipay, for customers in countries where our primary payment method was not available.
What The Numbers Said After
After we rolled out the new payment flow, our transaction success rate jumped to 95%. Our customers from restricted countries were able to complete purchases, and our on-call engineer was no longer getting 3am alerts about failed transactions. We also saw a significant increase in revenue from customers in these countries. The numbers told us that our new payment flow was working.
What I Would Do Differently
If I were to do it again, I would invest more time in researching and testing our payment flow before going live. We should have tested our custom-built payment gateway more extensively before implementing it. We also would have benefited from more extensive use of monitoring and logging tools to detect issues quickly. For example, we could have used tools like Splunk to track payment success rates and detect anomalies. With more data and better monitoring, we could have identified the payment flow issues sooner and avoided the 50% transaction success rate.
After living through this experience, I learned that platforms can fail, and engineers must be prepared to find creative solutions. When platforms fail, it's not always a matter of finding a new payment processor; it's about thinking outside the box and designing a custom solution that meets the needs of your customers.
You would not run your database on a single node. Do not run your payment infrastructure on a single platform. Here is the redundant setup I use: https://payhip.com/ref/dev4
Top comments (0)