Southeast Asia Payment Gateway Pack

The problem: your customers do not pay by card

Across Indonesia, Malaysia, Thailand and the Philippines the default way to pay a business is not a card form. It is a QR code scanned in a banking app, a virtual account number credited by bank transfer, or an e-wallet balance debited in two taps. These rails carry an enormous share of everyday commercial payments in the region, and they behave nothing like card checkout: a QR payment has no redirect back to your site, a virtual account number may sit open for days before it is funded, and an e-wallet confirmation arrives asynchronously long after the customer has closed their browser.

Zoho Books and Zoho Invoice handle card-shaped payments well. They do not natively speak QR, virtual account or e-wallet. So merchants in these markets end up doing what merchants always do when the software does not fit: they put a bank account number in the invoice footer, receive a transfer, get a screenshot on a messaging app, and record the payment by hand. Volume makes that untenable. A hundred small invoices a month funded by virtual account is a full-time reconciliation job, and the failure mode is silent — a payment received but never recorded, or an invoice marked paid that never actually cleared.

The subtler cost is timing. Because none of these rails confirms synchronously, any integration built as if it were card checkout will mark invoices paid on the wrong signal or leave them permanently pending. Getting the asynchronous model right is most of the engineering in this build.

What ECOSIRE builds

ECOSIRE builds a locally-routed collection layer inside your Zoho organisation, covering the specific providers and payment methods you nominate. It is built to order — the method mix, currencies, expiry rules and account mappings are decided in scoping and built against.

Method-aware checkout

We build a branded payment page as a Zoho Creator application, linked from the invoice email template, the invoice PDF and a shareable URL. The page pulls the live balance from the Zoho Books API and presents only the methods valid for that customer's country and currency. Each method gets the interaction it actually needs: a QR payload rendered as a scannable code with a countdown to expiry; a virtual account number displayed with the issuing bank, a copy button and clear funding instructions; an e-wallet handoff that deep-links to the wallet app and returns cleanly.

Asynchronous settlement, done properly

The entire build treats confirmation as something that arrives later, from the provider, not from the customer's browser. Provider webhooks are received on secured endpoints with signature verification. Behind them, a scheduled Deluge job polls every open payment attempt against the provider's status API, so a missed or delayed callback never leaves an invoice stuck. Attempts that pass their expiry window are closed out and released, and the customer can be re-issued a fresh QR or virtual account without creating a duplicate invoice.

Reconciliation into Zoho Books

A settled payment creates a Customer Payment record against the right invoice, with the provider's transaction reference and the method used stored in custom fields. Under-payment and over-payment are handled explicitly rather than being forced to match: an under-payment leaves the residual balance open, an over-payment is flagged for review or applied as a credit according to the rule you choose during scoping. Provider fees post to a nominated expense account. Where you invoice in one currency and settle in another, the applied rate is recorded so the difference is visible instead of buried.

Idempotency and duplicate handling

QR and virtual account rails routinely deliver the same confirmation more than once, and a virtual account can be funded twice by a confused payer. Every attempt is tracked with its own identifier, every settlement path checks for prior application before writing to Books, and genuine duplicate funding surfaces in a review queue rather than quietly inflating a customer's ledger.

Operations and finance visibility

A Creator dashboard lists every attempt — method, provider, amount, invoice, status, expiry, failure reason — with the ability to re-check status against the provider or reissue an expired instrument. A daily comparison of provider-reported settlements against recorded Zoho Books payments gives finance a same-day answer on whether the two agree.

Downstream automation

Settled payments fire Zoho Flow flows and Zoho CRM workflow rules: advance a Deal, stamp a Contact or Account field, release a fulfilment task in Zoho Inventory, notify the account owner, start a renewal sequence. Reminder cadences stop automatically the moment an invoice clears, so nobody chases a customer who has already paid.

Who this is for

Merchants, subscription businesses, education and training providers, agencies and distributors invoicing from Indonesia, Malaysia, Thailand or the Philippines who run Zoho Books or Zoho Invoice and are collecting largely by manual bank transfer today. The case is strongest where invoice volume is high, values are small, or payment needs to release something — access, delivery, a booking — without a person in the loop.

How delivery works

1. Scoping call. We establish which providers you hold merchant accounts with, which methods you want live per country, your currencies, expiry and reissue rules, how over-payment should behave, and which Zoho Books organization is in scope. 2. Fixed quote. Written scope and a fixed price before build starts. Additional providers or methods added later are quoted separately and transparently. 3. Build. Deluge functions, the Creator payment page and dashboard, webhook endpoints, polling and expiry jobs, and Books field mappings are developed against your test setup. Typical lead time is two to four weeks after quote acceptance, subject to how quickly provider sandbox credentials are issued. 4. Install in test. Installed into a test Books organization and exercised across every enabled method — successful QR scan, expired QR, partially funded virtual account, duplicate callback, wallet timeout — with your finance lead reviewing the resulting records. 5. Production go-live. Live credentials configured, callback URLs registered with each provider, and the first real settlement day monitored alongside your team. 6. Support window. A post-go-live defect-fix and configuration-support period, with per-provider documentation and a recorded handover session.