Case Study · 03 of 06

PaidBy: one-tap bank checkout for 4,000+ European banks.

A PSD2-compliant account-to-account payment flow that lets merchants accept money directly from a customer's bank — no card, no Apple Pay, no friction. Designed mobile-first, ported to web and embedded SDK.

Role
Lead Product Designer
Timeline
7 months · 2023
Team
2 designers, 5 engineers, 1 PM
Platform
Embedded SDK · Web · Mobile
PaidBy checkout — multi-device hero

Open Banking is a great idea wrapped in a bad UX.

PSD2 opened up direct bank payments across Europe. The technology works, but most implementations feel clunky — too many redirects, too much fine print, and a UI that screams "regulatory".

Our brief was to design a checkout that converted at least as well as cards, while honouring strong customer authentication, bank-selection logistics, and merchant white-labeling. The output had to ship as an embeddable SDK that partners could drop into their own product.

Designing inside a regulated black box.

Account-to-account payments hand off the user to their bank's authentication flow midway through checkout. That handoff is — legally — outside our control. Our checkout has 30 seconds before the redirect to win the user's trust, and another 10 seconds after to convince them it worked.

Constraint 01

Mandatory regulatory disclosures.

Strong customer authentication, payment-initiation consent, fee disclosure, bank-selection accuracy — all required by law. None of them optional. All of them text.

Constraint 02

4,000+ banks, each with its own auth UI.

We don't control what happens after the redirect. We had to set user expectations precisely enough that the bank screen wouldn't feel like a different product.

Constraint 03

Merchant white-labeling.

The checkout had to look like the merchant's brand, not ours. The design system had to flex without breaking.

Constraint 04

One-handed mobile use.

Over 70% of A2A checkouts complete on phones. Bank-selection has to be thumb-reachable. CTAs always at the bottom. No mid-screen taps.

Four screens, zero surprises.

We compressed the full A2A journey into four screens: amount → choose bank → confirm → success. Each screen has a visible relationship to the next, so users never wonder how far they are.

Highlights

  • Country-then-bank picker with smart defaults based on the user's locale, surfaced as visual logos rather than a long dropdown. Popular banks pinned, IBAN search as a fallback.
  • "You'll be sent to your bank" pre-redirect screen — explains what's about to happen, shows the amount and recipient, and sets the user up for the bank's own auth so it feels like one flow.
  • Status persistence via WebSocket: the post-redirect screen knows in real time whether the payment landed, failed, or expired, with copy tuned for each state.
  • Themeable tokens — merchants override 6 design tokens (color, radius, typography) and get a branded experience without breaking accessibility contrast.
"The first checkout I've installed where I didn't have to choose between brand and conversion." — Head of Payments, UK retailer (integration partner)

The full account-to-account journey.

Out-converting cards on every benchmark we set.

79%
End-to-end checkout conversion (vs. industry A2A benchmark ~60%)
-2.3s
Average time-to-confirm vs. previous flow
4,200
European banks supported at launch
22
Merchants integrated within the first 90 days

What I'd carry forward.

Design the redirect, even if it's not yours. The bank-side auth screen is the part of the journey we touch the least — and the part users remember most. Spending time scripting the moment before the redirect had the biggest single impact on completion.

Tokens are a contract. Once merchants depend on a token, you can't quietly rename it. The next iteration of the SDK shipped a documented token API with semantic versioning.

Accessibility audits early, not at QA. Color contrast on merchant-themed checkouts was the recurring bug. We now ship a contrast linter that runs at theme-load and falls back to a safe palette if the merchant theme fails WCAG AA.

Next Case Study · 04 of 06

Masspay Bulk Payments →

High-density operations console for thousands of payments per day