Open Banking & A2A: Pay-by-Bank for Online Shops 2026

Pay-by-bank built on open banking is moving from niche topic to a serious checkout alternative in 2026. A2A transaction volume in Europe has crossed EUR 850 billion with 30 percent year-on-year growth (European Business Magazine/Brite Payments). Provider data shows auth rates of 95 to 97 percent for open banking payments compared to 70 to 85 percent for cards (Volt, Yapily, TrueLayer). Anyone who wants to optimise both margin and conversion in e-commerce can hardly avoid A2A methods. Unlike SEPA Instant Payments - which form an infrastructure layer beneath many methods - pay-by-bank is the concrete checkout method: a direct payment flow initiated by the shop and authorised by the customer in their bank app.

A2A vs. card: economic comparison

Account-to-account payments bypass classic card networks. Instead of an authorisation via schemes like Visa or Mastercard, money flows directly from the customer's account to the merchant's account - typically as SEPA Credit Transfer or SEPA Instant Credit Transfer. The result: substantially lower fees and no classic chargebacks. Provider benchmarks from 2025 (Aeropay, Inpay, Shopify Payments evaluations) cite flat fees between 0.15 and 0.25 EUR per transaction or 30 to 70 percent savings over a typical card MDR of 1.5 to 3.5 percent plus a fixed fee. For a mid-market shop with EUR 1 million annual turnover and an average card MDR of 1.8 percent, that means five-figure annual savings as soon as meaningful transaction shares move to A2A.

On top of that come secondary effects often missed in classic TCO calculations: no interchange fluctuations by card type and card country, no authorisation reserves at the acquirer, no FX margins on non-euro cards, immediate cash availability instead of T+2 settlement gaps. In practice that means: even when the direct fee comparison only shows 25 percent savings, the operational benefits often add up to another 5 to 10 percentage points of margin impact. Anyone who treats pay-by-bank as a default in the standard checkout mix - not just as a niche option for repeat customers - realises these effects much faster, because the share of transactions stays below a perception threshold of typically 10 to 15 percent. Only above that threshold does the method become truly visible in marketing and operations reporting.

Perceived friction is the conversion driver. Volt and Yapily report typical sessions under 45 seconds from clicking the pay-by-bank button to confirmation. TrueLayer notes that 80 percent of first-time users repeat A2A within one month - a strong indicator of repeat usability when the first flow is convincing. Brite Payments reports an A2A share of EU e-commerce in 2024 at 17 percent of transaction value - with a clearly upward trajectory.

The fact that A2A payments settle in seconds rather than one to three business days is also relevant from a working capital perspective: tied-up cash drops, liquidity buffers shrink, and procurement can be aligned more tightly with actual cash flows. Anyone working in parallel on adaptive image loading and on checkout speed unlocks the conversion reserves of pay-by-bank most reliably - performance and payment method are siblings in perceived friction.

PSD3 and PSR: what changes in 2026

On 27 November 2025 the Council, Parliament and Commission reached a political agreement on the PSD3/PSR package (EU Commission, Norton Rose, KPMG IE). Publication in the Official Journal of the European Union is expected in Q2 2026. The package consists of two legal acts: a revised directive PSD3 and a directly applicable regulation PSR (Payment Services Regulation). The regulation enters into force 20 days after publication, with a 21-month transition period for the main duties. PSD3 is expected to apply in Q2 or Q3 2028 (KPMG IE/Norton Rose).

Three points are particularly relevant for online shops and their payment service providers. First, open banking APIs are anchored by the PSR as the primary access channel for third-party providers (TPPs) - screen-scraping fallbacks are further restricted. Second, a permission dashboard for end customers becomes mandatory: consumers must be able to see which third parties have access to their accounts and revoke permissions in one click. Third, the PSR enshrines a clear TPP non-discrimination rule - banks must not slow down licensed third parties through disproportionate friction.

1. 27.11.2025 - Political agreement of Council/Parliament/Commission (EU Commission)
2. Q2 2026 - Expected publication in the EU Official Journal
3. Q2 2026 + 20 days - PSR enters into force
4. Q1 2028 - End of the 21-month transition period (PSR duties apply)
5. Q2/Q3 2028 - Application of PSD3 (after national transposition)

AIS vs. PIS: two different licences

Open banking lives off two independent services - each with its own BaFin or EU licence. AIS stands for Account Information Service: read-only access to account and transaction data, typical for banking aggregators, credit scoring or reconciliation. PIS stands for Payment Initiation Service: read-write, with the TPP initiating a transfer from the customer's account to the merchant's account on the customer's behalf. For pay-by-bank in checkout, PIS is the relevant licence - usually held by the payment service provider, not the shop itself.

In practice many providers combine both services. A solid reconciliation uses AIS to match incoming SEPA payments with orders, while the actual payment is initiated via PIS. Anyone using PIS only is dependent on webhook confirmations and end-of-account reconciliation from the books - which quickly becomes an operational bottleneck when cross-border tax obligations come into play. From a regulatory perspective it is also worth noting that data processing in both models falls under the PSR regime: explicit consent of the account holder, purpose limitation, clear retention periods and a permission dashboard in the shop's customer frontend are no longer optional - they are a precondition for legally sound integration.

