BLIK, iDEAL, Bancontact: Lokale Zahlungsmethoden, die lokale Märkte erschließen

Die Abdeckung der Zahlungswege durch Gateways (Mollie, Stripe, Przelewy24, Adyen) entspricht den Methoden, die diese Module zum Zeitpunkt der Veröffentlichung unterstützten; die Verfügbarkeit hängt von Ihrem Händlerkonto ab. Prüfen Sie daher die aktuelle Liste im Dashboard des Anbieters, bevor Sie sich festlegen.

Hier ist die unbequeme Wahrheit über grenzüberschreitenden Verkauf mit einem PrestaShop-Shop: In den Märkten, in denen Sie die meisten Bezahlvorgänge verlieren, kann der Kunde häufig gar nicht mit den Methoden bezahlen, die Sie anbieten. Ein belgischer Käufer mit einer reinen Bancontact-Debitkarte kann sie nicht einfach in ein Visa-Feld eingeben. Ein niederländischer Käufer, der seit fünfzehn Jahren iDEAL nutzt, sieht ein Kartenformular und schließt still den Tab. Ein polnischer Käufer unter vierzig greift auf dem Smartphone zu BLIK, findet es nicht und geht davon aus, dass Ihr Shop ausländisch und riskant ist. Das ist kein Preisproblem und kein Problem fehlender Vertrauenssiegel. Es ist ein Problem des Zahlungswegs, und in PrestaShop lässt es sich konkret konfigurieren und beheben.

In diesem Leitfaden geht es gezielt darum, BLIK, iDEAL und Bancontact, die drei dominierenden lokalen Zahlungswege in Polen, den Niederlanden und Belgien, in einer PrestaShop-Kasse live zu schalten: welches Gateway-Modul welche Methode tatsächlich bereitstellt, wo die Einstellungen im Backoffice liegen und wie Sie jede Methode nur den Kunden anzeigen, die sie auch nutzen. Den breiteren Zusammenhang, warum ein größerer Zahlungsmix den Umsatz steigert, erklären wir in warum mehr Zahlungsoptionen mehr Verkäufe bedeuten; eine länderspezifische Übersicht darüber, was europäische Käufer erwarten, finden Sie unter Zahlungsmethoden für den europäischen E-Commerce.

Die drei Zahlungswege und warum jeder davon Pflicht ist, nicht nur eine nette Ergänzung

BLIK, iDEAL und Bancontact sind in ihren Heimatmärkten keine „alternativen“ Zahlungsmethoden. Sie sind der Standard, die Karte ist der Ausweichweg. Dieser Unterschied ist wichtig, weil er die Frage von „Sollte ich das hinzufügen?“ zu „Können meine Kunden hier überhaupt bei mir bezahlen?“ verschiebt.

Was bedeutet das also für Ihren Shop? Wenn Sie in diese Länder liefern und den passenden Zahlungsweg nicht anbieten, zeigt sich der verlorene Verkauf nicht als Beschwerde, sondern als Kaufabbruch, den Sie nicht erklären können. Der Kunde, der nicht so bezahlen kann, wie er immer bezahlt, schreibt Ihnen keine E-Mail. Er geht. Genau deshalb ist diese Zahlungsänderung die eine Maßnahme, die Sie umsetzen sollten, bevor Sie irgendetwas anderes an der Kasse optimieren.

Die PrestaShop-Realität: Sie integrieren nicht drei Zahlungswege, Sie wählen ein Gateway

Der erste Impuls ist oft, nach „einem BLIK-Modul“, „einem iDEAL-Modul“ und „einem Bancontact-Modul“ zu suchen. Tun Sie das nicht. In PrestaShop werden diese Zahlungswege jeweils über das Gateway-Modul eines Zahlungsdienstleisters bereitgestellt. Ein gut gewähltes Gateway deckt alle drei plus Kartenzahlungen unter einer Integration, einem Auszahlungskonto und einheitlichen Berichten ab. Drei separate Module bedeuten drei Stellen, an denen PCI-/SCA-Einstellungen synchron gehalten werden müssen, drei Update-Pfade über PrestaShop-Versionen hinweg und drei Chancen auf einen Hook-Konflikt im Zahlungsschritt.

