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.

If you run a business that pays card fees on every sale, or you build payment products, the question is whether pay by bank is ready for your checkout. This guide explains how account-to-account payments work under the hood, why US momentum picked up in 2025, the interchange math that motivates merchants, where pay by bank fits best and where it doesn't, the three integration paths builders choose between, and the open issues around disputes, bank reliability, and fraud.

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, and efforts are already underway to interlink instant payment systems across borders entirely. 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 enforced by the Consumer Financial Protection Bureau 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.

Benefits of Pay by Bank

The interchange gap is the headline, but merchants and customers gain in several other ways once money moves directly between accounts. Some of these benefits matter more than the fee saving for particular kinds of business.

Lower cost per transaction

Removing the card network and issuing bank removes most of the fees layered onto each payment. For high-volume, thin-margin businesses such as grocery, fuel, and marketplaces, the difference between a card percentage and a small flat or low-percentage fee adds up quickly across a year. For high-ticket purchases, the saving on a single transaction can be large enough to justify offering a customer discount for paying by bank.

Faster access to funds

Payments over instant rails like RTP, FedNow, Faster Payments, or SEPA Instant settle in seconds rather than the one to three business days typical of card settlement. Merchants can see cleared funds almost immediately, which improves cash flow, reduces the need for short-term financing, and simplifies reconciliation, since each payment arrives as a discrete, confirmed transfer.

Fewer chargebacks and less friendly fraud

Push payments authorised by the customer inside their own bank are generally treated as final once sent. That removes much of the chargeback exposure merchants carry with cards, including disputes from customers who received the goods but claim otherwise. Providers are building refund and dispute processes, but the default position is far less costly for merchants than card chargebacks.

No card data to protect

Because no card number touches the merchant's systems, there is no card data to store, tokenise, or protect at checkout. The customer authenticates with their bank, not with the merchant. That reduces one category of breach risk and the security work that comes with handling card details, though merchants still need to secure their own accounts and integrations.

Fewer failed renewals for subscriptions

Cards expire, get replaced after fraud, or hit limits, and each event can interrupt a subscription. Bank accounts change far less often. Pull-based pay-by-bank billing can reduce involuntary churn from declined or expired cards, which matters for businesses where retention drives revenue and every lost renewal is expensive to win back.

Pay by Bank Use Cases

Not every transaction is a good candidate. Pay by bank tends to work best where the savings are large or the customer is already used to moving money between accounts. The categories below are where merchants and platforms are seeing the clearest return, and where customers are least put off by a bank-login step.

High-ticket purchases

On a large purchase, a card fee of a few percent becomes a significant sum, while a pay-by-bank fee stays small. Furniture, electronics, travel, and education payments are natural candidates. Customers making considered purchases are also more willing to take the extra step of logging into their bank, especially if the merchant passes on part of the saving.

Recurring and subscription billing

Pull-based authorization lets a merchant collect recurring payments in the background once the customer has linked their account. Subscription businesses benefit from fewer failed payments caused by expired or replaced cards, and from lower fees on every renewal across the life of the customer.

Bill pay and utility-style payments

Rent, utilities, insurance premiums, and tuition are already commonly paid by bank transfer. Offering instant pay by bank simply makes an existing habit faster and gives the biller immediate confirmation that funds have arrived, instead of waiting days for an ACH payment to clear.

B2B payments

Businesses already pay each other by ACH and wire. Instant rails speed those payments up and give both sides certainty about timing, easing a friction we cover in why cross-border payments are still expensive. For suppliers waiting on invoices, faster settlement directly improves working capital.

Marketplace and platform payouts

Marketplaces pay sellers, drivers, and creators frequently. Moving those payouts over instant bank rails reduces the number of intermediaries, cuts cost, and lets recipients access earnings faster, which can be a competitive advantage for platforms recruiting sellers or workers who care about getting paid quickly.

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.

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, alongside emerging machine-to-machine payment and agentic payment protocol use cases as agentic commerce grows.

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.

Common Pay by Bank Mistakes

Merchants adding pay by bank often focus on the fee saving and miss the operational details that decide whether customers actually use it. These are the most frequent errors, and most of them show up in the first few months after launch.

Hiding the option at the bottom of checkout

Adding pay by bank as a small link below the card form signals that it is an afterthought, and few customers choose it. Adoption depends on visibility and a clear reason to try it. Merchants who present it as a first-class option, sometimes with a modest incentive, see far more uptake than those who bury it.

