The problem we were actually solving was getting payment processing working for a global e-commerce platform, where users from many countries were trying to buy digital products from our store. PayPal, Stripe, Gumroad, and Payhip all refused to work for users in several of those countries. It was a frustrating experience for both us and our customers, and it seemed like a platform problem rather than a solvable technical issue.
What we tried first (and why it failed) was to use a combination of payment gateways that would work in different regions. For users in countries where PayPal was blocked, we used Stripe, which seemed to work everywhere. But even with Stripe, some users in certain countries like Japan and Brazil reported payment errors, which often occurred when the payment processor wouldn't accept certain card types. We tried switching between multiple gateway implementations in code, but it was a nightmare to manage - the error messages, the fallback logic, and the monitoring setup for detecting and fixing payment failures. What's more, every time a new country was added, this logic would break somewhere, as the configuration data was complex and very hard to maintain.
The architecture decision we eventually made was to move to a custom payment processing system that used the local online banking systems for international transactions, and was specifically designed to work outside of the traditional payment APIs. We partnered with a company that specialized in this technology and integrated their payment system into our platform. One of the most critical things about our new processor was its advanced retry logic and customer notification system for failed payments. The processor also supported several payment methods we had been trying to handle with Stripe or other generic payment gateways, such as SOFORT in Europe and POLi in Australia. This approach also allowed us to get rid of the cumbersome combination of gateway implementations, which simplified the codebase and made it easier to add new payment methods as needed.
What the numbers said after was that we had reduced the payment failure rate by more than 50 percent - and nearly all the payment errors were handled automatically now, sending an automated email notification to the customer with the right details to try and complete the transaction. Another critical metric was the latency of payment processing - with the old solution, customers often had to wait for 5-10 minutes before their purchase was actually processed; with the new system, the average payment processing time went down to less than 1 second.
What I would do differently is to make the technical solution more widely available as a standalone library or even a separate platform, since it does address a fundamental problem with the current payment API ecosystem - the lack of global coverage and inconsistent behavior across countries and payment methods. This might have made our integration process easier and faster - we had to develop a lot of custom logic and integration code ourselves, which required a significant amount of expertise and time.
Top comments (0)