Pay by Bank: Account-to-Account Payments That Bypass Card Networks

Every time a customer taps a card at checkout, roughly 1.5% to 3.5% of the transaction gets skimmed off before the merchant sees a cent. That fee funds the card networks, the issuing bank, the acquiring bank, and everyone else standing between the buyer's account and the seller's. Pay by bank removes most of that chain. The money moves straight from the customer's bank account to the merchant's, no card required, no network in between.

This isn't a new idea — bank transfers have existed as long as banks have. What's new is that pay by bank is finally becoming fast, easy, and secure enough to compete with cards at checkout, rather than being reserved for rent payments and utility bills. That shift is now showing up in real transaction volume, not just pilot programs.

What Pay by Bank Actually Is

Pay by bank, often shortened to A2A (account-to-account) payments, is a checkout method where a customer authorizes a payment to be pulled directly from their bank account, or pushed from it, without a card number, card network, or card-issuing bank involved at any point.

Instead of typing in 16 digits and a CVV, the customer typically:

1. Selects "pay by bank" at checkout.
2. Gets redirected to (or securely connects with) their bank's own login.
3. Authenticates with their bank credentials or biometrics.
4. Confirms the payment amount and merchant.
5. The bank sends funds directly to the merchant's account, often via a real-time or near-real-time rail.

No card number ever touches the merchant's systems. No interchange fee gets carved out. No card network sits in the middle authorizing, clearing, and settling the transaction over a multi-day cycle.

The Rails Underneath

Pay by bank isn't one technology — it's a checkout experience built on top of different underlying payment rails depending on the country and provider:

In markets like India and Brazil, account-to-account payment rails already dominate everyday commerce — UPI and Pix are the default way people pay, not an alternative. The US and UK are earlier in that transition, which is part of why pay by bank is being talked about as a growth story there rather than old news.

How It Works Under the Hood

The mechanics differ slightly by provider, but most pay-by-bank flows rely on one of two connection methods.

Open Banking APIs

The merchant's payment provider connects to the customer's bank through an open banking API, often via an intermediary like Plaid, Trustly, or Volt. The customer logs into their actual bank through a secure, bank-hosted interface (never handing credentials to the merchant or the intermediary), and the API confirms account ownership and initiates the transfer. This is the model most consumer-facing pay-by-bank buttons use today.

Direct Bank Integrations

Some larger merchants or payment processors build direct relationships with banks or banking networks, bypassing third-party aggregators. This is less common for small merchants but reduces intermediary fees further.

Push vs. Pull

There's also a structural distinction worth understanding:

• Push payments: the customer's bank pushes the money out immediately upon authorization. This is how RTP and FedNow transactions typically work — fast, and generally treated as final once sent.
• Pull payments: the merchant (via their payment processor) pulls funds from the customer's account, similar to how a traditional ACH debit or direct debit works. This is more common with recurring billing and subscriptions.

Push payments are becoming the preferred model for one-time checkout because they settle faster and give merchants more certainty that funds have actually arrived.

Why It Matters Now

US pay-by-bank transaction volume nearly doubled in 2025, a jump big enough to move it from a niche checkout option to a line item retailers actively budget for. Two forces are converging to explain that growth.

The first is infrastructure. RTP and FedNow have matured to the point where instant, irrevocable transfers between US bank accounts are genuinely reliable at scale — something that wasn't true even three or four years ago when same-day ACH was the fastest realistic option.

The second is regulatory. Section 1033 of the Dodd-Frank Act, the open banking rule that requires banks to give consumers (and the third parties they authorize) secure access to their own financial data, is phasing in across the US financial system. As banks stand up the compliant data-sharing infrastructure Section 1033 requires, the same pipes that let a budgeting app read your transaction history can be used to authorize a payment out of your account. Compliance work banks were already doing for data-sharing reasons is lowering the cost of building payment-initiation features on top of it.

Put together, the rails got faster and the legal plumbing to move data (and by extension, payment authorization) between banks and third parties got standardized. That's a different situation than five years ago, when pay by bank existed mostly as a cost-saving side option buried at the bottom of a checkout page.