Three auth flows: redirect, decoupled, embedded

The Berlin Group, the UK Open Banking Standards body and the EPC SPAA scheme define three permitted authentication flows for PIS. Which one is used depends on the bank, the device and the legal framework.

The redirect flow is the robust default for online shops: the customer is redirected from checkout to the bank page or directly into the bank app, authenticates there and is returned to the shop after successful SCA. The decoupled flow decouples authentication from the browser: the customer enters their IBAN in the shop, the bank pushes a notification to the banking app, where they sign. Particularly relevant for Nordic markets and for wallets like Wero. The embedded flow - entering banking credentials directly with the TPP - is sensitive under data protection law and only permissible in narrow cases under PSD2/PSR. For regular shop checkouts it is essentially out of the question today.

Wero, iDEAL and national schemes

The European A2A landscape is fragmented - every country has its own market leaders. That is both an opportunity (local conversion wins) and complexity (multi-provider stack).

The global trend is unambiguous. Juniper Research projects growth in A2A transaction volume from USD 1.7 trillion (2024) to USD 5.7 trillion (2029) - +230 percent. The number of global A2A transactions climbs from 60 billion to 186 billion. Open-banking-payments users grow from fewer than 100 million (2023) to around 400 million (2027) and 600 million (2028). Open banking volume in Europe stands at USD 87 billion in 2026 (Juniper). The card share of EU e-commerce drops to 33 percent by 2026 (Juniper). Anyone planning international growth should treat national schemes as a mandatory part of their international shop strategy.

Refund handling and reconciliation

Refunds in A2A work differently from cards on a technical level. There is no refund endpoint in the classic sense; instead a second PIS initiation is triggered in the opposite direction - in many stacks expressed as a reverse payment from the merchant account back to the original buyer account. With instant schemes enabled (SEPA SCT Inst, UK Faster Payments) the credit reaches the customer's account in seconds. The prerequisite is that the merchant PSP has stored the original IBAN safely - which in turn requires clean GDPR processes.

For reconciliation, the End-to-End Reference (EREF) in SEPA SCT/SCT Inst is the most important lever. The EREF must be unique, appears in the bank booking's remittance information and should serve as a key in the bookkeeping system. A proven EREF convention looks like this:

# Schema: PBB-<YEAR>-<ORDER_ID>
# Examples:
PBB-2026-100245
PBB-2026-100246-R # R = Refund
PBB-2026-100247-P2 # P2 = Partial Refund #2

# Camt.053 / Camt.054 parsing (example mapping):
# <RmtInf><Strd><CdtrRefInf><Ref>PBB-2026-100245</Ref> ...
# -> Order #100245 = SETTLED

# Use the EREF as a structured reference instead
# of the unstructured remittance text - this reduces match errors

Beyond the EREF, it makes sense to also use a Creditor Reference (RF reference, ISO 11649) in parallel and an internal hash that combines order ID, IBAN check digits and gross amount. Combined with AIS-based account polling, the share of manually matched payment receipts is close to zero in practice - which saves headcount in accounting and makes liquidity planning more precise. Anyone working in parallel on Peppol e-invoicing should keep EREF schemes consistent between invoice and payment receipt.

SCA exemptions in an A2A context

Even in an A2A flow, strong customer authentication (SCA) is the default - with defined exemptions in force under PSD2 that PSR is expected to carry forward in largely similar form. The following exemptions are particularly relevant for pay-by-bank checkouts:

• Low-value payments - single payments below EUR 30, capped at 5 transactions or EUR 100 per 24 hours without a fresh SCA (RTS Art. 16)
• Trusted beneficiaries - the customer adds the merchant to their bank's whitelist; further payments without SCA
• Recurring transactions - recurring payments of identical amount to the same merchant; SCA only on the first payment
• Transaction risk analysis (TRA) - exemption based on low fraud risk, tiered by amount and the bank's score thresholds
• Corporate payments - secure intra-company procedures with their own authentication architecture

Disputes without chargebacks: shifting risk

Pay-by-bank does not have classic chargebacks. An authorised SEPA payment is in principle irrevocable; a return is only possible by an active reverse payment from the recipient. For merchants this is a massive economic advantage: no dispute fees of typically EUR 15 to 25 per case, no friendly-fraud waves after sale phases, less administrative effort in dispute resolution. The consequence for margin: even with otherwise comparable conditions, A2A becomes more attractive again as chargeback costs disappear.

The flip side: risks shift from the scheme provider to the merchant. Anyone who onboards buyers poorly, communicates opaque delivery times or ships defective goods does not lose via chargebacks - but via civil-law claims, poor reviews and a long-term decline in CLV. Compliance responsibility also moves closer to the merchant: AML/KYC requirements at shop onboarding tighten, additional identity checks on suspicious patterns become standard. Authorised Push Payment fraud (APP fraud) also remains in the risk mix: buyers may be manipulated into authorising a payment to a recipient that is not the expected shop. The Verification of Payee (VoP, IBAN-name check, mandatory since 09.10.2025) is the most important technical protection on the payer side - and an argument that should be communicated proactively in checkout.

