Security Overview

We protect the keys that connect your systems to the gateway and limit who can reach them.

Inside Payment Gateway Africa, access depends on a person's role, and multi-factor authentication is part of signing in to internal systems.

We keep documented plans for continuing operations and recovering from disruption, and we follow a defined process when an incident occurs.

Your servers, your staff accounts and the way you store your credentials remain your responsibility. The split is set out in the table further down this page.

Payment Gateway Africa is a payment gateway. It handles pay-ins, payouts where available for the method and project, and merchant settlement. Merchants connect through a Hosted Payment Page or through a direct H2H API. This overview applies to both connection paths and to all seven markets we serve: Kenya, Egypt, Ethiopia, Senegal, Tunisia, Mali and Guinea.

The page covers four areas: how we protect keys, how we control internal access, how we plan for continuity and recovery, and how we handle incidents. It does not describe every internal procedure, and it is not a contract. Your merchant agreement and onboarding documents set out the binding terms.

Merchant verification and anti-money-laundering checks are a separate subject. They are covered in our AML and KYB requirements for merchants.

Every merchant project uses keys. These keys authenticate requests from your backend to the gateway. Anyone who holds a valid key can act in the name of a project, so we treat keys as sensitive assets.

On our side, access to key material is limited to the roles that need it to run and support the service. We do not ask merchants to send keys by email or through chat. If you suspect a key has been exposed, contact us straight away.

Test projects and live projects use separate credentials. This keeps experiments in a test environment away from real money movement. The testing approach is described in the testing guide for developers.

Keys only stay safe if both sides handle them carefully. Section 6 lists the practices we expect from merchants.

Payment Gateway Africa staff do not all have the same access. Permissions are tied to defined roles. A person working in merchant support does not automatically get the rights of someone who configures projects, and the reverse also holds. Access is granted for a job function, not for convenience.

Signing in to internal systems requires multi-factor authentication. This adds a layer of protection beyond passwords.

We recommend the same approach inside your own organisation. Give each colleague only the access their work requires, and turn on multi-factor sign-in wherever your tools support it.

Payment operations need to continue through disruption. Payment Gateway Africa keeps business continuity and recovery plans. These plans describe how we respond to disruption and restore normal operation.

We do not publish the technical parameters of these plans, such as recovery targets or the architecture behind them. Making that detail public would give little value to merchants and could be useful to someone trying to cause harm. Merchants with a specific due-diligence need can raise it during onboarding.

You can also plan for disruption on your side. Design your checkout so that a delayed status does not leave an order stuck. Reconcile your records against reports. Do not treat a single missed notification as a failed payment. The postback and webhook documentation explains how to handle repeated or missing notifications.

An incident is any event that affects, or could affect, the gateway's operations or the integrity of a merchant's project. Payment Gateway Africa follows a defined process for these events. The process covers identifying the problem, containing it, restoring normal service and reviewing what happened.

The Payment Gateway Africa service status page explains how we communicate about incidents and which channels to use. If payments behave unexpectedly, contact our team with the operation details listed below.

If you notice something unusual, report it to us. Examples include activity on your project that you did not start, or a notification you cannot match to any order. Include the project ID, the operation identifiers, the approximate time and what you saw. Do not include keys or passwords in your report.

If an incident starts on the merchant side, such as a compromised server or staff account, tell us quickly. We can then help limit the impact on your project.

Security in a gateway integration is shared. The table below shows where each duty sits.

Integration keys: Payment Gateway Africa limits internal access to key material. You store keys only on your backend, keep them out of code repositories and client-side code, and ask for a replacement if you suspect exposure.

Access to systems: Payment Gateway Africa assigns internal access by role and requires multi-factor authentication. You manage your own staff accounts, remove access when people leave, and protect your accounts with multi-factor sign-in.

Infrastructure: Payment Gateway Africa runs the gateway and its continuity and recovery planning. You run, update and secure your own servers, hosting and checkout pages.

Status handling: Payment Gateway Africa sends postbacks and webhooks to your endpoint. You check that each notification is genuine before acting on it and build your handler to deal with repeated deliveries.

Incidents: Payment Gateway Africa follows its incident response process and communicates through the channels described on the status page. You report suspicious activity quickly and include the operation details we need to investigate.

Status notifications go to the merchant only. Payment Gateway Africa does not run a separate notification service for your customers, so any messages to buyers about their orders come from your own systems.

Keep keys on the server. Hosted Payment Page and H2H API integrations both need a backend, and keys belong there. They should never appear in a browser, a mobile app bundle or a public repository.

Check every notification before you act on it. A request that only looks like a postback must not mark an order as paid. Use the checks described in the developer documentation, and confirm the result from your server when in doubt.

Keep pay-ins, payouts and settlement separate in your own records. They are different flows. Mixing them makes reconciliation harder and hides problems.

Review who on your team can reach the merchant dashboard, your servers and your credentials. Remove access that is no longer needed.

Use the test project for development work. Move to live credentials only when your handler behaves correctly in every scenario you rely on.

This overview intentionally leaves out internal architecture and recovery parameters. Leaving something off this page does not make any statement about whether it exists. It reflects our choice to describe only what we have confirmed and can explain responsibly in public.

If your procurement or compliance team needs more information as part of a commercial review, raise it when you apply to start onboarding. We will tell you what can be shared and in what form.

For questions about this security overview, or to report a suspected issue with your project, contact the Payment Gateway Africa team and choose the request type that best matches your question.

We may update this page as our controls or services change. The date at the top shows the latest revision.