PayoutsMarkets

Egypt Payouts

EGP payouts to banks and Fawry wallets

Use this guide when you want to send EGP payouts to recipients in Egypt. Egypt supports bank transfers and mobile wallets (Fawry).

Overview

  • Currency: EGP (Egyptian Pound); USD is also supported for some bank transfers.
  • Payment location: EGY
  • Supported rails: Bank transfer, Mobile wallet
  • Payment methods:
    • Bank transfer → paymentMethodId: "banktransfer", recipient.type: "bank_account"
    • Mobile wallet → paymentMethodId: "mobilemoney", recipient.type: "mobile_money"

Required fields by rail

Bank transfer

FieldRequiredNotes
accountNumberYesBank account number; IBAN format supported (and required for USD bank transfers to most banks).
bankCodeYesUse a value from Bank codes (Egypt) below.
accountHolderNameYesName on the account.
countryYesEGY
phoneNumberNoInternational format; optional for bank.

Sender required. Egypt payouts (bank and wallet) require a sender object with originator (remitter) details. Include the sender object with the fields described in the API reference. Typical required sender fields: full name (first and last), address, date of birth (format DD-MMM-YYYY), nationality and country of residence (ISO alpha-2), and for some flows identity type (e.g. passport or government ID), identity number, and identity expiry date. Receiver address may be required for some USD bank transfers; see the API reference for the full schema.

Mobile wallet (Fawry)

FieldRequiredNotes
phoneNumberYes11 digits; Egyptian format supported (e.g. 01011111145, +201011111145, 201011111145).
countryYesEGY
operatorYesUse fawry
nameNoRecipient name

Top-level required fields for every payout: merchantId, merchantReference, destinationValue (with minorAmount and currency), paymentMethodId, paymentLocation, recipient. For Egypt, sender is also required (see above).

Bank codes (Egypt)

For EGP (and USD) bank payouts, use one of the following values in recipient.bankCode. These identify the beneficiary’s bank.

bankCodeBank
BDCBanque Du Caire
CIBCommercial International Bank
POSTEgypt Post (for cash pickup; account number required when using this code)

A full list of supported bank codes may be available via your account manager or a lookups endpoint; use a valid code from that list when in production.

Account and wallet format rules

  • Bank (EGP): Account number in local format or IBAN. IBAN is recommended for compatibility.
  • Bank (USD): IBAN is required for most banks; one bank code may accept non-IBAN. Use the format required by the rail for the chosen bank.
  • Wallet (Fawry): 11-digit Egyptian mobile number. Accepted formats: with or without country code (e.g. 01011111145, +201011111145, 201011111145).
  • Reference: merchantReference must be unique per payout. Use only letters (A–Z, a–z), digits (0–9), and hyphens (-).

Invalid account or wallet format (e.g. invalid Egyptian IBAN) returns a validation or downstream error with a message such as “Invalid Egyptian IBAN format. Please enter a valid IBAN.” Check failureReason or the error response for the exact field and message.

Purpose and remittance source

Egypt payouts require a purpose code (reason for the transfer). An optional source of remittance code may be supported. Valid purpose and source values are provided via the lookups API or your account manager; use those values in the request when the API supports them (e.g. in attributes or as specified in the Create Payout schema).

Example requests

Bank transfer (EGP)

1{
2  "merchantId": "your-merchant-id",
3  "merchantReference": "PAYOUT-EG-001",
4  "destinationValue": {
5    "minorAmount": 150000,
6    "currency": "EGP"
7  },
8  "paymentMethodId": "banktransfer",
9  "paymentLocation": "EGY",
10  "recipient": {
11    "type": "bank_account",
12    "accountNumber": "EG550019000510000000000000010",
13    "bankCode": "CIB",
14    "accountHolderName": "Omar Hassan",
15    "country": "EGY"
16  },
17  "sender": {
18    "fullName": "John Smith",
19    "address": "123 Main Street, City, Country",
20    "dateOfBirth": "01-Jan-1985",
21    "nationality": "US",
22    "countryCode": "US"
23  }
24}

For Egypt, sender is required. Add the sender object with the fields defined in the API reference; the example above shows typical fields (full name, address, date of birth, nationality, country). Identity type, number, and expiry may be required for some flows.

Mobile wallet (Fawry)

1{
2  "merchantId": "your-merchant-id",
3  "merchantReference": "PAYOUT-EG-002",
4  "destinationValue": {
5    "minorAmount": 75000,
6    "currency": "EGP"
7  },
8  "paymentMethodId": "mobilemoney",
9  "paymentLocation": "EGY",
10  "recipient": {
11    "type": "mobile_money",
12    "phoneNumber": "201001234567",
13    "country": "EGY",
14    "operator": "fawry",
15    "name": "Mona Ibrahim"
16  }
17}
  • minorAmount: 150000 = 1,500.00 EGP; 75000 = 750.00 EGP.
  • bankCode: Use a value from Bank codes (Egypt).

Status and failure behaviour (EGP)

EGP payouts use the same CrissCross payout statuses as other destinations: PENDING, PROCESSING, COMPLETED, FAILED, and CANCELLED. The following describes behaviour that is specific to Egypt payouts.

Invalid account or format
If the beneficiary account number or wallet number is invalid (e.g. wrong length, invalid Egyptian IBAN), the payout may move to FAILED with a reason in failureReason (e.g. incorrect account number, invalid account format, invalid wallet number). Validate account and wallet format before submitting.

Beneficiary bank or account restrictions
The payout may fail if the beneficiary bank is temporarily unavailable, the account is restricted and cannot receive funds, or the account does not accept the payout currency (e.g. EGP). You will receive FAILED with an appropriate reason in failureReason.

Compliance and sanctions
Transactions may be suspended or rejected after compliance or sanctions screening. In that case the payout moves to FAILED (or a dedicated status if your contract exposes it) with a reason indicating compliance/sanctions rejection. Do not retry the same transaction without resolving the underlying cause.

Reversals
In rare cases, a payout that has reached COMPLETED can be reversed (e.g. expired and returned). You will receive a final status update; the payout will no longer be considered completed. Check payout history and webhooks for the updated status and reason.

Cancellation
You can cancel an Egypt payout that has not yet completed. Once cancelled, the payout has status CANCELLED and will not be processed. Use the cancel endpoint or your integration’s cancellation flow; see the Payouts API Reference for cancel behaviour.

For full status definitions and how to track payouts, see Tracking Payouts.

Retries and idempotency (EGP)

If an EGP payout request times out or returns an error, retry using the same merchantReference. CrissCross treats the request as idempotent: if the original request was already accepted, a retry with the same reference will not create a duplicate payout.

  • Retry with the same merchantReference — Do not generate a new reference on retry; reuse the one from the failed or timed-out request.
  • Use exponential backoff — Wait a short time before the first retry (e.g. a few seconds), then increase the delay between subsequent retries.

This applies to all payouts but is especially important for Egypt when you rely on idempotency to avoid double sends after timeouts or transient errors.

Sandbox testing (EGP)

To simulate successful payouts, failures, third-party rejection, and bank rejection in the sandbox, use the account number suffix rules described in Sandbox Testing — Egypt (EGP).