Testing Your Integration Before Production

Testing runs in its own project. That project has its own identifier and its own key. Neither one is shared with your production project.

Keeping test and live credentials apart means a test request cannot create a real charge. It also means a live operation cannot appear in your test logs.

Store the test pair the same way you will store the production pair: in server-side configuration or a secrets store. Never put either pair in browser code or a mobile app bundle.

Both connection paths use this test project: the Hosted Payment Page and the H2H API. If you have not chosen a path yet, the integration guide for hosted and API connections compares them. Request structure is covered in the API overview.

Full API reference and credentials are provided after merchant onboarding.

In the test project, a person on the support team sends callback statuses manually. You create a test operation, then ask support to send a specific status for it. Support delivers that status to your callback endpoint.

This gives you control over the order of events. You can ask for a success on one operation and a failure on another. You can also ask for a second delivery of a status you have already received. Then you can watch how your handler reacts each time.

When you contact support, give them:

The test operation reference, so they can find the right operation.

The status you want delivered.

The callback URL you expect it to reach. This helps support confirm that the endpoint registered on the test project matches yours.

Because statuses are sent by hand, plan your test sessions ahead. Group the scenarios you want into one request rather than asking for them one at a time.

How postbacks are structured, verified and acknowledged is explained in the webhooks and postbacks guide. Read it before you start, so your endpoint is ready when the first test status arrives.

A test pass that only covers successful payments is not enough. The cases below often cause trouble in production, so add them to your plan.

Successful pay-in. Your order should move to paid exactly once. Fulfilment should start only after the status is received on your server.

Failed or declined pay-in. The order should stay unpaid. The customer should see a clear way to try again, and no goods or services should be released.

Repeated delivery of the same status. Ask support to send a status you have already processed. Your handler should recognise the operation, reply as it did the first time, and not ship twice, credit twice or send a second confirmation email. Use the operation reference as your idempotency key.

Customer closes the browser. Start a payment, then close the tab before returning to your site. The redirect back to your pages never happens. Your system must still reach the correct final state from the callback alone. Never treat the customer's return to your site as proof of payment.

Status arriving before or after the redirect. Your order page should show a pending state until the server has a confirmed result. It should then update without the customer having to pay again.

Payouts, where available for the method and project. If your project includes payouts, test them as a separate flow with their own statuses and records. Never handle them as a variant of pay-ins.

Keep settlement out of these tests. Pay-ins, payouts and merchant settlements are three distinct flows.

The sketch below shows the logic your callback handler should follow. It is not the real API. Field names are neutral placeholders, and the exact format comes with your onboarding materials.

POST {your registered callback path} 1. Read the body: operation_reference, status, amount, currency 2. Verify authenticity as described in the webhooks guide 3. Look up the order by operation_reference 4. If this status was already applied: reply success, do nothing else 5. Otherwise: record the status, update the order, trigger fulfilment if final 6. Reply success so the delivery is treated as accepted

Steps 3 and 4 are what make repeated deliveries harmless. Step 5 should run inside a transaction, or behind a lock on the order. That way two deliveries arriving close together cannot both pass the check.

Log the raw callback, the result of your verification and the decision your code made. When you compare notes with support during testing, these logs let you show exactly what your server received and did.

Your test plan should follow the countries and methods you intend to launch with. Customers in Kenya pay with M-Pesa in KES. In Egypt they use mobile wallets linked to a phone number, in EGP. In Ethiopia the options are CBE Birr, M-Pesa and local transfers, in ETB.

In Senegal, customers use Wave and Orange Money, in XOF. Mali adds Moov Money alongside Wave and Orange Money, also in XOF. In Guinea, customers pay with Orange Money in GNF. In Tunisia, they pay with D17 and Flouci, in TND.

Confirm that your backend stores the correct currency for each operation. Your interface should label the method the way customers recognise it. A summary of each market is on the countries we cover page. Method behaviour is described in the mobile money payment gateway overview.

Merchants already on Payment Gateway Africa can activate additional supported payment methods without any connection surcharge. However many methods you enable, your connection price stays the same. Whenever you add a method later, test it with the same scenarios before making it available to customers.

Going live means replacing both the test identifier and the test key with the production pair. Replacing only one of them leaves your system half-configured, and requests will not behave as expected.

Before you switch, work through this list:

Every scenario above has been run, and the results match what your code should do.

Repeated deliveries and the closed-browser case both end in the correct order state.

Production credentials are stored server-side and never committed to source control.

The production callback URL is public, uses your live domain and accepts the same logic you tested.

Test-only shortcuts, debug flags and mock responses are removed from the production build.

Monitoring is in place so your team notices if callbacks stop arriving.

Merchant onboarding, including KYB checks, comes before production access. The AML and KYC overview explains what is reviewed. The security page describes how responsibilities are split between you and the gateway.

Once you go live, Payment Gateway Africa sends out payouts to merchants on the day they are processed (T+0). This refers only to when funds are dispatched. The time they appear in your account is determined by your bank.

If your test project is not set up yet, the first step is an application. The get started page walks through the path from application to KYB, then to a test project and go-live. To learn how pricing for pay-ins, payouts and settlement is quoted, see how pricing is quoted.

To return to the starting point of the documentation, open the developer docs hub.