A Business Guide to Pay by Bank in the UK

Pay by bank lets your customers pay you directly from their bank account in a single tap — no card numbers, no CVVs, no card readers, no chargebacks. It runs on UK Open Banking, which means the money moves from the customer's current account straight into yours through a regulated, bank-grade channel. For most UK businesses it's cheaper than card payments, safer than handling cardholder data, and faster than a BACS transfer.

We've been helping UK businesses take phone and web payments since 2016, and pay by bank is the option we get asked about most often in 2026. The FCA has been pushing Open Banking hard since 2018, and adoption is now at the point where ignoring pay by bank feels like ignoring contactless in 2012. This guide covers what pay by bank actually is, how it works, what it costs, where it fits, and how to add it alongside your existing card payments.

What is pay by bank?#

Pay by bank is a payment method that moves money directly from your customer's bank account to yours, authorised by the customer in their banking app, with no card network in the middle. The customer doesn't type a card number. They don't enter a CVV. They just approve the payment the same way they'd approve sending money to a friend — Face ID, fingerprint, or a PIN inside their own bank's app.

Technically it's a type of Account-to-Account (A2A) payment running on top of the UK's Faster Payments rails, wrapped in an Open Banking API layer. The customer's bank is the one actually moving the money. An authorised Open Banking provider (like the payment gateway your business uses) initiates the request, the bank authenticates the customer, and Faster Payments settles the funds — usually in under 30 seconds, any time of day.

What pay by bank looks like for the customer

They're on your checkout page, on a phone call with one of your agents, or reading a payment link you've emailed them. They click "pay by bank" and pick their bank from a list. Their banking app opens automatically, and the payment details are already filled in — the amount, your business name, a reference. They tap "approve" with biometrics. The app hops them back to your site with a confirmation. Seven seconds, no typing, no card details left lying around.

What pay by bank looks like for your business

The money lands in your bank account almost immediately. There's no three-day wait, no weekend delay, no "pending" state. The transaction fee is typically a fixed pence amount rather than a percentage, which makes it dramatically cheaper than cards for higher-value payments. There's no PCI DSS scope because no card data is involved. And — this is the one businesses care about most once they've been on the receiving end of a few disputes — there are no chargebacks. Once a pay by bank payment clears, it's final.

Why pay by bank is gaining momentum in the UK#

The numbers are hard to argue with. By the end of 2025, UK Open Banking payments had passed 22.1 million users and were running at around 33 million transactions per month, according to Open Banking Limited's monthly tracker. That's up from roughly 9 million users and 14.5 million monthly transactions a year earlier. Variable Recurring Payments (VRPs), the recurring-debit version of pay by bank, are growing even faster.

The growth is being driven by three things: customers find it faster than typing a card number, businesses find it cheaper than card fees, and contact centres find it safer than handling cardholder data. For phone payments specifically, it means agents never have to hear, see, or store a card number — which collapses your PCI DSS scope to almost nothing.

Want to see this working in your setup? Book a working-demo call — we'll wire up your actual phone system and show you a live capture.

How a pay by bank transaction actually works#

The flow looks simple to the customer, but there's some regulatory plumbing worth understanding — particularly if you're going to be selling this internally.

The conversation between your business and the customer's bank happens through Open Banking APIs, governed by the UK's version of PSD2 and overseen by the FCA. A licensed third party called a Payment Initiation Service Provider (PISP) sits between you and the bank. The PISP is authorised by the FCA to ask the bank, on the customer's behalf, to initiate a payment. They never see or hold the customer's bank credentials — those stay between the customer and their bank.

The customer journey, step by step:

1. Choose pay by bank. At checkout, on a payment link, or over the phone with an agent, the customer picks pay by bank as the method.
2. Select their bank. A list of UK banks appears. They tap their own bank and get redirected to the bank's app or web portal. They never enter details on your site.
3. Authenticate. They log in to their banking app the way they always do — fingerprint, Face ID, or password.
4. Confirm. A pre-filled payment summary appears showing your business name and the exact amount. They check it and tap confirm. Nothing to type, so no typos.

