Pakistan Wallet Payment Gateway Connector

The problem

In Pakistan, mobile wallets are how consumers and a growing share of small businesses actually pay. Your customers send money from a wallet app, the money lands in your merchant account, and the wallet provider gives you a portal to look at. NetSuite knows none of it.

So somebody exports a transaction report every morning, opens it beside the open-invoice list, and matches payments to customers by reading reference numbers and phone numbers. Payments with a mistyped invoice reference sit unapplied. Two customers who paid the same amount on the same day get swapped. Settlement lands net of the provider's fee, so the deposit never equals the sum of the payments and the bank reconciliation carries a permanent unexplained difference. Refunds are processed in the provider portal and then remembered — or not — in NetSuite. And because none of this is posted in near real time, credit control chases customers who paid three days ago.

This is not a NetSuite deficiency in an abstract sense; it is simply that these rails are regional and no reconciliation path exists on the ERP side. ECOSIRE builds one.

What ECOSIRE builds

Merchant configuration and credential handling

A custom configuration record per merchant account, holding the endpoint set, merchant identifiers, integration mode and the PKR bank or clearing account the settlement posts to. Secrets are stored so that they are not readable from ordinary record view — we use NetSuite's secret handling with script-scoped access rather than plain custom fields, and the integration role that touches them is separate from any user role.

On OneWorld, configuration is per subsidiary, so a group with more than one Pakistani entity keeps its merchant accounts, currencies and clearing accounts properly separated.

Payment initiation

A request record and a SuiteScript 2.1 client and Suitelet flow that raises a payment request against an open Invoice or Sales Order: amount in PKR, customer, wallet mobile number, invoice reference, and an expiry. The connector calls the provider's API using N/https from a server script — never from the browser — and stores the provider's transaction identifier, status and raw response against the request record.

Where the provider supports a hosted checkout or a push-to-wallet prompt, the connector generates and returns the link or triggers the prompt, and the request record tracks it through pending, completed, failed, expired and reversed states.

Callback and status handling

A RESTlet endpoint that receives the provider's asynchronous callback. It verifies the message signature or hash before trusting anything in it, checks the amount and currency against the originating request, and is written to be idempotent — the same callback delivered twice produces one payment, not two. Duplicate delivery is normal on these rails and a naive handler double-posts.

Because callbacks are sometimes delayed or lost entirely, a Scheduled script also polls the provider's status API for any request still pending beyond a threshold and reconciles the state. A payment is never considered settled on a single unverified signal.

Posting into NetSuite

On a verified successful payment, the connector creates a Customer Payment applied to the referenced Invoice, or a Customer Deposit where the payment precedes invoicing, posting in PKR to the configured undeposited-funds or clearing account with the subsidiary, department, class, location and any custom segments your setup requires.

The provider's transaction reference, wallet mobile number, channel and timestamp are written to custom fields on the transaction, so the payment is traceable back to the rail without opening the provider portal. Where the provider deducts a merchant discount rate, the fee is posted to your expense account and the net is carried to the clearing account, so the deposit will actually match the bank.

Settlement reconciliation

A Map/Reduce script that ingests the provider's settlement or batch file, groups the underlying transactions, and creates the Deposit or Journal Entry representing the net amount that hits your bank — with the fee and any tax on the fee separated onto their own lines.

An exception dashboard surfaces the cases that need a human: a settlement line with no matching payment record, a payment marked successful in NetSuite that never appeared in a settlement, an amount mismatch, and a payment whose reference did not resolve to any open invoice. These are worked from a Suitelet queue rather than found by scrolling a spreadsheet.

Refunds and reversals

A refund request flow that calls the provider's reversal API and, on confirmation, creates the matching Customer Refund or Credit Memo application in NetSuite. Refunds route through SuiteFlow approval before they are sent, with the approver, reason and original transaction reference recorded.

Operations and audit

An integration log record capturing every outbound request and inbound callback with timestamps, status codes and correlation identifiers, retained for the window you specify. Saved searches report collection volume by channel, unmatched exception ageing, fee cost as a percentage of collections, and average time from wallet payment to NetSuite posting.

Who this is for

Businesses operating in Pakistan that already run NetSuite and collect from customers through mobile wallets: e-commerce and direct-to-consumer sellers, subscription and instalment businesses, education providers, healthcare clinics, utilities and service billers, distributors collecting from a long tail of small retailers, and any exporter or group subsidiary with a local PKR collection arm.

It is most valuable where volume is high enough that manual matching has become a daily job, or where unapplied receipts and bank reconciliation differences are already showing up in the month-end close.

How delivery works

1. Scoping call. We confirm which wallet rails and merchant products you hold, whether you are collecting against invoices, orders or subscriptions, how settlement reaches your bank, how fees are charged, your subsidiary and currency setup, and what your finance team needs to see on an exception. We also confirm what API credentials and sandbox access your provider has issued you, since we build against your own merchant credentials.

2. Fixed quote and specification. You receive a written specification listing every custom record, field, script, endpoint, saved search and role change, plus the fixed price and schedule. Nothing is built until you approve it.

3. Build. Developed as an SDF project using SuiteScript 2.1 — RESTlet for callbacks, Suitelet for the operations console, User Event and Client scripts on transactions, Scheduled scripts for status polling, and Map/Reduce for settlement ingestion — with token-based authentication and a scoped integration role. Typical build time is two to four weeks from approval.

4. Install into your sandbox. We deploy to your sandbox or development account and connect it to the provider's test environment using your credentials. You run end-to-end tests — successful payment, failed payment, expired request, duplicate callback, refund, settlement with a deliberately unmatched line — and see the resulting NetSuite postings before anything touches production.

5. Promote to production. After sandbox sign-off we deploy the same SDF project to production, switch to live credentials, and run a controlled low-volume go-live where each posting is checked, before opening the full flow. You own the source as an unmanaged bundle or SDF project in your account.

6. Support window. A defect-fix and question-answering window follows go-live, agreed at quote time. If a provider changes an API version or a settlement file format later, that adaptation is quoted as enhancement work.

What this is not

This is not a pre-built download and there is no trial. It is not a payment service — ECOSIRE does not hold funds, does not act as a payment processor, and does not issue merchant accounts. You hold the merchant relationship and the credentials directly with your provider; we build the ERP-side connector, reconciliation and posting logic against those credentials. Access to the provider's API documentation, test environment and production keys is a prerequisite we confirm at scoping.