Open Banking & A2A: Pay-by-Bank für Online-Shops 2026

Pay-by-Bank auf Basis von Open Banking wandelt sich 2026 vom Nischenthema zur ernstzunehmenden Checkout-Alternative. Das A2A-Transaktionsvolumen in Europa überschreitet 850 Milliarden Euro mit einem Wachstum von 30 Prozent gegenüber dem Vorjahr (European Business Magazine/Brite Payments). Anbieterauswertungen zeigen Auth-Raten von 95 bis 97 Prozent für Open-Banking-Zahlungen gegenüber 70 bis 85 Prozent bei Karten (Volt, Yapily, TrueLayer). Wer im E-Commerce Marge und Conversion gleichzeitig optimieren will, kommt an A2A-Methoden kaum noch vorbei. Im Unterschied zu SEPA Instant Payments - die als Infrastruktur unter vielen Verfahren liegen - geht es bei Pay-by-Bank um die konkrete Checkout-Methode: einen vom Shop initiierten, vom Kunden in seiner Bank-App autorisierten Direktzahlungs-Flow.

A2A vs. Karte: Wirtschaftlicher Vergleich

Account-to-Account-Zahlungen umgehen klassische Kartennetze. Statt einer Autorisierung über Schemes wie Visa oder Mastercard fließt das Geld direkt vom Konto des Kunden auf das Konto des Händlers - typischerweise als SEPA Credit Transfer oder SEPA Instant Credit Transfer. Die Folge: deutlich niedrigere Gebühren und keine klassischen Chargebacks. Anbietervergleiche aus 2025 (Aeropay, Inpay, Shopify Payments-Auswertungen) nennen flat fees zwischen 0,15 und 0,25 Euro pro Transaktion beziehungsweise 30 bis 70 Prozent Ersparnis gegenüber dem typischen Karten-MDR von 1,5 bis 3,5 Prozent plus Fixum. Bei einem mittelständischen Shop mit einer Million Euro Jahresumsatz und einer durchschnittlichen Karten-MDR von 1,8 Prozent reden wir über fünfstellige jährliche Einsparungen, sobald nennenswerte Transaktionsanteile auf A2A umgeleitet werden.

Hinzu kommen Sekundäreffekte, die in klassischen TCO-Rechnungen oft untergehen: keine Interchange-Schwankungen je nach Karten-Typ und Karten-Land, keine Authorization-Reserven beim Acquirer, keine FX-Margen bei nicht-Euro-Karten, sofortige Cash-Verfügbarkeit statt T+2-Settlement-Lücken. Kalkulatorisch heißt das: Selbst wenn der direkte Gebührenvergleich nur 25 Prozent Ersparnis ausweist, summieren sich die operativen Vorteile häufig auf weitere 5 bis 10 Prozentpunkte Margen-Effekt. Wer Pay-by-Bank konsequent in den Standard-Checkout-Mix aufnimmt - nicht nur als Nischenoption für Bestandskunden -, hebt diese Effekte deutlich schneller, weil der Anteil der Transaktionen jenseits einer Wahrnehmungsschwelle von typischerweise 10 bis 15 Prozent stehenbleibt. Erst ab dieser Schwelle wird die Methode für Marketing- und Operations-Reporting wirklich sichtbar.

Für die Conversion zählt vor allem die wahrgenommene Reibung. Volt und Yapily dokumentieren typische Sessions unter 45 Sekunden vom Klick auf den Pay-by-Bank-Button bis zur Bestätigung. TrueLayer berichtet, dass 80 Prozent der Erstnutzer A2A binnen eines Monats wiederholen - ein klares Indiz für Wiederkauf-Tauglichkeit, wenn der erste Flow überzeugt. Brite Payments meldet einen A2A-Anteil im EU-E-Commerce 2024 von 17 Prozent am Transaktionswert - mit klar steigender Tendenz.

