Wero in WooCommerce integrieren: PAYONE, Stripe & PSP-Vergleich (Teil 3)

Das Problem: Wero klingt gut – aber wie bindet man es technisch in den eigenen Shop ein? Welcher Payment-Service-Provider passt am besten? Und was unterscheidet PAYONE, Stripe, Worldline und Nexi wirklich?

Die Lösung: Wero wird in der Praxis fast immer über einen PSP eingebunden, nicht direkt. Die Wahl des PSP entscheidet über Kosten, Entwicklerfreundlichkeit und Flexibilität.

Das Ergebnis: Ein klarer Vergleich der wichtigsten PSPs für Wero – mit Code-Beispielen, Hinweisen zu States und Idempotenz, und einer ehrlichen Einschätzung, wann welcher Anbieter passt.

Warum Wero über Payment-Service-Provider?

Wero ist in der Praxis nur über PSPs sinnvoll nutzbar. Eine direkte Integration wäre technisch möglich, würde aber eigene Bank- oder Acquirer-Anbindungen erfordern – für die meisten Händler unrealistisch und betrieblich aufwändig. PSPs übernehmen diese Infrastruktur und bieten eine standardisierte API darüber.

Für Shops, Headless-Systeme und individuelle Backends ist die Wahl des PSP entscheidend – sie beeinflusst Kosten, API-Qualität, verfügbare Plugins und die langfristige Wartbarkeit.

Warum klassische europäische PSPs?

Günstigere Gebühren als Stripe
Direkte europäische Infrastruktur
Enge Zusammenarbeit mit Banken und EPI
Bessere Konditionen bei hohem Volumen
Ideal für Enterprise-Shops und Händler mit >10.000 Transaktionen/Monat

Technischer Überblick: So funktioniert Wero über einen PSP

Alle PSPs arbeiten nach dem gleichen Grundschema:

1. Payment anlegen

Shop-Backend → PSP-API: Betrag, Order-ID, Zahlungsmethode = Wero

2. Redirect zu Wero / Bank-App

Kunde bestätigt Zahlung per Bank-App / Wero-Flow

3. Webhook / Notify

PSP → Shop-Backend: Zahlungsstatus mit Signatur

4. Shop aktualisiert Bestellung

Order-Status auf bezahlt setzen – erst nach Webhook-Bestätigung

Return-URL ≠ Zahlungsbestätigung

Das ist ein klassischer Integrationsfehler: Die Return-URL, auf die der Kunde nach dem Wero-Flow weitergeleitet wird, dient nur der UX – sie zeigt dem Nutzer, dass er zurück im Shop ist. Den tatsächlichen Zahlungsstatus darf sie nicht bestimmen. Der Redirect kann ausbleiben, wenn der Nutzer den Tab schließt oder die Verbindung abbricht.

Die einzige verlässliche Quelle für den Zahlungsstatus ist der Webhook vom PSP.

Die Payment State Machine

Zahlungen sind nicht binär. PSPs liefern mehrere Status, und der richtige Umgang damit entscheidet über die Stabilität des Systems:

Status	Bedeutung	Aktion im Shop
`pending`	Zahlung angelegt, Kunde noch nicht fertig	Bestellung reserviert, nicht bestätigt
`authorized`	Betrag reserviert, noch nicht gebucht	Warten auf Capture
`captured` / `paid`	Geld gebucht	Bestellung als bezahlt markieren
`failed`	Zahlung fehlgeschlagen	Kunde benachrichtigen, Retry anbieten
`expired`	Kunde hat nicht in Zeit bestätigt	Bestellung stornieren
`cancelled`	Kunde hat abgebrochen	Bestellung stornieren
`refunded`	Rückerstattung ausgelöst	Buchung stornieren

Ein System, das nur success und failed kennt, ist nicht produktionsreif.

Async statt Sync

Auch wenn der Flow für Nutzer wie eine sofortige Zahlung wirkt, ist die technische Verarbeitung asynchron. Zwischen Kundenbestätigung in der Bank-App und der Webhook-Zustellung liegen Sekunden bis wenige Minuten. Systeme müssen so gebaut sein, dass sie Status verzögert oder mehrfach erhalten können – ohne doppelte Verarbeitung.

