If you aren’t working on solving the riddle of mobile payment, you certainly have read about it. From mobile wallets, credit card readers, loyalty cards, Passbook, and more, the solutions to paying with your mobile device is in demand now. Some have their offering in place already, but adoption still trickles in slowly. Some want to solve m-commerce for customer segments already in place, while others want to create a brand new base of users.

With the number of articles on the subject growing daily, I wanted to pass along some of the lessons I am currently wrestling with that may help with your project.

One caveat before I get rolling: there is no such thing as a magic bullet with current options. You will have to make some concessions in one way or another to get what you want in your app. Security, ease of use, performance, and other factors will need to be considered. What each of those items mean to your customers will look different. For example, to have top-of-the-line security you may not have the simplest user flow. 

You have to pay for these transactions just like any other credit card vendor. Payment processing companies were not built equally, and the longer they have been in business the more red tape they have. They also may have the best rates in terms of the millions of transactions you hope to have with your solution.

Last I checked, making as much money is still important. Keep that in mind when you are reviewing the architecture and UX of a vendor’s solution.

How many steps will you ask users to take? If the designers at your office work like mine, the answer to this question is usually, “as soon as possible.” They’re not wrong either. Users want less and less touches between them and their desired feature. Unfortunately, large companies have to care to some degree. Apple’s $100M settlement earlier this year was, in part, because it was all too easy for kids to run up the bill on their parent’s iTunes account. 

The question everyone has is, “how many steps are appropriate?” The current trend is to have users set up a virtual “gift card” in their device and only recharge it when needed. That way, you can have access to funds already secured for a particular vendor and only ask for those painful payment steps during the reloading of said card. Starbucks has had great success with their mobile payment app, which asks users to set up and use a Paypal account for reloads.

Why should they pay with an app versus plastic? Larger than the previous two points, this plays into the overall strategy of the app itself. Is there anything motivating users to download and use your mobile payment solution other than being one of the cool kids? 

Since I used them earlier, let’s look at what Starbucks does. There is a reward for transaction milestones related to free merchandise later on. Your fifth, tenth, twenty-fifth, etc., purchase results in something. If you like their coffee (if you want to call it that, it’s too strong for me), and shop there frequently anyway, this feature is of value to customers. As long as that value increases frequency of purchase, of course.

Your strategy needs to account for the value equation if it is going to be successful. You can see it represented below:

To increase the value your customers will receive with each visit, you either decrease the cost of the product or increase the perceived benefit. If you get two meals for the price of one, the customer feels they are getting a deal. This is the tactic a loyalty card employs. If you increase the perceived benefit, the customer pays the same price but has an enriched experience. This strategy has not yet been achieved in a mobile payment solution yet.

If you can understand the fiscal, technical and strategic aspects of your proposed solution, a viable option to plastic will persist in the market. Customers will not only download your app en masse, but rave about it to their friends and family.