Wero im Onlineshop: Kann Europas neues Zahlungssystem PayPal ersetzen oder ergänzen?
VeröffentlichtKategorie: E-Commerce
Veröffentlicht am 07.05.2026
Einleitung
Wero wird schnell als „europäisches PayPal“ bezeichnet. In echten Shop-Projekten hilft mir diese Abkürzung aber selten, weil Wero technisch anders tickt: Es ist keine klassische Wallet-Zwischenschicht, sondern zielt auf direkte Zahlungen zwischen Bankkonten.
Für Shopbetreiber heißt das: Wero kann langfristig eine starke Ergänzung werden – aber nur, wenn die Integration sauber umgesetzt ist. Der wichtigste Unterschied im Alltag: Der Shop bekommt den finalen Zahlungsstatus oft zeitversetzt. Wer das ignoriert, produziert bezahlte Bestellungen, die doch nicht bezahlt sind – oder umgekehrt.
Was ist Wero – in einem Satz?
Wero ist ein europäisches Zahlverfahren der European Payments Initiative (EPI), bei dem Kunden die Zahlung in ihrer Banking-App bestätigen und das Geld über Echtzeitüberweisung (SEPA Instant) direkt zwischen Bankkonten bewegt wird.
Warum entsteht Wero?
Europa ist im Online-Payment stark abhängig von Karten- und Wallet-Ökosystemen, die nicht in Europa gesteuert werden. Das merkt man in der Praxis an Gebührenmodellen, an sich ändernden Regeln und an harten Entscheidungen bei Risikothemen.
Wero soll eine zusätzliche, europäische Schiene schaffen: Bankkonto statt Karte, Banking-App statt Wallet-App, Echtzeit statt mehrtägiger Abwicklung. Wichtig: Das ist ein Aufbauprojekt. Abdeckung und Nutzererlebnis hängen derzeit noch stark von Land, Bank und PSP ab.
Wero vs. PayPal: Was ist konkret anders?
PayPal
- PayPal ist die Zwischenplattform.
- Kunde zahlt in/über PayPal, PayPal regelt den Rest.
- Für Shops fühlt es sich oft „sofort final“ an.
Wero
- Zahlung geht direkt zwischen Bankkonten.
- Kunde bestätigt in der Banking-App.
- Der endgültige Status kommt häufig erst danach automatisch im Shop an.
So läuft die Zahlung für Kunden ab (praxisnah)
Der Flow ist für Kunden relativ schlicht – und genau das ist die Idee. Typisch ist:
- Kunde wählt Wero im Checkout.
- Der Shop startet eine Zahlungsanfrage und leitet weiter (Redirect = kurze Weiterleitung zur Bank-/Zahlseite).
- Am Desktop häufig: QR-Code scannen. Am Smartphone oft: Banking-App öffnet direkt.
- Kunde bestätigt die Zahlung in der Banking-App.
- Kunde kommt zurück in den Shop.
Wie integriere ich Wero in einen Onlineshop?
In der Praxis sehe ich zwei Wege. Der erste ist der Standard, der zweite ist interessant, wenn du einen individuelleren Checkout hast.
1) Über einen PSP (für die meisten Shops)
Ein PSP (Payment Service Provider) ist dein Zahlungsanbieter, der technische Anbindung, Statusmeldungen und häufig auch Teile von Risiko/Compliance mit abdeckt. Typische Namen, die Wero in ihre Payment-Methoden integrieren (je nach Land/Rollout): Unzer, PAYONE, Mollie, Stripe, Worldline, PPRO.
- Wero im Checkout aktivieren (je nach System als zusätzliche Zahlart)
- Redirect/QR/Deep-Link wird vom PSP bereitgestellt
- Shop bekommt automatisch Bescheid, wenn die Zahlung abgeschlossen wurde (Webhook)
- Status lässt sich zusätzlich per API abfragen
2) Serverseitig / individuell (für Headless & Eigenbau)
Wenn du Headless-Commerce oder einen sehr eigenen Checkout betreibst, ist Wero grundsätzlich gut geeignet, weil der Ablauf klar API-getrieben ist. Du musst aber mehr Verantwortung übernehmen: Statuslogik, Fehlerfälle, Wiederholungen und Refunds.
Beispiel: Wero-Checkout-Element (Unzer UI Components)
Das folgende Beispiel zeigt, wie ein Wero-Element im Checkout aussehen kann. Es erzeugt ein UI-Element und stößt den Flow an. Keys/IDs sind Platzhalter:
<script type="module" src="https://static-v2.unzer.com/v2/ui-components/index.js"></script>
<unzer-payment publicKey="s-pub-xxxxxxxxxx" locale="de-DE">
<unzer-wero></unzer-wero>
</unzer-payment>
<unzer-checkout>
<button type="submit">Jetzt bezahlen</button>
</unzer-checkout>API-Beispiele: Was passiert im Backend?
Je PSP sehen die Endpunkte anders aus. Die Denke ist fast immer gleich: Zahlart bereitstellen, Zahlung starten, Status abholen. Beispielhaft (Prinzip):
POST /v1/types/wero
Content-Type: application/json
{
"merchantId": "m-123",
"country": "DE"
}POST /v1/payments/charges
Content-Type: application/json
Idempotency-Key: 8b2d7a2a-5a44-4c79-9c9a-7d4c0c6c2d31
{
"amount": "20.00",
"currency": "EUR",
"returnUrl": "https://www.scinet.eu/checkout/return",
"orderId": "ORD-100045",
"paymentMethod": "wero"
}GET /v1/payments/{paymentId}
Accept: application/jsonKurz erklärt: Idempotency-Key
Das ist ein „Doppel-Klick-Schutz“ fürs Backend. Wenn der Kunde oder dein System denselben Create-Call aus Versehen zweimal abschickt, sorgt der Key dafür, dass nicht zwei Zahlungen entstehen.
Wichtiger Punkt: Die returnUrl ist keine Zahlungsbestätigung
Das ist der Fehler, den ich am häufigsten sehe, wenn Shops neue Zahlarten anbinden: „Kunde ist zurück auf der Danke-Seite = bezahlt“. Das stimmt nicht zuverlässig.
- Der Kunde kann den Browser schließen oder abbrechen.
- Die Bank-App kann später bestätigen.
- Netzwerk kann hängen, Redirect kommt, Status noch nicht.
Praxis-Regel: Ich markiere eine Bestellung erst dann als bezahlt, wenn mein Server den finalen Status bekommen hat – automatisch (Webhook) oder notfalls per Statusabfrage.
Zahlungsstatus: welche Zustände du realistisch brauchst
Du musst nicht in „Bankensprache“ denken. Es reicht, wenn dein Shop diese Zustände sauber abbildet – weil sie im Alltag wirklich vorkommen:
pending
Zahlung läuft. Kunde hat noch nicht bestätigt oder die Bestätigung ist noch nicht bei dir angekommen.
authorized
Je nach Flow kann ein Zwischenstatus auftauchen. Behandle ihn als „noch nicht final“.
paid
Final bezahlt. Ab hier darfst du liefern/fulfille(n).
failed
Hat nicht geklappt. Kunde muss neu versuchen oder andere Zahlart wählen.
cancelled / expired
Kunde bricht ab oder der Vorgang läuft in ein Timeout. Order sollte nicht als bezahlt enden.
refunded
Rückerstattung ist durch. Kann voll oder teilweise sein.
Refunds und Teilrefunds: was Shops wirklich brauchen
In Shop-Projekten sind Rückerstattungen kein Randfall. Retouren, Teillieferungen, Kulanz, Stornos – das passiert jeden Tag. Deshalb ist für mich wichtig, dass Refunds nicht als „ein Button“ betrachtet werden, sondern als sauberer Ablauf mit Status und Limits.
Teilrefunds kurz erklärt
Du erstattest einen Teilbetrag zurück, z. B. weil nur ein Artikel retourniert wurde. Technisch muss dein Shop verhindern, dass insgesamt mehr erstattet wird als ursprünglich bezahlt.
POST /v1/payments/{paymentId}/refunds
Content-Type: application/json
Idempotency-Key: 9a63a4b1-1f63-4a70-b8d2-6b0e2d5b3a1c
{
"amount": "7.50",
"currency": "EUR",
"reason": "partial_return"
}Warum Wero für manche Branchen interessant werden könnte
Ich habe in Projekten immer wieder erlebt, dass bestimmte Branchen bei PayPal oder Klarna früher oder später in harte Einschränkungen laufen. Beispiele, die regelmäßig betroffen sind: E-Zigaretten/Tabak, CBD-nahe Produkte, bestimmte Supplements oder einzelne digitale Güter-Kategorien – je nach Anbieter, Land und Risikopolitik.
Was dann passiert, ist im Shop-Alltag unerquicklich: Kontosperrungen, plötzliche Kündigungen, eingefrorene Guthaben oder das Wegbrechen einer wichtigen Zahlart mitten in der Saison.
Wenn du in einer „heikleren“ Kategorie unterwegs bist, sehe ich Wero weniger als Heilsbringer, sondern als mögliche zusätzliche Zahlart, die du testen und schrittweise ausbauen kannst – sobald Abdeckung und PSP-Features passen.
Kritische Einordnung: Wo Wero aktuell noch hakt
Damit der Artikel nicht nach Zukunftsmusik klingt: Wero ist nicht automatisch überall verfügbar. In der Praxis stoße ich aktuell vor allem auf diese Themen:
- Abdeckung: Nicht jede Bank, nicht jedes Land, nicht jeder PSP-Account hat sofort vollen Support.
- Unterschiedliche Checkout-Erfahrung: Banking-Apps sind nicht einheitlich – das kann sich auf Conversion auswirken.
- Unterschiedliche Feature-Tiefen: Manche PSPs bieten zuerst Basis-Flow, später kommen Details wie bestimmte Refund-Optionen oder Statusgranularität.
- Operative Reife: Wenn du Wero einführst, brauchst du Monitoring: Wie viele hängen in pending? Wie viele laufen in expired?
Ersetzt Wero PayPal?
Kurze Antwort: aktuell eher nicht. PayPal ist extrem verbreitet, international und in vielen Zielgruppen Standard. Wero startet dagegen schrittweise und braucht Zeit, bis Abdeckung und Gewohnheit im Checkout wirklich breit sind.
Was ich realistisch sehe: Wero als Ergänzung. Als zusätzliche Zahlart, die je nach Zielmarkt und Kundenprofil Vorteile bringt – besonders, wenn du Bank-zu-Bank-Zahlungen im Checkout haben willst und dein PSP das stabil abbildet.
Handlungsempfehlung: So gehe ich in Projekten vor
Für Shopbetreiber
- PSP fragen: Welche Länder/Banken deckt ihr heute wirklich ab?
- KPIs definieren: Abbruchrate, pending-Quote, Zeit bis „paid“.
- Support vorbereiten: Was sieht der Kunde, wenn er zurückkommt, aber der Status noch läuft?
Für Entwickler
- Bestellung erst nach serverseitigem „paid“ freigeben.
- „Automatisch Bescheid bekommen“ sauber bauen: Webhook prüfen, Duplikate abfangen.
- Fallback: Status abfragen, wenn Events fehlen.
- Refunds/Teilrefunds als Standardfall testen.
Fazit
Wero ist deutlich mehr als nur ein neues Wallet. Europa baut hier gerade eine moderne Payment-Infrastruktur, bei der Geld direkt zwischen Bankkonten übertragen wird und der Kunde in seiner Banking-App bestätigt.
Ob Wero PayPal ergänzt oder teilweise ersetzt, entscheidet sich nicht am Label „europäisch“, sondern an ganz praktischen Dingen: Verfügbarkeit, Checkout-Erlebnis, stabile Statusmeldungen und eine saubere Shop-Logik, die mit zeitversetzten Zahlungsbestätigungen umgehen kann.