Webhooks: Idempotenz und Sicherheit

Signaturprüfung ist Pflicht

Webhooks müssen immer über Signaturen verifiziert werden. Ohne diese Prüfung kann jeder beliebige Request als „Zahlung erfolgreich” eingespielt werden. Jeder PSP implementiert das leicht unterschiedlich (HMAC-SHA256, HMAC-SHA512), aber das Prinzip ist überall gleich: Request nur verarbeiten, wenn die Signatur stimmt.

Idempotente Verarbeitung

PSPs senden Webhooks im Fehlerfall mehrfach – das ist kein Bug, sondern das erwartete Verhalten bei At-least-once-Delivery. Ohne Idempotenz können Bestellungen doppelt als bezahlt markiert oder Refunds mehrfach gebucht werden.

// Webhook verarbeiten – mit Signaturprüfung, Idempotenz und Fehlerfall
app.post('/webhooks/payment', verifySignature, async (req, res) => {
  const { id: eventId, status, method, reference, amount } = req.body;

  if (method !== 'wero') {
    return res.sendStatus(200); // andere Methoden ignorieren
  }

  // Idempotenz: Event bereits verarbeitet?
  if (await isEventProcessed(eventId)) {
    return res.sendStatus(200);
  }

  switch (status) {
    case 'captured':
    case 'paid':
      await markOrderPaid(reference);
      await markEventProcessed(eventId);
      break;
    case 'failed':
    case 'expired':
    case 'cancelled':
      await markOrderFailed(reference, status);
      await markEventProcessed(eventId);
      break;
    case 'refunded':
      await processRefund(reference, amount);
      await markEventProcessed(eventId);
      break;
    default:
      // unbekannter Status → loggen, nicht verarbeiten
      logger.warn({ eventId, status }, 'Unbekannter Wero-Webhook-Status');
  }

  res.sendStatus(200);
});

Monitoring

Fehlgeschlagene Webhooks oder Payment-Abbrüche müssen sichtbar sein – sonst entstehen stille Fehler im Bestellprozess. Das Minimum: ein Log-Aggregator, der Webhook-Fehler und unerwartete Status-Kombinationen aufzeichnet. PSPs bieten oft ein Webhook-Dashboard mit Retry-Übersicht; das sollte ins interne Monitoring-System gespiegelt werden.

PAYONE – Plugins und direkte Integration für deutsche Shops

Integration

REST-API (neue Commerce Platform, Worldline-Basis) und ältere Server API (URL-encoded)
WooCommerce-Plugin vorhanden, Shopware-6-Plugin ab v7.1.0
paymentProductId 900 für Wero
Authorization + Capture möglich (für physische Ware mit Versandverzögerung)

Entwickler-Features

Webhooks mit HMAC-SHA-512-Signatur
Retry-Schedule: 5 Versuche über 24h
Direct Sale und Authorization + Capture
Test-Accounts per Sandbox-Portal

Vorteile

Stark im deutschen Markt, günstige Transaktionskosten
Stabiler Plugin-Support für WooCommerce und Shopware
Auth-Fenster von 7–10 Tagen für physische Ware

Herausforderungen

Zwei parallele API-Systeme (Commerce Platform + Legacy Server API) mit unterschiedlichen Strukturen
Self-Service-Onboarding nicht möglich; Vertragsabschluss nötig
Onboarding typisch 2–6 Wochen

VR Payment – banknahe Infrastruktur, günstige Konditionen

VR Payment ist enger an die Volksbanken/Raiffeisenbanken-Infrastruktur angebunden als PAYONE und hat direkten Zugang zur EPI-nahen Abwicklung. Das macht sich in den Gebühren bemerkbar – VR Payment ist für viele DACH-Händler günstiger als PAYONE, hat dafür weniger fertige Plugins.

Integration

