GCC Payment Gateway Pack

Global card gateways do not acquire everywhere. Across the GCC and South Asia the payment that actually completes is usually taken by a local acquirer, a domestic debit scheme or a regulated mobile wallet — and each has its own API, its own settlement report, its own fee schedule and its own payout cycle. Dynamics 365 Finance and Supply Chain Management knows none of them. So a finance team ends up with a bank deposit, a spreadsheet exported from an acquirer portal, and a receivables clerk applying cash by hand, guessing which invoices a net payout covered and posting commission as a lump sum with no dimension detail.

This pack removes the manual step. ECOSIRE builds a connector set for the specific acquirers and wallets you hold merchant agreements with, as an X++ extension package for F&O plus a small relay component that runs in your own Azure subscription. Nothing is pre-built and nothing installs instantly; each build is scoped to your providers, your currencies and your posting rules, with a typical lead time of one working week from signed quote.

Taking the payment

Payment methods are configured as standard methods of payment (CustPaymModeTable), each bound to its own payment journal name, bank account and posting profile, so the ledger treatment of a wallet collection can differ from a card collection without a line of custom posting logic.

For receivables, the app generates a hosted payment link against an open customer invoice or a free text invoice and sends it through print management or a flow you already run, so the customer pays from the invoice they received. The link carries the invoice reference, which is exactly what makes automatic cash application possible later. Prepayments and deposits are supported where money is taken before an order is invoiced, posting to the prepayment account you nominate.

F&O is never exposed to the public internet for this. Provider webhooks are received by a small relay function in your Azure tenant, authenticated with a service principal, which calls a custom OData action on F&O. Every inbound message carries an idempotency key and is written to a gateway transaction log before it is acted on, so a provider retry — which is normal, not exceptional — cannot post the same payment twice.

Where the money lands in the ledger

A confirmed capture creates a customer payment journal through LedgerJournalTable and LedgerJournalTrans and settles the referenced open CustTrans record, so ageing and settlement history are correct without a second manual step. Journals can post automatically or be held for review, and can be routed through workflow where your controls require approval before cash posts.

Acquirer commission, per-transaction fees and wallet charges post to configurable main accounts with a full financial dimension combination, per provider and per instrument type. That is what lets a controller answer what each collection channel actually costs, instead of seeing one commission figure for the month.

Settlement, fees and bank reconciliation

Providers pay net, in batches, on their own cycle. The pack imports each provider settlement file through a Data management framework data entity and matches it line by line against the gateway transaction log, so every captured payment is accounted for and any transaction that never settled surfaces as an exception rather than a rounding difference. The net payout is written with a matching reference so it clears against the imported bank statement through advanced bank reconciliation matching rules.

Where a provider settles in a currency other than your accounting currency, the app applies a configurable exchange rate type and posts realized exchange differences to nominated accounts. Ledgers in AED, SAR, QAR, KWD, BHD, OMR and PKR are handled the same way, including the three-decimal minor units used by some Gulf currencies.

Status polling, settlement import and matching run on the batch framework as SysOperation services with their own batch group, recurrence and retry behaviour, raising alerts when a run finishes with unresolved exceptions.

Refunds, chargebacks and disputes

Refunds, full and partial, are initiated from F&O against the original captured transaction, so nobody has to log into a provider portal and then remember to post the entry. The reversal posts as a negative payment or a credit note depending on the rule agreed at scoping, and the provider reference is retained for dispute evidence. Chargeback and dispute notifications are written back against the customer transaction so receivables can see the hold without leaving the form.

Security and compliance posture

Credentials are held in Azure Key Vault and read through the F&O Key Vault parameters. No keys sit in code or in a configuration table a support user can read. No primary account numbers pass through or are stored in F&O — only provider tokens, references and masked display values. That design keeps card data out of the ERP and reduces the surface an assessment has to cover, but it is not a certification: your merchant agreement, your assessment and your provider onboarding remain yours.

Dedicated security duties and privileges are layered onto standard receivables and cash and bank roles, so operating the connector does not require handing out broad finance access.

Who this is for

Businesses running Dynamics 365 Finance and Supply Chain Management that collect through regional acquirers and wallets in the UAE, Saudi Arabia, Qatar, Kuwait, Bahrain, Oman or Pakistan, especially groups with several legal entities and currencies. It suits organisations invoicing from F&O and collecting online, and organisations whose current process is a monthly manual reconciliation of an acquirer report.

In-store card terminals are a different problem. Point of sale hardware station integration sits in the commerce stack, not in this pack, and we will say so at scoping rather than let it drift into scope by accident.

How delivery works

1. Scoping call. We confirm the providers, the merchant agreements you already hold, currencies and legal entities, invoice and prepayment flows, fee posting rules, and your environment topology and version. 2. Fixed quote. You receive a written scope covering each provider, the posting design, the settlement matching rules and the relay architecture, with a fixed price and delivery date. The listed price is a baseline; each additional provider is quoted on its own. 3. Build. Development runs against your target application and platform version, in an extension model with no overlayering, with source committed to a branch handed to your Azure DevOps repository. 4. Install in test. We deploy the package through your LCS release pipeline into a sandbox and the relay into your subscription, then run the full loop against provider sandbox credentials — authorize, capture, settle, import, reconcile, refund — until a complete cycle balances. 5. Production. The same artefacts move to production on your release cadence, switched to live credentials, with a controlled first-transaction test before volume is turned on. 6. Support. A defect-fix warranty window follows go-live, and an ongoing arrangement is available so provider API changes and service updates are handled before they break a payout.