Die praktische Frage lautet daher: Welches Gateway-Modul stellt welchen Zahlungsweg bereit? Denn die Abdeckung unterscheidet sich tatsächlich, und genau das sollte Ihre Wahl für Ihren konkreten Marktmix bestimmen.

Abdeckung und Verfügbarkeit verändern sich mit der Zeit und hängen von den für Ihr Händlerkonto freigeschalteten Methoden ab. Prüfen Sie daher die aktuelle Liste im Dashboard des Anbieters, bevor Sie sich festlegen. Das Muster ist jedoch stabil: Ein Benelux-geführter Shop tendiert zu Mollie, ein Polen-geführter Shop zu Przelewy24, und ein Shop, der Karten plus diese Zahlungswege unter einem Dach möchte, tendiert zu Stripe. Jede dieser Optionen hat ihre eigene Einrichtungstiefe, die dort behandelt wird, wo sie hingehört: Mollie als Gateway für mehrere Zahlungsmethoden, Przelewy24 und polnische Zahlungen einrichten sowie der Leitfaden zur Stripe-Integration. Wenn Sie überhaupt noch einen primären Zahlungsabwickler auswählen, sind Stripe vs PayPal und der vollständige Vergleich der Zahlungsmodule die richtigen Startpunkte.

Zahlungswege aktivieren: Wo die Einstellungen wirklich liegen

Unabhängig davon, welches Gateway Sie wählen, folgt die PrestaShop-Seite demselben Muster. Nachdem Sie das Modul installiert haben (Module → Modulmanager, ZIP hochladen oder aus dem Katalog installieren), werden die Methoden an zwei Stellen aktiviert, die Händler regelmäßig verwechseln:

• Im Gateway-Dashboard (Mollie-/Stripe-/P24-Seite): Der Zahlungsweg muss zuerst in Ihrem Händlerkonto aktiviert werden. iDEAL und Bancontact können bereits verfügbar sein, müssen je nach Konto und Land aber im PSP-Dashboard aktiviert oder freigegeben werden; BLIK muss häufig ausdrücklich freigeschaltet werden, manchmal nach einer kurzen Prüfung. Wenn eine Methode an der Kasse nie erscheint, egal was Sie in PrestaShop tun, liegt es fast immer daran. Der Zahlungsweg ist auf Kontoebene nicht eingeschaltet.
• In der Modulkonfiguration (PrestaShop-Seite): Öffnen Sie das Modul, dort finden Sie eine Liste der Zahlungsmethoden mit Schaltern pro Methode, Sortierung und (in den Modulen von Mollie und Adyen) Länder- und Währungsregeln pro Methode. Hier entscheiden Sie, welche Zahlungswege im Zahlungsschritt des order-Controllers angezeigt werden und in welcher Reihenfolge.

Zwei PrestaShop-spezifische Einstellungen entscheiden über Erfolg oder Misserfolg. Erstens: Währung. iDEAL, Bancontact und BLIK sind EUR-/PLN-Zahlungswege. BLIK wird in PLN abgewickelt, die anderen in EUR. Stellen Sie unter International → Lokalisierung → Währungen sicher, dass PLN vorhanden und aktiviert ist, wenn Sie Polen ansprechen; eine BLIK-Methode wird bei einem Warenkorb in einer Währung, die sie nicht verarbeiten kann, stillschweigend nicht angezeigt. Zweitens: SCA/3-D Secure: Diese europäischen Zahlungswege fallen unter PSD2. Lassen Sie die starke Kundenauthentifizierung daher im Gateway aktiv. Die Weiterleitung zur Bank ist die Authentifizierung. Sie zu deaktivieren macht nichts schneller, sondern unterbricht nur den Ablauf.

Zeigen Sie jedem Kunden den passenden Zahlungsweg

Diesen Schritt überspringen die meisten Shops, und das kostet leise Conversion. Wenn Sie jedem Kunden jeden Zahlungsweg anzeigen, wird der Zahlungsschritt zu einer Wand aus Logos: Ein französischer Käufer, der an iDEAL, Bancontact und BLIK vorbeiscrollt, um ein Kartenfeld zu finden, erlebt Reibung, und auf dem letzten Bildschirm vor der Conversion ist Reibung teuer. Das Ziel ist das Gegenteil: Jeder Kunde sieht die drei oder vier Methoden, die zu ihm passen, inklusive Karte als universelle Ausweichmethode.

PrestaShop gibt Ihnen diese Filterung, und es gibt drei Steuerungsebenen:

