UAE SME Payment Gateway Connector (Telr)

The problem this solves

UAE small and mid-sized businesses on NetSuite very often sit on a low-cost regional payment gateway, because the pricing works and the onboarding is straightforward for a company that is not processing enterprise volume. What that gateway does not come with is any link to NetSuite.

The day-to-day consequence is small but relentless. A customer pays online. The gateway confirms it. NetSuite knows nothing. Someone logs into the gateway dashboard, finds the transaction, works out which invoice it belongs to, opens NetSuite, creates a Customer Payment and applies it. If the payment was a deposit against a quote or sales order rather than an invoice, they have to decide how to record it, and different people decide differently. At the end of the month the gateway pays out net of its fees, so the bank statement disagrees with the payments recorded, and someone posts a balancing journal to make it go away.

None of this is a crisis on any given day. Over a year it is a meaningful amount of time, and it produces an AR ledger that is always slightly behind reality and a bank reconciliation that leans on manual adjustments.

There is no native NetSuite path to this gateway and no SuiteApp for it, so the only real answer is a customization.

What ECOSIRE builds

ECOSIRE builds a focused NetSuite customization that closes the loop between your gateway and your ledger, delivered as an unmanaged bundle or SDF project that you own. It is scoped and built for your account — this is not a pre-built product and there is no download.

This connector is deliberately narrower than an enterprise-scale build. It is designed for a single-entity or small multi-entity UAE business trading primarily in AED, and it is priced and scoped accordingly.

Automatic payment recording

A RESTlet receives the gateway's transaction notification. The signature is verified before anything is written, and the raw payload is stored on a custom transaction record so there is always an audit trail. A Map/Reduce script then finds the target transaction using a reference embedded in the payment request and creates the right NetSuite record:

• Payment against an open Invoice creates a Customer Payment and applies it, closing or part-closing the invoice immediately.
• Payment taken before invoicing creates a Customer Deposit against the Sales Order, so it applies automatically when the invoice is raised and stops advance payments sitting in limbo.
• Payment that cannot be matched lands in an unapplied queue with its payload attached, visible on a saved search, for someone to resolve.

Because this runs on the gateway's notification rather than a polling schedule, the payment is normally in NetSuite within moments of the customer paying.

AED settlement and fee reconciliation

A Scheduled script imports settlement or payout data and creates a settlement record listing the transactions in the batch, the gross amount, the gateway's fees and the net deposited. Fees post to a gateway-fees expense account through a small mapping table. The net amount clears against a gateway clearing account, which means the deposit that lands in your bank matches a single clearing balance instead of needing a manual balancing journal. If you also take the occasional non-AED payment, the transaction currency and settled amount are both recorded so the difference is visible rather than absorbed.

Refunds and cancellations

Refunds can be initiated from NetSuite. Raising a Customer Refund against a payment, or a Credit Memo with a refund action, triggers the refund call to the gateway from a Suitelet-driven button, and the gateway's response is written back so the two systems agree. Partial refunds against the original transaction are supported. Refunds and voids performed directly in the gateway dashboard are detected on the next reconciliation run and raised in NetSuite so nothing diverges quietly.

Configuration, roles and visibility

Gateway credentials and endpoints live in a custom configuration record, not hard-coded in script. Payment methods are mapped to NetSuite Payment Methods and GL accounts through a mapping record, so card and any other enabled method can be reported separately. A dedicated integration role is created with only the permissions the scripts need, and inbound calls use token-based authentication. A User Event script prevents a synced payment from being edited in a way that would break the link back to the gateway transaction.

A small set of saved searches gives finance a single daily view: payments recorded today, unmatched payments waiting for a decision, failed notifications to retry, and settlement batches not yet reconciled.

Who this is for

UAE small and mid-sized businesses already running NetSuite who take card payments through a regional gateway and are currently recording those payments by hand. It fits companies with one entity, or a small number of entities, trading mainly in AED — professional services firms, distributors, and online retailers whose transaction volume does not justify an enterprise integration project.

If you are running many merchant accounts across several countries and currencies with complex per-subsidiary accounting, this is the wrong size of build and we will say so during scoping.

How delivery works

Scoping call. We look at your gateway account, how payments arrive today, whether they land against invoices or sales orders or both, your chart of accounts, and which entity and currency they belong to. Short call, concrete outcome.

Fixed quote. You get a written scope and a fixed price before development begins. The listed price reflects a single-merchant, primarily-AED, single-entity scope. Anything beyond that is quoted explicitly rather than discovered mid-build.

Build. Typical lead time is one working week. Development uses SuiteScript 2.1 — a RESTlet for the inbound notification, Map/Reduce for posting and reconciliation, a Scheduled script for settlement import, a Suitelet for refund actions, and User Event scripts for guards — with SuiteFlow used where an exception needs routing to a person.

Install in test, then production. Everything is installed and tested in your sandbox first against the gateway's test credentials: a successful payment, a deposit against a sales order, a partial refund, a deliberately unmatchable payment, and a settlement batch reconciled end to end. Only then does the bundle move to production, and we watch the first live day with you.

Support. A support window follows go-live covering defect fixes and any gateway API change announced in that period. You receive the full source code and documentation, so you are free to maintain it in-house afterwards.