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. The infrastructure is in place: according to the payments statistics of the European Central Bank, instant credit transfers accounted for 25 percent of the number and 8 percent of the value of all credit transfers processed by euro area payment systems in the second half of 2025 (ECB). Anyone who looks at margin and conversion together 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 authorized by the customer in their bank app.

A2A vs. card: economic comparison

Account-to-account payments bypass classic card networks. Instead of an authorization via a card scheme, money flows directly from the customer account to the merchant account – typically as SEPA Credit Transfer or SEPA Instant Credit Transfer. That changes the fee logic fundamentally: card acceptance is usually billed as a percentage of turnover plus a fixed fee, while A2A providers mostly charge a fixed amount per transaction. Whether this turns into a cost advantage depends on the average cart value: a fixed amount per transaction has more effect the higher the basket. This calculation only holds with your own terms from the acquiring contract and the A2A provider quote, not with list prices from provider marketing.

On top of that come secondary effects often missed in classic TCO calculations: no interchange fluctuations by card type and card country, no authorization reserves at the acquirer, no FX margins on non-euro cards and earlier availability of the money. Anyone who treats pay-by-bank as part of the standard checkout mix – not just as a niche option for repeat customers – sees these effects sooner, because the share of transactions reaches a size worth evaluating in the first place. The assessment then belongs in your own contribution margin calculation: fees, failure rate, return behavior and handling effort per payment method side by side, over a period that covers seasonal outliers.

Perceived friction is the conversion driver: how many steps lie between clicking the pay button and the confirmation, how reliably the customer returns from the bank app to the shop, and how understandable the error message is when the bank aborts. These are measurable – drop-off per step, share of successful returns, time to confirmation – and they differ considerably by bank. Anyone introducing pay-by-bank therefore instruments the flow from day one and runs it against the existing card journey in an A/B test, instead of adopting provider figures from other assortments.

The moment of crediting also matters commercially. For instant credit transfers in euro, Regulation (EU) 2024/886 requires the payee payment service provider to make the amount available within ten seconds of receiving the payment order. Compared with card turnover, which is paid out days later depending on the acquiring contract, this reduces tied-up working capital. Anyone working in parallel on adaptive image loading and on checkout speed addresses both sources of friction around pay-by-bank – performance and payment method are siblings in perceived friction.

PSD3 and PSR: what changes in 2026

On 28 June 2023 the European Commission proposed a package of two legal acts: a revised directive PSD3 and a directly applicable regulation PSR (Payment Services Regulation) (European Commission). The Commission page on the package still carries this proposal status; it gives no date for publication in the Official Journal or for application. For planning that means: the direction is visible, the timetable is not – a project cut to a specific application date is planning on sand.

Three points of the proposal are relevant for online shops and their payment service providers. First, open banking APIs are to be anchored as the primary access channel for third-party providers (TPPs) – screen-scraping fallbacks would be further restricted. Second, a permission dashboard for end customers is foreseen: consumers should be able to see which third parties have access to their accounts and to revoke permissions. Third, the draft contains a TPP non-discrimination rule – banks should not be allowed to slow down licensed third parties through disproportionate friction. While the procedure runs, PSD2 and its regulatory technical standards continue to apply unchanged in day-to-day operation.

1. 28/06/2023 – Commission proposal: PSD3 as a directive, PSR as a directly applicable regulation (European Commission)
2. Open – conclusion of the legislative procedure and publication in the Official Journal
3. Open – transition periods for the duties arising from the PSR
4. Open – national transposition of PSD3 as a directive
5. Binding today – PSD2 with its regulatory technical standards and Regulation (EU) 2024/886 on instant credit transfers

AIS vs. PIS: two different licenses

Open banking lives off two independent services – each with its own BaFin or EU license. 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 license – 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 depends 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. For AIS access, one deadline deserves attention: where the user accesses account data through an account information service provider, the regulatory technical standards require a fresh strong customer authentication once more than 180 days have passed since the last access (Delegated Regulation (EU) 2018/389 as amended by Delegated Regulation (EU) 2022/2360). For both models the same applies: explicit consent of the account holder, purpose limitation, clear retention periods and a permission overview in the customer frontend are a precondition for compliant 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 established providers. That is both an opportunity (local conversion wins) and complexity (multi-provider stack).

How payment methods are distributed in the euro area is shown by the payments statistics of the European Central Bank for the second half of 2025: card payments accounted for 57 percent of all non-cash payments, credit transfers for 21 percent, direct debits for 14 percent and e-money payments for 6 percent (ECB). By number, cards are clearly ahead – the leverage of A2A lies less in displacing cards than in building a second rail for the baskets where it carries. Anyone selling internationally should treat national schemes as 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 – a remote payment of no more than EUR 30; no fresh SCA is required as long as the payments initiated since the last strong customer authentication do not together exceed EUR 100 or no more than five transactions have been initiated since (Delegated Regulation (EU) 2018/389, Article 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 authorized SEPA payment is in principle irrevocable; a return is only possible by an active reverse payment from the recipient. For merchants this is an economic advantage: no card scheme chargeback fees, 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 authorizing a payment to a recipient that is not the expected shop. The Verification of Payee (VoP, check of IBAN against name) is the most important technical protection on the payer side; payment service providers in the euro area have had to comply with this duty under Regulation (EU) 2024/886 since 9 October 2025 – 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, authorizes 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-optimized cart flows gets the A2A advantages with low drop-out rates.

Marketplace platforms: PI license 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) license – 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, internationalization 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 license 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: 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: 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: 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: 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 + optimization (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.