Add pay by bank transfer alongside your existing checkout options.
Your card payment setup works. The question is whether it works well enough when the fees are eating into margin, the chargeback rate is higher than it should be, or a meaningful portion of your B2B buyers would prefer to pay directly from their bank account.
Pay by bank transfer is not a card replacement. It is a checkout option – the model that UK platforms are increasingly offering as Pay by Bank – alongside card and wallet – avoiding card interchange fees (though provider pricing applies), with reduced card chargeback exposure, and Faster Payments settlement in seconds.
Nearly 33 million Pay by Bank transactions were processed in November 2025 alone (Open Banking Limited). In 2026, Amazon UK added it as a checkout option.
This is the implementation playbook. If you have decided to add it and need to know what your engineering team is building – this is that.
“The platforms that add pay by bank transfer successfully are the ones that treat it as a new checkout lane, not a card migration. They keep cards. They add banks. They let buyers choose.” – Yuri, Finexer
TL;DR
Pay by bank transfer is a checkout option powered by Open Banking PIS. A buyer selects their bank, authenticates via SCA in their banking app, and the payment settles via Faster Payments – no card data, no card-style chargeback mechanism, and avoiding card interchange fees (though provider pricing applies). Platforms add it via an FCA-authorised PISP. Engineering scope: bank selection UI, redirect handling, webhook endpoint, refund workflow, and edge case handling. It sits alongside cards – it does not replace them.
When Pay by Bank Transfer Makes Sense
The integration effort is the same regardless of volume. Whether it pays off depends on the use case.
Where it tends to work well
B2B invoice payments. High-value transactions where card fees are disproportionate – the pay by bank vs card cost difference is most visible at this transaction size. No card rewards friction. Settlement speed matters for cash flow visibility.
EPOS and in-store checkout. Platforms adding a QR-code or app-based payment option at point of sale – no card terminal dependency, instant settlement confirmation in the merchant dashboard.
Marketplaces with seller payouts. Buyer checkout and seller disbursement on the same rail. One integration covers both directions.
Donation platforms. High average transaction values, no recurring retry dependency, and reduced card chargeback exposure matters for platforms processing charitable giving.
SaaS first-payment flows. The initial payment on a subscription before the recurring mandate takes over – pay by bank transfer handles the first payment cleanly.
Where it is less suitable
Card-rewards-heavy consumer audiences. Buyers earning cashback or points will often choose cards. Forcing a switch creates friction rather than removing it.
International consumer checkout. Pay by bank transfer is UK-domestic. Non-UK buyers need a different rail.
Subscription-only billing where retry economics matter. Card retry and recovery stacks are mature. Variable Recurring Payments (VRP) are growing as the Open Banking equivalent, but the tooling and bank coverage are not yet equivalent.
The honest position: pay by bank transfer should be offered as a choice, not a mandate. Most platforms that add it see a portion of eligible buyers choose it where it is available – not all of them, and not instantly.
What Your Engineering Team Is Building
Before touching an API, scope what actually needs to be built.
Checkout button. A pay by bank transfer option in the payment method selector, alongside card and wallet. One button with your brand, provider-agnostic.
Bank selection UI. A list of UK banks for the buyer to choose from. This can be hosted by the PISP (faster go-live, less control) or white-labelled into your platform UI (full brand control, more build time).
Redirect handling. The buyer leaves your checkout, authenticates in their banking app, and returns. Your platform handles the return URL and maps the session back to the payment.
Webhook endpoint. The PISP sends a payment confirmation event to your server. The endpoint needs signature verification, idempotency handling, and retry logic for failed deliveries.
Refund workflow. Pay by bank transfer has no automated chargeback mechanism. Refunds are platform-initiated bank transfers back to the buyer. Your platform builds and owns this flow.
Edge case handling. Cancelled payments, failed authentication, partial timeouts, and buyer requesting fallback to card. Each needs a defined UX path.
The engineering surface is relatively contained. Build time varies significantly by stack, team familiarity, and edge case depth – some teams move faster, others take longer. The complexity tends to be in edge cases and integration testing, not the happy path itself.
The 6 Implementation Steps
Each step below maps to a component from the engineering scope above. Steps 1 and 2 are decisions; Steps 3 to 6 are built.
Step 1: Select an FCA-authorised PIS provider
Pay by bank transfer requires an FCA-authorised Payment Initiation Service Provider. The provider holds the regulatory relationship with banks – your platform does not need its own PISP authorisation.
The key evaluation criteria: UK bank coverage (gaps mean lost conversions), white-label flexibility for brand control, webhook reliability for confirmation handling, pricing validated at 12-month volume, and onboarding timeline. Teams that want to go deeper on selection criteria before committing will find Pay by Bank API selection useful at this stage.
Step 2: Choose white-label or hosted bank selection UI
Two approaches:
Hosted UI. The PISP serves the bank selection page. Faster to go live – no UI build required. The buyer sees the provider’s interface, not yours. Acceptable for B2B flows where brand consistency matters less.
White-label UI. You embed the bank list into your checkout using the provider’s component or API. Full brand control over the bank selection and initiation UI – the buyer does not see a third-party page during the selection step. Note: SCA still happens within the buyer’s own banking app regardless of which UI approach you choose. Requires more build time but produces a checkout experience that is visually consistent with your platform.
Most platforms start with hosted, migrate to white-label after validating adoption.
Step 3: Payment Initiation API Call
When the buyer confirms their bank and clicks pay with bank transfer, your backend makes a payment integration via API request to the PISP:
- Amount and currency
- Your payment reference (used for reconciliation – make this stable and unique)
- Return URL for post-authentication redirect
- Webhook endpoint for confirmation events
The PISP returns a redirect URL. Your frontend sends the buyer there.
Step 4: SCA in the Banking App
The buyer authenticates in their bank’s app or web interface using biometric or PIN. Your platform is not in the SCA flow – authentication is handled entirely by the bank. The full Open Banking payment flow from initiation to settlement is useful context for engineering teams building around this step.
This is a feature, not a friction point. The bank’s authentication is the security layer. Your platform does not handle card data, does not run fraud scoring on the payment, and is not in the SCA flow.
After authentication, the bank redirects the buyer back to your return URL.
Step 5: Webhook Handling for Payment Confirmation
Do not rely on the return redirect for confirmation. The redirect happens on the buyer’s device and can fail. The webhook is the authoritative signal.
Verify the signature. Match the payment reference to the session. Mark the order as paid only after a successful webhook, not on redirect. Implement idempotency – duplicate webhook deliveries happen. Process each reference once.
For platforms using Finexer’s payment infrastructure, the payment tracker delivers structured status webhooks with per-payment references – confirmation and retry handling built in.
Step 6: Reconciliation and Receipt UX
Pay by bank transfer produces a clean reconciliation record. The payment reference you set in Step 3 flows through to the bank transaction. If you use structured reference data, matching incoming payments to orders is reliable without manual intervention.
For platforms that have integrated Finexer’s Transaction Enrichment as a separate capability, enriched transaction data – merchant identification, categorisation, structured reference – can make the reconciliation output cleaner for downstream accounting or ERP exports. Enrichment is not automatically part of every payment flow – it is an additional data layer that platforms opt into.
The buyer receipt flow: send a confirmation email or in-app notification once the webhook confirms. Avoid making the buyer wait on the redirect page.
Edge Cases to Handle Before Go-Live
Cancelled mid-flow. The buyer selected their bank but cancelled it in the banking app. Return them to checkout with card options visible. Treat this as an incomplete attempt rather than a failed payment – the buyer did not pay, they simply did not complete the flow.
Failed authentication. The buyer failed SCA in the banking app. Surface a clear message and offer card fallback. Avoid dead-end error states.
Payment timeout. If the buyer takes too long to complete authentication, the payment session expires. Detect this via webhook timeout (no confirmation after N minutes) and prompt retry or fallback.
Refunds. There is no card-style chargeback. Your platform initiates a bank transfer back to the buyer. Build this flow before go-live – it will likely be needed. Ensure your platform retains the payment reference data required to initiate the return transfer.
Disputes. Pay by bank transfer does not have the card dispute mechanism. Your platform owns the dispute resolution process. For B2B flows this is typically fine. For consumer-facing checkout, make sure your terms and refund policy are clear before launch.
How Is Pay by Bank Transfer Different From a Manual Bank Transfer?
Pay by bank transfer via Open Banking PIS is not the same as asking a buyer to manually enter your sort code and account number and make a BACS or Faster Payment themselves.
The key differences:
- Initiation. Manual bank transfer requires the buyer to log into their own bank, enter your account details, and submit the payment independently. Open Banking PIS initiates the payment from within your platform – the buyer authenticates in their banking app, and the payment is sent directly without manual data entry.
- Reference accuracy. Manual transfers frequently arrive with missing or incorrect references, breaking automated reconciliation. Open Banking PIS passes your payment reference through the initiation flow – it arrives with the payment.
- Confirmation. With a manual transfer, you have no way to confirm payment until it appears in your bank statement. With Open Banking PIS, the PISP sends a webhook confirmation near-immediately after initiation.
- Abandonment risk. Manual bank transfers have high abandonment at the point of instruction – buyers who have to leave your checkout to log into their bank often do not return. Open Banking PIS keeps the buyer in your flow through the SCA step and returns them to your confirmation page.
The buyer’s experience of “pay with bank transfer” at a well-built checkout should feel as smooth as a card – not like receiving a PDF with bank details.
What Pay by Bank Transfer Does Not Replace
Platforms add pay by bank transfer alongside their existing options. They do not remove card support.
Cards still matter for: international buyers, card-rewards users, recurring subscription billing with retry logic, and any buyer who simply prefers cards. Wallets still matter for mobile-first audiences who pay with Apple Pay or Google Pay by habit.
The right framing: a new checkout lane with different economics and a different audience overlap. Offer it. Let buyers choose. Measure adoption by use case, not overall checkout volume.
VRP is the recurring payment equivalent of pay by bank transfer – and it is growing. But the commercial VRP stack is not yet equivalent to card retry-and-recovery for subscription billing. Build for today’s capabilities, monitor VRP maturity for future iteration.
How Finexer Supports the Pay by Bank Transfer Integration
Finexer provides FCA-authorised Open Banking PIS infrastructure for the integration described in this guide.
The problems with this implementation of walkthrough surfaces – bank coverage gaps, webhook reliability, white-label UI control, reconciliation complexity, and onboarding timeline – are the specific areas where provider choice changes the build experience.
On coverage: Finexer’s PIS connects to almost all major UK banks through a single API integration. A buyer seeing “your bank is not supported” is a lost conversion. Coverage tends to matter most – gaps mean lost conversions before the checkout flow even starts.
On the webhook reliability problem: Failed or delayed webhook delivery is among the more frequent post-launch issues for pay by bank transfer implementations. Finexer’s instant payments API delivers confirmation near-immediately with retry logic built in – the webhook handler receives a signed event with a stable payment reference, not a polling dependency.
On white-label UI control: Finexer supports white-label bank selection flows. The bank selection and payment initiation UI stays within your platform brand – no third-party branding visible during those steps. SCA authentication happens in the buyer’s own banking app, as it does for all Open Banking PIS flows.
On reconciliation: The structured payment reference that flows through from initiation to bank transaction means reconciliation against orders is reliable. No manual matching for well-structured payment references.
A B2B marketplace added pay by bank transfer as a checkout option for supplier invoices over £500. Within a few months, a meaningful share of eligible transactions were completed via bank transfer – finance teams appreciated the cleaner audit trail compared to card.
- FCA-authorised (FRN 925695)
- 3 to 5 weeks of hands-on onboarding support
- Usage-based pricing, commercial terms agreed based on use case
“The implementation questions we get most often are not about the happy path – it’s about webhook reliability, refund flows, and what happens when the buyer’s banking app crashes mid-authentication. Those edge cases are what determine whether the checkout option works in production, not just in testing.” – Yuri, Finexer
How long does it take to add pay by bank transfer to a platform checkout?
Build time varies by stack and edge case depth. The happy path is generally the smaller part of the effort – edge case handling, refund workflows, and testing across banks typically add more time on top. Provider onboarding (FCA compliance checks) typically takes 3-5 weeks – start that process before the engineering sprint, not after.
Does pay by bank transfer work for recurring payments?
Not with standard PIS. Each payment requires a new buyer authorisation in their banking app. Variable Recurring Payments (VRP) enable recurring bank transfers with upfront consent, but commercial VRP coverage is still developing. For subscription billing, card tends to be the more reliable recurring option in 2026 for most setups.
What happens if a buyer wants to pay with bank transfer but their bank is not supported?
Keep card as a fallback option. A buyer whose bank is not covered should have a clear fallback path, not a dead end. Surface the pay with bank transfer option only after confirming bank availability, or show it alongside the card so the fallback is visible.
Who handles refunds for pay by bank transfer payments?
The platform. There is no automated chargeback mechanism. Refunds are bank transfers initiated by the platform back to the buyer’s account. Build this workflow before going live – it will be needed. Refund processing time via Faster Payments is typically within seconds once initiated.
Add pay by bank transfer to your checkout. See how Finexer’s UK-exclusive focus provides 99% bank coverage without multi-market complexity.
About the Author
Yuri
Yuriy Yakushko is the Founder of Finexer, an FCA-authorised Open Banking platform that enables businesses to access real-time bank data and Pay-by-Bank payments through secure API infrastructure. With more than 20 years of experience in fintech and software engineering, he focuses on building scalable financial technology that helps businesses modernise payments and financial data workflows.