Google products’ latest design philosophy is in full effect here, with a clean, card-based UI (see Figure 3-2), clear calls to action, and Android OS best practices at work.

Google Wallet 2.0 features a slide-out navigation menu for key features like cards, money transfers, loyalty programs, and local offers.

Friendly tone and labels guide the user through payment experiences.

Figure 3-2. Google Wallet’s refreshed design (courtesy of Google)

Users who are reluctant to add a credit or debit card to their phone can opt instead to preload their Google Wallet Balance (Figure 3-3), which can be used at the time of purchase, similar to a prepaid card.

Figure 3-3. Users can opt to use either a credit or debit card for purchases, or load money onto their Wallet Balance as the funding source of a transaction, online or in store

Card images are generic, and do not reflect the actual card that was registered (i.e., a Wells Fargo or Citibank card).

The app-launch-to-payment flow is very fast; the user needs only to have the app open and unlocked (with his PIN) for payments to take place (Figure 3-4 shows what payments look like with Google Wallet). The first few times you use the app, there’s a helpful message that tells you when your app is ready to pay.

There is an audio cue and short vibration when the phone comes into contact with the reader.

There isn’t always an indicator that the card is turned “on” and ready to pay. Users may not understand that when the app is open and their phone’s NFC antenna is on, their payment card is considered “armed and ready.”

Except during the onboarding process, no instruction is given to the user regarding how to pay—that is, how to hold the phone over the reader or what to look for in a store that accepts NFC (only when reader is tapped without opening the app do you see an instructional diagram with tips on how it works).

When something goes wrong, Google Wallet displays helpful instructions, telling the user to try the tap again or check with the cashier for confirmation (Figure 3-5).

Figure 3-5. A helpful error message, directing the user to check with the cashier to confirm the transaction; this might appear if the reader was not compatible, or if the NFC handshake encountered a conflict

If the NFC antenna of the phone is turned off, or another NFC wallet is in use,^[45] Google Wallet informs the user as soon as she opens the app rather than waiting until she attempts to pay (Figure 3-6). The error messages also give the user a button to tap that will bring her to the screen in her device’s Settings menu where she can quickly rectify the issue.

Transaction feedback (refer back to Figure 3-4, center) is vague: “Requesting transaction...” feels like the app is asking permission to make a payment, when in fact the payment has already happened. Something less robotic-sounding, like simply “Paying now...” or “Payment completing...” would be more effective.

Figure 3-6. Two cases where the user might encounter problems paying with her phone: the NFC antenna is off (left), or another wallet is occupying the NFC function (right)

Even on “smarter” readers that can return rich transaction data (amount, currency, merchant name, address) the Transaction History in the app may not reflect this information right away. More information about the purchase may not display until the payment is processed and reported back via the Wallet’s cloud services (which requires data network access).

The user is greeted with his account identifier (Gmail address) when the app starts up (Figure 3-7, left), which is a nice touch of personalization that says, “this app remembers me.”

The passcode lockout feature activates after 15 minutes or 1 day of user inactivity. The passcode is also used to “lock” the app to prevent fraud, and allow for authorization of larger purchases—say, over $150.

Figure 3-7. Google Wallet’s PIN screen and security features

Progressive numeric fields are used as opposed to one long field, allowing for quick passcode entry, in four taps (similar to a phone lock screen). The app uses a custom keypad, rather than the stock OS one, which prevents eavesdropping by any malicious apps that may be installed somewhere on the device (Figure 3-7, left).

The user (or thief) has six attempts to get the passcode correct. Exceeding this limit locks the app and blocks any card data present in the OS memory to be invalidated by the cloud service.

The wallet passcode is labeled as a “PIN,” so debit card users might be tempted to reuse their ATM PIN, which is risky. A safer label might be mPIN or passcode.

There’s no indication of help if the user forgets his passcode until he enters an incorrect one, at which point a “Forgot PIN?” link displays.

Helpful instructions are displayed during the onboarding process (Figure 3-8), guiding the user through setup and payments.

Figure 3-8. Isis has clear instructions throughout the app, often using diagrams to explain how to use different features

