TOOLBOX: USSD & OTHER PROTOCOLS

Key Takeaways

* Not everyone has a smartphone or an internet enabled device
* We exploit USSD, a data channel that every mobile phone uses
* Consumers are familiar with using USSD – all prepaid products use it
* We figured out how to make almost any payment source work on USSD

* We also support other formats, see the table at the bottom of this page

USSD?

We’ll start right at the beginning.

What Is USSD?

"USSD" refers to Unstructured Supplementary Service Data and is sometimes referred to as "Short Codes". It is a protocol used by Mobile Network Operators to communicate with the mobile handset.

USSD is an interactive, menu-based technology, supported on almost all mobile phones.  Some examples of service usage are airtime top-ups, “please call me” services, balance checking and mini statements delivery. USSD short code format is defined by the * and # signs at the beginning and the end of the series of digits.

What is the difference between USSD and SMS?

USSD is a menu-based service which runs as a real-time open session between the application and the end-user. While SMS is a store and forward technology, USSD texts and interactions are not stored on the mobile phone. SMS content remains stored in the mobile phone memory. Additionally, USSD can have up to 182 characters, while SMS is limited to 160 characters.

What kinds of USSD short codes are there?

There are three types of USSD short codes available. The standard rate USSD short code is charged the standard fee for the USSD menu usage by the end-user. Reverse-billed short codes are free for the end-user. Premium rate USSD short codes are charging the end user a premium price for short code triggering. Generally, USSD short codes are either reverse-billed or standard rate.

USSD Payments

Online payments from mobile phones without an Internet connection!

This is a mobile service that allows merchants to receive online payments from older and non-smartphones which do not have an Internet connection. It does not interfere with existing infrastructure, payment contracts nor settlement cycles, it simply adds onto and compliments the business.

At its core it exploits USSD, a data channel supported by all mobile phone types. It leverages familiar behaviour, consumers in emerging markets already use USSD extensively (prepaid airtime, prepaid electricity). Atomicat has developed technology to allow us to securely render payment sources designed for a different data class into a mode compatible with USSD.

This solution is complementary, it adds to the business and does not replace existing systems. Equally, settlements from payment sources are left unchanged. We require however to evaluate the APIs of the payment sources for compatibility to our own technology, there are wide array of payment technologies available on widely differing standards.

USSD In Africa

USSD is essential to reach the majority of mobile phones in Africa.

It is used extensively by consumers in Algeria, Angola, Benin, Botswana, Burkina Faso, Burundi, Cameroon, Cape Verde, Central African Republic, Chad, Comoros, Congo, Cote d Ivoire (Ivory Coast), Djibouti, Democratic Republic of Congo, Egypt, Equatorial Guinea, Eritrea, Ethiopia, Gabon, Gambia, Ghana, Guinea, Guinea Bissau, Kenya, Lesotho, Liberia, Libya, Madagascar, Malawi, Mali, Mauritania, Mauritius, Morocco, Mozambique, Namibia, Niger, Nigeria, Rwanda, Sao Tome and Principe, Senegal, Seychelles, Sierra Leone, Somalia, South Africa, South Sudan, Sudan, Swaziland, Tanzania, Togo, Tunisia, Uganda, Western Sahara, Zambia and Zimbabwe.

SECURITY

There are four moving parts to security relevant to our USSD payments technology.

1. USSD - the mobile networks use technologies like Entersekt to provide a security layer on the USSD data channel. This is not for our benefit (though we benefit from it), it is to secure their pre-paid airtime transaction business which requires codes and PINs to be securely transmitted over the USSD channel. The MNO has to secure the channel as a whole, thus providing a secure starting layer.

2. PCI-DSS Compliance - the reason we make sure our services and servers are PCI-DSS compliant is that it provides a measurable standard and practises for security on our servers. A key part of that is that we use Amazon's compliant server services, meaning the cloud hosting we use forces a secure compliancy.

3. Encryption - our technology inside the secure cloud hosting shell uses deep, cell based encryption. This is very hard to deploy while keeping a system highly available for high load requirements and took us a few years to perfect. This means in English a hacker cannot hack the system all at once, every individual cell of data requires the same intense effort to open up. They would have to successfully hack millions of individual cells each with their own, unique secure keys to access the platform inside the secure cloud hosting.

The reason we encrypt additionally is because not all payment sources are equal. To our view the new kinds of mobile money do not have the depth, breadth and experience in transaction security as more traditional methods like credit cards do. This view has been disputed by some of the newer payment sources who claim adequacy, but we prefer to err on the side of caution.

4. Payment Sources - most payment sources run their own fraud and suspicious transaction detection systems. So a malicious actor gets through the USSD, the PCI-DSS compliant hosting, cracks open the relevant transaction information made up of smaller 128-bit encrypted cells, then submits the transaction into the payment source where the industry standard security systems kick in as they do for any transaction submitted if you pay online or at a POS point.

Payment Sources

Payment sources use Application Programming Interfaces (APIs) which in very general terms are a set of clearly defined methods of communication between various software components. To make a particular payment source available to online consumers, merchants integrate the payment source API into their website, specifically the shopping cart.

There are a massive variety of APIs available, even with what would be assumed is standardised or widely distributed payment source types.

In order to use USSD, we need to evaluate the APIs of the various payment sources that the merchant wishes to use (new or existing) on the USSD payment channel.

The evaluation is necessary as some older payment source and more exotic technologies are simply not compatible with USSD.

We integrate the compliant payment source APIs into our integration management systems.

We monitor the APIs ongoing to ensure the integration remains serviceable.

The merchant keeps their own merchant account with the payment sources, together with relevant commercials, and the payment source provider settles the merchant directly.

The merchant provides their own credential to unlock the payment source.

We provide detailed transaction reports which the merchant can integrate with their OEM/Backend system or use for their financial management.

Single Session Experiences

Where the merchant already has an USSD game or platform, we able to integrate USSD payments into the session flow keeping the user experience uninterrupted.

​

Supported Protocols