Integration
Network International, for merchants who already have the bank relationship
Network International is a major regional acquirer used by established UAE merchants, often alongside an existing bank relationship. Behind a Telegram bot it works as a hosted checkout. It is an enterprise-shaped relationship: onboarding is heavier than a gateway and the commercial terms are negotiated.
Network International integration: auth, limits and availability
- Auth model
- OAuth 2.0
- Tokens
- Short-lived; refreshed through the client-credentials flow
- GCC availability
- UAE primary market, with deep local bank relationships
- Data flow
- 5 hops, worker-mediated
As of 2025-10-01, Telegram Bot API 13.4
Why this integration exists
The businesses that end up here are rarely choosing a processor from scratch. They already accept cards in physical locations, they already have terminals and an acquiring relationship, and the online channel is being added to something that exists. In that situation, keeping one acquirer across both channels means one reconciliation, one set of commercial terms and one support relationship, which is worth more operationally than any API difference.
This changes the shape of the project. With a gateway aimed at small merchants, the integration is the work and onboarding is a form. With an acquirer of this size, onboarding involves account managers, technical certification and a schedule that belongs to someone else. The engineering is not harder; the coordination is, and a plan that treats it as a two-week API task will be wrong about the timeline by a factor.
What you get for that is a relationship with real weight behind it. For a business processing meaningful volume across physical and online channels, having one acquirer able to see both, and to negotiate on the whole, is a stronger position than a per-channel gateway arrangement. For a business that is not yet at that scale, it is overhead without the benefit.
How the data actually moves
Access is granted through an OAuth client credentials exchange producing a short-lived token, which is cached in the Worker and refreshed before expiry rather than on failure. Refreshing reactively means the first request after every expiry fails, which under load is a steady trickle of avoidable errors that looks like an unreliable gateway.
Auth model: OAuth 2.0
Their limits, and what they mean for you
Access tokens are short-lived and must be refreshed through the client credentials flow.
Tokens are cached and refreshed proactively before expiry. Refreshing on the first failure guarantees one failed customer payment per expiry window, which is a recurring, self-inflicted error.
Technical certification is required before production access is granted.
There is a sign-off step between a working integration and a live one, controlled by the acquirer's schedule. Building it into the plan is the difference between a launch date and a hope.
Commercial terms including rates and settlement are negotiated per merchant rather than published.
Cost cannot be estimated from public pricing. It is a conversation with an account manager, and it should happen before the technology decision rather than after.
Sandbox behaviour can differ from production in edge cases, particularly around 3-D Secure.
Certification exists partly for this reason. Plan for a round of production-mode testing with real low-value transactions rather than assuming sandbox parity.
How it fails, and what happens when it does
A cached access token expires mid-request.
The request retries once with a fresh token rather than surfacing an error. A single expiry should never reach a customer as a failed payment.
3-D Secure interrupts checkout and the customer abandons during the challenge.
The order stays pending and expires on a timer, releasing whatever it held. This is more common here than with consumer-focused gateways because the challenge is more often mandatory.
A webhook is delivered for an order the Worker has no record of.
Logged and escalated rather than ignored. It usually means an order was created against the wrong environment, which is worth finding immediately rather than at reconciliation.
Settlement reporting disagrees with the bot's order records.
Daily reconciliation compares the two and alerts on drift. With an acquirer this size the settlement file is authoritative, so the bot's job is to notice disagreement quickly.
Availability in the UAE and the wider GCC
United Arab Emirates
A primary market with deep bank relationships. The natural choice for an established merchant already acquiring through a UAE bank.
Wider Middle East and Africa
Substantial regional presence, with terms and capabilities varying by country. Each market is a separate commercial conversation.
Small merchants and startups
Generally a poor fit. The onboarding and certification overhead is designed for established volume, and a smaller business is better served by Telr or PayTabs.
Crypto and virtual assets
Not underwritten, in common with card acquirers generally. A virtual asset business needs a chain rail.
When not to use this integration
- You are a small or new merchant. Onboarding and certification overhead will dominate the project, and a gateway aimed at your size will get you live months sooner.
- You need to launch quickly. The certification step is controlled by the acquirer's schedule, and no amount of engineering urgency moves it.
- You have no existing bank or acquiring relationship. The main advantage here is consolidating one you already have.
- You are selling virtual assets. Not underwritten, as with card acquirers generally.
What it runs on
| Component | Version | Why |
|---|---|---|
| Cloudflare Workers | current | Token caching, order creation and webhook handling. |
| Cloudflare KV | current | Access token cache shared across Worker invocations. |
| Cloudflare D1 | current | Orders, settlement reconciliation state and the drift log. |
| Zod | 4.4 | Validation of token and webhook responses. |
Questions that come up during scoping
When is Network International the right choice over a gateway?
When you already acquire through a UAE bank for physical channels and want one relationship across both. The advantage is commercial and operational consolidation rather than anything technical, and it is real at scale.
What is technical certification and how long does it take?
A sign-off step where the acquirer verifies your integration behaves correctly before granting production access. The duration belongs to their schedule rather than yours, which is why it goes in the plan as a dependency rather than as a task.
Why cache the access token rather than fetching one per request?
Because a token exchange on every payment adds latency to the customer's critical path and multiplies your request volume for no benefit. It is cached and refreshed before expiry, so no customer ever waits for a token.
Is 3-D Secure mandatory?
More often than with consumer-focused gateways, and it materially affects completion. The checkout is designed expecting the challenge rather than treating it as an exception, since designing around the happy path makes the common case feel broken.
How do we reconcile against settlement?
A daily job compares the settlement file against the bot's order records and alerts on any drift. The settlement file is authoritative, so the bot's job is to notice disagreement in days rather than at a quarterly review.
Can we estimate the cost before talking to them?
Not usefully. Rates are negotiated per merchant rather than published, so the commercial conversation should precede the technology decision rather than follow it.
Related reading
For a smaller merchant without an existing acquiring relationship, start with the Telr integration.
Where several GCC countries are involved, compare against the PayTabs integration.
Deposit-heavy flows that depend on authorisation holds are covered by the car rental build.
Certification overhead is a real cost line, discussed in how payment integration affects the price.