MENA Payment Gateway Connector (PayTabs)

The problem

A Gulf or wider MENA business collecting online payments typically ends up with two sources of truth: the gateway portal, which knows what was collected, and NetSuite, which knows what was invoiced. Nobody reconciles them continuously. Payments are keyed in from a portal export, split settlements to a partner or a marketplace seller are tracked in a spreadsheet, and the clearing account grows a balance nobody can explain.

The problem is worse for anyone operating a marketplace or a franchise model, where a single customer payment has to be divided between the platform and one or more merchants. NetSuite has no native concept of that split, so the money arrives as one lump and the payable to each merchant is worked out manually after the fact.

What ECOSIRE builds

This is a build-to-order engagement. We build a MENA payment gateway connector as a native NetSuite customization inside your own account, against your own gateway merchant profile. It is not middleware you subscribe to and not a pre-packaged download.

Payment capture and application

A Suitelet initiates a hosted payment page from a Sales Order or Invoice, so the payer enters card details on the gateway, never in NetSuite. On an approved transaction the connector creates a Customer Payment applied to the target Invoice, or a Customer Deposit where you collect against a Sales Order before fulfilment. The gateway transaction reference, response code, payment method, scheme and issuing country are written to custom body fields so the audit trail sits on the transaction itself.

Split payments

Where your gateway profile supports splitting a payment across multiple beneficiaries, the connector models that in NetSuite instead of leaving it in a spreadsheet. Each split leg is recorded on a custom record linked to the source transaction, the platform's share is posted as revenue and the merchant's share as a payable to the corresponding Vendor. When the split settlement is confirmed by the gateway, a Map/Reduce script clears the payable and posts the movement, so what you owe each merchant is a real NetSuite balance you can report and pay.

Payment links and recurring collection

A User Event script on the Invoice produces a hosted payment link and merges it into your transaction email template, so collections can be worked from the Invoice record. For customers on stored payment tokens, a Scheduled script requests the charge on the agreed date and posts the resulting Customer Payment; declines are routed to a saved-search-driven exception queue with a defined owner and a retry rule rather than being silently dropped.

Webhooks, refunds and disputes

A RESTlet on a dedicated integration role receives gateway callbacks for authorization, capture, decline, refund, chargeback and dispute events. Payloads are signature-verified, logged to a custom record with the full request and response, and processed idempotently by gateway transaction reference so retries cannot double-post. Refunds initiated from a Customer Refund or Credit Memo pass through SuiteFlow approval before the gateway call is made, and the gateway result is written back before the NetSuite transaction is treated as complete. Chargebacks raise their own flagged record so finance sees the exposure while it is still contestable.

Settlement and multi-entity posting

Daily settlement batches are parsed and reconciled: gross collections, gateway fees, refunds, chargebacks and FX differences post to the accounts and departments you nominate, producing a Deposit that ties to the bank credit. If you run OneWorld, each merchant profile is bound to a subsidiary so Saudi, UAE, Egyptian or Jordanian entities keep their own base currency, accounts and nexus treatment. Custom segments are populated on every posting so payment activity appears in the same reporting dimensions as the rest of the ledger, and where a fiscal document must carry the payment reference, we stamp it onto the transaction.

Security and supportability

Merchant credentials are held in a secured custom record using NetSuite's secrets support and are excluded from script logs. The integration role holds only the permissions the connector needs. Every request, response and error is logged, and an operations saved search plus reminder surfaces anything unmatched, declined or stuck so it is worked rather than discovered at month-end.

Who this is for

MENA sellers invoicing from NetSuite who want collections to post themselves; marketplaces, franchises and platforms that must split a single payment between the platform and its merchants; and multi-entity groups running OneWorld with separate merchant profiles per country. It fits both card-not-present e-commerce and B2B collections against open invoices.

How delivery works

1. Scoping call. We review your gateway merchant profile, the countries, currencies and payment methods enabled on it, your invoicing and refund flow, your split-payment model if any, and your fee and clearing account structure. 2. Fixed quote. A written scope and a fixed price, agreed before development begins. 3. Build. Development runs in a Sandbox account as an SDF project under source control, typically one working week depending on merchant profiles, split logic and settlement mapping. 4. Install in test. The bundle goes into your Sandbox and is exercised end to end on gateway test credentials — approval, decline, partial refund, split settlement, chargeback and a full settlement cycle — with your finance team reviewing every resulting posting. 5. Production. After sign-off the same SDF project deploys to production, live credentials are configured, callbacks are pointed at the production RESTlet, and we monitor the first live settlement cycles. 6. Support. A post-go-live support window covering defects and gateway API changes encountered during that period.

You own the SDF project and its source. We charge nothing per transaction, and your processing terms stay directly between you and your gateway.