Buy Now Pay Later and Installments Gateway

The business pain

Split-payment checkout is now expected across the Gulf and South Asia. A customer takes the goods today, the provider pays you a few days later, minus a merchant discount fee, and the customer repays over four, six or twelve instalments that you never see directly. Your finance team is left with an invoice in Zoho Books that says one amount, a bank line that says another, and no record anywhere of which instalment plan the order actually sits on.

What usually happens next is manual. Someone downloads the provider settlement report, sorts it in a spreadsheet, guesses which orders are in which batch, and creates a journal entry for the fee. Refunds make it worse: a partial return against a six-instalment plan changes the customer's remaining schedule but the credit note in Books has no idea. Aged receivables become meaningless because the receivable is not really from the customer any more, it is from the provider. Nobody can answer how much cash is genuinely in transit.

This is not a Zoho limitation. Zoho Books, Inventory and CRM hold everything needed to model it correctly. What is missing is the layer that turns provider callbacks into the right records, on the right dates, against the right accounts.

What ECOSIRE builds

We build a Zoho-native instalment and BNPL layer for your organisation. It is written with Deluge custom functions, Zoho Flow orchestration, Creator screens where a real UI is needed, and REST API calls against Zoho Books, Zoho Inventory and Zoho CRM. Nothing runs outside your Zoho org except the outbound calls to your provider's API.

Order capture and plan modelling

When an order is placed on a split-payment plan, we record the plan itself, not just the total. A Creator application (or custom module in CRM, depending on where your sales process lives) holds the plan header — provider, plan type, number of instalments, first payment date, cadence — and a child record per scheduled instalment with its own due date, amount and status. Every instalment record links back to the Zoho Books invoice and to the CRM deal or contact, so the plan is visible from wherever your team already works.

Settlement and fee accounting in Zoho Books

The important accounting truth is that the provider owes you, not the customer. We post the customer invoice as normal, then record the payment against a dedicated clearing account so the customer ledger closes correctly on day one. When the provider settlement arrives, a scheduled Deluge function reconciles the settlement batch against the clearing account, splits out the merchant discount fee into your expense account, and creates the bank deposit for the net amount. The result is that your Zoho Books bank reconciliation matches the actual deposit line, and the fee shows up as a real expense rather than being buried in a rounding difference.

Webhooks, retries and status changes

Providers push status changes: plan approved, plan declined, instalment collected, instalment missed, plan cancelled, refund processed. We expose the receiving endpoint as a Zoho Flow webhook or a Creator API endpoint with signature verification, then fan each event into the right Deluge handler. Events are logged with their raw payload so a disputed transaction can be traced months later. Failed handlers retry on a schedule rather than silently dropping, and anything that cannot be matched lands in an exception queue with a human-readable reason.

Refunds, cancellations and partial returns

A return against an instalment plan needs three things to stay consistent: the credit note in Zoho Books, the stock movement in Zoho Inventory, and the revised schedule with the provider. We wire the credit note workflow so that raising it triggers the provider refund call, updates the remaining instalment records, and adjusts the clearing account balance. Where the provider only supports full refunds, we make that constraint explicit in the UI instead of letting a user create an accounting position that can never be settled.

Tax treatment

Instalment plans interact with tax rules — GST place-of-supply in India, VAT in the Gulf, and the question of whether the merchant fee is an input-taxed supply. We configure the tax treatment on the fee posting and on the customer invoice according to your accountant's instruction, using your existing Zoho Books tax settings and tax rates rather than inventing new ones. If you run multiple Books organizations for different legal entities, each one gets its own mapping.

Who it is for

Retailers and e-commerce sellers using Zoho Books or Zoho Inventory as the system of record who have added, or are about to add, a split-payment option at checkout. It fits merchants in the Gulf and South Asia in particular, where domestic providers each expose their own API and settlement format. It suits finance teams who currently reconcile provider statements by hand and want the fee, the timing and the receivable position to be correct without that work.

It is not for organisations that only take card or cash payment in full at the point of sale — there is nothing to model. It is also not a replacement for your provider's merchant agreement or their own dashboard.

How delivery works

Scoping call. We walk through your provider, your Zoho Books chart of accounts, your existing checkout flow, and the volume you handle. We ask for the provider's API documentation and a sample settlement file. This is where the real constraints surface — many providers differ sharply in what their API exposes.

Fixed quote. You receive a written scope covering the exact provider integrations, the accounting treatment, the modules touched, and what is explicitly out of scope. The price is fixed against that scope. No work starts until you approve it.

Build. Development happens in our environment against a sandbox and, where the provider offers one, their test credentials. Typical lead time is one working week depending on how many providers and how complex your account mapping is.

Install in test, then production. We install into a test Zoho org or a duplicate Books organization first and run your own real scenarios: a plan created, an instalment collected, a settlement reconciled, a refund pushed back. Once you sign off, we install into production and configure the live credentials with you on a call.

Support. A support window follows go-live for defect fixes and configuration adjustments. Provider API changes and new provider integrations after that window are quoted separately.