This is a continuing series on using keycode systems to deliver energy to pay-as-you-go solar home systems in off-grid energy markets.
- Why Distributors Use Pay-As-You-Go
- How Mobile Network Operators Utilize Prepaid Scratch Cards
- How Secure Pay-As-You-Go Keycode Systems Operate
- How Pay-As-You-Go Product Activation Works << You’re here
- The Design Approach for Developing Keycode Systems
Last time, we learned that the biggest design difference between existing pay-as-you-go (PAYG) systems like mobile network operators versus pay-as-you-go products is where the validating authority is located. For mobile networks, the validation is performed by a central gatekeeper. For pay-as-you-go products, the validation is distributed and performed by each individual device.
Moving the validation out to the edges introduces some interesting design constraints, especially when taking the actual hardware into consideration.
Image source: Wikimedia Commons
Above, is a phone that is fairly typical in East Africa. Even though it is far less capable than an iPhone, it’s still a modern miracle. Here, we have a nice bright LCD screen capable of displaying lots of colors, text is easily readable, and (low-resolution) photos can even be displayed. Beyond the 12 buttons on the keypad used for alphanumeric entry, there is also a 5-way cursor button and two soft-function keys, which can display context-dependent prompts. Finally, if not most obviously, this device has a radio inside of it that allows it to connect to the rest of the world. In short, this mobile phone, as antiquated as it might seem to some, is basically magical.
And yet, when a user buys a scratch card and types the keycode into this device, even with its full fleet of functional entry keys and beautiful display, all of the authorization and validation logic is in the network data center, running on modern computers and talking to huge databases.
Here, we see a client typing in a keycode generated by Angaza in order to activate his new solar home system. His product happens to be a Sun King Home 60 from Greenlight Planet, one of the off-grid solar market leaders partnering with Angaza to enable pay-as-you-go product sales.
Immediately, we see there are only five buttons on the device. What is less visible is the fact that there is no fancy LCD display either. The only feedback mechanism are some red and green LEDs capable of blinking. There definitely is no radio inside this device; indeed, most of the space inside the casing is occupied by the battery. So, not much to work with. And yet this humble device, optimized for affordability and durability in off-grid markets, can still validate and determine the value of the keycode entered.
Beyond that, there are some additional non-visible requirements being enforced:
- Each keycode should only be allowed to be used once on the device, and only once. If it accepted the same keycode over and over to enable it, then the keycode-based metering would not serve its purpose.
- Each keycode should only be allowed to work on that particular device, and no others. Otherwise, this client could trade keycodes with his friends in order to get more time from the device than he actually paid for.
- Keycodes shouldn’t be required to be entered in a specific order. If he makes both a down payment and a separate installment payment because he has extra money, he shouldn’t be required to enter the down payment keycode first; he should be able to enter the keycodes in any order he pleases.
- It should be possible to make variable payment amounts and receive appropriate keycodes. If he makes a payment of 4 in one week, and then a payment of 8 in two weeks, then the second keycode should be worth twice as much as the first keycode.
The last property allows us to support a variety of pricing models. After all, some solar distributors may think that weekly payments work best for their clientele while other distributors may prefer fortnightly or otherwise.
Finally, in the background, we have the obvious, yet unstated assumption that it should not be possible to brute-force the keycodes, either by typing keycodes manually or even if you hooked up a machine to attack it and shove in keycodes faster than a human could type.
Remember, this device only has five entry keys and only blinky LEDs for user feedback. These physical constraints mean that our keycodes must be strong enough to satisfy all the above requirements, yet we must make it easy to enter a sequence of numbers without any way of displaying the numbers already entered, and without any way to correct mis-typed numbers.
We also need to be able to give both a “successful entry” feedback and an “unsuccessful error” feedback.
That’s a lot going on for a device with less than 4 KiB of RAM. Next time, we’ll see how these requirements and constraints influenced the design process of the standard Angaza keycode system.
In the final installment of this series we’ll discuss the design process utilized to achieve Angaza’s keycode system.
