Payment Gateway Agreements in Egypt: Liability, Regulatory Classification and Data-Breach Responsibility
Legal/Tech & Data Protection Article Elkobtan MFA Leg/Tech & Data Protection Law Firm.
www.elkobtan-ip.com
This article is prepared for general legal and technology-law information. It does not constitute a formal legal opinion. The allocation of liability in any particular payment arrangement depends on the parties’ contracts, licensing structure, system architecture, regulatory status and the facts of the incident.
Introduction
Payment gateway agreements often appear to concern a purely technical service: an application programming interface, a hosted payment page or a connection between a merchant and a bank. In practice, however, the gateway may sit at the centre of the entire payment ecosystem.
When a transaction fails, the immediate question is rarely limited to whether the API was functioning. The more significant legal questions are:
- Who was responsible for initiating the transaction?
- Who controlled the payment infrastructure?
- Who was responsible for authorization, confirmation and settlement?
- Who had control over the relevant personal data?
- Was the intermediary merely transmitting information, or was it facilitating the payment and managing merchant risk?
- Did the merchant, developer, gateway, facilitator or bank have the practical ability to prevent the failure?
Under Egyptian law, these questions cannot be answered solely by the title used in the contract. A company described as a “gateway” may, in substance, perform functions associated with a technical payment aggregator or payment facilitator. Similarly, a developer may become legally responsible for a payment failure if it undertook responsibility for integration, hosting, cybersecurity or system maintenance.
The correct approach is to examine the actual functions performed, the contractual allocation of responsibilities and the applicable banking, payment and data-protection requirements.
The Middle Layer: Gateway, Technical Aggregator or Payment Facilitator?
The term “middle layer” has no single legal meaning. It may refer to a technology provider, a payment-service provider, a technical payment aggregator or a payment facilitator. These roles should be distinguished because their legal and regulatory responsibilities may differ substantially.
A technical payment aggregator generally provides infrastructure that connects a merchant to payment channels. Its services may include payment-page hosting, API connectivity, transaction routing, payment-status notifications, tokenisation, reconciliation tools and technical support.
A technical aggregator may not receive or control merchant funds. Its principal responsibilities will therefore usually concern the operation, reliability, security and integrity of its technology. It may be liable where its platform fails to transmit a valid transaction, sends an inaccurate payment status, duplicates a transaction, loses transaction records or fails to comply with agreed security and availability requirements.
A payment facilitator generally occupies a more substantial position. Depending on the applicable Central Bank of Egypt framework and the approved operating model, it may contract directly with merchants or sub-merchants, operate through a sponsoring bank, support merchant onboarding, manage transaction risk, facilitate settlement and deal with refunds, chargebacks or payment disputes.
The payment facilitator may consequently bear broader operational and regulatory responsibilities. Nevertheless, its classification does not make it automatically liable for every incident. Liability still depends on the specific obligation that was breached, the provider’s degree of control and the causal connection between the breach and the loss.
The decisive legal test is therefore functional rather than purely descriptive. The agreement should accurately identify what the provider does, what it does not do, whether it handles funds, whether it contracts with merchants and whether it determines any purpose for processing personal data.
Who Is Responsible When the Payment Flow Fails?
There is no universal rule under Egyptian law that assigns every payment failure to either the merchant or the intermediary. Responsibility must be assessed by isolating the precise point of failure.
The merchant’s responsibility
The merchant may be responsible where the failure results from:
- incorrect integration;
- inaccurate transaction information;
- invalid credentials;
- failure to follow technical specifications;
- insecure configuration of the merchant’s website or application;
- unauthorized changes to payment code;
- failure to maintain its own systems;
- failure to implement required customer-authentication or security measures.
The merchant is also generally responsible for its commercial relationship with the customer. It determines the goods or services being sold, the refund policy, the customer-facing terms and, in many cases, the purpose for which customer data is collected.
The use of a gateway does not normally transfer all of these responsibilities to the gateway.
The developer’s responsibility
The developer’s position depends on the scope of its engagement. A developer that merely writes code according to the merchant’s instructions may have a different liability profile from a developer that:
- designs the payment architecture;
- hosts the payment application;
- stores payment-related information;
- manages credentials and keys;
- maintains the production environment;
- controls security updates;
- operates the integration on a continuing basis.
Where the developer’s code or service causes an unauthorized transaction, data exposure, failed payment, duplicate debit or incorrect payment status, the developer may face contractual liability to the merchant. The merchant may remain responsible to the gateway or customer under its separate contracts and may then seek recovery from the developer.
The development agreement should therefore distinguish clearly between coding responsibility, hosting responsibility, security responsibility and banking or settlement responsibility.
The gateway or technical aggregator’s responsibility
A gateway or technical aggregator may be liable where the loss arises from a failure within its own systems or within services that it expressly undertook to provide. Examples include:
- platform downtime exceeding the agreed service level;
- failure to route an otherwise valid transaction;
- incorrect transaction-status messages;
- loss or corruption of payment records;
- duplicate processing;
- failure of agreed monitoring controls;
- inadequate access protection;
- failure to preserve transaction logs;
- failure to notify the merchant of a material incident;
- failure to process a refund or reversal in accordance with the agreement.
The provider cannot necessarily avoid liability by describing itself as a “technology intermediary” where it exercised control over the relevant function or expressly assumed responsibility for it.
The facilitator, acquiring bank or payment network
Some failures arise at the authorization, acquiring, issuing-bank or payment-network level. An agreement should identify how such events will be handled and what evidence must be provided.
A bank or payment network failure may limit the gateway’s responsibility for the external event itself. It should not, however, automatically excuse the gateway from obligations such as:
- maintaining appropriate redundancy;
- monitoring the service;
- communicating outages;
- preserving transaction records;
- preventing duplicate submissions;
- performing reconciliation;
- assisting with refunds and reversals;
- investigating disputed transaction statuses.
A clause excluding liability for “bank or network failures” should therefore be drafted narrowly. It should not be used to eliminate the provider’s independent operational obligations.
Liability Under Egyptian Civil Law
Egyptian Civil Law No. 131 of 1948 provides the general framework for contractual and tortious liability. In a payment dispute, the relevant analysis will usually involve the existence of an obligation, a breach, damage and a causal relationship between the breach and the damage.
Contractual liability
The primary starting point is the contractual documentation. This may include:
- the master services agreement;
- the payment gateway agreement;
- the technical annex;
- the service-level agreement;
- the information-security schedule;
- the data-processing agreement;
- the merchant operating rules;
- the incident-response procedure;
- the applicable payment and settlement terms.
A court may consider the agreement as a whole rather than relying on one isolated clause. A provider that promises transaction routing, availability, reconciliation or security cannot generally avoid all responsibility through a broad disclaimer that contradicts those obligations.
The contract should identify the standard of service, the applicable response times, the required controls and the remedies available when those obligations are not met.
Fault and professional negligence
Payment and technology providers are expected to exercise care consistent with the professional nature of their services. The assessment may take into account:
- the provider’s technical expertise;
- the sensitivity of payment and personal data;
- the security controls promised;
- the foreseeable consequences of system failure;
- the provider’s ability to monitor and prevent the risk;
- the applicable regulatory expectations;
- the provider’s failure to respond after discovering the incident.
The mere existence of a technical problem does not automatically establish liability. It is necessary to connect the failure to a contractual breach, negligence or another legally recognized basis of responsibility. Evidence such as system logs, incident reports, change records, security assessments and communications may be decisive.
Limitation of liability
Technology agreements often contain liability caps and exclusions. These provisions should distinguish between ordinary service interruptions and more serious events, including:
- fraud;
- intentional misconduct;
- gross negligence;
- loss or misuse of funds;
- unauthorized transactions;
- confidentiality breaches;
- personal-data breaches;
- regulatory violations;
- third-party claims;
- indemnity obligations.
A cap that may be commercially reasonable for routine downtime may be inappropriate for the loss of customer funds or a serious security incident. Clauses seeking to exclude responsibility for fraud or serious fault may also face legal challenge.
Payment Aggregator or Payment Facilitator: Why the Difference Matters
The distinction between a technical payment aggregator and a payment facilitator is legally important because it may affect:
- licensing and regulatory obligations;
- merchant onboarding;
- transaction monitoring;
- responsibility for sub-merchants;
- settlement and funds handling;
- chargebacks and refunds;
- fraud risk;
- record keeping;
- customer and merchant support;
- responsibility for payment-related data.
A provider that only supplies technical connectivity may not be responsible for funds that it never receives or controls. Conversely, a provider that contracts with merchants, facilitates transactions through a sponsored structure or handles settlement may carry broader responsibilities.
The agreement should therefore state expressly:
- whether the provider receives or controls funds;
- whether the provider contracts directly with merchants;
- whether it performs merchant onboarding;
- whether it manages sub-merchants;
- whether it is responsible for refunds and chargebacks;
- whether it acts through a sponsoring bank;
- whether it is a technical provider, a regulated payment-service provider or another type of intermediary.
The legal classification should be consistent with the provider’s actual operations and regulatory approvals.
Personal Data Responsibility Under Law No. 151 of 2020
Payment processing involves personal data and may involve information relating to customers, cardholders, account holders, employees, merchants and authorized representatives.
Law No. 151 of 2020 establishes obligations concerning the lawful processing, security and protection of personal data. The parties must identify their respective roles according to the purposes and means of processing.
The merchant as controller
The merchant will often be the principal data controller because it determines why customer data is collected and used. Examples include:
- completing a sale;
- delivering goods or services;
- authenticating a customer;
- processing refunds;
- managing customer accounts;
- responding to complaints;
- complying with legal obligations.
The merchant’s use of a gateway does not necessarily transfer its controller obligations. The merchant should select service providers carefully, document the processing arrangement and ensure that the provider applies appropriate safeguards.
The gateway as processor
The gateway may act as a processor when it processes personal data on behalf of the merchant and according to the merchant’s documented instructions.
The gateway’s obligations may include:
- processing data only for authorized purposes;
- maintaining confidentiality;
- restricting access;
- applying technical and organizational security measures;
- protecting credentials and encryption keys;
- managing vulnerabilities;
- monitoring systems;
- maintaining logs;
- controlling personnel access;
- managing subcontractors;
- assisting with investigations;
- returning or deleting data when required;
- notifying the merchant promptly of security incidents.
The processor’s obligations do not disappear because the merchant is the controller. A processor may face direct contractual and statutory consequences for its own unlawful processing, inadequate safeguards or breach of the data-processing agreement.
When the gateway may have an independent role
A gateway may not be merely a processor for every activity. It may determine its own purposes or essential means of processing when it conducts activities such as:
- fraud prevention;
- risk scoring;
- transaction monitoring;
- regulatory reporting;
- identity verification;
- independent analytics;
- legal retention;
- dispute management.
The parties should therefore avoid assigning one role to the gateway for all processing activities without examining the actual data flows. A single agreement may need to distinguish between processing performed on the merchant’s instructions and processing performed for the provider’s own legal or regulatory purposes.
Responsibility for a Data Breach
A data breach does not automatically produce a single liable party. Responsibility may be shared or concurrent, depending on the source of the breach and the duties undertaken by each party.
For example, the gateway may be responsible if the breach results from an unpatched vulnerability, weak access controls, exposed credentials or inadequate monitoring in its environment. The merchant may also bear responsibility if it transmitted excessive data, failed to secure its own systems, used insecure credentials or failed to supervise the processor properly. A developer may be liable where insecure code or poor deployment practices caused the exposure.
The Personal Data Protection Center may assess the conduct of each party according to its legal role, actual control and failure to comply with applicable obligations. A contractual indemnity may allocate the economic cost between the parties, but it does not necessarily prevent regulatory action against a party that independently violated the law.
Decree No. 816 of 2025 and Operational Compliance
The parties should review the requirements applicable to them under Decree No. 816 of 2025 and the implementing framework associated with Egypt’s data-protection regime. The precise obligations may depend on the entity’s role, licensing position, processing activities and the nature of the data involved.
A compliant agreement should address, where applicable:
- governance and accountability;
- technical and organizational security measures;
- processing records;
- data retention and deletion;
- processor and subcontractor controls;
- breach detection and notification;
- regulatory cooperation;
- audits and inspections;
- cross-border data transfers;
- data-subject rights;
- business continuity;
- incident-response procedures.
The contract should establish a clear internal notification deadline. The gateway should be required to notify the merchant without undue delay after becoming aware of a suspected or confirmed breach, even where the investigation is still continuing.
The breach procedure should also require preservation of logs, containment of the incident, forensic cooperation, identification of affected data, remediation, regulatory support and documented corrective action.
Drafting the Payment Gateway Agreement
A professionally drafted payment gateway agreement should not depend on a single general liability clause. It should allocate responsibility across the entire payment and data lifecycle.
The agreement should define the services precisely and distinguish between transaction initiation, routing, authorization, capture, settlement, refunds, reversals, chargebacks and reconciliation.
It should also contain measurable service levels, including availability, response time, incident escalation, planned maintenance, recovery time and recovery-point objectives.
The data-protection provisions should identify the parties’ roles for each processing activity. They should address instructions, confidentiality, security, subcontractors, retention, deletion, audits, breach notification and assistance with data-subject and regulatory requests.
The agreement should also specify which losses are recoverable, how liability caps operate and whether separate treatment applies to fraud, serious negligence, loss of funds, unauthorized transactions, confidentiality breaches and personal-data incidents.
Finally, the agreement should address termination and transition. A merchant should be able to retrieve transaction records, reconcile outstanding payments, process refunds and migrate to another provider without losing access to information necessary for legal, financial or customer-service purposes.
Practical Recommendations
Merchants should verify the provider’s regulatory and operational status before signing. They should determine whether the provider is a technical aggregator, payment facilitator, bank, payment-service provider or merchant-of-record entity.
Developers should define precisely whether they are responsible for code, hosting, maintenance, integration, credentials or security operations. They should not assume responsibility for banking or settlement functions that they do not control.
Gateways and facilitators should ensure that their contractual description reflects their actual activities. They should maintain reliable audit trails, transaction records, incident-response procedures and controls over subcontractors.
All parties should document the data flow from the customer’s device to the merchant, gateway, payment provider and bank. The data map should identify what information is collected, where it is stored, who can access it and how long it is retained.
Conclusion
Under Egyptian law, responsibility for a failed payment or data breach cannot be determined solely by asking whether the middle layer is called a gateway, aggregator or facilitator. The decisive issue is the function performed and the obligation undertaken.
A technical aggregator will generally be responsible for failures within its own infrastructure and processing services. A payment facilitator may carry broader responsibility because it may contract with merchants, manage transaction risk and facilitate settlement. The merchant remains responsible for its commercial relationship, lawful processing purposes and secure integration. A developer may be liable where its code, hosting or security services caused the failure.
For data protection purposes, the merchant is often the controller, while the gateway may be a processor. However, the gateway may assume an independent role for certain processing activities, particularly fraud prevention, regulatory compliance and risk management. Each party should therefore be assessed according to its actual conduct and control.
The most effective payment gateway agreement is not simply one that declares who is liable. It is one that clearly maps the payment and data lifecycle, assigns each obligation to the party capable of performing it, establishes evidence and escalation procedures, and provides enforceable remedies when the system fails.
Elkobtan MFA Leg/Tech & Data Protection Law Firm
*Legal insight at the intersection of financial technology, contracts, cybersecurity and data protection.
www.elkobtan-ip.com
