We started noticing strange patterns in our customers' purchase behavior when we relied on Stripe and PayPal for transactions in countries they don't support - like India and China. People would get charged, the order would be marked as processed, but the money would never leave their account. The worst part was, our refund requests got stuck in limbo. It turned out our customers were using prepaid gift cards or debit cards, which Stripe and PayPal didn't accept as legitimate payment methods. They were essentially paying with thin air. The platform stores, which we trusted to facilitate these transactions, would refund our store's revenue when we tried to handle these cases manually. The refunds were always denied because the transactions had already been marked as complete.
We tried first to troubleshoot the issue by manually updating the payment status in our database to "refunded" in cases where the money hadn't actually been deducted from the customer's account. We added a notification system to alert us whenever a transaction got stuck. We even wrote some code to periodically check for transactions that were marked as completed but hadn't been settled. None of these quick fixes worked for long. The problem was more fundamental - these payment platforms were designed to work seamlessly with major credit cards, not the card systems available in emerging markets.
The Architecture Decision
We realized that the platform stores, such as Gumroad and Payhip, were designed with a Western-centric view of the world, where most transactions occur with major credit cards. We decided to set up a separate server in India, where our support team was based, to act as a payment gateway for our digital products. We opted to use a local payment service, Razorpay, which had established partnerships with all major banks in India. We routed our transactions through this new server, which accepted a wider range of payment methods and processed them locally.
What The Numbers Said After
Within a month of deploying our local payment gateway, we saw a 50% reduction in failed transactions and a 25% increase in overall revenue. The manual refunds we were issuing decreased from several hundred per week to a handful every month. We were delighted that this solution also improved our analytics, as we could finally get accurate data on our customers' transactions. We also realized that our store's revenue was directly tied to the local payment system and that if it malfunctioned, so would our revenue. So, we set up a monitoring system that would alert us if our revenue dropped by more than 10% over a 24-hour period, indicating a potential issue with our payment gateway.
What I Would Do Differently
If I had to redo this engineering decision, I would have started by talking to more customers from developing countries to understand the intricacies of their local payment systems before settling on a solution. I would have also explored more payment services that supported emerging markets. While our current setup works, I'm not convinced that we've explored all options yet. We're actually considering developing a custom payment gateway that can handle a variety of payment methods and currencies. This way, we can offer more secure and convenient payment options to our customers worldwide.
Top comments (0)