Airtel Africa's official developer portal exposes Airtel Money Open APIs for merchants and e-commerce businesses, including collection and disbursement capabilities. Applications are managed by country operating company, so the first design rule is to treat Airtel Money as a country-scoped capability rather than one global switch.
What the public Airtel sources confirm
- The Airtel Africa Developer Portal supports merchant integrations with Airtel Money Open APIs.
- Airtel states that the APIs can be used to collect payments from Airtel Money customers and disburse to Airtel Money wallets.
- The portal requires developers to select the operating country before proceeding, and applications are managed per Op-Co.
The public pages do not expose every endpoint field or callback schema without portal access. Do not invent those details in your billing code or documentation; verify the exact contract in the merchant's current Airtel developer account.
Start with the invoice, not the Airtel transaction
A recurring invoice should already exist before the customer chooses Airtel Money. The payment attempt then stores the wallet, country, provider route, provider reference and raw result.
If the attempt fails, the invoice remains due. If it succeeds, the invoice closes once.
Scope merchant capability by country
A useful configuration includes merchant account, country, currency, wallet and enabled API product.
That matters because Airtel Money operates across multiple African markets and merchant onboarding, currency and provider routes can differ by operating company.
Treat final payment state as asynchronous unless the exact API contract proves otherwise
The billing layer should be able to represent Initiated, Awaiting customer, Pending, Succeeded, Failed, Expired and Unknown even if the raw Airtel statuses use different vocabulary.
Keep the raw provider status and timestamps for support and reconciliation.
Do not hard-code retry around missing callbacks
If the expected result is missing, use the status-enquiry or verification mechanism exposed by the merchant's Airtel route before creating another attempt.
A missing callback is an evidence problem, not automatically a failed payment.
Make callback processing replay-safe
- Authenticate or validate the event using the method Airtel or the PSP specifies.
- Deduplicate repeated delivery.
- Load the payment attempt and current invoice state.
- Preserve the raw result.
- Apply only valid forward state transitions.
- Treat a second successful payment against an already-paid invoice as an exception.
Keep wallet and provider route separate
The customer-facing wallet may be Airtel Money while the merchant integrates directly with Airtel or through a PSP. Store both concepts.
That makes reconciliation, provider migration and regional expansion easier.
Sources
Airtel Africa Developer Portal: https://developers.airtel.africa/
Airtel Africa announcement on Open APIs for collection and disbursement: https://www.airtel.africa/assets/pdf/press-release/Airtel-Africa-Developer-Portal_ENGLISH.pdf
Airtel Money overview: https://www.airtel.africa/mobile-money
