---

TL;DR:

• Pay by Bank allows customers to transfer funds directly from their bank accounts using their banking app. It relies on open banking APIs and a single regulated PISP to connect merchants with multiple banks securely. Merchants should implement webhook-based order fulfillment and keep fallback payment options during rollout to ensure seamless transactions.

---

Pay by Bank is defined as a payment method that lets customers transfer funds directly from their bank account to a merchant, authenticated through their banking app using biometrics or a passcode. The industry standard term is “account-to-account payment,” and it runs on real-time networks like the UK’s Faster Payments system. This pay by bank tutorial covers everything you need: how the payment flow works, what technical setup is required, how security compares to card payments, and how to avoid the operational mistakes that trip up most merchants during rollout.

Open Banking APIs power the entire process, removing card intermediaries and the fees that come with them. Strong Customer Authentication (SCA) is built into the bank app itself, which means compliance is handled at the source. The result is faster checkout, lower fraud risk, and no card data stored on your servers.

What is the pay by bank tutorial setup process?

Before you accept a single bank payment, your infrastructure needs to be ready. The most common mistake merchants make is treating Pay by Bank like a card gateway swap. It is not. The technical and operational requirements are distinct.

Understanding Payment Initiation Service Providers

A Payment Initiation Service Provider, or PISP, is the licensed intermediary that connects your checkout to the customer’s bank. One regulated PISP covers connectivity, authentication, and regulatory compliance across multiple banks. You do not need a separate contract with every bank your customers use. That single integration point is what makes the method practical at scale.

Technical requirements before going live

Your development team needs to address four areas before launch:

• API integration: Connect to your chosen PISP’s API to initiate payment requests and receive status updates.
• Webhooks: Set up real-time webhook endpoints to receive payment confirmation events from the PISP. This is non-negotiable for safe order fulfillment.
• Deep linking: Configure mobile-first deep links so customers on smartphones are redirected directly into their banking app, not a browser login page.
• Bank coverage mapping: Confirm which banks your PISP supports and communicate any gaps clearly at checkout.

Requirement	Purpose	Who Handles It
PISP integration	Initiates payments and handles bank auth	Developer team
Webhook setup	Confirms payment status in real time	Developer team
Deep linking	Sends mobile users to banking app directly	Developer team
Fallback payment option	Covers unsupported banks during rollout	Product team
Refund/dispute training	Prepares support staff for new workflows	Operations team

Pro Tip: Keep your existing card or digital wallet option active during the first 90 days of Pay by Bank rollout. Bank coverage gaps are real, and losing a sale because a customer’s bank is not yet supported costs more than the processing fee you saved.

How does the pay by bank payment flow work step by step?

The payment process follows a clear sequence. Understanding each step helps you configure your system correctly and set accurate customer expectations.

1. Customer selects Pay by Bank at checkout. The option appears alongside your other payment methods. The customer clicks it and sees a list of supported banks.
2. Customer selects their bank. Your checkout sends the payment request to the PISP, which prepares the authorization request for that specific bank.
3. Redirect or app switch occurs. On desktop, the customer is redirected to their bank’s online portal. On mobile, a deep link opens the banking app directly.
4. Customer authenticates using biometrics or passcode. Face ID, fingerprint, or PIN confirms their identity inside the bank app. No card number is typed. No CVV is entered.
5. Customer reviews and approves payment details. The bank app displays the exact amount and recipient. The customer taps approve.
6. Payment initiates over a real-time network. Funds move instantly through networks like Faster Payments, from the customer’s account to yours.
7. Your system receives a webhook notification. The PISP sends a status event to your webhook endpoint confirming the payment result.
8. Order fulfillment triggers. Your backend processes the order based on the confirmed webhook, not the customer’s return to your site.

Pro Tip: Never trigger order fulfillment based on the customer landing back on your confirmation page. Customers can close their browser mid-redirect. The webhook from your PISP is the only reliable signal that a payment completed.

The distinction between “payment initiated” and “funds settled” matters for high-value orders. Most real-time payment networks settle within seconds, but your fulfillment policy should specify which status triggers shipment. Define this in your backend rules before launch.

What security advantages does Pay by Bank offer?

