DUOLABS
Work

New QR payment app

We built the core payment flow of a mobile app that pays at stores by QR code. Users get a prepaid payment method issued inside the app, pay at merchants by scanning a QR code, and redeem points and coupons in the same app. The project had stalled once at the prototype stage and was being relaunched, simplified around payments. In a payment app, a request sent twice or a failed payment that looks successful is immediately a money problem. The work spans the whole payment flow, from QR scan and payment request to reading the server response and showing success or failure, along with its exception handling.

Launch
2020
Client
A payments company
Type
Payments
01 / 04

One unbroken flow from QR scan to payment complete

A payment in the QR payment app goes in order: scan the code, request the payment, receive the server response, and show success or failure. We tied these steps into one flow so the user can tell from the screen which step they are on. The rule for the screens was that a user should never be unsure whether a payment is still in progress or already done.

One unbroken flow from QR scan to payment complete
02 / 04

Payment requests designed around duplicates, delays, and cancellation

A payment request does not always come back with a normal response. Duplicate requests, failure responses, network delays, and a user cancelling mid-payment were designed together with the payment flow itself. Across the request and the result check, the request, the response, and the screen state were kept consistent so the user never sees a wrong payment status.

Payment requests designed around duplicates, delays, and cancellation
03 / 04

Rules that turn an unusual server response into app states

The payment server answered in an unusual format rather than the commonly used data format. We built the parsing for these responses and mapped each response case to the state the app should move to. Not just successful payments but error codes, missing fields, and malformed responses all lead the app to a defined screen instead of leaving it stuck.

Rules that turn an unusual server response into app states
04 / 04

Collaboration that kept both platforms on the same payment rules

The other platform's app for the same payment service was handled by another developer. We walked that developer through the payment logic and how server responses were handled, and helped with the implementation. The payment policy and exception rules have to match across platforms, or the same payment shows a different result depending on the app.

Collaboration that kept both platforms on the same payment rules

Highlights

01

A payment flow that runs from QR scan to showing success or failure

02

Exception handling for duplicate requests, failure responses, network delays, and user cancellation

03

Parsing an unusual server response format, including error codes and missing fields

Insights

Read the blog