You know what's frustrating? I watched a Vietnamese e-commerce startup lose ₫5 billion in potential annual revenue because they couldn't reliably process payments during flash sales. Not because their product was bad. Not because traffic was too high. Their payment gateway integration was so brittle that every spike in transactions triggered cascade failures. They were using legacy APIs that couldn't handle concurrent requests, and their retry logic was basically "pray and refresh."
That was 2019. It's 2026 now, and you'd think we'd have figured this out. But I still see companies making similar mistakes—businesses that understand their product perfectly but treat payment infrastructure like it's a necessary evil rather than a critical business layer.
The Integration Trap Nobody Talks About
Here's the brutal truth: payment gateway integration is deceptively simple on the surface and extraordinarily complex underneath. Most developers look at Stripe's "quick start" or Zalopay's documentation and think "oh, I just need to call an API and handle the response." Sure. And surgery is just cutting and stitching.
The real complexity emerges when you encounter the scenarios nobody mentions in tutorials:
A customer's payment succeeds on the bank's side but your webhook never fires (network timeout between gateway and your server)
Stripe (or Zalopay, or VNPay) processes a charge, but your database transaction fails
A customer initiates payment at 11:59 PM, completes it at 12:01 AM the next day, and your reconciliation logic assumes same-day matching
International transactions that succeed in real-time but take 5 business days to clear, and you've already shipped the product
Share this post
Related Posts
Need technology consulting?
The Idflow team is always ready to support your digital transformation journey.
Regulatory changes (Vietnam's financial authorities keep introducing new regulations) that require re-certification of your integration
This is why payment companies like Stripe charge 2.9% + 30¢ per transaction, or why Vietnam's major gateways charge 0.5-1.5% in commission. They're not making money off your transactions; they're making money off the infrastructure and fraud prevention they had to build. Every merchant they onboard is running 5-10 different edge cases they need to handle.
What Actually Matters: The Real Integration Checklist
Let me talk about what experienced teams prioritize, because it's different from what documentation emphasizes.
Idempotency First, Always. Every single payment request you make to a gateway must have an idempotency key. Why? Because the network is unreliable. Your request might succeed but the response gets lost. You retry. The gateway processes the payment twice. Now you're liable for investigating fraud. Most frameworks (Stripe, Razorpay, even local Vietnamese gateways) support idempotency keys, but I've audited codebases from mid-sized Vietnamese startups where developers hadn't implemented this—they just prayed the network wouldn't timeout.
Asynchronous Processing is Non-Negotiable. Never block a user's request on a payment API call. Ever. Not even if it's "usually fast." I've seen platforms where a single slow payment authorization from the bank's system (can happen during peak hours) cascaded into response timeouts across their entire checkout flow. Use message queues (Redis, RabbitMQ) or background jobs. Process the payment asynchronously, notify the user their payment is processing, and send them an email when it's confirmed.
Webhook Validation and Retry Logic. This is where things get gnarly. Gateways send you webhooks when payments complete, but:
- Webhooks can arrive out of order
- Webhooks can be retried 3+ times if you return a non-2xx status
- Webhooks might arrive before you receive the synchronous response from the initial payment request
- In Vietnam's market, some older gateway providers send duplicated webhooks (I'm looking at you, certain banks' payment APIs)
You need idempotent webhook handlers. Every. Single. One. If you process the same webhook twice, the result should be identical.
Settlement Timing is Different From Clearance. A customer's payment "succeeds" on their bank statement within minutes, but the actual funds don't arrive in your merchant account for 3-5 business days. Meanwhile, you've already shipped their product. If they do a chargeback after the shipment but before settlement, you're out both the product and the funds. Most Vietnamese businesses don't think about this. Stripe handles it for you (they absorb the chargeback risk if you follow their rules). But if you're using a local Vietnamese gateway with lower fees, you're self-insuring against chargebacks. That's expensive.
Vietnam's payment landscape is fragmented in ways that Western countries aren't. You've got:
Traditional card networks (Visa/Mastercard) processing through banks
Domestic bank transfers (NAPAS, which processes roughly ₫3 trillion in transactions monthly)
E-wallet providers (Zalopay, Momo, VNPay wallet)
Open Banking (newer, but growing—requires separate integration)
A single checkout form might need to support 5-6 different payment methods, each with its own gateway, its own webhook format, its own error codes, its own settlement timing. I've seen Vietnamese e-commerce platforms maintain 40+ lines of integration code per payment method just for error handling. Momo's webhook format doesn't match VNPay's. VNPay's success codes don't match NAPAS's. You end up normalizing everything to your own internal schema, which adds a translation layer.
And then there's fraud. Vietnamese e-commerce platforms have chargeback rates roughly 2-3x higher than Southeast Asian averages. Why? Partially because local payment enforcement is still developing. Partially because scammers know there's less friction. You need fraud detection rules that are way more aggressive than what you'd deploy internationally.
The Unglamorous Details
You also need to handle:
3D Secure authentication (the customer's bank pops up a verification dialog). Some Vietnamese banks return codes that Stripe treats as failures but are actually success states.
Timeout handling. What's your timeout threshold? Zalopay's API sometimes takes 8-10 seconds on their end. A generic "5-second timeout" won't work.
Partial failures. Payment succeeds, but you can't reach your email provider to send a confirmation. Your inventory system is down. Graceful degradation is harder than it sounds.
Reporting and reconciliation. You're going to need dashboards that reconcile what you processed vs. what the gateway reports vs. what actually settled. These numbers won't match day-to-day, and that's normal.
Building It Right
If I were integrating payment gateways for a Vietnamese business today, here's my priority order:
2Asynchronous processing (never block on the gateway)
3Robust webhook handling (treat webhooks as unreliable, implement deduplication)
4Fraud detection (aggressive, tuned for your specific market)
5Reporting layer (because you'll need to answer "why does our settlement not match our bank statement?" monthly)
6Dashboard visibility (know the status of every transaction in real-time)
The technical implementation varies. You could use Stripe (high fees, but incredible reliability and built-in fraud tools). You could use local gateways (lower fees, but more complexity). Most smart teams in Vietnam use both—Stripe as a backup payment method and a local gateway as the primary.
We've built payment infrastructure for Vietnamese platforms at Idflow Technology, and the pattern we always recommend is: start with a robust abstraction layer. Your checkout shouldn't know whether it's talking to Stripe or VNPay. If you design it right, swapping gateways becomes a configuration change, not a rebuild.
Payment infrastructure isn't glamorous. It doesn't make your product differentiated. But it's the difference between customers loving you and customers (rightfully) hating you when their purchase fails. Get it right first, optimize later.
