Recently we (Alexander Zeh and Peter Robinett) were asked to come up with a design for the interface of an Android tablet app for a mobile payments system to be launched in East Africa. Specifically, we were asked to develop mockups for the screens an agent would see when taking cash deposits from new or existing users.
Here’s what we came up with:
We were asked to present designs for the account deposit flow of an existing customer, in which an account holder deposits cash into their account via an agent using the agent tablet app. In the usage scenarios provided to us, deposits are posited as follows:
The interaction flow outlined above in the usage scenarios document has a mistaken interaction model in which a user controls the agent’s tablet. This is similar to an automated teller machine, where the user also logs in, selects the deposit task, and then deposits money. This ‘stateful’ design, where there is a user logged-in state on the tablet, creates a mixed interaction in which the agent is rendered superfluous during much of the interaction while still hovering nearby, only to be required at the end to take cash and validate the transaction. However, the user’s interactions do not have the freedom of occurring on a separate, stand-alone machine as would happen with an ATM.
Customers should authorize fully-specified transactions, not preemptively authorize them by ‘logging in’ to the agent tablet at the beginning of a transaction. The latter creates the possibility for abuse. For instance, suppose a customer logs in and enters all transaction information and then hands the tablet and cash to deposit back to the agent. A dishonest agent could then quickly alter the specified recipient or deposit amount and authorize the deposit with his PIN, robbing the customer and leaving the InnTrans system none the wiser.
In any country tablets are desirable products and frequent targets of thieves. This is especially true in poorer countries where they will be especially. Their portability, value, and use independent of the InnTrans system makes them easier and more attractive targets than traditional point of sales systems. For instance, this Nigerian TV report shows an M-PESA agent being robbed, with the attackers stealing approximately €1600 in cash and goods: http://youtu.be/tWpP6XL54kk
Not only will the tablets used by agents be desirable devices in their own rights, but a thief with access to the encryption keys stored on the device may be able to preform fraudulent transactions. For these reasons, we fear that an interaction flow which requires customers to handle the agent’s tablet machine is an unnecessarily risk. While physical restraints such as a Kensington lock would help, safer would be to simply keep the tablets in agents’ hands behind their shop counters.
We see the user deposit interaction flow as best described by a request- response cycle, where the a deposit action is requested and there is a response with authorization.
It’s is not the user who makes the request: it is instead the agent. This is so because it should be the user who authorizes a transaction, even a deposit one into his or her own account.
The reason for this reversed flow is both a matter of simplicity – an agent can more quickly enter a user’s despot request than a user unfamiliar with the agent app’s interface – but also of trust.
| Customer (SMS) | Service | Agent (Tablet) | Data Needs |
|---|---|---|---|
| Tells agent amount, own phone number, optional destination phone number | Selected the deposit action button under the Customer transaction tab | ||
| Sends deposit request | amount, customer phone number, destination phone number | ||
| Transfer ID returned to Tablet | Transfer ID | ||
| Sends all request info to customer + confirmation code (SMS) | Agent number, Transfer ID, Confirmation code, Amount, destination number | ||
| Gives cash and confirmation code to Agent | |||
| Agent confirms deposit with own PIN and confirmation code | Confirmation code, Agent PIN | ||
| Confirmation of deposit (SMS & Tablet) | Transfer ID, Amount, Destination, New Balance |
The Agent selects the Deposit action button under the Customer Transaction navigation tab.
The Agent fills in Customer information
The input fields validate their content
Service sends all request info via SMS to customer with a confirmation code
The request is stopped because the Customer does not have an account, the Agent registers the Customer in order to resume the deposit process

The Customer is recognized and a transfer ID returned to Tablet.
Agent confirms cash hand over and transaction via a code that the Customer received via SMS.
The agent confirms the transaction
Confirmation of deposit (SMS)

Transaction pending