OpenPAYGO Pass - Cheap and user friendly activation and data feedback in areas with poor connectivity

What is OpenPAYGO Pass?

OpenPAYGO Pass allows clients in areas with no mobile money and/or very poor connectivity to get a seamless PAYGO service through an RFID badge mechanism that will simplify the activation process and provide free data feedback in places where cash collection is required for PAYGO. The data feedback can open access to result-based financing opportunities to clients that would otherwise be excluded from it.


There are countries where there are still no mobile money providers and clients of PAYGO products go to kiosks to pay, give the serial number of their devices and get a token on a piece of paper that needs to be written by hand. This is prone to error, time consuming, risky and does not allow usage metrics to be obtained, which blocks clients from receiving some subsidies and manufacturers from improving their devices with data.

This process could be improved and allow getting usage data by using an RFID card that is tapped on the device before going to the kiosk to pay and tapped at the kiosk after paying to exchange the usage data and load the PAYGO activation. This general concept is used by utilities in some country (without the data feedback part) and is very cost effective while greatly improving the client journey while getting free data feedback.


In areas where there is no mobile money or no phone connection, clients currently have a very cumbersome process to activate their devices, where the clients must:

  1. Note down the serial number of their devices correctly (potential for human error)
  2. Go to the nearest agent/kiosk available to pay
  3. Give the agent the serial number of the device and the cash, the agent will then need to enter them into their app or via SMS (potential for human error) to register the cash collection
  4. The agent receives the token that he dictates to the client that needs to note it down properly (potential for human error)
  5. The client goes back home and enter the token into the device, if there was a mistake he needs to go back

This problem is cumbersome, time consuming and extremely prone to error. Moreover, this system does not allow for data feedback, which is a requirement for many result-based financing (RBF) programs that subsidise solar kits for end-clients, despite the relatively high typical cost of data feedback.


The solution relies on very low cost RFID readers (<1$) integrated in PAYGO devices and RFID tags (0.01$ - 0.5$ depending on style) to be given to clients, allowing a greatly improved client journey and free data feedback.

This general mechanism (without the data feedback part) is used by some utilities (such as in Ghana) and is a proven and very cost effective way to extend the benefits of PAYGO products to areas without mobile money by having a much simpler and less error-prone client journey, as well as opening the way to get result based financing for those clients that are usually excluded due to connectivity issues.

The improved client journey would be as follows:

  1. The client goes to the nearest agent/kiosk available to pay
  2. They give the agent their tag (e.g. keychain), the agent taps it on his app when he collects the cash.
  3. The client goes back home and taps their tag onto their device


We will develop the project the same way we did OpenPAYGO Token, by starting with discussions with manufacturers and distributors potentially interested by the solution and gathering feedback to create a thorough list of requirements.

We will then go on to engineer the system, prototype it and do some field or field-like testing to validate the solution.

Finally, we will create an easy to use development kit with a few Arduino-based examples to make it very easy for manufacturers to integrate the technology in their products adding only ~1$ to their COGS.


The whole innovation will be open source, the deliverables will be:

  • Website page presenting the project and the concept and use cases

  • General documentation introducing the project and use cases in more details and guiding interested people on where to start depending on their situation

  • SDK for the technology

  • At least one concrete functional examples using the technology made with Arduino (e.g. an example PAYGO lamp controller with the fully integrated system with OpenPAYGO Token+Pass with usage data of the hours of use)

  • Technical documentation for the SDK and the examples

  • Open source mobile app able to read/write a smartcard and connect to any server supporting OpenPAYGO Metrics to upload the usage data and get back the activation token

  • Everything published on Github


If anybody would like to discuss the project further please let us know, we are open to any feedback. If you would like to be part of the initial pilot for this project please let us know as well.

1 Like

Hello Ben and Claudio,
I think that´s a great idea, we see also that people struggle to enter tokens sometimes. The unser interface of simpler systems provides often not the very best feedback. The simplify the usage this way is a promising approach to overcome this issue.

Thank you Ben and team,

This sounds like a great way to potentially address a host of different connectivity and code-handling issues we see in the field. Code entry issues drive a surprising number of service calls and agent visits when some kind of human error is typically involved. For BioLite we are very interested in improving overall fleet management capabilities for our distributors, and it will be great if Solaris continues to build the tools that could allow usage and performance data tracking across devices; whether they be on traditional mobile money platforms, cellular connected themselves, or offline cash-paid with this new RFID approach. Keep up the great work!

It will be great to have a cheaper solution for paygo as to implement it on little cheap product and don’t increase price for poorest community who need energy at very low cost

