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. Die Infrastruktur dafür steht: Nach der Zahlungsstatistik der Europäischen Zentralbank entfielen im zweiten Halbjahr 2025 25 Prozent der Stückzahl und 8 Prozent des Werts aller von den Zahlungssystemen des Euroraums verarbeiteten Überweisungen auf Echtzeitüberweisungen (EZB). Wer im E-Commerce Marge und Conversion zusammen betrachtet, kommt an A2A-Methoden kaum 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 ein Kartenscheme 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. Damit ändert sich die Gebührenlogik grundlegend: Kartenakzeptanz wird in der Regel als Prozentsatz vom Umsatz plus Fixum abgerechnet, A2A-Anbieter rechnen meist einen festen Betrag je Transaktion ab. Ob daraus ein Kostenvorteil wird, hängt am durchschnittlichen Warenkorbwert: Ein fester Betrag je Transaktion wirkt umso stärker, je höher der Bon ist. Belastbar ist diese Rechnung nur mit den eigenen Konditionen aus dem Acquiring-Vertrag und dem Angebot des A2A-Anbieters, nicht mit Listenpreisen aus Anbieterwerbung.

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 und eine frühere Verfügbarkeit des Geldes. Wer Pay-by-Bank in den Standard-Checkout-Mix aufnimmt - nicht nur als Nischenoption für Bestandskunden -, sieht diese Effekte früher, weil der Anteil der Transaktionen überhaupt erst eine auswertbare Größe erreicht. Die Bewertung gehört anschließend in die eigene Deckungsbeitragsrechnung: Gebühren, Ausfallquote, Retourenverhalten und Bearbeitungsaufwand je Zahlungsart nebeneinander, über einen Zeitraum, der saisonale Ausreißer abdeckt.

Für die Conversion zählt vor allem die wahrgenommene Reibung: wie viele Schritte zwischen dem Klick auf den Bezahlbutton und der Bestätigung liegen, wie zuverlässig der Kunde aus der Bank-App in den Shop zurückkommt und wie verständlich die Fehlermeldung ist, wenn die Bank abbricht. Diese Größen sind messbar - Abbruchquote je Schritt, Anteil erfolgreicher Rückleitungen, Dauer bis zur Bestätigung - und sie unterscheiden sich je Bank erheblich. Wer Pay-by-Bank einführt, instrumentiert den Flow deshalb vom ersten Tag an und hält ihn im A/B-Test gegen die bestehende Kartenstrecke, statt Anbieterkennzahlen aus fremden Sortimenten zu übernehmen.

Auch der Zeitpunkt der Gutschrift ist betriebswirtschaftlich relevant. Für Echtzeitüberweisungen in Euro schreibt die Verordnung (EU) 2024/886 vor, dass der Zahlungsdienstleister des Zahlungsempfängers den Betrag innerhalb von zehn Sekunden nach Eingang des Zahlungsauftrags verfügbar macht. Gegenüber Kartenumsätzen, die je nach Acquiring-Vertrag erst Tage später ausgezahlt werden, sinkt damit das gebundene Working Capital. Wer parallel an adaptivem Bildladen und am Checkout-Speed arbeitet, schöpft die Conversion-Reserven von Pay-by-Bank am sichersten aus - Performance und Zahlart sind in der wahrgenommenen Reibung verschwistert.

PSD3 und PSR: Was sich 2026 ändert

Die EU-Kommission hat am 28. Juni 2023 ein Paket aus zwei Rechtsakten vorgeschlagen: eine überarbeitete Richtlinie PSD3 und eine direkt anwendbare Verordnung PSR (Payment Services Regulation) (EU-Kommission). Die Seite der Kommission zum Paket führt weiterhin diesen Vorschlagsstand; ein Datum für die Veröffentlichung im Amtsblatt oder für die Anwendung nennt sie nicht. Für die Planung heißt das: Die inhaltliche Richtung ist erkennbar, der Zeitplan ist offen - ein Projekt, das auf ein bestimmtes Anwendungsdatum hin geschnitten wird, plant auf Sand.

Für Online-Shops und ihre Payment-Service-Provider sind drei Punkte des Vorschlags relevant. Erstens sollen Open-Banking-APIs als primärer Zugangskanal für Drittanbieter (TPPs) verankert werden - Screen-Scraping-Fallbacks würden weiter eingeschränkt. Zweitens ist ein Permission-Dashboard für Endkunden vorgesehen: Verbraucher sollen sehen können, welche Drittanbieter Zugriff auf ihre Konten haben, und Berechtigungen widerrufen können. Drittens enthält der Entwurf ein TPP-Diskriminierungsverbot - Banken sollen lizenzierte Drittanbieter nicht durch unverhältnismäßige Friktion ausbremsen dürfen. Solange das Verfahren läuft, gilt für den Betrieb unverändert die PSD2 samt den technischen Regulierungsstandards.

1. 28.06.2023 - Vorschlag der Kommission: PSD3 als Richtlinie, PSR als direkt anwendbare Verordnung (EU-Kommission)
2. Offen - Abschluss des Gesetzgebungsverfahrens und Veröffentlichung im Amtsblatt
3. Offen - Übergangsfristen für die Pflichten aus der PSR
4. Offen - nationale Umsetzung der PSD3 als Richtlinie
5. Heute verbindlich - PSD2 samt technischen Regulierungsstandards und die Verordnung (EU) 2024/886 zu Echtzeitüberweisungen

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. Regulatorisch ist beim AIS-Zugriff die Frist im Blick zu behalten: Greift der Nutzer über einen Kontoinformationsdienstleister auf seine Kontodaten zu, verlangen die technischen Regulierungsstandards eine erneute starke Kundenauthentifizierung, sobald seit dem letzten Zugriff mehr als 180 Tage vergangen sind (Delegierte Verordnung (EU) 2018/389 in der Fassung der Delegierten Verordnung (EU) 2022/2360). Für beide Modelle gilt außerdem: explizite Einwilligung des Kontoinhabers, Zweckbindung, klare Aufbewahrungsfristen und ein Berechtigungsüberblick im Endkunden-Frontend sind Voraussetzung für eine 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).

Wie sich die Zahlungsarten im Euroraum verteilen, zeigt die Zahlungsstatistik der Europäischen Zentralbank für das zweite Halbjahr 2025: Auf Kartenzahlungen entfielen 57 Prozent aller bargeldlosen Zahlungen, auf Überweisungen 21 Prozent, auf Lastschriften 14 Prozent und auf E-Geld-Zahlungen 6 Prozent (EZB). Nach Stückzahl liegt die Karte damit deutlich vorn - der Hebel von A2A liegt weniger im Verdrängen der Karte als im Aufbau einer zweiten Schiene für die Warenkörbe, bei denen sie trägt. Wer international verkauft, sollte nationale Verfahren als Teil der 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 führen - 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 - eine Fernzahlung über höchstens 30 EUR; ohne erneute SCA bleibt es, solange die seit der letzten starken Kundenauthentifizierung ausgelösten Zahlungen zusammen 100 EUR nicht übersteigen oder seither nicht mehr als fünf Vorgänge ausgelöst wurden (Delegierte Verordnung (EU) 2018/389, Artikel 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 wirtschaftlicher Vorteil: keine Chargeback-Gebühren des Kartenschemes, 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, Abgleich von IBAN und Name) der wichtigste technische Schutz auf Seite des Zahlers; Zahlungsdienstleister im Euroraum kommen dieser Pflicht aus der Verordnung (EU) 2024/886 seit dem 9. Oktober 2025 nach - 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.