Moderne REST-API
Direkter Wero-Support über EPI-nahe Infrastruktur
Redirect-Flow mit Checkout-URL, Status-Push mit Signaturprüfung

Vorteile

Sehr günstige Transaktionskosten (ca. 0,77 % + 0,15 € fix)
Ideal für Shops mit Bezug zum Bankensektor und hohem Volumen
Stabiler Support für Instant Payments

Herausforderungen

Wenige fertige Plugins; mehr API-Arbeit nötig
Sandbox teils nur auf Anfrage
Kein Self-Service-Onboarding

Worldline – Enterprise und Omnichannel

Worldline betreibt die Plattform, auf der auch PAYONEs neue Commerce Platform basiert. Die APIs sind nahezu identisch. Der Unterschied liegt im Einsatzbereich: Worldline adressiert primär Enterprise-Händler mit Omnichannel-Bedarf (Online, POS, QR, später NFC).

Integration

Leistungsfähige REST-API, Hosted Checkout und Direct API
Omnichannel-ready: Online, POS, QR, später NFC
Server-SDKs für Java, .NET, Python, Node.js, PHP, Ruby

Entwickler-Features

Moderne Webhooks mit HMAC-SHA256-Signatur
Tokenization für Stammkunden
Endpoint-Verifizierung bei Webhook-Registrierung

Vorteile

Sehr robust für große Händler mit Multi-Channel-Betrieb
Dieselbe API-Struktur wie PAYONE Commerce Platform – wer eine kennt, kennt beide

Herausforderungen

Komplexer Setup-Prozess, Preisverhandlungen je nach Volumen
Weniger geeignet für kleine Shops ohne dediziertes Integrationsteam

Nexi – modernes API-Design für Headless und SaaS

Nexi hat von allen klassischen PSPs das modernste API-Design: konsistente REST-Strukturen, gutes SDK-Ökosystem, klare Fehlerformate. Das macht Nexi besonders attraktiv für Teams, die saubere Entwicklererfahrung höher gewichten als günstigste Gebühren.

Integration

Elegante REST-API, flexibel für Headless, Mobile Apps, Microservices
Klare Payment-Method-Definition für Wero
Schnelles Webhook-System, umfangreiche Logging-Umgebung

Vorteile

Technisch moderner als PAYONE oder VR Payment
Gut geeignet für SaaS, Marktplätze, Headless-Commerce
Steigende Händlerbasis in Europa (stark in DACH und Nordeuropa)

Herausforderungen

Wenige fertige Shop-Plugins für WooCommerce/Shopware (via Drittanbieter)
Onboarding teils strenger als bei anderen PSPs

Worldpay / Global Payments – neuer EPI-Acquirer seit März 2026

Worldpay ist seit März 2026 offizielles EPI-Mitglied. Relevant primär für Händler mit globalem Footprint, die Worldpay bereits nutzen oder internationale Expansion planen.

Vorteile

Starke internationale Präsenz (UK, EU, USA)
Enterprise-grade Infrastruktur
Für bestehende Worldpay-Kunden: Wero als Erweiterung des bestehenden Vertrags

Herausforderungen

Wero-spezifische Dokumentation noch im Aufbau
Vor allem für Händler interessant, die ohnehin Worldpay nutzen

Stripe – Plattform statt PSP

Stripe ist mehr als ein PSP – es ist eine komplette Payment-Plattform mit Billing, Subscriptions, Tax, Fraud und mehr. Wer Stripe ohnehin nutzt, integriert Wero als Erweiterung des bestehenden Systems, nicht als eigenes Projekt.

Integration

Exzellente REST-API, beste Dokumentation und SDKs
Wero seit Anfang 2025 live in Deutschland; BE, FR, NL folgen 2026
automatic_payment_methods: true zeigt Wero für deutsche Kunden automatisch
Stripe CLI für lokale Webhook-Entwicklung

Entwickler-Features