Auch der Umstand, dass A2A-Zahlungen in Sekunden settlen statt in ein bis drei Werktagen, ist betriebswirtschaftlich relevant: Das gebundene Working Capital sinkt, Liquiditätspuffer werden kleiner, und die Disposition bei Lieferanten lässt sich enger an die tatsächlichen Geldflüsse koppeln. Wer parallel an adaptive Image-Loading und am Checkout-Speed arbeitet, schöpft die Conversion-Reserven von Pay-by-Bank am sichersten aus - Performance und Payment-Method sind in der wahrgenommenen Reibung verschwistert.

PSD3 und PSR: Was sich 2026 ändert

Am 27. November 2025 erzielten Rat, Parlament und Kommission eine politische Einigung über das PSD3/PSR-Paket (EU-Kommission, Norton Rose, KPMG IE). Die Veröffentlichung im Amtsblatt der Europäischen Union wird im zweiten Quartal 2026 erwartet. Das Paket besteht aus zwei Rechtsakten: einer überarbeiteten Richtlinie PSD3 und einer direkt anwendbaren Verordnung PSR (Payment Services Regulation). Die Verordnung ist nach Veröffentlichung 20 Tage nach dem Inkrafttreten gültig, mit einer 21-monatigen Übergangsphase für die wesentlichen Pflichten. PSD3 wird voraussichtlich im zweiten oder dritten Quartal 2028 anwendbar (KPMG IE/Norton Rose).

Für Online-Shops und ihre Payment-Service-Provider sind insbesondere drei Punkte relevant. Erstens werden Open-Banking-APIs durch die PSR als primärer Zugangskanal für Drittanbieter (TPPs) verankert - Screen-Scraping-Fallbacks werden weiter eingeschränkt. Zweitens wird ein Permission-Dashboard für Endkunden zur Pflicht: Verbraucher müssen jederzeit sehen können, welche Drittanbieter Zugriff auf ihre Konten haben, und Berechtigungen mit einem Klick widerrufen können. Drittens sieht die PSR ein klares TPP-Diskriminierungsverbot vor - Banken dürfen lizenzierte Drittanbieter nicht durch unverhältnismäßige Friktion ausbremsen.

1. 27.11.2025 - Politische Einigung Rat/Parlament/Kommission (EU-Kommission)
2. Q2 2026 - Erwartete Veröffentlichung im EU-Amtsblatt
3. Q2 2026 + 20 Tage - Inkrafttreten der PSR
4. Q1 2028 - Ende der 21-monatigen Übergangsfrist (PSR-Pflichten greifen)
5. Q2/Q3 2028 - Anwendung der PSD3 (nach nationaler Umsetzung)

AIS vs. PIS: Zwei verschiedene Lizenzen

Open Banking lebt von zwei voneinander unabhängigen Diensten - jeweils mit eigener BaFin- bzw. EU-Lizenz. AIS steht für Account Information Service: read-only-Zugriff auf Konto- und Transaktionsdaten, typisch für Banking-Aggregatoren, Kreditscoring oder Reconciliation. PIS steht für Payment Initiation Service: read-write, der TPP initiiert im Auftrag des Kunden eine Überweisung von dessen Konto auf das Konto des Händlers. Für Pay-by-Bank im Checkout ist PIS die relevante Lizenz - meist eingebracht durch den Payment-Service-Provider, nicht durch den Shop selbst.

In der Praxis kombinieren viele Anbieter beide Dienste. Eine sinnvolle Reconciliation greift auf AIS zurück, um eingehende SEPA-Zahlungen mit Bestellungen abzugleichen, während die eigentliche Zahlung per PIS initiiert wurde. Wer nur PIS nutzt, ist auf Webhook-Confirmations und Endkonto-Abgleich aus der Buchhaltung angewiesen - was bei E-Commerce-Wachstum mit Cross-Border-Steuern schnell zur operativen Bremse wird. Aus regulatorischer Sicht ist außerdem zu beachten, dass die Datenverarbeitung in beiden Modellen unter PSR-Regime fällt: explizite Einwilligung des Kontoinhabers, Zweckbindung, klare Aufbewahrungsfristen und ein Permission-Dashboard im Endkunden-Frontend des Shops sind keine Kür mehr, sondern Voraussetzung für rechtssichere Integration.

Drei Auth-Flows: Redirect, Decoupled, Embedded