Firstly the Open Source approach to any solution is a great way forward, not having to work with licences and the fees involved helps any business. Mobile money has it’s challenges, especially in the more remote areas which is where we also operate so a solution not reliant on connectivity can only be good.
I like the ease of this solution as it doesn’t require the user to remember long PayGo ID’s where we often see they communicate the wrong number requiring time and effort to resolve, an RFID tag seems such a simple but effective solution.
I can see the definite benefits of using this approach and SureChill would support where it can with any assistance in testing this in the field.

@daniel.goldbach I am glad to hear you are interested in this innovation. Would you see this innovation potentially replacing keypad entry completely in your products?

@Arnaud If this solution is not lower cost than keypad entry of tokens would you still be interested?

I can see this being a possibility but it there also is a user element where they may prefer the mobile money and keypad approach so would need to gauge market feel once this was launched before saying for sure

Cost is obviously a key component as this will be in developing countries where there is much less disposable income but this addresses a need for a solution where connectivity and mobile money is not always an option so if cost was higher there is still a market need to evaluate.

Thank you for the feedback.

Have you looked at the cost of the equipment needed for the distributor as well, as this piece of equipment could be more expensive although I do believe there should be a way to bring that price down from the normal RFID equipment that is sold for these purposes.

I also wondered if you might have thought about looking at the Airlink solution instead of the RFID solution? It would be possible to do a similar offline recharge of meters, but would require use of a smart phone. I can see the advantage of the cards as this would work where the smart phone was not available.

We received the following feedback on the innovation. Would you have any feedback on this. They believe it is a good idea, but had the following three comments/questions.

  1. How big is the problem that this solution would solve? Token issues are often hardware-related.

  2. How is the RFID tag assigned to customers on site. Supply chain management with increased complexity of on-site processes are often the bigger problem. Here it would be good to understand whether the system tends to simplify or complicate processes in the last mile.

  3. The payers are often not the users of the system - so far it has been easy to send an SMS/Whatsapp with the token. How do you regulate this use case with the RFID tag?

For the cost of the readers we did look at that pretty deeply, those readers in fact are integrated into a lot of smartphones (any smartphone with NFC can actually read those tags), including low end ones found in our markets, most agents in kiosks already have smartphones so there should be no added costs for distributors on that side.

The Airlink solution might work in some cases but has significantly more cost and requires the agent to actually travel to the device’s location, which is not workable in our target use case. I think both solutions are complementary and serve different use cases.

Here are a few answer points:

  1. The actual size of the problem is hard to estimate, but we know of several distributors representing currently tens of thousands of clients that are dealing with issues like this on a daily basis. Some have developed proprietary systems to limit the errors (e.g. for the part of the token given by the agent, equipping the agent with a printer, but this is costly, agents often run out of paper and it does not solve the problem of the clients mis-remembering their device’s serial number).

  2. It is not assigned, the tags are device agnostic and any tag can be used on any device. As long as the tag is tapped on the device you wish to recharge once before tapping it to the agent’s phone it will work.

  3. To be clear, the tag is thought of as a complement to the token entry for the clients that are not able to receive SMS (out of coverage). For the clients that are able to receive SMS and have someone else pay for them, then no need for the tag to be used. If they have someone pay for them but are not able to receive SMS, then they will still need to go to an agent to tap their tag and recharge which is still better than going to an agent and write down a token on a piece of paper.

Thanks for your response. It does seem like there could be many use cases and/or potential variations on how someone might use these.

For number 2, I could see a customer going all the way to the agent and then realizing that their card was not properly tapped on the device, which would entail having to go all the back to the device. For those customers, I imagine that could benefit from this innovation that could be quite a distance. Likely, devices would need a way to indicate the tap had been done correctly.

To clarify, the tap just need to be done once. Though if it is done more often it means that data can be fed back, but for the purpose of just working the tap can be done only once in the history of the device (e.g. with the agent they get the device). If for some reason the tag failed the app would revert to giving a token to the client that could be written and inserted into the device.

Thanks for this interesting initiative and discussion!

I have a question on this part of the Problem statement:

Moreover, this system does not allow for data feedback, which is a requirement for many result-based financing (RBF) programs that subsidise solar kits for end-clients, despite the relatively high typical cost of data feedback.

Could you explain more about this please. My understanding is that, for cash top-ups, the agent who takes the payment and issues a token will register it onto a system for the company to track. What additional insights would the RFID card tap give? Is the added value in the digital verification of that particular product/payment?

Sure @DrewCorbyn . The RFID card would contain usage data from the device (e.g. number of hours of light provided, power generated, battery health, etc.) that would be transmitted to the backend platform through the phone of the agent collecting cash.