The customer never leaves their bank's secure environment for the authentication step. You never see their bank credentials. The diagram below shows the flow end to end.

Payment Initiation Services (PIS) explained — the engine behind pay by bank#

Most pay by bank guides skip over what's actually happening between the customer tapping "approve" and the money landing. That black box matters, because Payment Initiation Services (PIS) are the regulated mechanism that makes the whole thing possible. If you're going to defend the rollout to a finance director or a risk officer, you need to know what PIS is, who's regulating it, and where your business sits in the chain.

Under PSD2 (the EU rule the UK kept post-Brexit) there are two Open Banking service types:

• Account Information Services (AIS). Read-only access to bank account data — balances, transactions, statements. This is what budgeting apps and accounting tools use.
• Payment Initiation Services (PIS). Write access — the ability to instruct the customer's bank to make a payment. This is what pay by bank uses.

A company that provides PIS is called a Payment Initiation Service Provider (PISP). To be a PISP in the UK, you have to be authorised by the FCA under the Payment Services Regulations 2017. The FCA keeps a public register — you can look up any PISP and check they're real before signing anything. As of mid-2026 there are around 80 authorised PISPs in the UK, ranging from specialist Open Banking platforms to the major banks themselves.

How a PIS request actually flows

The technical sequence behind a single pay by bank transaction touches four parties: your business (the merchant), the PISP, the customer's bank (the ASPSP — Account Servicing Payment Service Provider), and the customer themselves. Here's what happens in the 7 seconds between the customer tapping "pay by bank" on your site and the confirmation screen:

1. Your platform calls the PISP API. You pass the amount, the customer's reference, your beneficiary account details, and a redirect URL. The PISP returns a payment authorisation URL.
2. The customer is redirected to their bank. Either the bank's mobile app opens (app-to-app redirect) or the bank's web login page loads. The customer authenticates with Strong Customer Authentication — normally biometrics on the app.
3. The bank shows the pre-filled payment screen. The amount, recipient, and reference are populated from the PIS request. The customer can't change them — only approve or reject.
4. The customer approves. The bank fires the payment onto Faster Payments rails and returns a status to the PISP via webhook.
5. The PISP confirms back to your platform. You get a webhook with the final status — settled, pending, or rejected. The customer's browser is redirected back to your confirmation page.

The whole flow uses OAuth 2.0 plus FAPI (Financial-grade API) profiles. FAPI is a tightened OAuth spec built specifically for financial APIs — mutual TLS, signed JWTs, narrower scopes. It's what stops anyone but an authorised PISP from talking to a UK bank's payment endpoint.

Where your business sits in the regulatory chain

You probably don't need to be a PISP yourself. The vast majority of UK merchants consume pay by bank through a PISP partner — the same way most merchants consume card payments through an acquirer rather than connecting directly to Visa. Your contractual relationship is with the PISP; the PISP's authorisation with the FCA covers the regulatory side.

That said, you do inherit a few obligations under PSD2:

• You can't store the customer's Open Banking consent token for them. The consent lives between the customer and the PISP/bank. You hold a payment reference, not credentials.
• You have to honour customer revocation. If a customer revokes consent for Variable Recurring Payments mid-mandate, your platform needs to stop charging them — same as a direct debit mandate cancellation.
• You're still on the hook for AML and KYC. PIS doesn't replace your own anti-money-laundering checks on the customer or the transaction.

If you're already PCI DSS compliant for card payments, the regulatory delta of adding pay by bank is small. The PISP carries the heavy lifting; you carry the merchant-side controls you already have.

Common PIS use cases beyond simple checkout

The first use case most businesses think of is e-commerce checkout — replacing the card form with a "pay by bank" button. That's the obvious one. The interesting deployments are elsewhere:

