GCC Payment Gateway Suite

Selling in the Gulf breaks at the last click. A merchant can run a tidy Zoho Books organization, correct VAT treatment, a clean item list and a well-maintained customer master, and still lose the sale because the payment link on the invoice presents a card form the buyer does not recognise, in a language they do not read, drawn on an acquirer that will not settle into their local bank account.

The Online Payments section of Zoho Books ships with a fixed list of gateways. That list is built around processors licensed for North America, Europe and India. The acquirers a Gulf business actually holds a live merchant account with, the ones that clear domestic debit through the national card switches, the local wallets, and the instalment products buyers now expect at checkout, are simply not in the dropdown. So finance teams do one of three things: they take bank transfers and chase them by hand, they run a separate hosted checkout that never posts back into Books, or they reconcile a monthly processor statement against hundreds of invoices in a spreadsheet.

Every one of those routes puts the ledger out of step with the money. Discount fees land as an unexplained variance. Refunds never reach the original invoice. Settlement in one currency against invoices raised in another produces exchange differences nobody owns. And when a tax authority asks for the invoice that matches a specific payment, the audit trail is a spreadsheet somebody keeps on a laptop.

What ECOSIRE builds

We build a payment gateway layer that lives inside your own Zoho org: Deluge custom functions, a Zoho Creator app for the hosted checkout and the audit log, Sigma widgets where the workflow belongs on a CRM record, and direct calls to the Zoho Books and Zoho CRM REST APIs. The connector is written against the specific acquirer or acquirers you already have contracts with, using their published REST endpoints and signed webhooks.

Checkout and capture

The buyer receives a Zoho Books invoice or Payment Link as normal. The pay button routes to a hosted checkout page we build as a Creator page, branded to your entity, with Arabic and English content and full right-to-left layout. The page reads the invoice, its currency, its balance due and its tax lines from the Zoho Books API, then hands off to the acquirer's payment session. On a successful authorisation the acquirer's webhook hits a Deluge endpoint that verifies the signature before writing anything, then creates a Customer Payment against the exact invoice, in the invoice currency, with the gateway transaction reference stored on the payment.

Settlement, fees and reconciliation

Capture is not the same event as settlement, and treating them as one is where most homegrown integrations lose the ledger. We pull settlement batches from the acquirer on a schedule, post the net deposit to the correct Zoho Books Bank Account as a bank transaction, and post the merchant discount rate, fixed fees and any scheme or cross-border charge to a dedicated expense account in your Chart of Accounts. Each settlement line is matched back to the Customer Payment it came from, so a month-end close is a review rather than an investigation. Where the invoice currency and the settlement currency differ, the conversion is recorded against the exchange gain or loss account you nominate.

VAT correctness across the region

A Gulf group rarely runs one tax profile. We map each Zoho Books organization to its own credential set, bank accounts, tax rates and account mappings, so a 5 percent regime, a 15 percent regime, a 10 percent regime and a no-VAT jurisdiction can all run through the same connector without cross-contamination. The tax registration number, place of supply and tax breakdown are carried onto the payment record and the customer-facing receipt, and the connector never modifies a posted invoice to make a payment fit.

Refunds, retries and recurring billing

Refunds and partial refunds initiated from Zoho Books are pushed to the acquirer and tracked back to a resolved state, with the credit note linked to the original transaction reference. Failed and abandoned attempts are logged rather than silently dropped, and every write is idempotent so a webhook replay cannot double-post a payment. Where your acquirer supports tokenisation, Zoho Books Recurring Invoices can auto-charge a stored card reference instead of emailing a reminder.

Visibility for the sales side

Payment status is written back to Zoho CRM against the Deal or the custom module you use for orders, via a workflow rule and custom function, so account managers see paid, part-paid or failed without opening Books. Zoho Flow handles the low-risk fan-out, such as notifying a channel or updating a fulfilment record, so the core money path stays in code we can test.

Who this is for

Gulf retail and wholesale groups running Zoho Books across more than one country entity. E-commerce and services businesses whose buyers expect a domestic debit card, a local wallet or an instalment option at checkout. Finance teams who currently reconcile a processor statement by hand every month. Businesses with an existing merchant account that Zoho does not list natively.

How delivery works

Everything here is built to order. Nothing is pre-packaged, and there is no instant download.

1. Scoping call. We go through your acquirer contracts, the Zoho Books organizations in scope, currencies, tax profiles, your Chart of Accounts, and how you want fees and settlement posted. We ask for your acquirer's integration documentation and sandbox access. 2. Fixed quote. You receive a written scope with the exact acquirers, methods, currencies and postings covered, the deliverables, the timeline and a fixed price. Nothing is built before you approve it. 3. Build. Typical lead time is two to four weeks depending on how many acquirers and organizations are in scope. Development runs against your sandbox credentials in a Creator environment we control. 4. Install in test. We install into a test Zoho Books organization or a sandbox setup and run a scripted pass: authorisation, capture, decline, abandoned checkout, webhook replay, refund, partial refund, settlement batch, multi-currency invoice, Arabic checkout rendering. 5. Production. We install into your live org, configure credentials, walk your finance lead through the first real settlement batch end to end, and confirm the ledger balances before handover. 6. Support. A support window follows go-live for defects and configuration adjustments, with the option to extend.

What this is not

We are not an acquirer and we do not underwrite payments. You hold the merchant account and the commercial terms; we build the integration into it. Card data is handled by the acquirer's hosted session, so cardholder details do not land in your Zoho org. If your acquirer's API does not expose a capability, such as instalment plans or settlement detail, we will tell you at scoping rather than after the build.