The app includes familiar navigation patterns, and has a contemporary look and feel.

Like Google Wallet, Isis comes with a prepaid card from American Express Serve, so the user doesn’t have to add her bank cards to the app if she’s hesitant due to security concerns.

Users are rewarded with cash back for purchases made with the app, and given discounts from a handful of large brands that have partnered with Isis (e.g., Jamba Juice, Foot Locker, Toys R Us, and Coca Cola).

Users can also add a few loyalty cards to the app, which automatically count any purchases made to the merchant’s loyalty system or points aggregator.

A map search is included for nearby participating merchants.

There is no customization of cards or card nicknames.

There is no transaction history to show the user a log of payment activity, acting as a digital receipt.

The onboarding process is somewhat fragmented, with web-based enrollment of cards, rather than enrollment being handled within the app (Figure 3-9). When the user taps the Add Card button, she’s taken to the phone’s web browser to fill out her card issuer’s enrollment form. This was likely to accommodate the disparate authentication requirements for the three card issuers. It’s a subtle difference, but a significant one—users may view jumping around between parallel apps to be too much trouble, and this design opens up the probability of navigation issues or service errors. More importantly, it may discourage users who are wary of logging into their bank’s web services using their phone.

The Ready to Pay indicator (Figure 3-10, left) shows when a card is ready to pay.

Figure 3-10. Paying with an American Express prepaid Serve card

Subtle instructions tell the user how to hold the phone over the reader, by placing the back of the phone (where the NFC antenna is) over the reader at the register.

The card slides up when the reader (Figure 3-10, center) is detected, giving a clear indication that a payment has begun.

When an Offer (e.g., $5 off at Jamba Juice) is turned on by the user, there is not much indication on the Pay screen (Figure 3-10, left) of which offer is turned on. The only clue is a button with a vague label, Clear Offers.

Likewise, when the payment is done (Figure 3-10, right), it doesn’t tell the user which offer was applied to the purchase. He has to rely on the cashier or the paper receipt for this confirmation.

The animation, sounds, and vibration paired with messaging is general enough to show that a payment has been attempted, without any conflicting messaging from the point-of-sale reader (for instance, if the card was declined, or did not complete for some other reason).

The confirmation screen clearly shows which card was used for the transaction (Figure 3-11).

Figure 3-11. The somewhat vague confirmation screen showing the user that a transaction has taken place

Flipping a card image over reveals basic details about each card in the wallet, such as the last four or five digits of the card, and the type of card it is. The back of the Serve prepaid card is especially helpful. It shows the last known balance, so the user knows how much she can spend, and has links to add more money or use the cards for bill payments online.

If the user opens the app when her phone’s NFC antenna is switched off, an alert pops up to inform her and show her where to turn it back on (Figure 3-12).

The display of transaction details is fairly vague (Figure 3-11). For example, it doesn’t display the amount of the purchase, the name of the merchant, which offer was redeemed, or which loyalty card was used. The screen doesn’t seem definitive.

The user must still rely on the cashier or the POS to tell her whether the payment was successful.

The PIN screen uses a large, custom numeric keypad, instead of using the stock OS keypad (see Figure 3-13, left).

The user can lock his app using his PIN at any time—a Lock Wallet button is readily available from the slide-out menu (see Figure 3-13, right).

Figure 3-13. The PIN screen prevents fraud, and the user can lock the app at any time from the app’s menu

As with most NFC wallets, the user’s card data is stored inside the device on the SIM card, in an encrypted container.

The user’s name, email address, or full card numbers are never stored or displayed in the UI, which reduces exposure of financial data.

As with Google Wallet, the passcode is labeled as a PIN (which may put cardholders at risk if they use their debit card PIN).

The letters on the keypad aren’t really necessary, as most users opt for numeric passcodes, especially when they are meant to be four digits or characters.

Users can link several cards and bank accounts to the app, or preload their Wallet Balance. This gives them more options to check out with.

Because PayPal uses various payment methods, the list of accepting merchants is greater than that for most cloud-based wallets (see Figure 3-14 for an example of two payment options, and a list of merchants).