• Länderregeln im Gateway-Modul. Die Module von Mollie und Adyen lassen Sie eine Methode direkt in ihrer Konfiguration an Rechnungsländer binden, Bancontact auf Belgien, iDEAL auf die Niederlande, BLIK auf Polen. Das ist der sauberste Weg, weil die Logik bei der Methode bleibt.
• Zahlungsbeschränkungen im PrestaShop-Kern. Die PrestaShop-Seite Zahlung → Einstellungen erlaubt es, Module nach Währung, Land, Gruppe und Versanddienst einzuschränken, eine Beschränkungsmatrix, in der Sie ein Zahlungsmodul je Dimension ein- oder ausschalten können. Das ist gröber als Regeln pro Methode, funktioniert aber mit jedem Gateway.
• Reihenfolge der Modul-Hooks. Der Zahlungsschritt rendert die Optionen, die jedes Modul über den Hook paymentOptions zurückgibt (in 1.6 displayPayment genannt); die angezeigte Reihenfolge entspricht der Reihenfolge in der Modulkonfiguration oder der Hook-Position. Setzen Sie den dominierenden lokalen Zahlungsweg für den jeweiligen Markt an die erste Stelle, die Karte an die zweite, der Kunde sollte seinen Standard sehen, bevor er die Ausweichmethode sieht.

Wenn diese Ausrichtung bewusst statt überladen wirken soll, passt sie natürlich zu einem aufgeräumten Zahlungsschritt in einer Kasse auf einer Seite, bei dem die relevanten Methoden zusammen mit der Bestellsumme sichtbar bleiben, statt hinter einem Schrittwechsel zu verschwinden.

Testen Sie es, bevor Sie darauf vertrauen, der Teil, der in Produktion schmerzt

Lokale Zahlungswege scheitern anders als Karten, und sie scheitern nachdem der Kunde Ihre Seite verlassen hat. Ein kurzer „lädt bei mir“-Check reicht also nicht. Gehen Sie jeden Zahlungsweg im Test-/Sandbox-Modus des Gateways von Anfang bis Ende durch, bevor Sie live gehen:

• Die Rückkehrstrecke. iDEAL und Bancontact nutzen Bankweiterleitungen; bei BLIK kann der Kunde einen Code an der Kasse eingeben und die Zahlung in der Banking-App bestätigen. Die Bestellung wird erst bestätigt, wenn das Gateway den Webhook/IPN Ihres Shops aufruft, nicht wenn der Kunde zurückkehrt. Wenn Ihr Server die Callback-URL blockiert oder eine Caching-/CDN-Schicht oder ein Sicherheitsmodul vor dem Webhook-Controller des Moduls sitzt, entsteht der klassische Geisterfall: Geld eingezogen, Bestellung bleibt in einem ausstehenden/unvollständigen Status hängen. Prüfen Sie, dass der Webhook ankommt und die Bestellung in einen bezahlten Status versetzt.
• Die abgebrochene Weiterleitung. Testen Sie, was passiert, wenn der Kunde den Bankbildschirm erreicht und ihn schließt. Der Warenkorb sollte wiederherstellbar bleiben und die Bestellung darf nicht als bezahlt markiert werden. Genau hier verdient auch eine Warenkorbabbruch-Nachverfolgung ihren Platz, denn Absprünge bei Weiterleitungen sind ein normaler Teil dieser Abläufe.
• Währungsabgleich. Platzieren Sie eine echte Testbestellung in PLN, um zu prüfen, dass BLIK erscheint und abgewickelt wird, und in EUR für iDEAL/Bancontact. Eine an der Kasse fehlende Methode ist fast immer ein Währungs- oder Länderregel-Mismatch, kein Fehler.

Was der Webhook-Controller tatsächlich tut

Der oben beschriebene „Geisterauftrag“ ist es wert, verstanden und nicht nur getestet zu werden, denn genau dieser Fehlermodus kostet still und leise bereits bezahlte Verkäufe in der Abstimmung. Bei einem Zahlungsweg mit Weiterleitung wird die Bestellung in einem ausstehenden Status erstellt, wenn der Kunde zu seiner Bank geht; es ist der Server-zu-Server-Callback des Gateways, nicht die Rückkehr des Browsers, der die Zahlung bestätigt. In einem PrestaShop-Modul trifft dieser Callback einen eigenen Front-Controller, dessen Aufgabe eng umrissen ist: prüfen, dass die Benachrichtigung wirklich vom Gateway stammt, und dann die Bestellung in einen bezahlten Status verschieben. Die Form ist immer diese:

