What Is Pay by Bank? A Merchant Guide to Bank-Based Checkout

Pay by Bank is a checkout payment method that lets a customer authorize payment directly from a bank account instead of entering card details. In a typical flow, the customer selects Pay by Bank, chooses a bank, authenticates through a bank-controlled experience, and confirms the payment.

For merchants, the practical question is not just "what is Pay by Bank?" It is whether the target market, supported banks, payment status model, refund route, settlement reporting, and support process are ready for launch.

This guide treats Pay by Bank as one bank-funded checkout option inside a broader alternative payment methods strategy. HaiPay can generally support Pay by Bank, account-to-account payments, and open banking payment methods, but availability is region-specific and depends on local bank coverage, payment rails, and the final implementation plan. Contact the HaiPay team to confirm what is available for your target markets.

What is Pay by Bank?

Pay by Bank is a payment method where the customer approves a checkout payment from a bank account. Instead of typing card details into the checkout page, the customer selects a bank, completes bank authentication, and authorizes the payment.

For a cross-border ecommerce merchant, the useful definition is this:

Pay by Bank is a bank-funded checkout method that can let customers authorize payment from their bank account, while merchants must verify market coverage, supported banks, confirmation timing, refunds, settlement reporting, and support handling before launch.

Pay by Bank is different from a manual bank transfer. The customer is not usually asked to copy account details, enter a transfer reference, leave the merchant site, and wait for a finance team to match incoming funds later. A Pay by Bank checkout flow is designed to connect the checkout action, customer authorization, payment status, and merchant order flow more tightly.

It is also not a synonym for every bank payment. Provider docs, market rules, and payment rails vary. For example, Stripe describes its Pay by Bank implementation as a single-use payment method for customers in the UK and Europe, powered by banking infrastructure and open banking APIs. That is a provider-specific implementation example, not a universal rule for every market or checkout provider.

How Pay by Bank works

The customer-facing flow is usually short. The operational flow behind it is where merchant teams need to pay attention.

In plain language:

1. The customer selects Pay by Bank at checkout.
2. The customer chooses a bank from the available list.
3. The customer authenticates through a bank app, web portal, or other bank-controlled flow.
4. The customer confirms the payment.
5. The merchant receives a payment status and decides what should happen to the order.
6. Finance reconciles the transaction against settlement and reporting data.

The word "status" matters. A merchant should not treat every bank-funded checkout attempt as completed just because the customer started authentication. Depending on the provider and rail, a payment may be confirmed, pending, failed, expired, refunded, or require another resolution path. Stripe's Pay by Bank docs, for example, describe cases where a payment can be authorized but fail if funds are not received within the expected window. Treat that as a reminder to design for exceptions, not as a statement about every provider.

Pay by Bank vs account-to-account payments vs open banking

These terms overlap, but they are not identical. Keeping them separate helps product, finance, and compliance teams ask better questions before launch.

In the United States, open banking discussions often connect to personal financial data rights and authorized third-party access. The CFPB's Personal Financial Data Rights rule is about making covered financial data available to consumers and authorized third parties under defined requirements. That does not automatically mean a merchant can offer Pay by Bank in every US checkout. It means product and compliance teams should avoid treating "open banking" as a generic feature label.

Payment rails are another layer. FedNow, for example, is an instant payment infrastructure from the Federal Reserve that allows participating financial institutions to send and receive instant payments in real time. That does not mean every Pay by Bank checkout settles instantly or uses FedNow. The provider, bank participation, market, and payment method design all matter.

Pay by Bank vs card payments, wallets, and bank transfers

Pay by Bank is easiest to evaluate when it sits next to the methods your checkout already supports.

The point is not that Pay by Bank replaces cards or wallets. For many merchants, the better question is whether Pay by Bank should be added as one option for the right customers, markets, and order types.

Use the comparison table to narrow the decision:

• If customers recognize bank authentication and key banks are covered, Pay by Bank may deserve a test.
• If confirmation timing, refunds, or settlement reporting are unclear, the method needs more provider validation before launch.
• If customers already prefer cards or wallets and would not recognize a bank-selection step, Pay by Bank may add friction instead of reducing it.

Why merchants consider Pay by Bank

Merchants usually evaluate Pay by Bank for practical checkout and operations reasons:

• They want a bank-funded checkout option alongside cards and wallets.
• They sell in markets where bank authentication is familiar to customers.
• They want to reduce manual bank-transfer work and connect checkout status to order handling.
• They want to evaluate payment acceptance economics beyond card rails.
• They want a method that may fit certain high-value, recurring, or bank-preferred customer segments.

The cost argument needs careful handling. A Federal Reserve note on the merchant payments use case says Pay-by-Bank is often presented as cheaper than cards, but also warns that blanket cost-saving claims should be interpreted carefully because merchants may still face setup, transaction, processor, subscription, receiving-bank, security, and compliance costs. In other words: Pay by Bank may reduce some costs in some contexts, but a merchant should compare total cost by transaction value, volume, provider pricing, operational work, fraud handling, and support burden.