Figure 3-14. PayPal acts as a wallet, allowing the user to link several accounts, and supports several payment interaction types

Users can browse nearby merchants without having to log in first.

The app is available for Apple, Android, and Windows devices.

The app depends on data connectivity in order for the user to be able to log in, pay, place an order, or really do anything other than browse for nearby merchants.

The app shows the user a comprehensive list of all the nearby merchants, which can be browsed in map or list views (Figure 3-15). The distance and the address of each shop are easy to find.

Icons and buttons clue users in as to which kind of payment they take: a clock or button for pre-paying for something they’ll come in to pick up later or have delivered, a phone for merchants who will see users check in and charge their PayPal account for the order, and no icon for larger chains that accept just a phone number and PIN at checkout (Figure 3-16).

For check-in payments, users can add a picture of themselves to their profile, so that the merchant will recognize them.

Experiences are fragmented. Though it is convenient that so many merchants accept PayPal, the three different checkout flows are so drastically different that the user isn’t quite sure what to expect from each transaction (Figure 3-16).

For remote ordering, PayPal may pass the user off to a third-party site, like EAT24, to complete the transaction.

Remote ordering and check-in payments require a data connection.

The user is kept informed with helpful error messaging written in plain English, without any technical jargon.

Users are provided a transaction history with a robust record of recent payments (Figure 3-17). Wallet balances are clearly displayed.

A data connection is required, so a digital receipt is not immediate and may be delayed if the connection is slow.

The user is still fairly reliant on the store cashier to verbally confirm whether the payment was successful.

The full details of the user’s linked cards and bank accounts are never displayed on screen (just the last four card or account numbers).

Most activities like transfers and payments or changing account settings can be accessed only in password-protected areas of the app.

Users can lock the app with either their PayPal email and password, or their phone number and PIN (Figure 3-18). This lets them enter the app with the security credential they feel most comfortable with (or can remember at the time).

Sensitive user data, such as home addresses and expiration dates, is displayed for some stored cards. These are completely unnecessary to show in the app. If this information is cached in the OS memory, it can be exposed.

Complex passwords (mix of letters, symbols, and numbers) are not required.

The PIN fields in the app use the OS keyboard (Figure 3-18), which could expose users’ PINs to any malicious apps that may be running in parallel on the device.

LevelUp maintains a cheerful and consistent design across several platforms (iPhone, Android, and Windows Phone).

The design is simple, with no frills. There are no overwhelming menus or processes, and onboarding (which starts from the screen shown in Figure 3-19) is fairly quick and pain free.

Figure 3-19. LevelUp uses QR codes for payments at small businesses

The merchant directory search results (Figure 3-20, right) are displayed in a logical manner, calling out enticing offers.

The app is ready to present to the reader as soon as it opens (Figure 3-20, left); no additional taps or loading times are needed.

Figure 3-20. Payments are efficient, thanks to a ready-to-scan QR code and a helpful merchant directory that shows nearby shops and the rewards they offer

Users can add a tip to their bill using the tip slider at the bottom of the screen, which changes the QR code accordingly.

The QR code itself is large, so it’s easy for merchants to scan.

A data connection is required for the user to get a digital receipt in the form of an SMS or push notification.

It can only be used at merchants that also have the LevelUp POS app.

Within a minute or so after the merchant accepts payment, the user can view an itemized receipt.

The receipt is usually accompanied by a visualization showing how much more the user needs to spend at a particular shop to earn cash back (Figure 3-21).

A data connection is required, so the receipt takes some time to display and may be delayed if the connection is slow.

The transaction history is oddly buried under Settings; it could be more prominent in the navigation.

LevelUp lets the user set an optional four-digit passcode or PIN to lock the app (Figure 3-22).

The app uses a custom keypad, rather than using the stock OS keypad.

Figure 3-22. An optional passcode lock keeps users’ QR codes from being accessed without their permission

