Making contactless payments easier to get right
I improved tap guidance across Surfboard’s payment terminal and Android app. I designed clearer tap targets, card-read feedback and guidance for different phone models.
- Fewer first-tap failures on SurfPad.
- 86%
- Fewer support contacts about card-tap problems on SurfPay Android.
- 63%
At a glance
- People needed to know where to tap and when the card had been read.
- I designed clearer tap targets, read confirmation and guidance for different Android phones.
- A revised terminal screen and an Android payment flow with device-specific guidance.
- Fewer first-tap failures on SurfPad and higher first-tap success on Android.
Context
Surfboard Payments provides terminals and a payment SDK for merchants and software platforms across Europe. I designed the payment guidance and feedback across SurfPad and SurfPay Android.
SurfPad: make the tap location clear
Before the redesign, 14% of SurfPad payments failed on the first tap. Customers were tapping the branding below the reader. The screen needed to make the correct location clear and confirm when the card had been read.
Tapping away from the NFC reader
The terminal’s branding drew attention away from the reader. I worked within the existing hardware, using the screen and feedback timing to guide the tap.
Feedback fired too early
Early feedback could make an unsuccessful tap feel complete. I moved the vibration to a successful NFC read, so the cue confirmed that the reader had received the card data.
Key design decisions
Mark the reader location
I enlarged the contactless icon and placed it over the reader zone. The screen now gave customers a specific place to tap.
Say what to do
I added “Tap your card here” beside the target. The instruction made the action explicit without adding another step.
Confirm the card read
Vibration followed a successful NFC read. This acknowledged card capture; the payment still needed its processing and approval result.
Outcomes
First-tap failures fell from 14% to 2%.
Software only
The physical reader stayed fixed. Clearer interface guidance and correctly timed feedback reduced failures without a hardware revision.
The impact
The improvement came from making the existing hardware easier to use. The reader stayed in place while the interface made its location and feedback clearer.
SurfPay Android: guide the tap on different phones
Before the redesign, 31% of Android transactions needed another tap. NFC reader positions vary across phones, so merchants needed guidance that matched their device, including models the app could not identify.
Map the device differences
I mapped reader locations to understand which guidance could be shared and which needed to change by device.
I divided the back of each phone into nine zones and mapped NFC positions across models from Samsung, Pixel, OnePlus, Xiaomi, Oppo and Realme.
The mapping suggested recurring upper and central positions. I used those patterns to shape a lookup table for known models and broader guidance for unknown devices.
Mapping NFC positions
Comparing reader locations helped define device-specific guidance and a fallback for phones outside the lookup table.
Choosing the guidance and fallbacks
Android 14 API detection
Android 14 introduced an API for antenna-position information. It offered precise guidance where supported, but older phones still needed a fallback. The API can also return no data, so OS version alone is not enough.
Learning from transaction data
I considered learning positions from transaction data. That approach depended on collecting enough usable data after launch, so it could not solve guidance for the first merchants.
Manufacturer matrix
A lookup table could provide guidance for known models from day one. Its limits were coverage and maintenance: new or uncommon phones still needed another path.
Physical sticker at the NFC position
I designed light and dark stickers to mark the reader on a merchant’s phone. They made the location visible when staff shared the device. The tradeoff was a manual onboarding step and replacement when the phone changed.
How the signals worked together
- Android 14 API
- Use antenna-position data when the device provides it.
- Manufacturer matrix
- Use the recorded position for a known phone model.
- Generic animation
- Show broader guidance when a precise position is unavailable.
- Physical sticker
- Mark the reader physically on a correctly identified device.
The flow
Detect
Use the best available position information: the Android API, then a known-model lookup, then broader guidance. A robust fallback also needs to handle missing API data on supported versions.
Animate
A Rive animation on the payment screen highlights the relevant area of the phone. The customer presents their card there while the merchant uses the phone as the payment terminal.
Confirm
After a successful card read, the guidance clears. If the read fails, the animation restarts with a short retry prompt.
The solution
The solution combined device data, a model lookup and broader fallback guidance. Each digital path used the same payment-screen animation. Stickers provided a physical reference for merchants using a fixed device.
Keeping guidance on the payment screen meant merchants could retry without leaving the transaction to look for help.
SurfPay Android outcomes
91%
First-tap success on SurfPay Android, up from 69%.
The impact
This work taught me to design the fallback alongside the ideal path. Device-specific guidance improved the first tap, while broader guidance and a physical marker helped cover gaps in the available data.