The Problem We Were Actually Solving
Our product was a collaborative IDE plugin for data teams. Growth was explosive in emerging markets—Nigeria, Pakistan, Vietnam—where developers were hungry for tooling but had no access to global payment rails. The moment we tried to plug in Stripe, PayPal, or Gumroad, the integration simply failed with a 400 error: Country not supported. Our first thought was to open a shell company in a supported jurisdiction, but the legal fees exceeded our runway. We needed a payment path that didnt depend on a bank account sitting in a compliant jurisdiction.
What We Tried First (And Why It Failed)
We flirted with crypto gateways: BitPay, CoinGate, even a custom USDC flow. Onboarding took weeks, volatility wiped out monthly margins, and customer support tickets exploded after each market swing. We also tried regional aggregators like Flutterwave and PayTabs, but their KYC rules required a local corporate bank account—something foreign founders couldnt easily obtain.
Our most painful mistake was wiring money manually through Western Union. We had a customer in Ghana who begged to pay via mobile money, but we had to treat each transaction as an international wire into our personal accounts, then immediately forward it to our contractor. Within two weeks we breached the $10k personal transfer limit and PayPal froze our personal balances for suspicious activity. Thats when we realized the problem wasnt technical—it was architectural.
The Architecture Decision
We rebuilt the product tier to unbundle the payment flow into three legs:
Frontend: a next.js checkout page that collected card details via a legacy iframe from a local payment facilitator we found in Vietnam called VNPay Global. VNPay didnt require a foreign merchant account; instead, it acted as a sub-merchant under its own Vietnamese license and settled funds into a local bank account we opened under our Vietnamese subsidiary.
Backend: a Go microservice that tokenized card data using VNPays JavaScript SDK client-side, then relayed tokens to VNPays API instead of our own. Crucially, we never stored PANs; VNPay handled PCI scope for us.
Billing: we used a separate Ledger micro-service that only stored subscription state. Invoices were rendered in PDF and emailed weekly. Revenue recognition happened when the Vietnamese bank sent us a CSV at month-end.
The biggest trade-off was latency. VNPays API introduced 800–1200ms latency per charge versus the 150ms we had with Stripe. To mask it, we implemented a server-side cache for successful tokens and added a loading spinner with skeleton screens. It felt clunky compared to Stripe Elements, but users didnt churn because of latency.
What The Numbers Said After
After two quarters, the VNPay flow processed 87% of our transactions. Monthly recurring revenue reached $240k; 61% came from markets Stripe had blocked. Chargeback rate sat at 0.4%, lower than the industry average of 0.8% in those regions. Cash flow lagged by 7–10 days due to Vietnamese settlement cycles, but we offset it by pre-funding operations with a $30k venture debt line secured against future receivables.
The most surprising metric: customer support tickets dropped by 38% after we replaced email invoices with PDFs sent automatically from the Ledger service. Users finally had a single source of truth.
What I Would Do Differently
I would never again rely on a single regional aggregator. Month three, VNPay rolled out a new fee structure that raised costs by 1.2%—overnight. We scrambled to integrate PayTabs in parallel, but their onboarding portal expected a UAE bank account, so we shelved it. Diversify the processor chain upfront: have at least two rails in different jurisdictions and failover logic baked into the Go service.
Second, Id insist on a real-time ledger feed instead of waiting for CSV reconciliation. We lost two weeks debugging revenue recognition when the banks CSV format changed without notice. If wed ingested webhooks into the Ledger microservice, we could have caught the schema drift immediately.
Last, Id push back harder on the idea of using personal accounts. We burned $4k in legal fees and a week of engineering time cleaning up PayPal holds. If youre building outside the supported rails, open a local corporate account first, even if its in a secondary jurisdiction. That step alone would have saved us three months of reactive engineering.
Top comments (0)