// controllers/front/webhook.php – reached at
// index.php?fc=module&module=yourmodule&controller=webhook
class YourModuleWebhookModuleFrontController extends ModuleFrontController
{
    public function postProcess()
    {
        // 1. Read + verify the notification really came from the gateway
        //    (signature / API re-fetch – never trust the raw POST alone).
        $paymentId = Tools::getValue('id');
        $status    = $this->module->api->getPaymentStatus($paymentId);

        // 2. Only on a confirmed-paid status, flip the order forward.
        if ($status === 'paid') {
            $this->module->validateOrder(
                (int) $cartId,
                (int) Configuration::get('PS_OS_PAYMENT'), // "Payment accepted"
                $amountPaid,
                $this->module->displayName
            );
        }

        // 3. Answer 200 fast – the gateway retries on timeout/non-200.
        http_response_code(200);
        exit;
    }
}

Zwei Dinge darin sind die Stellen, an denen echte Shops scheitern. Der Prüfschritt (1) ist der Grund, warum Sie eine Bestellung niemals nur deshalb als bezahlt markieren, weil der Browser des Kunden zur Erfolgs-URL zurückgekehrt ist. Diese URL kann auch ohne Zahlung erreicht werden; das maßgebliche Signal ist der verifizierte Webhook. Und die schnelle 200 (3) ist der Grund, warum eine schwere CDN- oder Sicherheitsschicht vor diesem Controller gefährlich ist: Wenn der POST des Gateways geprüft, umgeschrieben oder durch einen Timeout abgebrochen wird, erhält es nie seine 200, die Bestellung wechselt nie den Status, und Sie bekommen den bezahlt-aber-ausstehend-Geisterfall. Sie schreiben diesen Controller nicht selbst, das Gateway-Modul liefert ihn mit, aber wenn Sie seine drei Aufgaben kennen, wissen Sie genau, was Sie prüfen müssen, wenn eine Bestellung hängen bleibt: Ist die Callback-URL erreichbar, gibt sie 200 zurück, und sitzt irgendetwas davor?

Woran Sie erkennen, dass es funktioniert hat

Beurteilen Sie das nicht nach Gefühl und nicht nach drei Tagen Daten. Bevor Sie die Zahlungswege hinzufügen, notieren Sie zwei Kennzahlen aus Ihrer Analyse, nach Land segmentiert: die Abbruchrate an der Kasse und die Warenkorb-zu-Bestellung-Conversion für die Niederlande, Belgien und Polen im Besonderen. Nachdem die Zahlungswege live sind, vergleichen Sie dieselben länderspezifischen Zahlen über mindestens 30 Tage und mit einer aussagekräftigen Bestellmenge, genug Volumen, um einen Trend zu sehen und nicht nur Schwankungen von Woche zu Woche. Der Gewinn hier ist selten ein gleichmäßiger Anstieg über die gesamte Website; es ist eine deutliche Erholung in genau den Märkten, die zuvor nicht bei Ihnen bezahlen konnten. Genau deshalb messen Sie sie getrennt. Welche Steigerung auch immer für das Hinzufügen eines dominierenden lokalen Zahlungswegs zitiert wird: Betrachten Sie sie als Richtungshinweis und lassen Sie Ihre eigenen segmentierten Zahlen das Urteil sprechen.

Ein weiterer Zahlungsweg ist einen Blick wert, wenn Sie ohnehin in den Zahlungseinstellungen sind: In denselben Märkten gehört Jetzt kaufen, später bezahlen (insbesondere Klarna) neben BLIK und iDEAL ebenfalls zu den Erwartungen vieler Käufer, und die meisten der oben genannten Gateways können es auf die gleiche Weise aktivieren. Ob sich das Angebot lohnt, ist eine eigene Entscheidung, wir gehen sie in Jetzt kaufen, später bezahlen und was es für Ihre Conversion bedeutet durch.

