Pay screen

Background

Luno Pay lets customers spend crypto directly at physical stores — scan a QR code, pay with a rand-backed stablecoin called ZARU, and earn a rewards kicker back. The problem was that none of this had anywhere to live. There was no landing screen and no dedicated entry point; customers who found Luno Pay mostly stumbled into it.

The team needed a proper home for the feature: something that could explain what Luno Pay was, show the merchant network, surface live promotions, and give returning customers a fast way back to scanning — built on a backend-driven architecture so content could change without an app release, and ready inside a tight, externally-fixed deadline about a month out.

My role

I led product design on the Pay screen, working through information architecture, layout and content structure with a product manager, a UX writer, a design system lead and engineers across Android, iOS and Web. I resolved the navigation and iconography questions that cut across three surfaces, organised and ran the cross-platform test party ahead of release, and stayed on through launch — reviewing push-notification copy and helping define the metrics we'd use to judge whether the screen actually worked.

No baseline, a hard deadline

There was no usage data to design from — the feature barely had a front door, so there was nothing to benchmark against. What we did have was clarity on the shape of the problem: the merchant network was already large, the reward mechanic already worked, and none of it was visible. The screen had to earn its place in the navigation by being genuinely useful before it could earn a permanent bottom-nav slot, which was itself queued behind another team's tab restructure.

We settled early on a backend-driven content model: the client renders whatever sections the API returns, in whatever order, and quietly skips anything it doesn't recognise. That one decision meant later changes to content and promotions wouldn't need an app release to reach customers.

0

dedicated entry points into Luno Pay before this screen existed

3

platforms — Android, iOS and Web — building the same screen in parallel

~1M

merchants across South Africa already reachable through Luno Pay

Getting the structure right

Early direction pushed toward a bolder, more conceptual layout for an internal showcase — a hero section with a toggle between ZARU and other cryptocurrencies, closer to a dedicated payment card than a standard app screen. Once the showcase had done its job, the design settled back onto the existing design system so engineering could build it inside the release window.

Three questions came up repeatedly, and each needed a real answer rather than a preference:

Roughly six weeks from kickoff to a public marketing page

The release window was fixed externally — structure had to lock early enough for three platforms to build in parallel, with a test party before code freeze and marketing following a week after ship.

Three doors, one screen

Rather than one entry point deciding everything, three separate surfaces needed to agree on where they sent people — and the icon they used to say so. All three entry points resolved to one consistent icon and the same landing screen.

A cross-platform test party

Ahead of release we ran a structured test party across Android, iOS and Web against a shared set of test cases — feature-flag gating, layout and content rendering, the sticky call-to-action, merchant chips and their dialogs, promotions, FAQ, and every error state. It surfaced two real bugs before launch — a navigation block on Android and a back-navigation issue on iOS and Web — and iOS coverage was the hardest to pin down, so I chased that down separately to make sure nothing shipped untested.

After launch, we ran a short customer survey to understand which Luno Pay use cases people were actually interested in, which shaped the merchant and content priorities we picked up next.

“We're going blind without knowing how people will actually use the page — worth testing, but not worth blocking on.”

A real home, and the numbers to prove it

The screen shipped to South African customers on Android, iOS and Web on 1 June 2026, with the public marketing page following a week later. Because there was no baseline to compare against, measuring impact meant setting one up properly rather than eyeballing it — so with a data analyst and the product manager we defined what would actually tell us whether the screen was working before we had anything to look at.

June answered the question. Completed Luno Pay payments rose 27%, and the shape of that increase lines up with the screen starting to gain views — the ramp begins where the landing screen does, which is the strongest attribution available without a holdout. Weekly customers completing a payment climbed about 40% over the same stretch, and that is the number I trust most: it counts people rather than volume, so it can't be carried by a handful of large payments.

Reading the charts

Four dashboards carried most of the signal. Absolute figures are blurred in everything below — the shapes and the direction are the point, and the underlying volumes are Luno's to publish rather than mine.

Adoption is the clearest of them. Landing-screen views sit at zero for the first four months of the year, because there was nothing to view, then climb steeply from May once the screen exists — split across Android and iOS with a thin band of web. Completed payments bend upward on the same timeline rather than a month later, which is what makes the attribution credible. Web stays flat at zero on the payments chart by design: the payment flow is mobile-only.

The weekly view separates the two things that could be moving. Payments and rand value bounce around week to week, but the light blue customer bars step up in the final weeks and stay up — more people paying, not the same people paying more.

The carousel earned its space

The merchant carousel was the section that took the most curation, so it was the one I most wanted data on. It gets significant interaction, and the pattern inside that interaction is more interesting than the total.

What the screen is built from

Because content is backend-driven, the screen is really a set of interchangeable sections rather than one fixed layout — which is what let promotions and merchant content change after launch without touching the apps. Any section can be reordered, replaced or omitted entirely from the backend — the client never assumes a fixed shape.