Pay by Bank vs Card Payments: What the Comparison Actually Costs You

Most merchants comparing pay-by-bank vs card payments expect to find a fee table with a clear winner. What they find instead is a rail decision with consequences that run through their refund operations, reconciliation logic, and fraud exposure long after the integration is live.

The fee savings are real. But they sit inside a more complicated picture than the headline numbers suggest. This article is written for those evaluating whether to add pay by bank alongside cards and those who need to make this case credibly to their merchant customers.

The episode of Fintech Garden, DashDevs’ fintech podcast, is out. Johannes Kolbeinsson, co-founder and CEO at PAYSTRAX, joined the show for a conversation that will feel familiar to anyone who has been watching the A2A payments space closely. The promise is real, the friction is also real, and the honest answer about who benefits is more specific than most vendors let on. Listen to Podcast 167 with Johannes Kolbeinsson.

That’s why we’ve prepared an infrastructure-layer companion to that conversation—what the rails actually do once the strategy decision is made.

What is pay by bank? How it differs from card payments

Pay by bank (also referred to as account-to-account payments or A2A) is a transaction initiated directly from a customer’s bank account, routed over ACH or instant payment rails, and settled directly into the merchant’s bank account. No card network sits in between. For a broader A2A primer, see our guide to account-to-account payments.

That distinction matters more than it might appear. In a standard card transaction, the payment between a customer’s issuing bank and a merchant’s acquiring bank is authorized, cleared, and settled through a card network intermediary (Visa, Mastercard, or equivalent). Each party in that chain takes a fee. The card network enforces the rules for disputes, chargebacks, and consumer protection.

Pay by bank removes the network intermediary entirely. The payment flows through open banking infrastructure, facilitated by third-party service providers that handle initiation, authentication, consent, and processing via banking API connections between the merchant, the customer’s bank, and the merchant’s bank.

A few things pay-by-bank is not, which often confuses bank payments vs. card payments discussions:

• It is not a digital wallet. Most digital wallets (Apple Pay, Google Pay) still fund transactions via a linked card. They route over card networks.
• It is not a wire transfer, which is a separate high-value, high-fee instrument.
• It is not identical to a SEPA Credit Transfer in isolation, though European PIS under PSD2 uses SEPA rails as its settlement mechanism.

The underlying rail (ACH for deferred settlement, FedNow, or RTP for instant settlement) determines the cost structure, the finality of the payment, and crucially, what happens when something goes wrong.

A good test for new payment methods is simplicity. Is it simple? And then—do your kids use it? Do your parents use it? I’ve never seen my parents using account-to-account. They scratch their head and say, ‘No, no—I’m just going to use my card.’ — Johannes Kolbeinsson, Fintech Garden

Johannes is not making a dismissive argument. He is making the correct one. Consumer trust is load-bearing infrastructure. The mechanics of the rail are irrelevant if adoption does not follow.

Pay-by-bank vs card payment fees: total cost compared

The claim that pay-by-bank vs pay by card produces savings of 40–85% for merchants comes from vendor estimates (Plaid at the lower end, Adyen at the higher) that model specific high-order-value scenarios. The Federal Reserve’s July 2025 analysis of the merchant payments use case is direct: a blanket claim of significant cost savings from switching to pay-by-bank at the POS should be interpreted with care.

The reason is structural. Card fees are percentage-based. Pay-by-bank fees are flat per transaction. Those two models produce different answers depending entirely on your order value.

Card payment costs

Credit card and debit card fees both run through the same network structure, but at different rates.

• Processing rate: 1.5–3% of transaction value in total card processing fees.
• Interchange: the fee paid to the card-issuing bank, making up 70–90% of that total.
• Network and acquirer costs: assessment fees, acquirer margins, and gateway or processor fees stack on top of interchange, adding to total processing costs.
• Chargebacks: a reversal of funds plus a dispute fee (typically £15–£100 per case) and staff time to contest.

The percentage-of-value model means card fees scale directly with ticket size. A £500 transaction at 2% costs £10 in fees; a £5,000 transaction costs £100. At low order values, the percentage is manageable; at high order values, it becomes a real line item. Merchants with chargeback rates above roughly 1% face “high-risk” designations that trigger stricter compliance requirements or account termination.

Pay-by-bank costs

Pay-by-bank does not eliminate fees on pay-by-bank transactions; it restructures them. Merchants typically pay:

