Xintong Zou — UX & Product Designer

A cold start with a clear target

Pay by Bank (PBB) is Kody's Open Banking payment method. It launched on in-person terminals, prompting customers to scan a QR code and pay in their bank app on their mobile device (typically for transactions above £40).

I collaborated with PM to clarify the ultimate goal of this project to tackle this 'cold start'.

However, after the first version launched in one and a half months, the numbers were flat. Adoption was low, and the data volume was too small to tell us why.

Business requests

Add 64 more banks options into this payment method.

Achieve a 30% increase in adoption rate in this iteration.

Constraints

Terminal is a core tool that values speed and stability, which are the main requirements in an offline payment scenario.

£40+ transaction threshold (cost/business constraint).

Team resources are limited, requiring swift directional decisions.

Learn why adoption stalled

With limited usage data and high implementation cost, shipping changes would have been largely guesswork. Instead, I ran 10+ rapid qualitative interviews with merchants and frontline staff to identify the real adoption blockers before investing in a build.

To capture a broader range of perspectives, I grouped participants into key cohorts before the interviews (recent users, churned users, high-value cases, negative feedback, and internal account managers).

Recent PBB users (past 7 days)× 2

Highest-value PBB transactions× 2

Churned PBB users (no use in 3 weeks)× 4

Negative feedback cases× 2

Customer account managers× 4

Why would I ever…

During the interview, there is a most frequent challenge from merchants and customers, which is

"Why would I ever do this instead of just tapping my card?"

In a high-pressure hospitality environment, speed is currency. PBB added friction and was hard to explain to customers.

CARD

(Tap/Insert)

Speed: Fast (3–5S)

Reliability: High (Offline)

Cognitive load: Low

PBB TERMINAL

(Scan QR)

Speed: Slow (30–75S)

Reliability: Variable (Wifi)

Cognitive load: High (Multi Step / App Switch)

Connectivity issue

Venue basements often have poor signal, killing the QR flow for both customers and staff.

Adds friction & slowness

Waitstaff prioritise rapid table turnover — PBB slows them down during peak hours.

Refund limitations

Merchants worried about complex refund processes on terminals.

Communication gap

Launch emails only went to business owners. Staff operating the terminals were left in the dark about PBB's benefits.

Despite adding more banks, terminal PBB adoption would likely remain low because the terminal checkout context prioritises speed, reliability, and refund expectations.

Where Pay by Bank can actually win

After all the insights, I joined a deep-dive with the CTO, Head of PD and Tech Lead alongside the PM to align my findings and bring out my Opportunity hypothesis.

"PBB is better suited to low-urgency, off-premise payment moments (e.g., prepayments, remote orders, booking deposits), where transactions are more likely to meet the £40+ threshold"

Based on this hypothesis, I drafted a few criteria to define a proto-persona for Pay by Bank:

Proto-persona criteria

Low-urgency payment moments (not queue-based)

Typical AOV above £40 (aligned with the business constraint)

Serving repeat local customers (a supporting signal)

To sanity-check the hypothesis, I partnered with our data team to run a lightweight segmentation check using "merchant category (KYC code) + typical AOV ≥ £40". From the resulting merchant list, we saw that Pay by Link appeared more frequently in higher-value, off-premise scenarios—supporting it as the primary channel to prioritise for PBB adoption.

We shifted the centre of gravity from 'expanding banks on terminal' to 'making Pay by Bank succeed in Pay by Link'. Terminal expansion was de-scoped into a secondary track.

Effort

Impact

Low effort

High impact

High effort

Low impact

Integrate PBB into PBL

Check solution

Pay by Link as the primary growth channel

Deprioritise PBB on terminal

Expand bank coverage

Highlight PBB's cost-saving benefits

Terminal: explore new interaction methods (e.g., NFC)

Refund support

Phase One: Focus on key users' needs

Phase Two: Expand to broader merchant base

Turning the pivot into a working flow

Pay by Link as the primary growth channel

Integrate PBB into PBL

Rapid ideation with implementation realism (AI-assisted)

To stay implementation-realistic and move quickly, I started from the existing Pay by Link checkout HTML and ran it locally. Using Claude Code, I generated an initial Pay by Bank flow (eligibility ≥ £40, bank list, connecting state) directly on top of the current UI system.

I then brought the potential flow into Figma (via MCP) to iterate on hierarchy, nudges, and bank selection patterns, producing a small set of variants for review.

Once aligned, I mapped the final components back to the running HTML and reviewed feasibility and edge cases with PM and engineers.

The new flow we built around

We prioritised Pay by Link as the primary channel for PBB, designed for low-urgency, higher-value payments

Merchants create and share a payment link in Kody Universe (KU).
Customers choose their bank in a web flow (popular banks, search, and recent banks).
Clear messaging explains the benefits and builds confidence.

Merchant create payment link on internal SaaS Platform

Customer open payment link

Merchant check payment details on internal SaaS Platform

Step 1 — Merchant creates a payment link

Highlight fee savings to drive Pay by Bank adoption

Auto-deselect Pay by Bank when eligibility requirements aren't met (e.g., payment below £40)

Step 2 — Customer selects bank in web flow

Expand bank coverage

Customers open the link from SMS or email, choose Pay by Bank, and complete authorisation in their banking app.

First customer

If the customer is new to PBB (or cookies are declined), prioritise Pay by Bank as the primary option to drive adoption.

Return customer

Remember the previous bank selection to reduce steps for returning customers and improve adoption.

Step 3 — Confirmation, status tracking, refund

Refunds are not automatic for Pay by Bank. We added a clear explanation on the transaction details page so merchants understand the refund model and can guide customers through the correct next step.

For Merchant

Text message

Email notification

Email result

For Customer

Deprioritise PBB on the terminal and expand bank coverage

Deprioritise PBB on terminal

To protect the core checkout flow, we kept card payment as the primary option and moved Pay by Bank (and other immediate payment methods) into a secondary menu—reducing cognitive load for staff.

Drive adoption with clear value messaging

Highlight PBB's cost-saving benefits

To support merchant adoption and address low awareness of the fee-saving value proposition, I prepared launch enablement materials alongside development—creating a step-by-step guide, drafting Intercom prompts, and producing email communications that clearly explain PBB's fee-saving benefits.