An open banking payment passes through the merchant's page, the provider's consent screen, the bank's login and back again, and every hand-off loses people. The bank's own login loses the most, because customers land on a web login they've never used. App-to-app redirects, a QR hand-off on desktop, a bank picker that remembers and a return page that survives a lost session fix far more than visual polish does.
The pitch for pay by bank is two taps: choose your bank, approve in your banking app, done. No card number, no 3-D Secure challenge, lower fees. All of that is true, and none of it describes the journey a customer actually takes.
I built consent screens at an open banking provider (the case study has the numbers).
Five hand-offs, three parties
A single payment crosses three owners. The merchant owns the checkout, the provider owns bank selection and consent, and the bank owns login and authorisation. Nobody owns the gaps between them, and the gaps are where people leave:
- 1Checkout to the bank picker.
- 2Bank picker to the consent screen.
- 3Consent screen to the bank.
- 4The bank's login to authorisation.
- 5The bank back to the merchant.
Measure each one separately. A single completion rate hides which gap is losing people, and the answer is rarely the screen you own.
Bank selection is the first exit
The bank picker looks like the easy part. It's a list of forty-odd UK banks, many with separate personal and business entries, shown to someone who just wanted to pay and now has to find their bank in it.
- Order by your own traffic, not alphabetically. A handful of banks cover most payments; put them first as large logos.
- Search that knows aliases. "RBS" should find Royal Bank of Scotland, and "Barclays" should offer both the personal and business entries. Customers type what they call their bank, not its listed name.
- Remember the last bank on that device, and offer it as a single "Continue with Monzo" button. Returning customers skip the list entirely.
- Show a bank outage before the redirect, not after. A customer sent to a bank that is down blames the merchant, and doesn't come back.
The consent screen is legally required, so keep it short
Before the customer leaves for their bank, the provider has to show what they're agreeing to: who is being paid, how much, and the payment reference. The Customer Experience Guidelines set out what must be there. They don't require a wall of legal text.
Show the payee, the amount, the bank and one "Continue" button, with the terms one tap away. This is about attention, not wording: every sentence here is one the customer reads while wondering whether this page is a scam.
The redirect is where people go missing
By default the redirect opens the bank's web login, on desktop and phone alike, and it asks for credentials many customers have never typed: they only ever use the banking app. They don't have them, so they close the tab.
On mobile, the fix is app-to-app. Hand off a link the bank's app has claimed through universal links on iOS or app links on Android, so the customer lands in their banking app, approves with Face ID and is sent straight back.
On desktop, stop sending people to web login at all. A QR code that opens the same consent on their phone turns a credential hunt into the app-to-app path above, while the desktop tab waits for the result.
Don't be tempted to build your own login screen for the bank instead. Collecting bank credentials on a third-party page is screen scraping, which open banking exists to replace, and it trains customers to type bank passwords into pages that aren't their bank's.
Getting back is its own step
A customer can authorise the payment and still never see the confirmation. The bank's app opens the redirect URL in the phone's default browser, often not the browser or tab the customer started in, so the merchant's session cookie isn't there. The return page sees an anonymous visitor and shows a login screen, and the customer assumes the payment failed.
Make the return page work with no session at all. It reads an unguessable payment ID from the redirect, asks the provider for the status, and shows "Payment received" or "Still processing" from that alone, never the order details. The merchant's own records come from the provider's webhook, deduplicated like any other, never from the customer reaching this page. Whether the customer makes it back is a UX problem; whether the payment is recorded can't depend on it.
Re-consent every 90 days
Payments are one-off; data access is a standing consent, and it has its own leak. Under the original strong authentication rules that came with PSD2, a customer who connected their account to an app for balances or transactions had to go through the full bank redirect again every 90 days. Many didn't, and to them the app just stopped working.
The UK changed this in 2022 with the FCA's PS21/19: the bank no longer re-authenticates, and instead the provider asks the customer to reconfirm every 90 days, inside the app, without a redirect. Make reconfirmation one in-app prompt, shown a week before expiry, with the accounts and data listed so the customer can see what they're keeping.
Polish doesn't fix a hand-off
A friendlier loading animation, reworded buttons and brand colours on the consent page are the easy things to ship, and they barely move completion. The customer's problem is rarely that a page looks wrong. It's a step they can't complete, or a hand-off that drops them.