Launching without a refund process

Card networks provide a built-in dispute and refund framework. Pay by bank doesn't automatically carry that over, and some providers offer much more than others. A merchant that launches without clear refund handling leaves customer service improvising when a customer wants money back, which damages trust in the new payment method quickly.

Assuming every bank works equally well

Open banking API quality varies, and smaller banks and credit unions have historically lagged larger institutions. Testing only with a few major banks hides failures that customers of smaller institutions will hit. Merchants need to know their provider's bank coverage and monitor completion rates by bank once live.

Ignoring authorized push payment scams

Instant, final transfers are attractive to fraudsters who trick victims into authorising payments themselves. Merchants and platforms that treat pay by bank as fraud-free skip the monitoring and customer warnings that markets like the UK have learned are necessary.

Treating it as a full card replacement

Removing card payments entirely, especially for low-ticket retail, pushes away customers who rely on card rewards and familiar protections. Pay by bank works best as an additional option for the transactions where it fits.

Pay by Bank Best Practices

For merchants and builders adding pay by bank, these practices help capture the savings without hurting conversion or customer trust. They assume you are adding pay by bank alongside existing card payments, which is the right starting point for almost every business, and that you will expand its role gradually as customers adopt it.

• Start with the transactions where savings are largest. Launch on high-ticket purchases, subscriptions, or bill pay first, where the fee difference and customer tolerance for an extra step are both highest.
• Make the option visible and explain the benefit. Present pay by bank alongside cards rather than below them, and tell customers in one line why it might suit them, such as faster processing or a small discount.
• Choose a provider for coverage and dispute handling, not price alone. Check which banks the provider connects to, how authentication failures are handled, and what refund and dispute process customers get.
• Publish a clear refund policy. State how refunds work for bank payments, how long they take, and how customers raise a problem, so support teams aren't inventing answers.
• Monitor completion rates by bank. Track where customers abandon the flow and which institutions fail most often, and raise persistent problems with your provider.
• Add fraud monitoring for push payments. Watch for patterns associated with authorized push payment scams, especially on high-value or first-time transfers, and warn customers where appropriate.
• Keep cards available. Treat pay by bank as an additional rail and let customer behaviour, not policy, decide how much volume moves across. Review the split every quarter to see where incentives are working.
• Plan the upgrade path. Start with an embedded provider button, and revisit a direct aggregator integration once volume justifies the engineering effort and you need more control over the checkout experience.

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, much as the GENIUS Act is doing for stablecoin regulation.

Fraud patterns will shift, not disappear. Removing card networks removes certain fraud vectors (card skimming, card-not-present fraud) but doesn't eliminate fraud, which is why banking fraud detection has to evolve alongside the rails. 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.

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.

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. At checkout, you typically pick your bank, get redirected to its app or website, log in, and approve the specific payment. Some providers let you link your account once so repeat payments, such as subscriptions, don't need a full login each time.

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. For a business with thin margins, the difference between a 2.5% card fee and a small flat or percentage pay-by-bank fee can be significant over a year. Subscription businesses also like it because bank accounts don't expire the way cards do, reducing failed renewals.

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. Merchants can still issue refunds, usually as a transfer back to the original account. What's missing is a consistent, network-wide process for disputes when the merchant won't cooperate, which is where cards still have a clear consumer-protection advantage.

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.

Conclusion

Card fees are a tax most merchants have accepted because there wasn't a practical alternative at checkout. Pay by bank changes that by moving money directly between bank accounts over ACH, RTP, or FedNow, cutting out card networks and much of the interchange that comes with them.

The opportunity is real but uneven. It's strongest for high-ticket purchases, subscriptions, bill pay, B2B payments, and marketplace payouts, where savings are large and customers already think in bank transfers. It's weaker for small, frequent retail purchases where a saved card is faster and rewards habits are sticky. The caveats deserve equal weight: dispute and refund processes aren't standardized, smaller banks' APIs can be unreliable, Section 1033 implementation is still unfolding, and authorized push payment scams follow instant transfers wherever they spread.

For most merchants, the sensible first move is adding pay by bank as an option through a provider's checkout button, then measuring adoption, completion rates, and refund handling before considering deeper integration. If you're building payment flows or integrating an open banking provider into your platform, our API development team can help you design it.