DUOLABS
Work

Micropayment app

We took on the app for a telecom carrier's payment service, where people pay by phone micropayment instead of a credit card and the amount is added to the next month's phone bill. When we joined, the code was tangled and mixed with unused code, so we first mapped and cleaned up the screen, payment, notification, and release code. On that base we added barcode payment for use in stores and a home-screen widget that goes straight into payment. If users misread whether a payment succeeded, failed, or is still in progress, they cannot even tell whether they paid, so status display and error handling were checked together.

Launch
2017
Client
A Korean telecom carrier
Type
Payments
01 / 04

In-store barcode payment charged to the phone bill, with no card to register

Carrier micropayment lets subscribers pay without registering a card, adding purchases to the phone bill within a micropayment limit. The amount is billed with the next month's phone charges, and at the store the carrier's membership discount and the payment are applied in one step. We added barcode payment for stores such as convenience stores, bakeries, and restaurants. The flow, from entering the payment screen and showing the barcode to showing whether payment is available right now and explaining when it is not, was built to finish quickly at the counter.

In-store barcode payment charged to the phone bill, with no card to register
02 / 04

Entry to payment that starts from a widget, without opening the app

In a payment app, the fewer steps between taking out the phone and seeing the payment screen, the better. We built a home-screen widget that goes straight to the payment screen without opening the app first. The work focused on cutting the steps between the widget and the start of payment.

Entry to payment that starts from a widget, without opening the app
03 / 04

Payment status shown so success, failure, and in-progress never blur

If users of a micropayment app misread the payment status, they cannot tell whether they have paid. Screen flows and exception cases were checked together so that success, failure, and in-progress are clearly distinct on screen. Notifications travel over two delivery routes, so we verified receipt, device registration, and error cases while checking how each route behaves differently and what exceptions can occur in live service.

Payment status shown so success, failure, and in-progress never blur
04 / 04

Untangled code, plus a test distribution and crash tracking setup

When we joined, the micropayment app's code was tangled and mixed with unused code. To get it to a state where it could be maintained and extended, we first mapped and cleaned up the code for screens, payments, notifications, and releases. We then set up an environment for test distribution and crash tracking, so that test builds could be handed out and errors checked during development and acceptance testing.

Untangled code, plus a test distribution and crash tracking setup

Highlights

01

Tangled code cleaned up into a state where features could be added

02

In-store barcode payment and entry to payment from a home-screen widget

03

Verified notification delivery and device registration, plus a test distribution and crash tracking setup

Insights

Read the blog