There's also a competitive dynamic at play. As more large merchants add pay by bank as a visible checkout option rather than a hidden one, customer familiarity compounds — each successful transaction makes the next one feel less unusual. That's the same adoption curve card payments themselves went through decades ago, and it's the same curve UPI went through in India and Pix went through in Brazil, both of which went from near-zero to dominant payment methods within a handful of years once the underlying rails and regulatory backing were in place.

Why Merchants Care: The Interchange Math

For merchants, the appeal of pay by bank starts and ends with cost, though it doesn't end there in practice.

Card interchange fees in the US typically run 1.5% to 3.5% per transaction, depending on card type, merchant category, and whether the card is present or not. On top of interchange, merchants often pay additional processor markups, assessment fees, and chargeback-related costs. For a business running on thin margins — grocery, fuel, subscription services — that percentage is not trivial.

Pay by bank transactions typically cost merchants a flat fee or a much lower percentage, often in the range of a few tenths of a percent to around 1%, because there's no card network or issuing bank taking a cut. At high transaction volumes, that difference compounds into real money.

Chargebacks are a particularly meaningful difference. Card networks give consumers a formal dispute process that can result in merchants losing both the goods and the payment. Bank transfers historically haven't had an equivalent consumer-facing dispute mechanism, though this is an area providers are actively building out as pay by bank scales — expect chargeback-like protections to become more standardized as adoption grows, not stay entirely absent.

Practical Implications for Businesses and Builders

For a merchant deciding whether to add pay by bank as a checkout option, the calculus generally comes down to a few concrete questions:

• Transaction volume and margin: high-volume, low-margin businesses (grocery, fuel, marketplaces) feel interchange savings the most acutely.
• Customer base familiarity: younger, digitally native customers and those already using open banking apps adapt to pay by bank faster than customers who've never left the card flow.
• Recurring vs. one-time billing: subscription businesses benefit from pull-based A2A models that reduce failed-payment churn compared to expired or declined cards.
• Refund and dispute tooling: businesses need to confirm their payment provider offers a workable refund process, since the built-in dispute infrastructure of card networks doesn't automatically carry over.
• Checkout friction: redirecting a customer to their bank's login screen adds a step compared to a saved card on file — providers are racing to make that step feel closer to one-click.

For fintechs and payment platforms building on top of this trend, the opportunity looks less like "replace cards entirely" and more like "become the default rail for specific use cases" — bill pay, high-ticket purchases, marketplace payouts, and subscription billing are all areas where the cost and speed advantages outweigh the friction of an unfamiliar checkout flow.

Where Pay by Bank Fits Best

Not every transaction is a good candidate. It tends to work best for:

1. High-ticket purchases where interchange savings are largest in absolute dollar terms.
2. Recurring or subscription billing, where pull-based authorization can run in the background.
3. Bill pay and utility-style payments, where customers are already accustomed to bank transfers.
4. B2B payments, where ACH and wire transfers are already the norm and instant rails simply speed things up.
5. Marketplace and platform payouts, where reducing the number of intermediaries reduces both cost and settlement delay.

It tends to work less well, for now, in low-ticket, high-frequency retail purchases where the friction of a bank-login redirect outweighs the savings, and where customers have strong card-based loyalty or rewards habits they're reluctant to give up.

Integration Paths for Builders

Teams building or buying pay-by-bank capability generally choose between three approaches, each with a different tradeoff between speed to market and control:

• Embed a third-party provider's checkout button (the fastest route): a payments platform handles the bank connections, authentication flow, and settlement, and the merchant simply adds a button alongside existing card options. This is the lowest-effort path but ties the merchant to that provider's coverage of banks and dispute policies.
• Integrate directly with an open banking aggregator's API: gives more control over the checkout experience and pricing but requires more engineering investment to handle edge cases like failed authentications, partial bank outages, and multi-currency accounts.
• Build direct bank relationships: reserved for large enterprises and payment processors with the scale to negotiate directly, cutting out aggregator fees entirely but requiring significant compliance and infrastructure investment.

Most businesses start with the first option and only move toward the second or third once transaction volume justifies the engineering cost.

Real Limitations and Open Questions

Pay by bank's growth story shouldn't obscure the real constraints still in play.

Consumer habit is sticky. Cards come with rewards points, fraud protections consumers understand, and decades of muscle memory. Getting someone to choose a bank-login redirect over a saved card that autofills in one tap is a genuine behavioral hurdle, not just a technical one.

