Paymob Guide: Non-Card Payment Collection in Egypt and the Middle East

Paymob Guide: Non-Card Payment Collection in Egypt and the Middle East

Designing a payment setup for Egypt as if it were a card market usually shows problems within the first month. The defining trait of markets such as Egypt is a high share of non-card methods: offline collection points, mobile wallets and local card schemes together carry most volume, so card-only acquiring is not merely incomplete coverage but a direct loss of many orders that could have completed.

The value of a local acquirer is exactly here, bringing those non-card methods in. Paymob started in Egypt and serves the Middle East and parts of Africa, covering card and non-card local payment methods. But connecting non-card methods is where the real work begins: asynchronous arrival, voucher verification and different refund paths all have to be designed before launch, and none of them can be handled with the synchronous logic that card acquiring allows. This guide follows the order of an actual integration: positioning and boundaries, onboarding, integration shapes, method behaviour, fee composition, and the misreadings that recur.

1. Positioning: A Local Egyptian Acquirer and a Non-Card Entry Point

1.1 A High Non-Card Share Is the Real Structure

When discussing Middle Eastern payments, the easiest distortion is to imagine the whole region as a wealthy card market. The real transaction structure is far more layered: offline collection points carry a large share of cash-based transactions, where the buyer pays at a branch and receives a voucher; mobile wallets are one of the primary channels in mobile scenarios; and local card schemes coexist with international cards, with local acceptance and habit often better for the local scheme.

What these three share is that pure card acquiring cannot cover any of them. Offline collection needs a voucher system, wallets need redirects and state confirmation, and local cards need local acceptance. If your checkout page has only a card input field, the typical buyer does not try another card but closes the page and looks for somewhere that accepts cash.

That is the value of a local acquirer here: it brings card and non-card methods into one collection chain so you do not have to find a separate partner for each method.

1.2 What It Is Not

First, it is not a local entity. The local entity, tax registration and invoicing obligations that apply when you operate in Egypt do not disappear because you use a local acquirer. For the wider structure see the Cross-Border Seller Entity and Account Structure Guide.

Second, it is not one uniform solution for the whole Middle East and Africa. Differences inside the region are large: card and wallet structures in the Gulf, cash and collection structures in North Africa, and mobile wallet structures in parts of sub-Saharan Africa do not follow the same logic. For regional depth read the Middle East Payment Guide and the Africa Payment Guide separately.

Third, it is not outsourced fraud control. Fraud and dispute behaviour on non-card methods differs from cards, and in many scenarios the evidence burden rests on the merchant order records and delivery proof. For the overall framework see the Payment Fraud Prevention Strategies Guide, but the operating rules must be rewritten per local method.

2. Onboarding and Entity Requirements

2.1 What Onboarding Actually Looks At

Onboarding variables for local acquiring match mature markets: entity location, how explainable the business model is, how verifiable the website and product are, expected volume and category risk. The difference is sensitivity. Markets such as Egypt weigh cross-border money movement and category risk more heavily, especially for non-card methods, because tracing the source of funds in cash-based transactions is harder and regulators therefore demand more explainability.

The most underestimated item when preparing material remains business explainability. The reviewer needs a page a third party can open, from which to judge what you sell, to whom, whether the refund policy is clear, and whether the support channel actually works. If the page is product images and an order button, the number of rounds rises noticeably.

Another point is that delivery model must line up. Digital content, physical goods, subscription services and offline redemption businesses have different transaction structures and accept different evidence. If the page says physical goods while the order flow has no shipment and return path, review stalls easily.

2.2 Local Entities and the Collection Network

One point is often missed: a local acquirer can cover offline collection points and local wallets because it has connections into the local collection network. The other side of that connection is responsibility. When you use these methods, part of the transaction takes place inside the local network, which means vouchers, identity details and stated purpose must be acceptable to that network.

In practice this shows up in several ways. Some non-card methods require a local merchant identity, some apply tiered rules on per-transaction and cumulative amounts, and some require delivery proof from the merchant when a buyer complains. None of these rules loosen because you operate well in another market.

So the entity question has to be settled early: which markets can contract on your existing entity and which require a local entity or local contact first. Make that list, then decide which market to integrate first, which saves far more time than integrating everything and fixing entities afterwards. For overall account structure see the entity guides, adjusted to Egyptian and Middle Eastern local rules.

3. Integration Options and Account Structure

3.1 Integration Shapes and Checkout Flow

Local acquirers generally offer two integration shapes: hosted checkout, which takes the buyer to a provider-maintained page, and an API integration, where you render method selection in your own page and handle state yourself.

In a market with a high non-card share, this choice matters more than in a card market. The reason is that non-card checkout flows are longer: wallets redirect, collection needs voucher and branch information, QR payments need a refreshable code within its validity window. Hosted checkout maintains all of this for you and gets you live fast. An API integration gives you control over flow order and failure guidance, but you handle the special states of every method. If the goal is local conversion, the API integration is usually worth the effort, provided the team can carry the state machine work.

On account structure, the common shape is a main account with several merchant configurations underneath, separated by market, currency and business line. Confirm whether each configuration can set payment methods independently, produce its own settlement report, and how refund permissions are divided.

3.2 Three Design Points That Differ From Cards

The first is asynchronous state. Card authorisation returns inside the request. Most non-card methods do not. Voucher-based collection waits for the buyer to pay at a branch, and wallet methods can sit in an intermediate state for a long time. The system must define validity windows, timeout closure rules and arrival matching rules per method.

The second is voucher verification. Offline collection is not a case of the webhook arriving and therefore being successful. The buyer receives a voucher number at the branch, and you need a separate verification or query flow to align the voucher with actual funds received, and to answer a customer query about where the money is.

