Imagine you want to start your own solar distribution company, and your plan involves collecting small amounts of money from people every week. This might seem reasonable until you realize how geographically dispersed your customers often are. And even if you solve the money collection problem, you still need to figure out how to apply the payment data to the entire fleet of metered solar devices (because they’ll refuse to turn on otherwise1).
Keep in mind that while some of these devices are small and portable and could presumably be carried to a point of sale for some sort of activation, others, like solar water pumps meant for agricultural irrigation, are heavy and bulky and not easily moved.
One way to solve this problem is with people power: build a large agent network, send them out into your geographic region, and ask them to collect money and activate the solar devices. There are certain advantages to this high-touch approach. Your repayment rates will probably be pretty good because your agents will get to know their clients fairly well and the social pressure of paying someone standing right there is more difficult to ignore compared to, say, a phone call asking for money.
On the other hand, there are also a number of drawbacks to this approach. Training costs for agents can be high, and managing employee turnover can be challenging. Sparse populations require more time and energy spent on travel, increasing the cost of collections. If your agents are collecting cash payments, you need to figure out how to get the money to physically flow safely to your offices.
The good news is that, in many emerging markets, mobile network operators (MNOs) have deployed quite a bit of infrastructure in terms of both technological and human capacity. Their large human-powered operations were created because most of their customers tend to prepay for cellular connectivity in small, affordable amounts.
Sounds familiar, right?
In last chapter, we learned that building a solar distribution company in an emerging market shares many of the same operational challenges that mobile network operators (MNOs) face. Here, we’ll discuss one approach they use to overcome some of their operational challenges. Of course, not all solutions from MNOs can be directly applied to solar distribution, but it’s still worth understanding this prior art to use it as inspiration for PAYG solar technologies.
At the time that these MNOs were building out their operations, their markets were predominantly cash economies. In order to scale their businesses, they needed to make it super convenient for as many people as possible to transact with them as often as possible. The only way to reduce the amount of friction per transaction was to build out a huge point-of-sale network, with a wide geographic reach, operated by humans, and designed to collect cash.
But what do their customers actually receive in exchange for the cash? How do you actually load more airtime or data onto a specific phone? These points of sales are often simple kiosks, meaning there is no computer system to record a transaction or do anything else automatically
One solution might be for the kiosk operator to call into a call center confirming that a transaction has completed successfully, and that the MNO should then load more credit onto the customer’s phone. This approach has the obvious drawback of requiring even more staff for the call center, and the less obvious drawback requiring the operator to figure out how to physically transport the cash from thousands of kiosks back to central headquarters.
It turns out there’s a simpler solution that compensates for the impedance mismatch between a high tech cell phone network and a low tech operational environment, which is to convert virtual electronic “inventory” of airtime and data into actual physical inventory. Now, this inventory can be distributed and sold at wholesale prices to a distribution network of kiosk owners, who apply a markup, and sell it just like any other piece of physical inventory, like chewing gum or bottled water.
Say hello to the humble scratch card.
The concept here is both simple and elegant. Network operators print zillions of these cards, which are then sold at thousands of locations. Each card has a secret code2 that is revealed by scratching off the weird silvery stuff3. The end customer then enters this code into their phone. The backend computer systems receive the code, verify it, and finally add credit to the customer’s account.
The cards are not only durable but, more importantly, enable an extremely low-friction customer purchasing experience. They can be bought for cash, in fairly small granularity4, whenever needed by a customer. There’s no latency introduced at the time of sale, and no waiting around for a computer system or call center operator to add credit to your account. They can be stored and consumed when convenient.
From the MNO’s perspective, scratch cards are a pretty good compromise to achieve widespread market reach if you’re trying to bootstrap an entire infrastructure. They’ve made it easy and affordable for their customers to buy service in discrete chunks. In the process, they created a market where none existed previously. There are drawbacks, such as the overhead of printing and physically distributing the cards. And, of course, the major concern from the MNO perspective is ensuring and protecting the integrity of the codes.
Hopefully we’ve set enough of the broader context around this particular problem space. In our next installment, we’ll be taking a closer look at the keycodes themselves.
In the last chapter, we provided some of the context for why keycodes and scratch cards are a good solution to the impedance mismatch between a high tech product offering and a low tech operational environment.
But what’s in a keycode, really? And are keycodes and scratch cards the same thing?
Fundamentally, a keycode provides a user authorization to system resources, whether it be cell network airtime or, in our case at Angaza, clean solar energy.
Thinking of a keycode as a security token is useful because it allows us to perform the standard “usability versus security” tradeoff analysis when designing a keycode system. Here is where it’s important to understand the operational differences between a mobile network operator and a pay-as-you-go solar distributor.
In a mobile network, the resource to protect is access to the network itself. The network operator wants to grant access to the network to anyone who has paid while denying access to everyone who has not.
Although a special device (e.g., a phone) is required to access the network, the real value is not in the device, but rather in participating in the network.
So, the network operators usually don’t care about securing the phones which are at the edges of their operations. Instead, they care about protecting the central resource — the network — and the practical result is that their keycode systems are designed around the availability of a centralized authorization mechanism.
In fact, while scratch cards are an integral part of the network operators’ keycode systems, it’s important to understand that they’re just a small part of a larger picture.
In the above diagram, the network operator distributes the scratch cards to the points of sale, just like any other sort of physical inventory. The customer buys a scratch card, types the keycode into their phone, the network operator validates it, and finally allows the phone to access the network.
The key aspects here are:
- the keycode is validated centrally, by the network operator, not by the phone
- the scratch card is merely a method of distributing the keycode to the customer
- ownership of the scratch card is proof of purchase
Additionally, what may not be obvious from this diagram is that:
- the input method — the phone — has a radio and is connected to the network
- the customer may only purchase scratch cards on an ad hoc basis
- the codes from any scratch card may be entered on any phone
- each code is unique, and may be used only a single time
In contrast, when designing a metered system for product financing, the goal is to ensure the device’s usage is authorized, else it should be prevented from turning on. The devices may not be able to directly communicate with any central authority. Adding a GSM radio to a device, for example, is cost prohibitive when that device retails for less than $1505. This constraint is one of several that make this problem more difficult.
This constraint implies that the devices themselves must be able to validate the codes, which pushes the authorization mechanisms all the way out to the edges of the system That problem is considerably more difficult to solve, for reasons that will become apparent later.
In this diagram, we are assuming that the user has a mobile phone and access to mobile money. This assumption is often the case in many of our operating territories, but not always6. In any case:
- Notice how the network operator is still involved. When a user wants to make an installment payment for their device using mobile money, the payment goes through the Network Operator, and all of the money being transferred stays inside their mobile money system.
- The Angaza Hub7 receives a notification that a payment was made successfully. This notification is, in other words, a receipt. Again, no money has been transferred out of the mobile money system at this time.
- The receipt is proof of a purchase. The Angaza Hub sends the keycode to the user, usually via an SMS, when that proof is received
- The user physically types the keycode into the solar device. If the keycode is authorized, then the device is enabled.
Again, some non-obvious points about this type of system design:
- The only time that a user needs cell phone coverage is the short period of making a mobile money payment and receiving the keycode SMS. After receiving the SMS, the user is free to travel the “last mile” back to their house, where there is no electrical grid and potentially no cell coverage.
- The solar device is not consistently connected to any sort of network8 at all, and must be able to decide on its own whether a keycode is valid or not.
If you take anything away from this post, it’s the difference between the security mechanism of a mobile network versus pay-as-you-go solar.
- Mobile Network = Centralized Gatekeeper
- Pay-As-You-Go Solar = Distributed, Per Device
As we’ll find out, the distributed nature of validating keycodes for a pay-as-you-go solar device is the dominant factor in the design of the overall keycode system. In our next installment, we’ll finally start exploring the design space.
———–
1 “Not turning on unless payment data is pushed onto the device” is the key idea behind technically enforced pay-as-you-go solar devices and Angaza’s specialty. The specifics of how this works is out of scope for our keycode blog series, but for an overview, please do check us out: http://www.angaza.com
2 Often referred to [interchangeably] as a “keycode”, although as we shall see in a future blog post, there is a big difference between “codes on a scratch card” vs “a fully functional keycode system”. For what it’s worth, Angaza focuses on the latter.
3 It turns out there is a lot of science behind this weird silvery stuff!
4 Scratch cards come in a variety of different face values, to accommodate a wide range of individual consumer cash flows.
5 All prices are quoted in USD PPP.
6 Angaza supports many types of operational work flows, including pure cash, but for clarity, this article focuses on mobile money scenarios.
7 Angaza’s B2B SaaS product for solar distributors.
8 In this specific context, the solar device isn’t connected to a network because it is inexpensive and doesn’t have a GSM radio, so the technical challenge of keycode authorization must be done purely in the device itself, and can’t just ask a server somewhere. However, even more expensive devices with a GSM radio that could communicate directly with a server, could benefit from independent authorization in situations where the GSM connection isn’t currently working. must have some way of independently validating keycodes in order to prevent replay attacks.
Alex Chiang is Senior Software Engineer at Angaza.
Sources:
https://www.angaza.com/2018/11/26/why-distributors-use-pay-as-you-go/
https://www.angaza.com/2019/01/28/mobile-network-operators-prepaid/
https://www.angaza.com/2019/02/25/pay-as-you-go-keycode/