Pay by Bank changes the fraud equation in a meaningful way. Card-not-present fraud is one of the highest-risk categories in online retail. Pay by Bank eliminates the conditions that make it possible.

No card data, no card fraud

The customer never types a card number, expiration date, or CVV. There is nothing to steal from your checkout page. Skimming attacks, which inject malicious scripts to capture card fields, have no surface to exploit when card fields do not exist.

SCA is automatic

Strong Customer Authentication is handled entirely by the bank app. Biometric verification meets PSD2 compliance requirements automatically. You do not need to build SCA logic into your checkout. The bank does it for you, and it does it at a security level that card networks cannot match at the point of entry.

Pay by Bank satisfies Strong Customer Authentication at the bank level, meaning merchants inherit biometric-grade security without building it themselves. This eliminates card-not-present fraud risk and removes chargebacks from the equation entirely.

No chargebacks

Card chargebacks happen because the card network allows customers to dispute a charge after the fact. Pay by Bank payments are authorized directly by the customer inside their bank app. The customer reviewed the amount and recipient before approving. Disputes still exist, but the chargeback mechanism that costs merchants time and fees does not apply.

Additional security benefits at a glance

• No stored card data on merchant servers, reducing PCI DSS scope
• Payment authorization tied to the customer’s device and biometric identity
• Velocity controls specific to bank payment risk profiles, not card-based fraud rules
• Reduced checkout friction compared to 3D Secure card flows, which improves conversion while maintaining security

Best practices for merchants supporting Pay by Bank

Getting the integration live is step one. Running it well over time requires operational discipline that most guides skip.

• Rely on webhooks, not redirects. Your PISP sends a webhook when payment status changes. Build your fulfillment logic around that event, not the customer’s return URL. A customer who closes their tab after approving payment in their bank app will not trigger a redirect, but the webhook will still fire.
• Define fulfillment rules by payment status. Distinguish between “payment initiated” and “funds confirmed.” For physical goods, ship only on confirmed status. For digital goods, you may accept initiated status given the lower risk.
• Train your support team separately. Refund timelines and dispute processes for bank payments differ from card payments. Your support staff needs a separate playbook. Customers who ask “where is my refund” after a bank payment return will get wrong answers if your team only knows card workflows.
• Monitor bank coverage monthly. Your PISP expands its bank list over time. Review coverage reports and update your checkout messaging when new banks are added.
• Keep fallback options available. Not every customer’s bank will be supported from day one. A customer who cannot pay by bank and finds no alternative will abandon the cart.

Pro Tip: Ask your PISP for a sandbox environment that simulates webhook failures. Testing your system’s behavior when a webhook is delayed or missed is the single most valuable pre-launch test you can run.

How does Pay by Bank compare to cards and digital wallets?

Pay by Bank is not the right method for every transaction. Understanding where it excels helps you position it correctly in your checkout.

Feature	Pay by Bank	Credit/Debit Card	Digital Wallet
Authentication	Biometric via bank app	CVV + optional 3DS	Device biometric
Fraud risk	Very low	Medium to high (CNP)	Low
Processing cost	Low (no card network fee)	Medium to high	Medium
Chargeback exposure	None	High	Low to medium
Settlement speed	Near instant	1–3 business days	Varies
Bank coverage	Growing	Universal	App-dependent
Best for	High-value, repeat customers	Universal acceptance	Mobile-first shoppers

Pay by Bank performs best for high-value transactions where chargeback risk is a real concern, for repeat customers who are comfortable with their banking app, and for businesses where processing cost reduction has a direct impact on margins. It is less suited for one-time guest purchases where the customer may not want to open their banking app for a small-value item.

Businesses in sectors like furniture, electronics, and professional services see the strongest case for Pay by Bank. The average order values are high, fraud risk is elevated, and the cost savings on processing fees compound quickly. For a broader view of how Pay by Bank fits into a multi-method checkout strategy, the right approach is to offer it alongside cards and wallets rather than replacing them.

Key Takeaways

Pay by Bank succeeds when merchants combine a reliable PISP integration, webhook-based fulfillment logic, and a trained operations team before going live.

