In this digital age, we are constantly seeing innovative solutions to revolutionize the way we interact with money.

African network provider MTN’s Mobile Money platform is at the forefront of this evolution. It allows users to perform various financial transactions using their mobile devices, such as sending and receiving money, paying bills, purchasing airtime and data, and saving or borrowing money.

THE MTN MoMo API allows developers to seamlessly integrate MTN Mobile Money’s many features into applications and systems. From transaction facilitation to enable digital commerceits potential is immense.

Even so, the MTN MoMo API It has its own technical challenges, including security issues related to data breaches and issues with downtime and functionality. Navigating its complexities can be daunting, and there are areas where clarity and functionality could be improved. As a technologist, you can help solve MTN MoMo API issues by contributing to open source, such as projects on GitHub.

In this tutorial we will enhance the MTN MoMo Open API using Postman as our primary API platform, although you can use any client platform you feel comfortable with. In this guide I will conduct tests in the sandbox environment. If you decide to go live, be prepared for a simple and self-explanatory process.

Head to the MTN MoMo Developer platform and set up your account to get things started. When you sign up, you will have access to various products within the MoMo API ecosystem, including collections, disbursements, collection widgets, and remittances, designed to tailor functionality to the needs of your application. Subscribing to these products is essential to obtain the primary and secondary keys necessary for the perfect integration of this service.

Visual representation of the subscribed products.

We are focusing on the collection product, which facilitates remote collection of payments from consumers of the service. Although the API endpoints differ, the operational logic remains consistent across all products.

Our first goal is to generate a user and API key for OAuth 2.0 authentication. Every time Ocp-Apim-Subscription-Key is mentioned, it refers to the UUID (Universally Unique Identifier) ​​V4 that we will generate later. Likewise, X-Reference-Id indicates the primary key obtained for the post-product subscription. While it might seem complex, don’t worry. We will go through each step together.

The Collections product offers a range of API endpoints that can improve the functionality of our applications.

List of endpoints exposed by the collections product.

However, we can’t use them yet without creating an API user, which we’ll do later.

Prepare your favorite API platform, like the postmanand access the URL https://sandbox.momodeveloper.mtn.com/v1_0/apiuser to initiate a POST request. Make sure you include the file X-Reference-Id and the Ocp-Apim-Subscription-Key in the request headers. THE X-Reference-Id corresponds to the V4 UUID that you can generate for free UUID generator website. On the contrary, the Ocp-Apim-Subscription-Key represents the primary key acquired after subscribing to the product. Following the documentation, it is essential to include a callback function in the request body to be executed after the request executes successfully. For demonstration purposes we will use a generic callback function. If necessary, you can get your custom callback feature from a free and accessible site callback function generator.

Visual representation of the headers to include in the API user creation request. (Mine are hidden)

After submitting the request, a status code created by resource 201 will confirm that an API user was created. However, you may notice that the response body is missing user information that is essential for subsequent requests. To acquire this critical data, perform a GET request to the URL https://sandbox.momodeveloper.mtn.com/v1_0/apiuser/{X-Reference-Id}, replacing “X-Reference-Id” with the UUID from user creation. Remember to include the Ocp-Apim-Subscription-Key in the headers for authentication.

Visual representation of the response body from the “get user information” request.

Once you’ve created a new user and retrieved their information, it’s time to delve deeper into the collection’s product features. WELL they require an API key and bearer token for each API request to get started. These essential elements act as access passes, allowing the API to recognize the source of the request and grant us access to the necessary resources.

To get started, we’ll generate an API key by making a POST request to the URL https://sandbox.momodeveloper.mtn.com/v1_0/apiuser/{X-Reference-Key}/apikey, replacing “X-Reference-Key” with the UUID. Remember to include your subscription key in the request headers.

Visual representation of the API key received in the response.

Next, we will create a bearer token to authenticate each request to the various endpoints of the collection product. For this step, we’ll approach things a little differently. We will initiate a POST request to the URL https://sandbox.momodeveloper.mtn.com/collection/token/, including the subscription key in the headers. Using basic authentication, we will set the username as X-Reference-Id and the recently generated API key as the password.

Visual representation of the bearer token returned by the POST request.

We can now use the collection product endpoints, specifically the “payment request” endpoint, although with the information provided we can also use all other endpoints. We start by sending a POST request to the URL https://sandbox.momodeveloper.mtn.com/collection/v1_0/requesttopay. This request operates in three distinct states:

1. Approval status: where the consumer provides their PIN, confirming the transaction and marking it as successful.
2. Status pending: where the request awaits approval or rejection by the consumer.
3. State of refusal: where the consumer refuses the request.

In the request headers, next to the standard X-Reference-Id and subscription key, we will introduce the recovered target environment when recovering user information. Additionally, we will update the authorization method for bearer token authentication using the newly acquired bearer token. We will include a JSON object with the specified properties in the request body. Feel free to customize the values ​​as needed.

Visual representation of a successful “request for payment” request.

Before concluding, let’s briefly explain the properties within the JSON object sent as the body of the “payment request” request:

The “amount” indicates the money debited from the consumer’s account, while the “currency” indicates the name of the currency of the transaction. The “External ID” serves as a reference for the transaction, aiding in reconciliation and reporting of transaction history. Inside the nested “payer” object, “partyIdType” can be “MSISDN” for a validated phone number or “EMAIL” for a verified email address. The “partyId” represents the consumer’s phone number. The “payerMessage” field contains the message for the payer’s transaction history, and finally, “payeeNote” includes a note for the payee’s transaction history. Customize these properties as needed for your transactions.

In the dynamic world of digital finance, the MTN MoMo Open API stands out as a game changer for those ready to redefine financial services.

Despite the potential of the MTN Mobile Money platform and its API, we have identified technical barriers that need to be addressed, from complex documentation to improved functionality. It is up to us, the technology community, to advance these improvements and shape the future of FinTech through open source collaboration.

Read Andela’s latest guide to hiring the best FinTech engineers apply technological advances to improve current and create new financial products and services.

Group created with Sketch.

Source