The same caution applies to fraud and disputes. Bank authentication may reduce some risks, but Pay by Bank is not immune to fraud, customer confusion, operational failures, or unclear dispute responsibilities. The Federal Reserve note specifically calls out uncertainty around fraud liability and dispute resolution in some deployments. That is exactly why the launch checklist matters.

Where Pay by Bank can create operational complexity

The smoothest customer journey can still create work for product, finance, risk, and support teams. Review these areas before treating Pay by Bank as a default checkout option.

Customer recognition. If customers do not recognize the Pay by Bank label or do not trust the bank-selection step, the method can add friction. Test the label, bank picker, redirect flow, and return-to-merchant page before rollout.

Bank coverage. "Supports Pay by Bank" is not enough. Which banks are supported in each market? Are your most important customer banks covered? Are unsupported banks clearly handled in checkout?

Authentication handoff. Some flows redirect to a bank app or web portal. Product teams need to test browser behavior, mobile deep links, session expiry, and the return path back to the merchant.

Payment states. Your order system needs clear rules for confirmed, pending, failed, expired, and refunded payments. Do not ship only the happy path.

Refunds. Refund behavior is provider-specific. Some providers support partial refunds; others may have limits, status webhooks, or fallback workflows. Verify the exact route before promising a refund experience to customers.

Settlement and reconciliation. Finance needs to know how the transaction appears in reporting, what reference fields are available, when funds settle, how fees appear, and how failed or returned payments are reported.

Support scripts. Support teams need plain-language answers for "Is this safe?", "Why is my payment pending?", "My bank is not listed?", "Can I get a refund?", and "Why did the payment fail?"

What to verify before adding Pay by Bank to checkout

Use this checklist before enabling Pay by Bank payments in a live checkout.

If you are using a checkout provider, ask for documentation on availability, supported banks, payment states, webhooks or callbacks, refund handling, and settlement reporting before adding the method to your checkout roadmap.

Pay by Bank implementation checklist

Before launch:

• Confirm the target market and customer segment.
• Confirm provider availability and bank coverage.
• Test the customer authentication flow on desktop and mobile.
• Define order-state rules for pending, failed, expired, and confirmed payments.
• Define refund rules and support escalation paths.
• Confirm settlement reports and reconciliation fields with finance.
• Prepare customer-support scripts.
• Review compliance, privacy, and customer-protection language.
• Decide whether the method appears for all customers or only selected markets/order types.
• Monitor conversion, abandonment, failure rate, refund rate, support contacts, and reconciliation exceptions after launch.

After launch, review the method as an operating system, not just a button in checkout. A payment method that improves payment acceptance but creates unclear support or finance workflows may still need more configuration.

For the broader method mix, the next step is to review your supported payment methods and decide where Pay by Bank would sit beside cards, wallets, bank transfers, and local methods.

How Pay by Bank fits into an alternative payment methods strategy

Pay by Bank belongs in the bank-funded part of an alternative payment methods strategy. It should not be evaluated in isolation from the rest of checkout.

A practical method mix might include:

• Cards for broad familiarity and coverage.
• Wallets for mobile-heavy and stored-payment behavior.
• Local payment methods for market-specific customer preference.
• Bank-funded methods, including Pay by Bank or bank transfer, where customer bank coverage and operational readiness are strong.

Keep the pillar-page distinction clean. The APM strategy page should explain the whole method mix. This Pay by Bank article should help the merchant decide whether bank-based checkout deserves a place in that mix.

When to use a checkout provider

A checkout provider can be useful when your team needs payment-method coverage, checkout UI, payment status handling, reporting, and integration support in one place. For Pay by Bank specifically, the provider conversation should be precise:

• Which markets are available?
• Which banks are supported?
• What is the authentication flow?
• What statuses can a payment enter?
• How are pending or late payments handled?
• How do refunds work?
• What reconciliation fields are included?
• What support documentation is available?

Explore HaiPay Checkout: checkout implementation

Talk to the payments team: contact HaiPay

Because Pay by Bank, A2A, and open banking payment methods have regional restrictions, do not treat the method as universally available. Use the contact flow to confirm target markets, supported banks, settlement/reporting requirements, and implementation details.

When contacting HaiPay, prepare these details so the payment-method discussion can be concrete:

• Target customer countries or regions.
• Customer location and merchant entity setup.
• Expected order type, value range, and checkout device mix.
• Refund and support requirements.
• Settlement reporting and reconciliation needs.

Pay by Bank may fit when

Pay by Bank may fit when:

• Your target market has meaningful bank coverage and customers recognize bank-based checkout.
• Your product, finance, and support teams can handle pending, failed, expired, refund, and reconciliation states.
• You want a bank-funded option alongside cards and wallets, not a replacement for every payment method.
• Your provider can document supported banks, confirmation timing, settlement reporting, and refund workflow.

Pay by Bank may not fit when:

• Your customers strongly prefer cards or wallets and would not recognize bank authentication at checkout.
• You need instant, universal confirmation across all markets but cannot verify rail or provider behavior.
• Your support team is not ready to explain bank selection, authentication, pending payments, or refunds.
• Your provider cannot confirm availability, bank coverage, settlement reporting, or refund handling.