Point	Details
PISP is the foundation	One licensed PISP handles bank connectivity, authentication, and compliance across all supported banks.
Webhooks drive fulfillment	Trigger order processing from PISP webhook events, never from customer redirect returns.
SCA is automatic	The bank app handles Strong Customer Authentication, satisfying PSD2 compliance without extra checkout logic.
No chargebacks	Bank-level authorization eliminates the card chargeback mechanism, reducing dispute costs.
Keep fallback options	Maintain card and wallet options during rollout to prevent lost sales from unsupported banks.

Why the backend setup matters more than the frontend

Most of the Pay by Bank conversations I see focus on the customer experience: the clean checkout, the biometric tap, the instant confirmation. That part is genuinely good. But the merchants who run into trouble are almost always the ones who underestimated the backend.

The webhook configuration is where real operational risk lives. I have seen businesses go live with Pay by Bank and fulfill orders based on the customer’s return to the confirmation page. When a customer approves payment in their bank app and then closes the browser, the merchant never sees a redirect. The order sits unfulfilled. The customer calls support. It is a fixable problem, but it should never happen in production.

The other thing I would stress is the coexistence phase. Pay by Bank adoption is growing, but it is not universal. Customers who bank with institutions not yet covered by your PISP need another way to pay. Removing cards too early is a mistake. The right model is to present Pay by Bank prominently, let customers choose it when it works for them, and keep the full payment menu available.

Platforms like Sensepass make this coexistence practical. When your payment infrastructure supports Trustly, LinkMoney, Apple Pay, Google Pay, Klarna, and 50+ card processors through a single integration, you are not choosing between methods. You are offering all of them, and letting the customer decide.

The step-by-step integration guide is worth reading before you brief your development team. Getting the sequence right the first time saves weeks of rework.

— Vlad

How Sensepass supports Pay by Bank for retailers

Sensepass connects retailers to Pay by Bank providers Trustly and LinkMoney alongside a full spectrum of payment methods through a single integration layer.

Sensepass integrates with major POS platforms including NetSuite, SuiteCommerce, Oracle Xstore, Aptos, Shopify POS, BigCommerce, Storis, NCR, and Dynamics365. Beyond Pay by Bank, it supports digital wallets like PayPal, Venmo, WeChat, Apple Pay, Google Pay, Alipay, and Amazon Pay; BNPL options including Klarna, Sezzle, ZIP, Splitit, and Afterpay; financing through WeGetFinancing and Affirm; and crypto payments via BitPay and Coinbase. Sensepass is processor-agnostic, giving merchants access to 50+ card processors for maximum flexibility. For retailers building a complete omnichannel payment strategy, Sensepass provides the infrastructure to support every method your customers prefer.

FAQ

What is Pay by Bank and how does it work?

Pay by Bank is an account-to-account payment method where customers authorize a direct transfer from their bank account using their banking app. The payment moves over real-time networks like Faster Payments, with no card details required.

Do I need contracts with individual banks to offer Pay by Bank?

No. A single regulated PISP handles connectivity and compliance across all supported banks. You integrate once with the PISP and gain access to its full bank network.

How do I confirm a Pay by Bank payment was successful?

Rely on the webhook notification from your PISP, not the customer’s return to your confirmation page. The webhook fires regardless of whether the customer completes the browser redirect.

Is Pay by Bank safe for high-value transactions?

Pay by Bank is well-suited for high-value orders. Biometric authentication via the bank app satisfies Strong Customer Authentication automatically, and there is no chargeback mechanism, which reduces dispute risk significantly.

What happens if a customer’s bank is not supported?

The customer cannot complete a Pay by Bank transaction. Always maintain a card or digital wallet fallback option at checkout to prevent cart abandonment when bank coverage gaps exist.

Recommended

• Pay by Bank Integration: A Step-by-Step Business Guide – Omnichannel payments at the Point Of Sale | Sensepass
• How to Add Bank Transfer Options for Retailers – Omnichannel payments at the Point Of Sale | Sensepass
• How to start a payment processing business in 2026 – Omnichannel payments at the Point Of Sale | Sensepass
• Essential Payment Gateway Selection Tips for Retailers – Omnichannel payments at the Point Of Sale | Sensepass