• Phone payments via secure link. An agent's on a call. They generate a pay-by-bank PIS request and send the customer a one-tap link by SMS. The customer authorises in their banking app while the agent watches the status update in real time. No card number spoken, no DTMF masking needed because there's no card data to mask. Average handle time drops because the customer doesn't have to find their wallet.
• Insurance first-premium collection. An aggregator quote turns into a bound policy only when the first premium clears. PIS settles in seconds on Faster Payments, so cover can go live the same minute the customer approves. Compare that to a Direct Debit, which takes 3-5 working days to confirm and creates a window where cover exists but money hasn't moved.
• Account top-ups for regulated wallets. Trading platforms, prepaid cards, and crypto on-ramps use PIS to credit accounts instantly without the card-not-present fraud risk that comes with debit card top-ups. The customer's bank authenticates, so the inbound funds are pre-verified.
• Government and council payments. Council tax, fines, MoT renewals — anywhere the amount is fixed and the customer needs to settle quickly. HMRC has supported PIS for self-assessment payments since 2021, which is the largest PIS deployment in Europe by transaction value.
• Variable Recurring Payments for subscriptions. VRP is the PIS-based alternative to Direct Debit and continuous card authority. The customer authorises a recurring payment mandate inside their bank's app, with limits they control (max amount per payment, max payments per period, total cap). The merchant fires individual payment requests against the mandate — same SCA model, just pre-authorised. Commercial VRP launched in the UK in 2025 and is the rails most subscription-led businesses will move to over the next few years.
• B2B invoice settlement. A supplier emails an invoice with a pay-by-bank link. The buyer's finance team opens it, authorises from the company's business banking app, and the supplier sees settled funds the same hour. No card fees on a 50,000 invoice, no waiting for BACS.

Each of these is solving a different problem — speed, fraud, cost, or compliance — but they all share the same PIS plumbing underneath.

Faster Payments rails: what your money is actually riding on#

Pay by bank doesn't run on its own network. It's an Open Banking API layer that hands the actual payment to the UK's Faster Payments Service (FPS). If you want to understand why pay by bank settles in seconds instead of days, you have to understand Faster Payments — because the speed, the reliability, and the limits are all FPS attributes that pay by bank inherits.

What Faster Payments actually is

Faster Payments launched in 2008 as a real-time interbank settlement scheme operated by Pay.UK (the same not-for-profit operator that runs BACS and the cheque imaging system). It runs 24/7/365 — weekends, bank holidays, Christmas Day, 3am on a Tuesday. There's no batch window, no settlement cut-off, no "next working day." A payment instructed at 02:14 on a Sunday lands at 02:14 on a Sunday.

Around 40 banks and building societies are direct participants in FPS. Everyone else — smaller banks, fintechs, credit unions — reaches FPS through a sponsor bank. The end result for the customer is the same: their bank can send and receive on Faster Payments.

The scheme has handled over 4.5 billion payments a year as of 2025, totalling north of 3.7 trillion. It's the rail that consumer payment apps (Monzo's instant transfers, Revolut payments), corporate payments, and most Open Banking transactions ride on.

Why the speed matters for your business

The fact that money lands in seconds isn't just a UX win. It changes several operational things:

• Cash flow is real-time. You can see settled funds in your account before the customer's even off the phone. Reconciliation can happen against your bank feed rather than a delayed acquirer report.
• Refunds clear the same day. If a customer needs a refund, you can push it back over Faster Payments the same minute you approve it — not the 3-5 working days a card refund takes.
• You can use the payment status as a trigger. Settled-funds confirmation can release goods, activate a subscription, dispatch an order, or send a confirmation email — all the same minute the customer approves. No "awaiting payment" limbo.
• End-of-month rush isn't a thing. Because settlement doesn't queue up at a batch cut-off, you don't get the BACS-style end-of-day spike that breaks reconciliation.

Faster Payments transaction limits