Webhooks mit HMAC-SHA256, Stripe-Signature-Header mit Timestamp (Replay-Schutz)
Umfangreiches Testing-Framework, keine separaten Wero-Sandbox-Credentials nötig
stripe.webhooks.constructEvent() bündelt Signaturprüfung, Body-Parsing und Fehlerhandling

Vorteile

Beste Developer-Experience, perfekt für Headless (Next.js, Node, Serverless)
Schneller Start: bestehende Stripe-Kunden aktivieren Wero im Dashboard ohne Code
Top WooCommerce-Plugin

Herausforderungen

Deutlich höhere Gebühren als PAYONE/VR Payment (ca. 1,1–1,4 % + Fixbetrag)
Wero verliert hier seinen Kostenvorteil gegenüber PayPal
Keine Subscriptions mit Wero, kein Express Checkout Element

PSP-Vergleich

Feature	PAYONE	VR Payment	Worldline	Nexi	Worldpay	Stripe
WooCommerce	Gut	Schwach	Mittel	Schwach	Schwach	Sehr gut
Headless-API	Mittel	Mittel	Gut	Gut	Gut	Sehr gut
Gebühren	Gut	Sehr gut	Mittel	Mittel	Mittel	Schwach
API-Qualität	Solide	Modern	Sehr gut	Sehr gut	Gut	Exzellent
Auth/Capture	Ja	Ja	Ja	Ja	Ja	Nein (Wero)
Self-Service	Nein	Nein	Nein	Nein	Nein	Ja
Ideal für	DACH, Plugins	Banknah, Volumen	Enterprise, Omnichannel	Headless, SaaS	Global Enterprise	Start-ups, Bestands-Stripe

Wero-Kostenvergleich

PSP	Kostenstruktur	Wero-Kostenvorteil erhalten?
PAYONE	Günstig, vertragsabhängig	Ja
VR Payment	~0,77 % + 0,15 € fix	Ja
Worldline	Mittel, verhandlungsabhängig	Ja
Nexi	Mittel, markttypisch	Ja
Worldpay	Mittel, Enterprise-orientiert	Ja
Stripe	ca. 1,1–1,4 % + Fix	Nein – Kostenvorteil gegenüber PayPal minimal

Code-Beispiele

Beispiel 1: WooCommerce mit PAYONE

// PAYONE WooCommerce Plugin (payone-gmbh/woocommerce-3):
// 1. Plugin installieren
// 2. In WooCommerce > Einstellungen > Zahlungen:
//    API-Credentials eingeben, Zahlart "Wero" aktivieren
// 3. Webhooks werden vom Plugin automatisch verarbeitet

Beispiel 2: Headless-Shop mit Node.js (generischer PSP-Flow)

// Payment anlegen
const createPayment = async (order) => {
  const res = await psp.createPayment({
    method: 'wero',
    reference: order.id,
    amount: order.total,
    currency: 'EUR',
    returnUrl: `${BASE_URL}/checkout/return`, // nur UX, kein Status
    notifyUrl: `${BASE_URL}/webhooks/payment`, // hier kommt der echte Status
  });

  return { redirectUrl: res.redirectUrl };
};

// Webhook verarbeiten – mit Idempotenz
app.post('/webhooks/payment', verifySignature, async (req, res) => {
  const { id: eventId, status, method, reference } = req.body;

  if (method !== 'wero') return res.sendStatus(200);
  if (await isEventProcessed(eventId)) return res.sendStatus(200);

  if (status === 'paid' || status === 'captured') {
    await markOrderPaid(reference);
    await markEventProcessed(eventId);
  } else if (['failed', 'expired', 'cancelled'].includes(status)) {
    await markOrderFailed(reference, status);
    await markEventProcessed(eventId);
  }

  res.sendStatus(200);
});

Beispiel 3: Stripe-Integration

import Stripe from 'stripe';
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

// Payment anlegen
const session = await stripe.checkout.sessions.create({
  payment_method_types: ['wero'],
  line_items: [{
    price_data: {
      currency: 'eur',
      product_data: { name: 'Order #123' },
      unit_amount: 4999,
    },
    quantity: 1,
  }],
  mode: 'payment',
  success_url: `${BASE_URL}/success`, // nur UX
  cancel_url: `${BASE_URL}/cancel`,
});