• Setup and integration fees to the open banking third-party provider.
• A flat per-transaction fee to the provider—not a percentage of value.
• Receiving bank service fees.
• Rail operator fees—ACH (FedACH) and instant rail (FedNow) both publish flat per-transaction fee schedules.

The absence of interchange and network assessment fees is real. But the flat-fee structure means the per-transaction cost, as a percentage of value, falls as order value rises—and rises as order value falls.

The crossover point

At order values above roughly £200/$250 (depending on your specific provider rates), flat-fee pay-by-bank economics start to pull ahead materially. Below that threshold, the advantage narrows or disappears. For high-volume, low-ticket merchants, the per-transaction fee can match or exceed what they pay on card rails today.

Payment orchestration across multiple rails is where this cost logic becomes operationally manageable, routing by transaction value, geography, and risk profile rather than committing a single rail to every transaction type.

How refunds work: pay by bank vs card payments

This is the dimension of the pay-by-bank vs card payments comparison that most vendors omit and the one that most often surprises merchant operations teams post-integration. The refund mechanics on each rail are structurally different, not just procedurally different. That gap has direct consequences for customer experience, fraud exposure, and how finance teams close the books.

How card refunds work

When a customer requests a refund on a card transaction, the merchant initiates a reversal through their acquirer. The acquirer processes it through the card network, which instructs the issuing bank to credit the customer’s account. The timeline is typically 3–10 business days. The chargeback route adds a consumer protection layer: a customer can dispute a transaction directly with their issuing bank without involving the merchant first, and the card network arbitrates.

That consumer protection is not free. Merchants have been hit with a noticeable surge in chargeback-related losses, driven largely by what the industry calls “friendly fraud”—a challenge Johannes put clearly in our Fintech Garden conversation.

80% of the fraud figures are actually friendly fraud. Friendly fraud is where I make a transaction myself and then later say, ‘This was a mistake; I don’t want this,’ but I did the transaction. The merchant has no chance to defend themselves. It’s not a fair system where you can just press a button and all of a sudden you’re regarded as a fraudster. — Johannes Kolbeinsson, Fintech Garden

He went further. PAYSTRAX commissioned a survey of 1,000 UK cardholders and found that among adults under 30, some described chargeback abuse as “beating the system”—ordering a product, receiving it, and still filing a chargeback. That is not a rounding error in fraud statistics. It is a structural cost of the card model’s consumer protection design.

How pay-by-bank refunds work

There is no reversal mechanism for push payments on ACH or instant rails. When a merchant receives a pay-by-bank payment, the funds have moved from the customer’s bank account to the merchant’s bank account. If the customer requests a refund, the merchant must initiate a new, separate outbound credit payment back to the customer.

On instant rails (FedNow, RTP), this is compounded by finality: instant payments are irrevocable once settled. There is no “pull back.” The refund is an entirely new transaction, initiated by the merchant, routed as a new payment, and reconciled separately from the original.

The Federal Reserve’s July 2025 note explicitly flags the dispute resolution gap: some deployments do not clearly outline whom a customer should engage with to initiate and resolve a dispute, with liability shifting between the bank, the third-party provider, and the merchant. There is no card-network-equivalent consumer protection escalation pathway.

What this means for operations

Pay-by-bank removes the chargeback. It does not remove the refund. Finance teams that discover this post-integration have a reconciliation problem, not a payment problem.

For high-refund businesses (fashion retail, travel, consumer marketplaces), the operational friction of managing A2A payments refund is a real cost that must sit alongside the fee savings calculation. Each refund requires:

• An outbound payment initiated by the merchant
• A refund reserve to fund those payments before the original settlement is redeployed
• Reconciliation logic to match outbound refund credits against original inbound transactions—a task that card rails handle with structured data; A2A rails handle less consistently

For low-refund businesses (utilities, SaaS subscriptions, B2B invoicing), this friction is minimal. The chargeback elimination is a clear gain with little operational offset.

Is pay by bank secure? Risk comparison with card payments

The honest framing is not “pay by bank is more secure than cards.” It is that the two rails carry different risk profiles, with different merchant-side and consumer-side exposures.

Pay-by-bank security advantages

Pay-by-bank initiation typically requires multi-factor or biometric authentication—the customer logs into their banking app, confirms the payment amount and merchant details, and may enter a one-time code. This is harder to spoof than a stolen card and PIN, reduces the card-not-present fraud surface area, and reduces NSF-driven chargebacks.