FPS has a scheme limit of 1 million per payment as of October 2024 (raised from 250,000 to handle higher-value commercial payments). In practice your customer's bank will impose a lower limit on retail accounts — most UK banks cap consumer Faster Payments somewhere between 25,000 and 100,000 per day, with individual transaction limits varying by channel and customer history.

For most consumer pay-by-bank transactions, the bank's per-customer limit is the binding constraint, not the scheme limit. If you're planning to take larger payments by pay by bank — a deposit on a property purchase, a large B2B settlement — it's worth telling the customer to check their banking app's daily limit before they try. Some banks let customers raise the limit in-app, with a cooling-off period; others require a phone call to the bank.

What happens when Faster Payments is down

FPS is one of the most resilient payment systems in the UK — the scheme reports availability of 99.95%+ each year — but it does have outages. When FPS is degraded, pay-by-bank payments can fail or sit in a pending state until the rail recovers. The fallback options:

• CHAPS for high-value or time-critical payments. Same-day, but only on business banking days and at higher cost.
• Card payments as a backup channel on your checkout. If you offer both, the customer can switch methods if their pay-by-bank attempt fails.
• Retry on settle. Most PISPs queue failed payments and retry once FPS is back. Your platform should surface the pending state to the customer transparently rather than silently retrying.

The Bank of England is also building RT2, the next-generation real-time gross settlement system, due to fully replace the existing RTGS in 2026-27. That doesn't change anything for merchants on the surface — the scheme rules and APIs stay the same — but it's worth knowing about because it underpins the long-term resilience of FPS and CHAPS.

The New Payments Architecture (NPA) — what's coming after FPS

The longer-term replacement for Faster Payments and BACS is the New Payments Architecture, also run by Pay.UK. NPA will consolidate the existing retail payment rails onto a single ISO 20022-based platform. The migration is being phased in through the late 2020s. For pay-by-bank merchants, the practical effect will be:

• Richer payment data on every transaction (longer reference fields, structured remittance data).
• Better reconciliation — ISO 20022 messages carry enough structured data to auto-match payments to invoices.
• Higher transaction limits and improved fraud detection at the scheme level.

None of this is something you need to action today. But if you're picking a PISP partner now, ask them about their NPA migration roadmap — you don't want to pick a vendor who'll be stranded when the rails move.

Strong Customer Authentication, by default

Every pay by bank transaction is covered by Strong Customer Authentication (SCA), the rule introduced under PSD2 to cut online payment fraud. SCA requires two of these three factors:

• Knowledge: something only the customer knows (a password or PIN)
• Possession: something only the customer has (their phone)
• Inherence: something the customer is (a fingerprint or face scan)

Pay by bank hits these by design. The customer logs into their banking app on their phone (possession) and authorises the payment with biometrics (inherence) or a password (knowledge). It's SCA-compliant without you having to bolt anything on.

That's a meaningful difference from card payments, which often rely on static data — a 16-digit number and a three-digit code — that can be stolen and replayed. With pay by bank, the customer pushes the payment from inside their own bank's authenticated session, and once Faster Payments settles it, it's done.

Variable Recurring Payments — the subscription story#

If single pay-by-bank payments are the entry point, Variable Recurring Payments (VRP) are where the model gets interesting for subscription businesses. VRP is PIS for recurring transactions, with the customer pre-authorising a payment mandate at their bank with consumer-controlled limits. Once the mandate's live, the merchant can fire individual payments against it without redirecting the customer back to their bank each time.

It's the closest thing the UK has to a modern Direct Debit, but with three meaningful differences:

• Settlement is real-time. Each individual VRP transaction lands on Faster Payments in seconds. Direct Debits take 3-5 working days and can fail silently if the customer's account doesn't have funds at settlement time.
• The mandate has hard limits the customer sets. The customer agrees a maximum per payment, a maximum per period (e.g. 100 per month), and a total ceiling. The merchant can't exceed those without re-prompting for consent.
• The customer can revoke instantly in-app. Direct Debit cancellation goes through the customer's bank but can be slow to propagate. VRP revocation is real-time — the next payment attempt just fails.

