
Education and Health are two sectors where these institutions can simplify the way they accept payments from clients.
Institutions such as school, colleges, universities, hospitals and clinics can set up online payment portal where clients can make one-off payments online or set up recurring payment which can be deducted from their mobile money account automatically on a regular basis.
The Recurring Payments Mobile Money APIs allow service providers to setup electronic payment mandates for mobile money customers and initiate payments against payment mandates.
For further reading, please refer to the following:
All documentation can be found on the GSMA Mobile Money API Developer Portal.
| Audience | Usage | Role |
|---|---|---|
| Mobile Money Providers | - To understand how to implement the Mobile Money API to receive recurring payment requests from service providers. - To understand how to implement the Mobile Money API to create recurring payment requests initiated by customers using a channel (e.g. app) provided by the mobile money provider. | API Provider |
| Service Providers | To understand how to implement the Mobile Money API to request recurring payment mandates against mobile money accounts. | API Consumer |
This diagram illustrates the setting-up of a recurring payment via a debit mandate. The service provider initiates the request which is authorised by the account holding customer. In this diagram, an asynchronous flow is used with a final callback.
In this diagram, the account holder declines to provide authorisation to setup the recurring payment. The service provider receives a callback containing an error object detailing the reason for failure.
In this diagram, the service provider initiates a payment request to the FSP to debit the account-holders account as per the debit mandate.
In this diagram, the service provider initiates a payment request to the FSP to debit the account-holders account as per the debit mandate. The FSP is unable to process the payment and returns a callback containing the error object.
In this example, an asynchronous payment flow is used with the polling method. The client polls against the request state object to determine the outcome of the payment request.
Service Providers can issue a refund to payers. In this diagram, the refund is not linked to the original transaction and hence the /transactions API is used. Where a refund needs to be linked to the original transaction, the /reversals API must be used to perform the refund.
In some failure scenarios, a service provider may need to reverse a transaction. This diagram illustrates a reversal with the final result communicated via the callback.
This diagram illustrates how the MM API can be used by a mobile money provider to allow a payer to setup a recurring payment using a channel provided by the provider, for example, a mobile money app.
This diagram illustrates use of a cursor mechanism to retrieve all payments for a service provider via multiple requests.
The Heartbeat API is used for monitoring purposes and establishes whether the FSP is in a state that enables a client to submit a request for processing.
This API can be used by the service provider to retrieve a link to the final representation of the resource for which it attempted to create. Use this API when a callback is not received from the FSP.
As a platform that offers educational content through mobile money, we appreciate the importance of being integrated with MMPs using APIs. It enables our consumers to easily purchase desired content. As we continue to expand our services and customer base, we hope to have access to a Standard API in the future, which will enable us to reach a wider base of users in remote areas.
Eneza Education
Education Service Provider