Fewer intermediaries also means fewer potential compromise points in the transaction chain.

Pay-by-bank security risks

The Federal Reserve’s July 2025 analysis supplies the data the vendor-authored SERP does not. Among US adults surveyed, 56% cited security and trust concerns as their top reason for not using open banking payments. It reflects real unfamiliarity with third-party provider interactions during authentication and genuine concern about data privacy when a TPP accesses bank account information via API.

Third-party provider risk is real: open banking providers vary significantly in their security architecture and compliance posture. Instant rail fraud deserves specific attention. Because instant payments are final and irrevocable, authorized push payment (APP) fraud is unrecoverable without merchant cooperation. Regulatory liability rules for open banking payment disputes remain, as the Fed notes, not always transparent and clear.

Card payments: for balance

Cards carry their own structural vulnerabilities: card-not-present fraud in e-commerce, compromised card data at scale, and the chargeback fraud dynamic noted above. Tokenization and 3D Secure reduce but do not eliminate exposure.

The practical difference is that card dispute and fraud resolution frameworks are mature and defined. Pay-by-bank frameworks are functional but uneven across deployments.

Where pay-by-bank works today: UK, EU, and US rail maturity

A merchant’s geography determines whether adding pay-by-bank is a decision they can execute this quarter or a strategic position on an ecosystem still maturing. Here is the line clearly drawn.

UK and EU: a now-decision

PSD2 mandated open banking APIs from major banks across the EU and UK. Payment Initiation Services (PIS) operate within a defined regulatory and liability framework. Faster Payments in the UK and SEPA Instant across the EU provide instant settlement rails at a meaningful scale. Consumer familiarity is higher than in the US. The regulatory consumer protection framework (including defined dispute resolution pathways) is in place.

For UK and EU merchants evaluating bank payments vs card payments, the infrastructure question is largely resolved.

The decision is commercial: does your transaction profile justify the integration? For merchants in markets like the Netherlands, Johannes noted on the podcast that iDEAL has seen a resurgence in the past two years—a signal of what mature open banking rails can achieve once the user experience catches up.

For merchants building across the best online banking platforms in this environment, the connectivity layer is real and scalable. Choosing open banking providers still matters for coverage, consent UX, and liability clarity.

US: a strategic bet on a maturing ecosystem

FedNow launched in July 2023 and is still scaling—not all banks participate. The Clearing House’s RTP network has broader participation (live since 2017) but is not universal. The CFPB’s Section 1033 rule creates an open banking framework, but implementation across financial institutions is ongoing.

The pay-by-bank adoption statistics from the Federal Reserve’s July 2025 note make the picture concrete:

• Approximately 11% of US adults have completed at least one open banking payment transaction in the past year, with instant-rail transactions built to settle instantly rather than over the multi-day ACH window.
• Willingness to adopt is higher among younger consumers—72% of Gen Z and 66% of millennials—suggesting the trajectory is real, but the current conversion base is limited.

Walmart’s partnership with Fiserv to offer instant pay-by-bank for online purchases, announced for 2025 deployment, is a significant signal that large retailers are willing to build for this rail. It’s an early-mover position, not established infrastructure.

For US merchants right now, adding pay-by-bank is a forward-looking integration decision. The economics work in specific transaction profiles; consumer adoption requires either incentivizing the switch (merchant discounts, which affect the cost calculation) or targeting the segments most likely to use it.

When to use pay by bank instead of cards: decision framework

The honest answer to the pay by bank vs pay by card question is not “offer both as a payment option and hope customers sort it out.” It’s a set of specific criteria tied to your transaction profile.

Four criteria to run your own assessment:

1. Order value — Above roughly £200/$250, flat-fee rail economics start to pull ahead of card-percentage fees in a way that justifies integration costs. Below that threshold, model the crossover against your actual provider rates before committing.
2. Refund rate — Above roughly 5%, the operational cost of A2A refund management (outbound credit payments, refund reserves, and reconciliation) may offset fee savings. Low-refund businesses get the cleaner version of the value proposition.
3. B2B vs B2C — B2B buyers are less attached to card rewards. Authorization friction—the redirect to a banking app—is more acceptable in a professional procurement context. Dispute risk is lower. The case for card vs bank transfer payments tilts toward bank transfer faster in B2B than in consumer commerce.
4. Geography — UK and EU merchants have infrastructure and regulation today. US merchants are making a forward-looking bet. The right question for US merchants is not “Should we add pay-by-bank?” but “Which transaction types in our mix should route over bank rails, and for which segments?”

