> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.crisscross.money/payout-market-egypt/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.crisscross.money/_mcp/server. # Egypt Payouts 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 | Field | Required | Notes | | ------------------- | -------- | ----------------------------------------------------------------------------------------------- | | `accountNumber` | Yes | Bank account number; IBAN format supported (and required for USD bank transfers to most banks). | | `bankCode` | Yes | Use a value from [Bank codes (Egypt)](#bank-codes-egypt) below. | | `accountHolderName` | Yes | Name on the account. | | `country` | Yes | `EGY` | | `phoneNumber` | No | International format; optional for bank. | **Sender required.** Every payout requires a **sender** object with originator (remitter) details: `fullName`, `identity` (document type, e.g. `passport` or `nationalId`), and `identityNumber` are required for KYT/KYC screening. Egypt payouts typically also need `senderAddress`, `dateOfBirth` (format `DD-MMM-YYYY`), and `nationality` and `country` of residence (3-letter ISO codes); `identityExpiryDate` may be required for some flows. Receiver address may be required for some USD bank transfers; see the [API reference](/api-reference/payouts/payouts/payouts/initiate-payout) for the full schema. ### Mobile wallet (Fawry) | Field | Required | Notes | | ------------- | -------- | ------------------------------------------------------------------------------------------- | | `phoneNumber` | Yes | 11 digits; Egyptian format supported (e.g. `01011111145`, `+201011111145`, `201011111145`). | | `country` | Yes | `EGY` | | `operator` | Yes | Use `fawry` | | `name` | No | Recipient name | Top-level required fields for every payout: `merchantId`, `merchantReference`, `destinationValue` (with `minorAmount` and `currency`), `paymentMethodId`, `paymentLocation`, `recipient`, `sender` (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. | bankCode | Bank | | -------- | -------------------------------------------------------------------------- | | `BDC` | Banque Du Caire | | `CIB` | Commercial International Bank | | `POST` | Egypt 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](/api-reference/payouts/payouts/payouts/initiate-payout) schema). ## Example requests ### Bank transfer (EGP) ```json { "merchantId": "your-merchant-id", "merchantReference": "PAYOUT-EG-001", "destinationValue": { "minorAmount": 150000, "currency": "EGP" }, "paymentMethodId": "banktransfer", "paymentLocation": "EGY", "recipient": { "type": "bank_account", "accountNumber": "EG550019000510000000000000010", "bankCode": "CIB", "accountHolderName": "Omar Hassan", "country": "EGY" }, "sender": { "fullName": "John Smith", "identity": "passport", "identityNumber": "A12345678", "senderAddress": "123 Main Street, City, Country", "dateOfBirth": "01-Jan-1985", "nationality": "USA", "country": "USA" } } ``` The `sender` object is required for every payout — `fullName`, `identity`, and `identityNumber` at minimum. The example above adds the fields Egypt typically needs (address, date of birth, nationality, country); `identityExpiryDate` may be required for some flows. See the [API reference](/api-reference/payouts/payouts/payouts/initiate-payout) for the full schema. ### Mobile wallet (Fawry) ```json { "merchantId": "your-merchant-id", "merchantReference": "PAYOUT-EG-002", "destinationValue": { "minorAmount": 75000, "currency": "EGP" }, "paymentMethodId": "mobilemoney", "paymentLocation": "EGY", "recipient": { "type": "mobile_money", "phoneNumber": "201001234567", "country": "EGY", "operator": "fawry", "name": "Mona Ibrahim" }, "sender": { "fullName": "John Smith", "identity": "passport", "identityNumber": "A12345678", "senderAddress": "123 Main Street, City, Country", "dateOfBirth": "01-Jan-1985", "nationality": "USA", "country": "USA" } } ``` * `minorAmount`: 150000 = 1,500.00 EGP; 75000 = 750.00 EGP. * `bankCode`: Use a value from [Bank codes (Egypt)](#bank-codes-egypt). ## Status and failure behaviour (EGP) EGP payouts use the same [CrissCross payout statuses](/payout-tracking#payout-status) 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](/payout-tracking#viewing-payout-history) and [webhooks](/core-concepts-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](/api-reference/payouts) for cancel behaviour. For full status definitions and how to track payouts, see [Tracking Payouts](/payout-tracking). ## 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 and failure scenarios in the sandbox, use the account-number ending rules described in [Payout Trigger Endings](/payout-sandbox-testing). ## Related guides * [Bank Transfers](/payout-bank-transfers) * [Mobile Wallet](/payout-mobile-wallet) * [Supported Destinations](/payout-supported-destinations) * [Tracking Payouts](/payout-tracking) * [Payout Trigger Endings](/payout-sandbox-testing) > EGP payouts to banks and Fawry wallets