Integration into Shopware checkout

Technically pay-by-bank is integrated into Shopware 6 as a payment method plugin. The shop PSP exposes a PIS API which the plugin code calls in the backend to create a payment initiation; the customer is redirected, authorises in the bank app and the shop receives a webhook confirmation on a dedicated route. Important: the final order status is not derived from the browser redirect, but exclusively from the signed webhook - the browser return is just UX. A typical webhook handler pattern looks like this:

<?php

namespace XICTRON\PayByBank\Controller;

use Shopware\Core\Checkout\Order\OrderEntity;
use Shopware\Core\Framework\Routing\Annotation\RouteScope;
use Symfony\Component\HttpFoundation\JsonResponse;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\Routing\Annotation\Route;

/**
 * @RouteScope(scopes={"api"})
 */
class PayByBankWebhookController
{
    public function __construct(
        private OrderTransactionStateHandler $stateHandler,
        private SignatureVerifier $verifier,
        private LoggerInterface $logger
    ) {}

    #[Route(path: "/api/_webhook/pay-by-bank", name: "webhook.pbb", methods: ["POST"])]
    public function handle(Request $request): JsonResponse
    {
        // 1. Verify signature (HMAC SHA256, replay protection via timestamp)
        if (!$this->verifier->verify($request)) {
            return new JsonResponse(["ok" => false], 401);
        }

        $payload = json_decode($request->getContent(), true);
        $eref = $payload["eref"] ?? null; // PBB-2026-100245
        $status = $payload["status"] ?? null; // settled | failed | refunded
        $amount = $payload["amount"] ?? null;

        // 2. Resolve order via EREF (idempotency!)
        $orderId = $this->resolveOrderIdByEref($eref);
        if (!$orderId) {
            $this->logger->warning("PBB webhook unknown EREF", ["eref" => $eref]);
            return new JsonResponse(["ok" => true]);
        }

        // 3. Drive the state machine (Shopware OrderTransactionStates)
        match ($status) {
            "settled" => $this->stateHandler->paid($orderId, $context),
            "refunded" => $this->stateHandler->refunded($orderId, $context),
            "failed" => $this->stateHandler->fail($orderId, $context),
            default => null,
        };

        return new JsonResponse(["ok" => true]);
    }
}

Three points are critical in practice. Idempotency: the webhook may be delivered multiple times, every state transition must be guarded by a unique reference (EREF). Signature verification: HMAC with shared secret and replay protection via a timestamp header are standard. Order state consistency: in Shopware Flow Builder, shipping workflows should only fire after settled arrives - the browser return is not enough. Anyone combining this with express checkout patterns and conversion-optimised cart flows gets the A2A advantages with low drop-out rates.

Marketplace platforms: PI licence or PSP?

Anyone running a marketplace platform, i.e. holding and paying out money between buyers and independent sellers, faces a strategic decision in 2026. The PSR tightens the existing commercial agent exemption: platforms that do not act exclusively in the name of one side (buyer or seller) fall more easily under the payment services regime. Practically, two options emerge. First: apply for an own payment institution (PI) or e-money institution (EMI) licence - with significant capital, compliance and staffing effort. Second: partnership with a regulated payment service provider that offers marketplace functionality (split payments, escrow, payouts) on a trustee basis - the platform itself stays unlicensed.

The choice depends on volume, internationalisation roadmap and business model. For most mid-market marketplaces the PSP partnership is the faster path to a productive platform; once GMV reaches eight figures the own licence becomes economically attractive. The DSA duties for marketplaces should be considered in parallel as they require similar governance structures.

Implementation roadmap in 5 phases

1. Phase 1 - Discovery (1-2 weeks): Audit of current payment mix, card MDR analysis, identification of the top 3 target markets and matching A2A schemes (Wero, iDEAL, Bizum, BLIK, Swish, generic pay-by-bank).
2. Phase 2 - PSP selection (2-3 weeks): Requirements workshop, RFP to several licensed providers, comparison of coverage, auth flows, refund API, reconciliation interfaces, webhook stability, sandbox quality, pricing.
3. Phase 3 - Integration (3-6 weeks): Shopware plugin development or configuration, webhook handler with idempotency and signature verification, EREF schema, refund paths, AIS-based reconciliation, logging and monitoring.
4. Phase 4 - Test run (2-3 weeks): End-to-end tests including refunds, edge cases (bank timeout, aborted SCA, wrong IBAN), load tests of the webhook endpoint, accounting integration, terms and privacy update.
5. Phase 5 - Go-live + optimisation (continuous): Soft launch with a limited customer segment, A/B test of the button position in checkout, monitoring of auth rate, settlement time, refund ratio, gradual activation in further markets.