The third is the refund path. Non-card refunds frequently do not return simply to source: collection methods may need an offline refund process, and wallet methods may return funds to a wallet balance. A refund flow designed on card assumptions breaks at the first batch of refund requests. For operational detail see the Payment Reconciliation and Bill Operations Guide and the Payment Refund and Settlement Operations Guide.

4. Core Capabilities and Market Coverage

4.1 Arrival Behaviour of Payment Methods

When evaluating a market like this, the most useful step is to mark the arrival behaviour and operational load of each method. Arrival behaviour drives the state machine and support scripts, while operational load decides how many people you need for verification, queries and exception handling.

Local cards offer good acceptance and synchronous authorisation, with refunds and disputes still following card rules. International cards are accepted less consistently in some scenarios and face stricter review on cross-border transactions. Mobile wallets confirm synchronously or near-synchronously but bring redirect and wallet-side cancellation problems. Offline collection is classically asynchronous and needs a voucher system with manual or semi-manual verification. Local transfer methods need matching of funds by amount and reference number.

4.2 Methods and Operational Load

The way to use the table is to fix the lead methods for your buyer profile first, then reserve people for the high-load ones. If offline collection and local transfers need manual work, that cost belongs in the operating budget from the start rather than being discovered in peak season. For regional method differences see the Local Payment Methods by Region Guide.

5. Fee Structure and Real Cost

5.1 Fee Components

Local acquiring fees are not one number but a set of components, and non-card methods lengthen the list considerably.

Current rates and conditions belong to the official quote and the signed contract. Any percentage in an article goes stale, and budgeting from old numbers is the easiest error to make.

5.2 Judging the Real Cost

Comparing headline rates is the easiest mistake at this stage. The right method is to build a transaction mix that matches your business: the same method share, the same order value bands and the same refund rate, then compare total cost and final received amount.

Non-card markets carry one hidden item: manual labour. If offline collection and local transfers depend on manual verification, that cost grows linearly with order count, while percentage fees scale with value, so the two behave completely differently as volume grows. List it separately in the budget.

Another dimension is failure and abandonment. Non-card flows are longer, so abandonment is usually higher than with cards, which directly reduces actual revenue. Comparing fees without completion rate usually produces an over-optimistic conclusion.

6. How It Divides Work With Other Options

6.1 Against Regional Aggregators

Regional aggregators have the advantage of consistency across markets: one contract covering several markets with one interface style. In a region as internally varied as the Middle East and Africa, the aggregator value is letting several markets run at low organisational cost. When evaluating, compare the market focus and method lists of PayTabs and dLocal.

The cost is local depth. Non-card methods usually depend on local collection networks, and an aggregator coverage in a given market may fall short of an acquirer that works the ground there. If Egypt is your main market, local depth usually matters more. If Egypt is one of several markets, aggregator convenience may pay off better.

6.2 Against Global Acquiring Platforms

Global acquiring platforms offer mature interfaces, complete documentation and full tooling, which suits teams with engineering capacity that want payment logic under their own control. Their local method coverage usually depends more on partner channels: the method list may be sufficient, but success rate and experience on local non-card methods may not match a local acquirer. When evaluating, compare the Middle East method lists and settlement structures of Adyen and Stripe.

A pragmatic combination is to run main card volume on a global platform and non-card local methods through a local acquirer. The cost is two reconciliation flows and two dispute processes, which needs extra engineering to abstract. Whether it is worth it depends on the weight of local non-card methods in overall revenue.

7. Who It Fits and Who It Does Not

7.1 Good Fit

First: teams where Egypt or the Middle East is the main market and buyers are mostly local consumers. Non-card coverage directly decides whether a sale completes.

Second: businesses with modest order values but high order frequency, such as consumer goods, content subscriptions and local services. Checkout failure hits these most directly.

Third: teams willing to invest operations headcount in voucher verification and management. Non-card methods do not run by themselves after integration.

Fourth: teams willing to design custom state machines and refund paths. Treating non-card methods like cards will certainly mean rework.

7.2 Weak Fit

First: teams whose buyers are mostly abroad and where Egypt is only a supplementary market. The incremental gain from local non-card methods may not cover integration and operating cost.

Second: teams with no operations capacity to handle offline vouchers. Collection methods keep generating vouchers and queries that need human handling.

Third: teams hoping one interface solves the whole Middle East and Africa. Internal differences are too large, so single-market options are more realistic.

Fourth: teams treating compliance and fraud control outsourcing as the goal. Evidence burdens on non-card methods fall more heavily on the merchant, which is the opposite of that expectation.

8. Rollout Notes and Common Misreadings

8.1 Rollout Notes

8.2 Common Misreadings

The first misreading is treating the Middle East as a uniformly card-based wealthy market. The region contains a great deal of cash and collection activity, and wallets are common in mobile scenarios. Card-only integration does not stop money entirely, but it loses a large number of orders that could have completed.

The second misreading is treating offline collection voucher verification as a gateway webhook. Collection confirmation is not solved by one callback: the buyer pays at a branch and receives a voucher, and you need a separate verification or query flow to align the voucher with funds received and to answer buyer queries with a definite answer. Handling it as a callback produces a mass of paid-but-unmarked orders.

The third misreading is assuming refunds always return to source. Non-card refund paths often differ: collection methods may need an offline refund process and wallet methods may return funds to a balance. Confirming each method before launch saves far more than discovering it at the first batch of refunds.

If you are evaluating payment options for Egypt and the Middle East, use this guide as a checklist: confirm first how buyers actually pay, then confirm whether arrival behaviour, voucher verification and refund paths for those methods all have a design in your system. For more regional judgement, continue from the Payment category page.

Source: 16IDC original. Product capabilities, pricing and eligibility requirements follow the relevant providers’ official documentation and contract terms.