There are two flavours of VRP in the UK as of 2026:

• Sweeping VRP. Same-customer transfers between accounts the customer already owns (e.g. sweeping a current account balance into a savings account). This was the first VRP use case mandated by the FCA and has been live since 2022.
• Commercial VRP. Merchant-to-customer recurring billing — subscriptions, regular invoices, recurring service fees. The commercial VRP scheme launched its first phase in 2025 with utilities, financial services, and government as the lead sectors. Coverage is expanding through 2026 and 2027 as more banks join.

For a subscription business, the calculation is straightforward. Direct Debit costs about 25-50p per transaction with a 3-5 day clearing cycle and a non-trivial failure rate (4-6% of attempts fail because the customer's account is short). Continuous card authority costs 1.5-2.5% on every recurring charge and has the same chargeback exposure as one-off card payments. Commercial VRP charges a low fixed fee, clears the same minute, and fails clean — the customer's bank refuses the payment in real time if there aren't funds, so you know immediately and can ask for an alternative.

VRP isn't yet the right answer for every recurring billing scenario. Some smaller banks haven't enabled commercial VRP, so coverage isn't universal. But for new businesses launching a subscription product in the UK in 2026, it's worth pricing both options before defaulting to Direct Debit.

Why your business should consider pay by bank#

Three reasons, in the order most businesses care about them: it's cheaper, it kills card fraud, and customers actually prefer it.

Lower transaction costs

Card payments come with a stack of fees — interchange, scheme fees, acquirer fees — typically priced as a percentage of the transaction. Pay by bank skips the card networks entirely. The pricing is usually a fixed pence-per-transaction fee, often single digits.

For a business processing 1,000 payments a month at an average value of 150, moving from a 1.5% card fee to a flat 10p pay by bank fee saves around 2,150 a month. The bigger the average transaction, the more dramatic the saving — which is why insurers, B2B services, and high-ticket retailers tend to move first. Our payment processing savings calculator will give you a number based on your actual volumes.

No chargebacks and no card-not-present fraud

Card-not-present (CNP) fraud and chargebacks are two of the most expensive problems a contact centre deals with. Pay by bank removes both:

• No chargebacks. Every payment is authenticated by the customer inside their own banking app. It's a verified push payment, not a card debit. The chargeback mechanism doesn't apply.
• No CNP fraud. No card details are shared, stored, or typed — so there's nothing for a fraudster to steal or reuse.
• Built-in identity verification. For high-value payments — insurance payouts, financial settlements — you know the money's going to a bank account in the verified customer's name.

For contact centres, the bigger win is that agents never see or hear any payment data. That alone changes your risk profile and your PCI DSS obligations.

Pay by bank vs traditional payment methods

A better customer experience

A clunky payment process kills conversion. Pay by bank is mobile-first and takes a few taps — no hunting for a wallet, no 16-digit card number, no expiry date, no CVV. For older customers and anyone who's ever botched a card number, it's genuinely easier.

Two scenarios where this matters most:

• IVR payments. A customer can settle a bill over the phone via an automated flow. The system sends them a secure link, they approve it in their banking app, the IVR confirms — no agent time, no card data over the line.
• Insurance payouts. An insurer can push a claim payment directly into the verified customer's bank account in seconds. At a moment when the customer's stressed, that speed builds real trust.

Security and compliance#

Pay by bank operates under the UK's Open Banking framework and PSD2. The authentication happens inside the customer's own bank, which means the responsibility for verifying the customer shifts to the financial institutions that already do this for everything else they handle. The result is a payment that's harder to defraud than a card transaction, with most of the regulatory burden sitting with the banks rather than you.

What about PCI DSS?

This is the question we get most from contact centres. The pay by bank transaction itself involves no card data — no card number, no CVV, no expiry — so it's outside PCI DSS scope entirely. That's a real cost saving.

The catch: if your contact centre also takes card payments, your environment as a whole still falls within PCI DSS scope. Pay by bank doesn't get you out of compliance, it just moves transactions out of the card-data path. PCI DSS v4.0.1 is the current standard (v3.2.1 retired in March 2024, and the future-dated v4 requirements went live in March 2025), so any contact centre still handling cards needs to be on v4.0.1 now.

The cleanest answer is a single platform that handles both pay by bank and card payments under one compliance umbrella. That way you offer customers the choice without splintering your security posture or doubling your audit work.

How the right platform reduces your compliance load

A unified payment platform does three useful things:

• One security layer for every channel. Card, pay by bank, web, phone, video — same controls, same audit trail, no gaps between systems.
• Massive PCI DSS scope reduction. For phone payments, DTMF masking keeps the card number out of your contact centre entirely. That alone removes most of the systems that would otherwise be in scope.
• Broader compliance, not just payments. A serious platform also meets GDPR and holds certifications like Cyber Essentials Plus, so you're not stitching together half a dozen vendors.

If you want the detail on what PCI DSS expects of different transaction volumes, our guide to PCI DSS levels of compliance covers the four merchant levels and what each one means in practice.

Integrating pay by bank into your contact centre#

Adding a new payment method to a busy contact centre is mostly a planning exercise. The goal is to make pay by bank feel like a natural part of the agent's script, whether they're on a phone call, a video call, or a web chat.

Audit what you've got first

Before adding anything, look at your current payment systems, your telephony (PBX or VoIP), and your CRM. The integration question is really about how those three currently talk to each other and where the new payment method needs to plug in. A turnkey platform that connects telephony, CRM, and gateway in one place is usually a faster path than a bespoke build.

Where to deploy pay by bank

You don't have to roll it out everywhere at once. The three highest-value deployment patterns:

• Agent-assisted payments. An agent generates a secure payment link in real time and sends it via SMS, email, or web chat. The customer authenticates in their banking app, the agent gets an instant confirmation, and the conversation carries on without a card number being spoken.
• Automated IVR. For routine bill payments, a self-service IVR can run the whole pay by bank flow without an agent. Agents only get involved for the calls that actually need them.
• Web chat and video calls. Agents can trigger a payment request inside a chat window or a video call, so the customer doesn't have to switch channels to pay.

For more on how this plays out in regulated environments, see our page on secure payment solutions for contact centres.

A short implementation checklist

Start by defining what you want — lower fees, less fraud, better customer experience, or all three. Pick a partner with real contact centre experience and the right certifications (PCI DSS Level 1 and Cyber Essentials Plus at minimum). Map pay by bank into your existing agent scripts and customer journeys so it feels like a natural option rather than a bolt-on. Configure and test the integrations with your PBX, CRM, and gateway before launch. Brief your agents — the flow is simple but they need to be confident offering it. Then roll out in phases, monitor success rates, and tune from there.

Sector-specific pay by bank use cases worth pricing#

Pay by bank doesn't fit every business equally. Some sectors get a transformational win; others get a modest one. Here's where we see the biggest ROI in 2026, based on the customer conversations we're having:

Insurance

Insurance was an early mover on pay by bank for one reason: the first premium has to clear before cover binds. With cards, the merchant carries CNP fraud risk on day one and a chargeback risk for the policy term. With pay by bank, the premium settles in seconds, cover binds the same minute, and there's no chargeback exposure. Claims payouts run the same rail in reverse — a settled claim can be in the customer's bank account within seconds of approval.

Financial services and lending

Lenders use PIS to pre-fund accounts, disburse loans, and collect repayments. The combination of instant settlement and Account Information Services (AIS) means underwriting and disbursement can happen in one customer session — the lender pulls 12 months of bank statements via AIS, approves the loan, and disburses via PIS, all in under five minutes. VRP is increasingly the rail for monthly repayments.

Utilities and telecoms

For one-off bill payments, pay by bank cuts the cost vs cards and the customer effort vs manual bank transfer. For monthly billing, commercial VRP is starting to replace Direct Debit for new customer onboarding — same monthly rhythm, but faster setup, no 3-5 day clearing wait, and the customer sees the bill amount before each payment.

Government and public sector

HMRC, DVLA, and a growing list of local councils accept pay by bank for tax, fines, and service charges. The driver is cost: card fees on a million Self Assessment payments add up. GOV.UK Pay's adoption of Open Banking has been one of the biggest pay-by-bank deployments in Europe.

B2B and high-value retail

Anywhere the transaction value is above about 500, the card fee maths gets painful and pay by bank starts looking obvious. We see strong adoption in private healthcare, education (tuition fees), professional services (legal invoices), and high-ticket retail (jewellery, motorhomes, fitted kitchens).

Charities and donations

Charities use pay by bank to cut transaction fees on donations — every 1.5% saved is more money going to the cause. Some donor platforms now lead with pay by bank as the default option, with cards as the fallback.

Where pay by bank doesn't fit (yet)

Pay by bank isn't the right answer everywhere. The honest list of where it underperforms:

• Travel and hospitality with pre-auth. A hotel taking a card-on-file deposit, or a car hire firm needing a hold, can't replicate that with pay by bank — there's no hold mechanism on Faster Payments. You either take the full amount up front or stick with cards for the deposit.
• International customers. Open Banking is a UK/EU framework. A US or Asian customer with no UK bank account can't use UK pay by bank. The closest international equivalents (US FedNow, EU SEPA Instant) aren't fully interoperable yet.
• Reward-card-loyal customers. Some customers genuinely prefer earning Avios or cashback on their card. Forcing pay by bank as the only option will cost you those customers.
• Buy-now-pay-later checkouts. If you're offering Klarna or Clearpay, that's the buyer's preferred rail — pay by bank is parallel, not a replacement.

For most regulated UK businesses with a high-value or recurring-payment model, pay by bank is the cheapest and safest rail. For others, it's a useful addition rather than a primary channel. The right question isn't "should we offer pay by bank?" — it's "which payments make most sense to route through pay by bank, and which through cards?"

Time to rethink your payments?#

Pay by bank isn't just another button on the checkout. It's a different way of moving money — direct from the customer's bank, authenticated by the customer's bank, settled in seconds, with no card data anywhere in the path. For regulated businesses and contact centres especially, the maths usually works out: lower fees, no chargebacks, smaller PCI DSS footprint.

The shortlist of what changes:

• Fraud risk drops sharply. SCA is built into every transaction.
• Costs come down. Fixed pence-per-transaction beats percentage-based card fees, especially on higher-value payments.
• Compliance gets simpler. Card data out of the contact centre means PCI DSS scope contracts dramatically.

The honest test is to look at your current payment setup and ask where the cost, the fraud, and the operational pain actually live. If most of it's in card fees, CNP fraud, or PCI DSS audit work, pay by bank is going to move the needle. See how Paytia can help you get started with smarter, safer payments.

Questions we get about pay by bank#

What does pay by bank mean?

Paying direct from your bank account using your banking app, instead of handing over card details. You see a QR code or a link at the checkout, open your banking app, approve the payment with Face ID or a fingerprint — done. No 16-digit card number. No CVV. The money moves from your account to the merchant's in seconds. Technically it's an instant bank transfer, but the experience is closer to tapping Apple Pay than setting up a manual transfer.

What's the difference between pay by bank and a manual bank transfer?

A manual bank transfer puts all the work on the customer. They have to leave your payment journey, log into their bank, and type your sort code, account number, amount, and a payment reference. It's slow and a prime spot for typos that cause reconciliation headaches.

Pay by bank uses Open Banking to handle all of that automatically. The transaction is prepared behind the scenes; the customer just opens their banking app and approves. Faster, safer, no human error.

Is pay by bank instant?

Yes, almost always. Pay by bank transactions run on the UK's Faster Payments Service, so funds land in your business bank account seconds after the customer authorises the payment. That's a real cash-flow improvement over the two-to-three day wait on card settlement.

What is a Payment Initiation Service Provider (PISP)?

A PISP is a company authorised by the FCA to instruct payments on a customer's behalf, under PSD2. When you offer pay by bank, you're either a PISP yourself (rare) or you're consuming pay by bank through a PISP partner. The PISP holds the regulatory licence to talk to UK banks' Open Banking APIs and initiate payments — the customer's bank still does the actual authentication and money movement, but the PISP is the entity that makes the request. You can check any PISP's authorisation status on the FCA register before signing a contract.

What's the difference between AIS and PIS in Open Banking?

Account Information Services (AIS) is read-only — a third party can see your account data (balances, transactions) with your consent. Payment Initiation Services (PIS) is write — a third party can initiate a payment from your account with your consent. AIS powers budgeting apps and lending decisions; PIS powers pay by bank. The two are governed by the same FCA rules under the Payment Services Regulations 2017 but require separate authorisations.

How fast is Faster Payments?

Faster Payments is real-time — typically under 30 seconds end to end, 24/7/365. There's no weekend pause, no overnight cut-off, no batch window. A pay-by-bank payment instructed at 2am on a Sunday lands at 2am on a Sunday. The Pay.UK scheme rules guarantee settlement within 2 hours; in practice, well under a minute is the norm. Most outages are isolated and short-lived; the scheme reports availability above 99.95% each year.

What's the maximum pay-by-bank transaction limit?

The Faster Payments scheme limit is 1 million per payment as of October 2024. In practice your customer's bank will impose a lower per-customer or per-day limit — typically 25,000 to 100,000 for consumer accounts, much higher for business accounts. The binding limit is usually the bank's, not the scheme's. For larger payments, the customer may need to raise their daily limit in-app first.

Can pay by bank be used for recurring payments?

Yes, through Variable Recurring Payments (VRP). VRP lets a customer pre-authorise a recurring payment mandate at their bank, with limits they control (max per payment, max per period, total ceiling). The merchant can then take individual payments against the mandate without redirecting the customer each time. Sweeping VRP (between the customer's own accounts) has been live since 2022. Commercial VRP for merchant subscriptions launched in 2025 and coverage is expanding through 2026.

Which banks support pay by bank?

Almost all of them. HSBC, Barclays, Lloyds, NatWest, Santander, Halifax, TSB, Nationwide, Monzo, Starling, Revolut, First Direct, Metro Bank, and Chase UK all support pay by bank through Open Banking. A handful of smaller building societies and credit unions haven't joined yet, but coverage is close to universal — if your customer has a UK current account and a mobile banking app, they can almost certainly use it.

What if a customer doesn't use a mobile banking app?

Pay by bank works on desktop too. The customer gets redirected to their bank's website to log in and approve the payment. Most UK customers use either mobile or online banking; for the small number who don't, you'd offer another payment option so nobody's locked out.

How does this affect our PCI DSS compliance?

Pay by bank transactions don't touch any card details, so the transactions themselves are completely outside PCI DSS scope. The important caveat: if your contact centre also takes card payments, your environment as a whole is still in scope for PCI DSS v4.0.1. The cleanest answer is a single PCI DSS-certified platform that handles both methods, so your compliance posture stays unified rather than fragmented.

Paytia provides a unified, secure platform to help your business adopt pay by bank alongside traditional card payments, all within a PCI DSS-compliant environment. Explore our solutions at paytia.com.

Related reading#

• Pillar guide: Payment Gateway API Integration: 2026 Developer Guide
• Pay by Link vs Hosted Checkout: Which to Use
• Manual vs Automated Payment Chasing: When to Switch
• How Open Banking Works: Essential Business Guide
• What is click to pay: A Faster, Safer Online Checkout

Want to see this working in your setup? Book a working-demo call — we'll wire up your actual phone system and show you a live capture.