Das Prinzip dahinter ist einfach: Jeder Kunde, der Ihren Zahlungsschritt erreicht, hat sich bereits für den Kauf entschieden. Ihre einzige Aufgabe ist, nicht zwischen ihm und der Methode zu stehen, der er vertraut. In PrestaShop bedeutet das: ein Gateway wählen, das iDEAL, Bancontact und BLIK unterstützt; jeden Zahlungsweg sowohl auf Konto- als auch auf Modulseite aktivieren; ihn auf das Land ausrichten, das ihn nutzt; und nachweisen, dass der Webhook für die Rückkehrstrecke auslöst, bevor Sie feiern. Wenn diese vier Dinge stimmen, beginnen die Märkte, in denen bisher still Bestellungen verloren gingen, so zu konvertieren wie Ihr Heimatmarkt.

Häufig gestellte Fragen

Brauche ich ein separates Modul für BLIK, iDEAL und Bancontact?

Nein, und Sie sollten es auch nicht tun. Jeder Zahlungsweg wird über das Gateway-Modul eines Zahlungsdienstleisters bereitgestellt, und ein gut gewähltes Gateway trägt alle drei plus Kartenzahlungen unter einer einzigen Integration und einem Auszahlungskonto. Mollie deckt alle drei als vollwertige Methoden ab; Stripe führt sie neben Karten; Przelewy24 ist der Polen-zuerst-Weg mit nativem BLIK. Drei separate Module bedeuten nur drei Update-Pfade, drei Stellen für SCA-Abstimmung und drei Chancen auf einen Hook-Konflikt im Zahlungsschritt.

Warum wird BLIK an meiner Kasse nicht angezeigt, obwohl ich das Modul aktiviert habe?

Zwei Ursachen sind üblich. Erstens die Kontoebene: BLIK muss häufig ausdrücklich im Gateway-Dashboard freigeschaltet werden (manchmal nach einer kurzen Prüfung), bevor es überhaupt erscheinen kann, die Aktivierung des PrestaShop-Moduls reicht nicht aus. Zweitens die Währung: BLIK wird in PLN abgewickelt und wird daher bei einem Warenkorb in einer Währung, die es nicht verarbeiten kann, stillschweigend nicht gerendert. Prüfen Sie, dass PLN unter International → Lokalisierung → Währungen vorhanden und aktiviert ist und dass BLIK im Dashboard des Anbieters eingeschaltet ist.

Der Kunde hat mit iDEAL bezahlt, aber die Bestellung hängt ausstehend fest, was ist passiert?

Die Rückkehr im Browser wurde abgeschlossen, aber der Server-zu-Server-Webhook des Gateways hat Ihren Shop nicht erreicht. Deshalb wurde die Bestellung nie auf bezahlt gesetzt. Die Bestellung wird durch den Webhook bestätigt, nicht dadurch, dass der Kunde wieder auf Ihrer Erfolgsseite landet. Prüfen Sie, ob die Webhook-/Callback-URL des Moduls öffentlich erreichbar ist, schnell 200 zurückgibt und ob keine CDN-, Cache- oder Sicherheitsschicht davor sitzt, die den POST des Gateways abfragt oder umschreibt.

Welches Gateway sollte ich wählen, wenn Polen mein Hauptmarkt ist?

Tendieren Sie zu Przelewy24. Es ist BLIK-nativ und auf polnische Banküberweisungen ausgerichtet, also die stärkste Passung, wenn Polen Ihr Schwerpunkt ist. Wenn Sie im selben Shop auch starke Karten- und globale Abdeckung brauchen, führt Stripe BLIK (in PLN, abhängig von der Freischaltung im Konto) neben Karten, was die einfachere Ein-Dach-Lösung sein kann. Der spezielle Einrichtungsleitfaden für Przelewy24 führt den Polen-zuerst-Weg Schritt für Schritt durch.

Brauchen diese Zahlungswege mit Weiterleitung trotzdem 3-D Secure / SCA?

Sie sind bereits darauf aufgebaut. iDEAL, Bancontact und BLIK sind europäische Zahlungswege unter PSD2, und die Weiterleitung zur Bank (oder die Bestätigung in der App) ist die starke Authentifizierung. Lassen Sie SCA im Gateway aktiv. Sie zu deaktivieren macht nichts schneller, sondern unterbricht den Ablauf. Für die Karten-Ausweichmethode neben diesen Zahlungswegen übernimmt dasselbe Gateway 3-D Secure für Sie; Sie programmieren nichts davon selbst.