Fintech API connectivity across payment rails requires this kind of segment-level analysis before the build starts—the integration architecture follows the routing logic, not the other way around.

How to add pay by bank to your checkout: integration requirements

The scope of a pay-by-bank integration is consistently underestimated. Teams that approach it as a payment method toggle discover quickly that they have changed their refund architecture, their fraud logic, and their reconciliation pipeline. The integration list is longer than the checkout flow suggests:

1. Open banking provider selection — The TPP layer determines which banks your customers can pay from, what the authentication UX looks like, and what data you receive at settlement. Coverage, uptime SLAs, and security posture vary materially—this is a meaningful decision, not commodity procurement. See our guide to integrations with open banking providers.
2. Authentication and consent flow — Redirect (customer leaves your site to their banking app) vs embedded (inline authentication within checkout) affects conversion rate. Redirect is more universally supported; embedded requires deeper integration with individual bank APIs via fintech integration services.
3. Refund logic — An outbound payment flow has to be built specifically for refunds—a separate integration from the inbound payment flow—including refund reserve management and trigger logic for when refunds fire.
4. Reconciliation architecture — Card transactions arrive with structured data (authorization codes and network reference numbers) that match easily to orders. A2A transactions need a different matching approach, typically payment references embedded in the transaction or webhook-based confirmation events, handled natively rather than as a workaround.
5. Webhook and event handling — Settlement confirmation on ACH is deferred. On instant rails, it’s near-real-time. The system has to handle both, plus settlement failures and retries, without creating double-processing risk.
6. Fallback routing — Not every customer’s bank sits in the open banking network, and not every connection succeeds. A fallback to a card (or another rail) needs to be designed into the checkout flow from the start, not bolted on after go-live.

The build decisions here connect directly to payment gateway services and card issuing services. Understanding what you are adding—pay-by-bank, alongside other shapes—and how the integration is scoped from the start matters. Our custom software development approach treats this sequence as a production system, not a checkout toggle. The scope is knowable, but only if you have seen where it breaks in production.

What we’ve learned building pay-by-bank integrations

Refunds are usually the first surprise. There is no network reversal to lean on, so partial refunds, split payments, and delayed refunds all need their own logic—something teams tend to discover after launch, not before.

We saw this play out building a payment orchestration platform for a European BNPL provider. Cards, wallets, and A2A payments (including BLIK) had to run through one routing layer, handling 10,000+ requests per second during peak periods, while giving the client actual control over repayment cost and timing. The real work was not the bank rail. It was everything around it.

Regulation does not make integration simple either. On Tarabut, one of MENA’s first regulated open banking platforms, the framework was clear from day one, but every bank connection still had its own quirks and consent flow. Worth keeping in mind for the UK/EU vs US comparison above: a mature rulebook does not mean a uniform build.

Fallback routing matters more than it gets credit for. If a bank’s API times out, checkout should quietly fall back to card. It is often the last thing teams build and the first thing that breaks in production.

And reconciliation is usually where the real effort goes. Not glamorous, but it is the piece most often missing when a merchant goes live.

We have built both sides of this: regulated open banking infrastructure and multi-rail orchestration designed to scale. If you are scoping a pay-by-bank build and want a second pair of eyes on the refund and reconciliation architecture, that is a conversation we have often—get in touch.

The bottom line

The benefits of pay-by-bank payments are real: lower fees at high order values, no chargebacks, faster settlement on instant rails, and a cleaner cost structure for recurring B2B payments. The case against defaulting to cards for every transaction type is getting stronger as open banking infrastructure matures in the UK and EU and gradually in the US.

But as Johannes Kolbeinsson put it on Fintech Garden, account-to-account is converting cash, not cards. The population most likely to switch to pay-by-bank is not the reward-card loyalist buying online. It’s the business paying a large invoice, the subscriber on a recurring utility, or the merchant tired of watching friendly fraud eat into margins.

But the comparison doesn’t resolve to a single winner. It resolves to a routing decision: which transactions in your mix should move over bank rails, for which customers, and in which markets. That question needs your actual transaction profile—order value distribution, refund rate, B2B vs. B2C split, and target geography.

The teams that get the most from pay-by-bank build the refund architecture and reconciliation logic properly from the start, rather than discovering those requirements after the payment flow is live.