European merchants now have two mature ways to take money online. The first is the familiar one: card acquiring, where a scheme network carries an authorisation from your acquirer to the cardholder's issuer. The second is account-to-account (A2A) payment through open banking, where a licensed payment initiation service provider asks the payer's bank to push a credit transfer straight to your account. Both end with funds on your side. Almost everything in between is different.
This guide is not another list of payment methods — our payment methods overview covers the full range, and our explainer on how open banking changes financial services covers the wider market. Here we compare the two rails on the criteria that decide real merchant stacks: technical flow, checkout behaviour, settlement, disputes, regulation, cost structure, coverage and integration effort.
How card payments work
A card payment is a pull. The customer gives the merchant permission to draw on a card, and the merchant's side does the drawing. The gateway collects the card details or a token, runs authentication where required, and passes an authorisation request to the acquirer. The acquirer routes it through the card scheme to the issuer, which checks funds, limits and risk and answers approve or decline in a few seconds.
An approval is a promise, not money. The merchant captures the authorised amount — immediately or later, for example at shipment — and captured transactions are cleared in batches. The acquirer then settles net proceeds to the merchant account on the schedule in your acquiring agreement, after deducting fees and any reserve. Because the merchant pulled the funds, the cardholder keeps a structured route to pull them back: the chargeback.
How open banking and A2A payments work
An open banking payment is a push. Under the second Payment Services Directive, a licensed payment initiation service provider (PISP) can, with the payer's explicit consent, ask the payer's bank to execute a credit transfer from their online account. The payer is redirected or handed off to their banking app, authenticates with the bank, approves the payment, and the bank sends the transfer — increasingly over SEPA Instant where both banks support it, otherwise over standard SEPA credit transfer or a domestic scheme.
Merchants rarely connect to each bank directly. Platforms that provide open banking infrastructure for account-to-account payments put one API in front of many bank interfaces, while the regulated payment initiation and account information services are performed by licensed providers. That split — software orchestration on one side, licensed AIS/PIS activity on the other — is worth understanding before you sign anything, because it decides who is responsible for what in your contract.
Payment initiation vs card authorisation
The two "success" messages mean different things, and treating them as equivalent is the most common integration mistake.
- Card authorisation reserves funds on the card. The issuer has said yes, but nothing has moved until capture, clearing and settlement.
- Payment initiation tells you the payer's bank accepted the instruction. Depending on the bank, the scheme and the status model, the transfer may still be pending, may be rejected after initiation, or may arrive later than the status suggests.
For digital goods or anything released instantly, the safe pattern for A2A is to release on confirmed credit to your receiving account, not on the first initiation status. For cards, the equivalent discipline is to ship on capture-ready authorisation and to reconcile on settlement files, not on the authorisation response.
Checkout UX and authentication
Card checkout is familiar and works anywhere: number, expiry and CVC, or a stored token or wallet. On cards issued in the EEA, strong customer authentication usually means a 3-D Secure 2 flow, which can be frictionless when the issuer has enough risk data or an exemption applies, or a step-up challenge in the banking app when it does not.
Open banking checkout replaces card entry with bank selection and a handoff to the bank's own authentication. On mobile, with a well-maintained app-to-app redirect, this can be very short: the customer approves with the same biometric they use every day. On desktop, or where a bank's redirect is weak, it can mean a QR code, a web login or a dropped session. Conversion therefore depends heavily on the specific banks your customers use and on the quality of the provider's bank connections — something to measure in your own traffic rather than assume.
Settlement timing and reconciliation
Card settlement follows the acquirer's schedule, typically in batches some days after capture, net of fees, with a separate file to match settlements to transactions. The mechanics are well understood, but the money arrives later than the sale and in aggregated form.
A2A payments are gross transfers into your account, one credit per payment. Under the Instant Payments Regulation, payment service providers in the euro area that offer standard euro credit transfers must also offer instant ones, and the European Central Bank's instant payments overview explains how that infrastructure fits together. Faster funds do not remove reconciliation work: you still need a reference that ties each incoming credit back to an order, handling for partial or duplicate payments, and a view of the receiving account. This is where open banking solutions that combine payment initiation with settlement verification against the receiving account earn their place, because they close the gap between "initiated" and "money received" in one data model.
Disputes, chargebacks and refunds
Cards offer the cardholder a chargeback right defined by scheme rules. For merchants that means exposure to fraud and "item not received" disputes, evidence deadlines, fees and monitoring thresholds — but also a mature, predictable process that customers trust.
A2A payments have no card-style chargeback. That does not make them dispute-free or fraud-free. Payers can still complain to their bank, claim an unauthorised transaction under PSD2, or pursue a merchant through consumer-protection routes, and authorised push payment fraud remains a real risk. Refunds are also different: there is no "reverse the card transaction" button, so the merchant (or provider) sends a new outbound transfer, which requires the payer's account details and its own controls. Plan the refund journey before launch, not after the first request.
SCA, consent and regulatory considerations
Both rails sit under the same framework. PSD2 (Directive (EU) 2015/2366) created the licensing regime for payment initiation and account information services and the requirement for strong customer authentication. The detailed rules are in the regulatory technical standards developed by the European Banking Authority — see the EBA page on SCA and secure communication — and adopted as Commission Delegated Regulation (EU) 2018/389.
In practice: for cards, the merchant's provider manages exemptions and liability shift through 3-D Secure; for A2A, the payer's bank applies SCA and the PISP must hold the right licence or operate under one. Consent must be explicit and specific to the payment. The EU has also been revising this framework through PSD3 and a Payment Services Regulation; check the current status and application dates of those texts with your providers and advisers rather than planning around draft provisions. The ECB's payments section is a useful reference for how the underlying infrastructure is overseen.
Cost structures and operational overhead
Card pricing is usually built from interchange, scheme fees and the acquirer's margin, quoted either blended or as interchange-plus, plus chargeback fees, gateway fees and possibly reserves. A2A pricing is usually a per-transaction or tiered fee from the provider, with your bank's own charges for incoming transfers and refunds on top. We do not quote figures here because both depend on volume, sector, risk profile and contract terms.
Compare total cost of acceptance, not headline rates. On the card side, include dispute handling time and fraud losses. On the A2A side, include refund operations, customer support for failed bank handoffs and the reconciliation work your finance team does today.
Bank connectivity and geographic coverage
Card acceptance is close to universal: a customer with a card from almost any country can pay. Open banking coverage is national and bank-by-bank. PSD2 obliges account-holding banks in the EEA to provide access interfaces, but the quality of those interfaces, the availability of instant rails and the share of your customers who actually bank online vary by market. Before committing, map your customer base by country and bank, and ask providers for coverage of those specific banks, not a total bank count.
Integration complexity and API orchestration
Cards usually arrive through one payment gateway integration with hosted fields or SDKs, tokenisation and webhooks for authorisation, capture, refund and dispute events. Open banking adds a different set of states — consent, initiation, bank status, credit received — and the variation between banks makes direct integrations costly to maintain. An orchestration layer that normalises bank responses into one model is usually the pragmatic route. Whichever you choose, design your order system around idempotent webhooks and a single internal payment state machine that both rails map into. Our integrations page explains how CardPMT connects the card side.
When cards are preferable
- International customers, or markets where open banking adoption is low.
- Recurring billing and merchant-initiated transactions built on stored credentials.
- Customers who value chargeback protection, for example on high-ticket or delayed-delivery purchases.
- Authorise-now, capture-later flows such as pre-orders, hospitality and marketplaces.
- Checkouts where buying on credit matters to the customer.
When open banking is preferable
- Higher-value, one-off payments in markets where bank-app payment is already habitual.
- Account funding, top-ups and invoice settlement, where a push from the payer's own account fits the use case.
- Businesses that need faster, gross receipt of funds and per-payment confirmation of the credit.
- Use cases where card acceptance is restricted or costly for your sector — subject to the provider's own risk policy.
Hybrid payment stack decision checklist
Most merchants end up running both rails and steering between them. Use this checklist to decide where each belongs in your payment method mix.
Customers and markets
- Which countries and banks do your customers actually use, and how many pay on mobile?
- Do your buyers expect chargeback protection or credit?
Product and flows
- Do you need recurring payments, delayed capture or partial refunds?
- Do you release goods instantly, and can you wait for confirmed credit before you do?
Finance and operations
- Can your ledger handle net card settlements and gross A2A credits side by side?
- Who handles refunds to bank accounts, and with which controls?
- Have you compared total cost of acceptance, including disputes, support and reconciliation?
Compliance and vendors
- Which party holds the PIS/AIS licence, and which is a technical service provider?
- How does each provider apply SCA, exemptions and consent, and how will changes under the revised EU framework reach you?
- Can you run both rails into one payment state machine, with clean fallback from a failed bank handoff to card?
Cards and open banking solve different problems. Treat them as complementary rails, measure them on your own traffic, and let the data — not the hype around either one — decide how much volume each carries.
- open banking
- card acquiring
- A2A payments
- PSD2
- strong customer authentication
- settlement