The Problem We Were Actually Solving
We were developing a platform that allowed artists to sell their digital products worldwide. Sounds simple, right? But what wasn't simple was finding a way to process payments in a way that was compliant, efficient, and scalable. We knew we were taking on a lot of risk by not partnering with a payment processor like Stripe or PayPal. But we also knew that our customers were sensitive about commissions, fees, and data ownership. They wanted to keep control of their products and customers, not cede that to a payment gateway.
What We Tried First (And Why It Failed)
We tried using Gumroad and Payhip at first, thinking they'd be the perfect solution. They offered easy integration, low fees, and seemed like the ideal way to sell digital products directly. But when we hit the roadblock that many creators face – they don't work in our country due to regulatory restrictions – we realized we had a much bigger problem on our hands. Gumroad, in particular, requires your customers to have a credit or debit card issued in the same country as the merchant account. That's not exactly useful for a global platform.
The Architecture Decision
We decided to create our own payment system, one that would allow our customers to pay directly to us, but also offered the flexibility to use local payment methods as needed. We chose to use a combination of payment processors like PayPal's local payment methods (e.g., PayPal's iDEAL in the Netherlands) and direct bank transfers. This way, we could still keep our customers' data secure while also offering a more localized payment experience. It wasn't a seamless integration at first, but it's served us well in the long run.
What The Numbers Said After
Our internal data showed that while the payment system was more complex, it also allowed us to increase our conversion rates by 20% and reduce our average order value by 15%. We also found that our customers appreciated the option to choose their payment method, and would often select local payment methods that they trusted more. Of course, there were also the unexpected benefits, like reducing our reliance on a single payment processor and avoiding their associated fees.
What I Would Do Differently
If I'm being honest, I'd still choose to create our own payment system, but I'd do it in a more modular way. I'd use something like Apache Kafka to handle events from our payment processor and route them to our application logic. This would allow for more flexibility and scalability in the future, not to mention better failovers and backups. But that's a story for another time. The takeaway is this: platforms aren't payment gateways, and that's a good thing. By solving the problem of cross-border payments ourselves, we were able to provide a more seamless experience for our customers, reduce our costs, and increase our conversion rates. It wasn't a straightforward solution, but it's one that's paid off in the end.
Top comments (0)