Dispute resolution is less mature. Card networks built chargeback systems over decades. Pay-by-bank providers are still standardizing what happens when a customer disputes a legitimate-looking but fraudulent or unwanted transaction. Different providers currently offer different levels of protection, which makes the experience inconsistent for consumers moving between merchants.

Bank-side reliability varies. Not every bank's open banking API or authentication flow is equally fast or equally stable. A pay-by-bank button is only as good as the weakest bank connection behind it, and smaller community banks and credit unions have historically lagged larger institutions in API maturity.

Regulatory implementation is still unfolding. Section 1033 phases in over several years, with compliance timelines tiered by institution size. Exactly how banks price and gate third-party access to payment initiation — not just data access — is still being worked out, and that will shape how cheap and how open pay-by-bank infrastructure ultimately becomes.

Fraud patterns will shift, not disappear. Removing card networks removes certain fraud vectors (card skimming, card-not-present fraud) but doesn't eliminate fraud. Authorized push payment scams, where a victim is tricked into authorizing a legitimate-looking transfer themselves, are already a known problem in markets like the UK where instant bank transfers are common, and that risk moves with pay by bank as it scales elsewhere.

What to Watch Next

A few developments will signal how far and how fast pay by bank goes from here:

• Section 1033 compliance deadlines as they hit for different bank tiers — larger institutions are required to comply first, which will determine how quickly open banking infrastructure becomes universal rather than partial.
• Major retailer adoption, particularly whether large US merchants make pay by bank a prominent checkout option rather than a buried alternative.
• Dispute and refund standardization across pay-by-bank providers, which will materially affect consumer trust and willingness to switch from cards.
• Bank pricing responses, since some banks may begin charging fees for third-party payment initiation access, which would change the cost equation that currently favors pay by bank over cards.
• FedNow and RTP coverage expansion, since pay by bank's speed advantage depends on how many banks are actually connected to instant-rail networks rather than falling back to slower ACH.

FAQ

Is pay by bank safe?

Pay by bank uses bank-grade authentication (the customer logs in through their own bank's secure interface, not a form on the merchant's site) and encrypted open banking APIs, which generally makes it as secure as online banking itself. The bigger open question isn't the security of the connection but the maturity of dispute and refund processes if something goes wrong after a legitimate authorization.

How is pay by bank different from a debit card?

A debit card payment still routes through a card network (Visa, Mastercard, etc.) even though the money ultimately comes from a bank account, which means interchange fees and network rules still apply. Pay by bank skips the card network entirely, moving funds directly between bank accounts via ACH, RTP, or FedNow.

Do I need a card to use pay by bank?

No. Pay by bank only requires a bank account and the ability to log into that bank's online or mobile banking to authorize the transaction. There's no card number, expiration date, or CVV involved anywhere in the flow.

Why are merchants pushing pay by bank at checkout?

Mainly cost. Card interchange fees typically run 1.5% to 3.5% per transaction, while pay-by-bank fees are usually a fraction of that, plus settlement can happen in seconds rather than days, which improves merchant cash flow.

What is Section 1033 and why does it matter for pay by bank?

Section 1033 is a Dodd-Frank Act provision requiring US banks to give consumers, and third parties consumers authorize, secure access to their own financial account data. As banks build the compliant infrastructure this requires, it lowers the technical and legal barriers for payment-initiation services like pay by bank to connect to bank accounts.

Can I get a refund with pay by bank the same way I can with a credit card chargeback?

Not automatically in the same way. Card networks have decades-old, standardized chargeback rules; pay-by-bank refund processes vary by provider and are still being standardized, so it's worth checking a specific merchant or provider's refund policy before relying on it for large purchases.

Will pay by bank replace credit and debit cards?

Unlikely to replace them outright, at least in the near term, given how embedded card rewards and consumer habits are. It's more likely to become a standard alternative option at checkout, capturing a meaningful share of transactions, particularly high-ticket purchases, subscriptions, and bill pay, while cards remain dominant for everyday small purchases.

Businesses evaluating whether to add pay by bank to their checkout stack, or banks navigating Section 1033 compliance, can work through the integration tradeoffs with Woyce Technologies.