Detailed information about credit or debit cards is never shown in the app, and in fact the user’s card information is stored by payment gateway Braintree. The app relies on a tokenization system instead to process payments via the QR codes, which are randomly generated for each user.

There’s no clear way for users who have forgotten their passcode to reset it or receive a reminder, unless they block the app after five incorrect attempts.

Rather than using a more traditional tab bar or slide-out menu, the app has a dashboard (Figure 3-23, left) that gives the user fast access to payments, as well as spending history and a store locator.

The app encourages repeat visits with free drink rewards by showing graphs and animations to indicate the user’s progress to the next reward milestone.

Payments with the Starbucks app are very simple: present the barcode of the user’s registered Starbucks card to a barcode scanner attached to the point of sale.

Users may also redeem drink rewards using the same barcode.

Figure 3-23. The Starbucks app was recently redesigned, with new features and emphasis on earning rewards

Screen brightness is automatically adjusted to the brightest setting for easier scanning.

A shortcut feature called “Shake to Pay” (Figure 3-24) lets users pull up their Starbucks card to pay from any point in the experience.

Payments can still be processed even if there is no data connectivity.

The dashboard is heavily weighted to rewards and marketing messages.

The button for Pay is at the top left of the screen, which makes it difficult to reach during one-handed use.

Shortly after the purchase, the user is shown a receipt, which displays the store information, time, and date, along with the amount and which card was used (Figure 3-25, left).

The tip feature lets users choose from preset amounts to add after the payment has already been made.

After the user hits the Done button on the pay screen, the app checks the card’s balance and updates it. The balance is also checked anytime the app is opened, so the user can always see the latest balance.

The user must still rely on the cashier to confirm whether the card has scanned correctly.

The app never shows a confirmation of payment during the interaction, unless the user actively goes back to the Dashboard and taps on Account History.

An itemized receipt is sometimes delayed, though the user eventually receives a push notification with an updated balance.

It may take a few minutes for the card balance to update within the app, if the data connection is slow.

Even though the financial risk to consumers is low, Starbucks still allows them to lock the app with a four-digit passcode (Figure 3-26).

The app uses the term passcode instead of PIN and follows best practices for numeric passcode patterns.

The passcode is “offline,” so no data connection is needed to access the app.

Because the app uses a barcode, a thief could just as easily take a screenshot of your barcode if the phone is left unattended, and use that at checkout.

GoWallet uses familiar navigation patterns that follow the relevant platform (e.g., iOS, Android) guidelines.

Gift cards are presented in an easy-to-use list view (Figure 3-27, left), which resembles slots in a physical wallet.

The app is complemented by features like balance tracking and reloading for each card.

The app can store several cards from any supported retailer, so it reduces the number of plastic gift cards the user must carry around.

Many UI elements have no visual touch feedback, leaving the app feeling somewhat flat and unresponsive.

There are several buttons with mysterious icons that require excessive pop ups and dialogs to explain their function. In Figure 3-28, for example, the dollar sign icon means “real-time balances may not be available,” and the card icon means “please keep your original plastic card.”

Tapping the Redeem button on a GoWallet card displays a large barcode in landscape view, which makes for easy scanning at the register (Figure 3-28).

If the barcode can’t be read by the scanner, a numeric redemption code is also clearly displayed, so that the merchant can read it if necessary.

There is often an excessive lag (a loading dialog) between the time the user taps the Redeem button and the barcode displays, which slows down the checkout experience.

GoWallet can’t really tell the user when a payment has happened or for how much. He has to rely on POS for confirmation.

The card’s balance does not update after the user closes the barcode screen after a payment. He must tap the Refresh button to get a new balance update. It’s best to avoid extra steps like these.

Some cards don’t have balance checks at all, so users are directed to track it “manually” or to call a service number to check the balance (Figure 3-29).

GoWallet allows the user to set a PIN for protecting her stored gift cards (Figure 3-30).

The app allows several incorrect entries, which opens it up to brute-force PIN hacking.

GoWallet uses a native keypad, which opens it up to malicious pattern-recognition attacks (especially on rooted Android devices).

There’s no clear way for the user to reset her PIN if she has forgotten it.