Pay by Bank in Pay by Link

Background

Pay by Bank lets customers pay directly from their bank accounts, without using cards. It is a cost-effective option for both consumers and businesses. Kody first brought this technology into the in-person experience through its terminal product.

The terminal launch did not get good market feedback. Two months in, it was clear that Pay by Bank did not fit the busy offline checkout environment because it is a context-sensitive payment method. I analysed the problem and identified Pay by Link as a payment channel better matched to PBB's strengths.

Who is the user?

Link creation is manager-level work, and link payment happens between the payer and their bank.

Finding and defining the opportunity

Looking again at the interviews through the lens of Pay by Link surfaced four themes. I separated them with one question: which can design actually move?

• Merchants don't know Pay by Bank saves them money. The launch communication reached business owners, not the operation managers who actually create links.
• Payers default to card or Apple Pay. Familiar methods win when there is no reason to consider an alternative.
• The £40 minimum. Merchants don't want it and don't fully understand it.
• No chargeback. Unlike cards, Pay by Bank can't be reversed, which creates a potential trust concern for payers.

Merchant fee saving awareness

Pay by Bank can save merchants around 60% in transaction fees by removing interchange fees and card scheme fees. Most merchants did not realise this.

Part of the reason was organisational. Manager levels differ across companies, and the first launch communication often reached only the business owner, not the payment link operators or managers who create links day to day.

Rather than putting all the effort into marketing, the opportunity was to make the saving visible at a moment when the merchant could act on it.

Earning the payer's choice, then their trust

The opportunity was to design the two moments that decide whether a payer chooses Pay by Bank and completes it: the moment of choice on the landing screen, and the moment of finding their bank.

Moment 1: The landing screen

A Pay by Link page offers multiple payment methods. Payers follow muscle memory and reach for card or a digital wallet. UK consumer familiarity with the term "Pay by Bank" was cited as 38%, so unfamiliar wording pushed people back to methods they recognised.

I could not change Apple Pay and Google Pay buttons because they render as components defined by the platform. What I could control was how much visual weight the Pay by Bank block carried.

Moment 2: Choosing a bank

Before designing the bank list, one decision came first: should bank selection be its own screen? I prototyped three simple approaches to feel the difference in flow.

Approach 01

Bank list inside the Pay by Bank card

Fewest steps. But it flattens two decisions of very different weight — choosing a method and searching across more than 60 banks — onto one screen, competing for attention.

Approach 02

Popular banks on the first screen, rest on a second screen

Fast for common banks. But it splits bank selection across two screens, and the variant step still has to land somewhere.

Approach 03Selected

Bank selection as its own dedicated screen

One more step. But each screen asks for one kind of decision: pick a method, then pick a bank.

Provider constraint

Yapily returns a flat variant list

"Monzo Personal" and "Monzo Business" are separate entries. Collapsing them into one entry per brand would need a maintained mapping and ongoing upkeep that the beta timeline did not allow.

Designing the list

I used the variant list directly: no aggregation and nothing to maintain. To make it usable, the 9 most used personal account variants were pinned to the top, with the rest in an alphabetical list below. Every row behaved the same way: tap a variant, it is selected.

Kody's transaction data showed 87% of Pay by Link payments came from merchant categories where payers are overwhelmingly individuals, so personal account variants were the pragmatic first priority.

Designing for the wrong choice

The flat list made one failure predictable: a payer choosing the wrong variant, such as personal instead of business. The cost of that is not one lost payment; it is a payer who walks away believing Pay by Bank does not work.

The error copy names a neutral mismatch and routes them straight back to the bank picker with Pay by Bank still selected. For payers who had already left, email and SMS bring them back to the same link, framed as finishing an open payment rather than retrying a failed one.

Original error EOP

PBB Error EOP

All error scenarios led to this general error page

Instead of a single generic error page that gave users no useful information, I worked with engineering to identify two scenarios that happen most often — and designed for each separately

Time lag between the API and the bank's response

Authorisation with wrong account type

Rapid prototype with AI help, kept realistic for implementation

The web payment link design was missing from the design library, so I started from the existing Pay by Link checkout HTML to generate the correct design file. I used Claude Code to create initial PBB flows on top of the current UI system, then iterated in Figma on hierarchy, nudges, and bank selection patterns.

Final design

Here is the full shipped flow, from a merchant creating a link to both sides seeing the payment settle.

kodyuniverse.com/payments/new

Merchant creates a payment link for an amount above £40

Payer receives the link by email or SMS, opens it, chooses Pay by Bank, and selects their bank

Connect to the bank app

Payment completed — the payer sees confirmation

mail.google.com

Payer also receives a digital receipt by SMS and email

kodyuniverse.com/payments/links/overview

kodyuniverse.com/sales

Merchant can track the payment link's status in Kody Universe

1. Select Pay by Bank by default and highlight fee saving for merchant understanding

Pay by Bank is selected as one of the payment methods by default, and the fee saving benefit is surfaced during payment link creation.

Copy & framing

“Save 60% in fees” — Highlight fee savings to drive Pay by Bank adoption

Interaction model

Auto-deselect Pay by Bank when eligibility requirements aren't met (e.g., payment below £40) — showing it deselected, with the reason, teaches them the rule

2. Launch message through Intercom and email to reach the right merchants

Intercom (inside Kody Universe) and email together targeted operation managers — the people who actually create links — rather than relying on business owners to pass information down. The two channels carry the same information in different shapes: Intercom leads with a visual hero for fast scanning; the email is structured for closer reading.

3. Remember the customer's previous bank

Returning customers can reuse their previous bank selection, reducing steps and making Pay by Bank feel faster on repeat payments.

Interaction model

First-time payer: Pay by Bank is pre-selected and visually led, with bank logos shown to build recognition

Interaction model

Returning payer: their previous bank is pre-filled to speed up Pay by Bank

4. Streamline flow to select banks and complete authorisation

The bank selection and Open Banking authorisation steps are consolidated into a single guided flow, reducing drop-off at the most unfamiliar part of the checkout.

Visual hierarchy

The 9 pinned banks at the top are personal variants, covering the majority of payers without changing the interaction model.

Visual hierarchy

The rest of the bank options are listed in alphabetical order.

5. Confirmation, status tracking, and refund handling

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

For Customer

Text message

Email notification

Email result

Within one month of shifting focus to Pay by Link

Reflection