Die Berlin Group, der UK Open Banking Standards-Verband und das EPC SPAA-Schema sehen drei zulässige Authentifizierungs-Flows für PIS vor. Welcher davon eingesetzt wird, hängt von der Bank, vom Endgerät und vom rechtlichen Rahmen ab.

Der Redirect-Flow ist der robuste Standard für Online-Shops: Der Kunde wird vom Checkout zur Bank-Seite oder direkt zur Bank-App weitergeleitet, dort authentifiziert und nach erfolgreicher SCA zurück in den Shop geführt. Der Decoupled-Flow entkoppelt die Authentifizierung vom Browser: Der Kunde gibt im Shop seine IBAN ein, die Bank schickt eine Push-Notification an die Banking-App, dort wird signiert. Besonders relevant für nordische Märkte und für Wallets wie Wero. Der Embedded-Flow - Eingabe von Banking-Credentials direkt beim TPP - ist datenschutzrechtlich heikel und unter PSD2/PSR-Auslegung nur in eng umrissenen Fällen zulässig. Für reguläre Shop-Checkouts kommt er praktisch nicht mehr in Frage.

Wero, iDEAL und nationale Schemes

Die A2A-Landschaft in Europa ist fragmentiert - jedes Land hat eigene Marktführer. Das ist gleichzeitig Chance (lokale Conversion-Wins) und Komplexität (Multi-Anbieter-Stack).

Der globale Trend ist eindeutig. Juniper Research prognostiziert ein Wachstum des A2A-Transaktionsvolumens von 1,7 Billionen US-Dollar (2024) auf 5,7 Billionen US-Dollar (2029) - +230 Prozent. Die Anzahl globaler A2A-Transaktionen klettert von 60 Milliarden auf 186 Milliarden. Open-Banking-Payments-User wachsen von unter 100 Millionen (2023) auf rund 400 Millionen (2027) und 600 Millionen (2028). Das Open-Banking-Volumen in Europa liegt 2026 bei 87 Milliarden US-Dollar (Juniper). Der Karten-Anteil am EU-E-Commerce sinkt bis 2026 auf 33 Prozent (Juniper). Wer Internationalisierung plant, sollte nationale Schemes als Pflichtbestandteil seiner internationalen Shop-Strategie verstehen.

Refund-Handling und Reconciliation

Refunds in A2A funktionieren technisch anders als bei Karten. Es gibt keinen Refund-Endpunkt im klassischen Sinne; stattdessen wird eine zweite, in die Gegenrichtung laufende PIS-Initiierung ausgelöst - in vielen Stacks abgebildet als Reverse-Payment vom Händlerkonto zurück auf das ursprüngliche Käuferkonto. Bei aktivierten Instant-Schemes (SEPA SCT Inst, UK Faster Payments) erfolgt die Gutschrift in Sekunden. Voraussetzung ist, dass der Händler-PSP die ursprüngliche IBAN sicher gespeichert hat - was wiederum saubere DSGVO-Prozesse erfordert.

Für die Reconciliation ist die End-to-End-Reference (EREF) im SEPA-SCT/SCT-Inst der wichtigste Hebel. Die EREF muss eindeutig sein, taucht im Verwendungszweck der Bankbuchung auf und sollte als Schlüssel im Buchhaltungssystem fungieren. Eine bewährte EREF-Konvention sieht so aus:

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

# Camt.053 / Camt.054 Auswertung (Beispiel-Mapping):
# <RmtInf><Strd><CdtrRefInf><Ref>PBB-2026-100245</Ref> ...
# -> Order #100245 = SETTLED

# Statt im Verwendungszweck (UNSTRUCTURED) die EREF
# als strukturierte Referenz fuehren - reduziert Match-Fehler

Neben der EREF empfiehlt sich der parallele Bezug auf eine Creditor Reference (RF-Referenz, ISO 11649) sowie ein internes Hash-Verfahren, das Order-ID, IBAN-Prüfziffer und Brutto-Betrag verbindet. In Verbindung mit AIS-basiertem Konto-Polling ist die Quote der manuell zugeordneten Zahlungseingänge in der Praxis nahe null - was wiederum Personalkosten in der Buchhaltung spart und Liquiditätsplanung präziser macht. Wer parallel an Peppol-E-Invoicing arbeitet, sollte die EREF-Schemata zwischen Rechnung und Zahlungseingang konsistent halten.