// Webhook – Stripe kümmert sich um Signaturprüfung
app.post('/webhooks/stripe', express.raw({ type: 'application/json' }), (req, res) => {
  const event = stripe.webhooks.constructEvent(
    req.body,
    req.headers['stripe-signature'],
    process.env.STRIPE_WEBHOOK_SECRET
  );

  if (event.type === 'checkout.session.completed') {
    const session = event.data.object;
    markOrderPaid(session.metadata.orderId);
  }

  res.sendStatus(200);
});

Refunds und Reconciliation

Rückerstattungen laufen nicht automatisch wie bei Kreditkarten, sondern müssen aktiv über den PSP angestoßen werden. Jeder PSP hat dafür eine eigene API – im Stripe Dashboard geht das ohne Code, bei PAYONE und Worldline via API-Call mit Pflichtfeldern (z. B. refundReason).

Für die Buchhaltung ist außerdem wichtig, dass Transaktionen sauber mit Bestellungen abgeglichen werden (Reconciliation). PSPs liefern dafür Settlement-Reports. Tools wie PayJoe übertragen Stripe- und PAYONE-Settlements automatisch nach DATEV.

Ein Wero-Refund verhält sich buchhalterisch wie eine Rücküberweisung auf das ursprüngliche Konto – kein Guthaben, keine Kartenrückbuchung.

Multi-PSP-Strategie

Größere Händler setzen oft auf mehrere PSPs parallel, um Ausfälle abzufangen oder Kosten zu optimieren. Wero kann dabei je nach Region oder Händlerlogik unterschiedlich geroutet werden: Stripe für internationale Kunden und schnelles Onboarding, PAYONE oder VR Payment für deutsches Volumen mit niedrigen Gebühren. Das erfordert eine Routing-Schicht im Backend, ist aber bei hohen Transaktionsvolumen wirtschaftlich sinnvoll.

Sandbox und Produktion

Viele PSPs haben vereinfachte Test-Flows in der Sandbox – gerade bei Wero kann der simulierte QR-Code-Flow vom Produktionsverhalten abweichen. Plane Zeit für Tests im Production-ähnlichen Staging-Environment ein, bevor du live gehst. Stripes Testmodus ist hier am nächsten an Produktion – der Flow ist identisch, nur mit Test-Cards und simulierten Events.

Entscheidungshilfe

Wähle PAYONE oder VR Payment wenn:

Du hohe Transaktionsvolumen hast und Gebühren entscheidend sind
Du WooCommerce oder Shopware nutzt
Du primär DACH-Markt bedienst

Wähle Worldline oder Nexi wenn:

Du Enterprise-Features oder Omnichannel (Online + POS) planst
Du eine moderne API für Headless oder SaaS-Architektur brauchst
Du EU-weit expandieren willst

Wähle Stripe wenn:

Du bereits Stripe-Kunde bist (Wero als Dashboard-Aktivierung, kein Mehraufwand)
Developer-Speed wichtiger ist als optimale Kosten
Du wenige Transaktionen hast und den Stripe-Stack insgesamt nutzt

Einordnung

Die technische Integration von Wero ist kein großes Problem – der Redirect-Flow ist bekannt, die PSP-APIs sind ausgereift, und für gängige Shop-Systeme gibt es fertige Plugins.

Die eigentliche Herausforderung liegt woanders: richtige Wahl des PSP, sauberes State-Handling, idempotente Webhook-Verarbeitung und stabiles Monitoring. Wer das vernachlässigt, baut eine Integration, die im Prototyp funktioniert und im Produktionsbetrieb stille Fehler produziert.

Wero selbst bleibt dabei für den Endkunden immer gleich: Zahlung in der Bank-App bestätigen – fertig.

Im vierten Teil geht es tiefer in den technischen Checkout-Flow: Redirect-Logik, Webhook-Verarbeitung, Auth vs. Direct Sale und die typischen Stolperfallen.