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).

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.

When I joined, the brief was already in place: integrate 64 more banks into our in-person payment terminal, and lift Pay by Bank adoption by 30% this quarter. Five weeks of development.

Business requests

Add 64 more bank 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.

No PM in the team for this version development.

Learn why adoption stalled

With limited usage data and a high implementation cost, shipping changes without research would have been largely guesswork. Rather than having engineers spend 4 weeks hardcoding bank options — with considerable maintenance to follow — I ran 10+ rapid qualitative interviews with merchants and frontline staff to identify the real adoption blockers before investing in a build.

Merchants / Business Owners× 4

Frontline staff× 6

End payer× 3

Three different user groups raised multiple issues about the Pay by Bank method. I organised them into three dimensions:

Merchant

Front line staff

Payer

Awareness

Doesn't know when to recommend it

Doesn't know what it is

Doesn't know why they'd use it

Operation

Not present at checkout, can't observe what's happening

High explanation cost, awkward fallback when it fails

Three context switches: terminal → QR → bank app → back

Risk

Anxious about the refund flow

Fumbling in front of customers when signal drops

Fear of a public failure while others wait

Perceived value

Fee savings exist but are invisible

Absorbs 100% of operational cost, captures 0% of the savings

Absorbs 100% of cognitive cost, captures 0% of the savings

During the interviews, the most frequent challenge from merchants and customers was:

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

What does PAY BY BANK on terminal mean to users?

At the offline payment context, card payment is the default — fastest, most familiar, most reliable method. PBB never offers users more than card does.

Merchant

⚠️

Invisible transaction fee saving
Even Pay by Bank can help save around 60% transaction fee, few business owners are aware of this benefit

Front line staff

❌

Zero upside — only added work

Payer

❌

Zero upside — only added steps

What's the Product-strategy Problem?

From the qualitative research, it is clear that PBB isn't losing to card on product capability in the offline payment environment — it's losing on context fit. The problem shifts from “how to improve PBB on terminal” to:

Where can PBB deliver net upside to all three users in a transaction — and does that context exist within Kody's current product surface?

Channel Audit

After all the insights, I held a deep-dive with the CTO, Head of PD, Tech Lead, and PM to align on my findings and present my hypothesis on the right channel.

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

Criteria

Low-urgency payment moments (not queue-based)

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

A self-controlled environment (payer is not dependent on a venue's connection or a staff member to explain the flow)

With those criteria, I listed all the payment channels Kody was operating and pulled AOV data for each with help from data analytics, evaluating each against the context requirements from the previous section. Pay by Link emerged as the primary fit for Pay by Bank.

Channel	Time pressure low?	AOV ≥ £40 likely?	Self-controlled environment?	Verdict
Terminal	❌	⚠️	❌	Current failure mode
Pay by Link	✅	✅	✅	Match, primary fit
Online checkout	✅	⚠️ varies	✅	Secondary fit, low Kody coverage
QR payment at table	❌	❌	⚠️	Time-pressure issue + low AOV

The Pivot Decision

In a discussion with the Tech Lead and Design Lead, alongside the insights from interviews and the channel hypothesis, I presented high-fidelity prototypes — one with extended bank options on terminal, and one with Pay by Bank in the payment link. I quickly built the prototypes with the help of AI (Figma Make) to walk everybody through the pros and cons from tech cost and experience perspectives to persuade my team.

Prototype comparison: terminal expansion vs Pay by Link

Only expand the bank options on terminal

Pros: Fits with the initial business requirement without significant structural changes.

Cons: Significantly slows down staff operation speed and increases the error rate. Engineers would need to hardcode each bank option — extra cost and at least 3 weeks of implementation time.

This image is an example of the PBB flow, not the final design. Please check Designing Pay by Bank for Pay by Link for the final design.

Integrate PBB into the payment link channel while deprioritising PBB on terminal

Pros:Can directly use the API provider on the web environment to save development time. Applying PBB on the user's own device instead of switching between devices better matches the payment context.

Cons: Requires redesigning the Pay by Link checkout flow and coordinating cross-team on terminal deprioritisation messaging.

Results

Roadmap updated

The pivot was successfully reflected on the product roadmap. Instead of having “expand bank options” as the P0 task, the P0 task became “explore integrating PBB into Pay by Link and help business owners understand the benefit of PBB.” The new P1 requirement became deprioritising PBB on terminal for target users — for a better terminal experience and brand reputation.