SCA-Exemptions im A2A-Kontext

Auch im A2A-Flow ist die starke Kundenauthentifizierung (SCA) der Default - mit definierten Ausnahmen, die unter PSD2 in Kraft sind und unter PSR in weitgehend ähnlicher Form fortgeschrieben werden sollen. Für Pay-by-Bank-Checkouts sind insbesondere folgende Exemptions relevant:

• Low-Value Payments - Einzelzahlungen unter 30 Euro, kumulativ maximal 5 Transaktionen oder 100 Euro pro 24 Stunden ohne erneute SCA (RTS Art. 16)
• Trusted Beneficiaries - Kunde fügt den Händler einer Whitelist seiner Bank hinzu, weitere Zahlungen ohne SCA
• Recurring Transactions - Wiederkehrende Zahlungen identischer Höhe an denselben Händler, SCA nur bei der Erstzahlung
• Transaction Risk Analysis (TRA) - Ausnahme bei niedrigem Betrugsrisiko, gestaffelt nach Betrag und Score-Grenzwerten der jeweiligen Bank
• Corporate Payments - Sichere unternehmensinterne Verfahren mit eigenständiger Authentifizierungs-Architektur

Disputes ohne Chargebacks: Risiko-Verschiebung

Pay-by-Bank kennt keine klassischen Chargebacks. Eine autorisierte SEPA-Zahlung ist grundsätzlich unwiderruflich; eine Rückbuchung ist nur durch aktive Rücküberweisung des Empfängers möglich. Das ist für Händler ein massiver wirtschaftlicher Vorteil: keine Dispute-Fees in Höhe von typischerweise 15 bis 25 Euro pro Fall, keine Friendly-Fraud-Welle nach Sale-Phasen, weniger administrativer Aufwand in der Streitbeilegung. Konsequenz für die Marge: Auch bei sonst vergleichbaren Konditionen wird A2A durch das Ausbleiben von Chargeback-Kosten noch einmal attraktiver.

Der Reverse der Medaille: Risiken verschieben sich vom Schema-Provider zum Händler. Wer Käufer schlecht onboardet, intransparente Lieferzeiten kommuniziert oder mangelhafte Ware liefert, verliert nicht über Chargebacks - sondern über zivilrechtliche Forderungen, schlechte Bewertungen und langfristig sinkenden CLV. Auch die Compliance-Verantwortung rückt näher an den Händler heran: AML/KYC-Anforderungen werden im Shop-Onboarding strenger, zusätzliche Identitätsprüfungen bei Auffälligkeiten sind die Regel. Im Risk-Mix bleibt zudem das Thema Authorised Push Payment Fraud (APP-Fraud): Käufer könnten unter falschen Vorwänden manipuliert werden, eine Zahlung zu autorisieren, deren Empfänger nicht der erwartete Shop ist. Hier ist der Verification of Payee (VoP, IBAN-Name-Abgleich, seit 09.10.2025 verpflichtend) der wichtigste technische Schutz auf Seite des Zahlers - und ein Argument, das im Checkout aktiv kommuniziert werden sollte.

Integration in Shopware-Checkout

Technisch wird Pay-by-Bank in Shopware 6 als Payment-Method-Plugin integriert. Der Shop-PSP stellt eine PIS-API bereit, die der Plugin-Code im Backend aufruft, um eine Payment-Initiation zu erzeugen; der Kunde wird redirected, autorisiert in der Bank-App, und der Shop erhält eine Webhook-Bestätigung auf einer dedizierten Route. Wichtig: Der finale Bestellstatus wird nicht aus dem Browser-Redirect abgeleitet, sondern ausschließlich aus dem signierten Webhook - der Browser-Return ist nur UX. Ein typisches Webhook-Handler-Pattern sieht so aus:

<?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. Signatur pruefen (HMAC SHA256, Replay-Schutz mit 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. Order via EREF auflösen (Idempotenz!)
        $orderId = $this->resolveOrderIdByEref($eref);
        if (!$orderId) {
            $this->logger->warning("PBB webhook unknown EREF", ["eref" => $eref]);
            return new JsonResponse(["ok" => true]);
        }

        // 3. State Machine bedienen (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]);
    }
}

Drei Punkte sind in der Praxis kritisch. Idempotenz: Der Webhook kann mehrfach zugestellt werden, jeder Status-Übergang muss durch eine eindeutige Reference (EREF) abgesichert sein. Signaturprüfung: HMAC mit shared secret und Replay-Schutz über einen Timestamp-Header sind Standard. Order-State-Konsistenz: Im Shopware Flow Builder sollten erst nach Eingang von settled Versand-Workflows ausgelöst werden - der Browser-Return reicht nicht. Wer im Checkout zusätzlich Express-Checkout-Patterns und konversionsoptimierte Warenkorb-Flows berücksichtigt, kombiniert die A2A-Vorteile mit niedriger Drop-Out-Rate.

Marketplace-Plattformen: PI-Lizenz oder PSP?

Wer eine Marktplatz-Plattform betreibt, also Geld zwischen Käufern und unabhängigen Verkäufern hält und auszahlt, steht 2026 vor einer strategischen Weichenstellung. Die PSR verengt die bisherige Commercial-Agent-Exemption: Plattformen, die nicht ausschließlich im Namen einer Seite (Käufer oder Verkäufer) handeln, fallen leichter unter das Regime der Zahlungsdienste. Praktisch ergeben sich zwei Optionen. Erstens: eine eigene Lizenz als Zahlungsinstitut (PI) oder E-Geld-Institut (EMI) beantragen - mit erheblichem Eigenkapital-, Compliance- und Personalaufwand. Zweitens: Partnerschaft mit einem regulierten Payment-Service-Provider, der treuhänderisch Marketplace-Funktionalität (Split-Payments, Escrow, Auszahlungen) betreibt - Plattform bleibt selbst lizenzfrei.

Die Wahl hängt von Volumen, Internationalisierungs-Roadmap und Geschäftsmodell ab. Für die meisten mittelständischen Marktplätze ist die PSP-Partnerschaft der schnellere Weg zur produktiven Plattform; spätestens bei achtstelligem GMV wird die Eigen-Lizenz wirtschaftlich attraktiv. Auch die DSA-Pflichten für Marktplätze sollten parallel betrachtet werden, da sie ähnliche Governance-Strukturen voraussetzen.

Implementierungs-Roadmap in 5 Phasen

1. Phase 1 - Discovery (1-2 Wochen): Bestandsaufnahme aktueller Payment-Mix, Karten-MDR-Analyse, Identifikation der Top-3-Zielmärkte und passender A2A-Schemes (Wero, iDEAL, Bizum, BLIK, Swish, generisches Pay-by-Bank).
2. Phase 2 - PSP-Auswahl (2-3 Wochen): Anforderungs-Workshop, Ausschreibung an mehrere lizenzierte Anbieter, Vergleich von Coverage, Auth-Flows, Refund-API, Reconciliation-Schnittstellen, Webhook-Stabilität, Sandbox-Qualität, Pricing.
3. Phase 3 - Integration (3-6 Wochen): Shopware-Plugin-Entwicklung oder -Konfiguration, Webhook-Handler mit Idempotenz und Signaturprüfung, EREF-Schema, Refund-Pfade, AIS-basierte Reconciliation, Logging und Monitoring.
4. Phase 4 - Testlauf (2-3 Wochen): End-to-End-Tests inkl. Refunds, Edge-Cases (Timeout-Bank, abgebrochene SCA, falsche IBAN), Lasttests des Webhook-Endpunkts, Buchhaltungs-Integration, AGB- und Datenschutz-Update.
5. Phase 5 - Go-Live + Optimierung (laufend): Soft-Launch mit eingeschränktem Kundensegment, A/B-Test der Button-Position im Checkout, Monitoring von Auth-Rate, Settlement-Zeit, Refund-Quote, schrittweise Aktivierung in weiteren Märkten.