Single-stage vs multi-stage payments

In the previous topic, we discussed the mobile money ecosystem and the role of the core wallet platform at the heart of it. One of the primary roles of the platform is to ensure the integrity of the wallet, and ensure that there is no money leakage or fraudulently created money in the system.

The core wallet platform is responsible for performing debits and credits, thereby keeping the system balanced.

The are are two main types of payments that we have come across on the core wallet platform – single-stage payments and multi-stage payments. Some platforms only support one type or the other, however, some support both types depending on the use case. The payment type that is used is usually determined by a setting on the core wallet platform itself.

So what is the difference between these types of payments? We’ll start by discussing the concept of a single-stage payment.

Let’s consider an example where John wants to buy a KFC meal for $5. He will initiate the transaction using the channel he prefers, such as USSD. An instruction is then sent to the core wallet platform to debit $5 from John’s account, and credit $5 to KFC’s account. The core wallet platform moves the funds, and the payment gateway then sends a notification to KFC’s backend system to confirm their account has been credited. KFC can now give John his KFC meal.

As you can see, in a single-stage payment, money is immediately debited from the customer’s account and credited to the third-party’s business account. The third-party platform is then notified that the money is reflecting in their account.

But, as we all know, things can, and do, go wrong.

To continue our example, let’s say that when the payment gateway tries to notify KFC’s platform of the payment, something goes wrong and the notification is not acknowledged. In this case, the money has already moved from John’s account to KFC’s account, but KFC is unaware of the payment.

This results in various issues. Firstly, John has a very poor user experience as he has paid for his KFC meal, but hasn’t received it because KFC hasn’t received the notification.

Secondly, there needs to be a reconciliation between the mobile money operator and KFC. This involves a manual investigation to determine what went wrong.

As you can imagine, with high volumes of transactions and multiple third-parties, this becomes difficult and time-consuming. All the while, John has to wait for the mobile money operator to complete the reconciliation and hopefully issue a reversal so he can get his money back.

If the reconciliation confirms that KFC didn’t get the notification, and have not provided John with his burger, a reversal will be issued for the funds to be transferred from KFC’s account back to John’s account. This can sometimes take a few days!

In some cases this can lead to fraud as the money that has been transferred to the business account can be withdrawn before the reversal is completed. In this case, if there are insufficient funds in the business account the reversal cannot be made and the business will retain the money despite not providing the service.

Although a reversal could be thought of as a business-to-consumer (B2C) payment, it’s actually a different type of transaction because it is performed using the original transaction number of the transaction that needs to be reversed. Rather than initiating a new payment to John, an instruction is sent to the core wallet platform to perform a reversal using the original unique transaction number of the transaction you want to reverse. The core wallet platform finds the transaction id, checks the amount to be reversed, and moves the funds back to John’s account. Because no new transaction is initiated, no fee is charged for the transaction, which also differentiates it from a traditional B2C payment.

As you can see, single-stage payments are vulnerable to user experience and security issues. So mobile money operators decided to solve these problems using what we call multi-stage payments.

So, what is a multi-stage payment and how does it differ from a single-stage payment?

A multi-stage payment is broken into two stages. The first stage is to reserve a certain amount of funds for a specific business short code, and the second stage is to commit the reserved funds to that business’ account.

Let’s take a look at our example of John buying a KFC meal, where the setting on the core wallet platform is set to multi-stage payment.

As before, John initiates the payment for his KFC meal. Now, however, an instruction is sent to the core wallet platform to reserve $5 on John’s account for KFC. It is important to understand that the money is not debited from John’s account. Instead, it is “authorised”, which means the amount is temporarily held for KFC and John cannot use that money for something else.

In the backend, KFC is notified that $5 has been reserved for them on John’s account, which will be paid to their account when they provide John with the meal he has ordered.

When KFC confirms they have received the notification of the reserved funds, the payment gateway sends an instruction to the core wallet platform to commit the funds. When the funds are committed, the amount is debited from John’s account and credited to KFC’s account.

So now what happens if something goes wrong? Let’s assume the funds are reserved on John’s account but KFC doesn’t acknowledge the notification of the reservation. In this case, instead of committing the funds, a rollback can be performed, which releases the hold on the reserved money in John’s account. The user experience is much better for John as his balance never changes and he has access to the reserved funds as soon as they are released.

The decision to either commit or rollback the reserved funds is based on the feedback received from the third-party system. When the payment gateway sends KFC the notification of the reserved funds, they can send back a confirmation with various responses. For example, they could accept or decline.

In other cases, the payment gateway could receive a response from the third-party system that it doesn’t cater for and doesn’t have the business logic to handle. There could also be a situation where no response is received and there is a timeout between the payment gateway and the third-party system.

These transactions go into what we call an “ambiguous state” where there is a hold on the customer’s money, but the payment gateway is unsure if it must commit or rollback the funds based on the configured business logic.

Ambiguous transactions are not only frustrating for customer’s, but can also present a challenge for Mobile Network Operators as authorised transactions have an automated expiry date. This means that it is possible that John could receive and eat his KFC meal, even though the payment gateway is unable to notify the core wallet platform to commit the funds. If the commit doesn’t go through, an auto uncommit will occur after the specified number of days and John will have access to the previously reserved funds once again. In this case, the Mobile Network Operator will lose that money and either have to pay KFC for John’s meal, or contact John to make a manual payment for the specified amount.

The number of ambiguous transactions can rise rapidly, and the amounts involved can add up quickly. Therefore, Mobile Network Operators monitor ambiguous transactions by keeping an eye on how many transactions are in an authorised state on the mobile money platform. Ideally, they like to keep this number as low as possible as a rising number indicates a problem. There are some processes and tools that help in handling this challenge, which we will cover in another lesson.

Summary

In this topic, we explained the concept of a single-stage payment, and discussed its shortcomings in terms of user experience and security. We then introduced the concept of a multi-stage payment and discussed how it solves many of the issues encountered with single-stage payments. You should now have a good understanding of these types of payments, as well as the concept of ambiguous transactions.

You have now come to the end of the What is Mobile Money lesson. In the next lesson you will be introduced to our iNSight Payment Gateway.