PrestaShop ist um einen einzelnen Vorgang herum gebaut: ein Warenkorb, eine Bestellung, eine Zahlung. Ein Abonnement setzt das Gegenteil voraus, eine Bindung, die über die Zeit Zahlungen erzeugt, ohne dass der Kunde wiederkommt. Diese beiden Modelle treffen sich nicht von selbst.
Hier ist die Architektur, die funktioniert, und die Stellen, an denen Umsetzungen brechen.
Wer die Wahrheit hält
Erste Entscheidung, und sie bestimmt alles Weitere.
Eine Zahlungsplattform wie Stripe verfügt über eine vollständige Engine für wiederkehrende Abrechnung: Abonnements, Fälligkeiten, Wiederholungsversuche, Umgang mit abgelaufenen Karten. Das in PrestaShop nachzubauen wäre ein Fehler.
Die Aufteilung, die trägt: Stripe hält das Abonnement, also den Zyklus, die Fälligkeiten und den Einzug. PrestaShop hält Katalog, Kunde und die Bestellungen, die zu jeder Fälligkeit entstehen.
Konkret erzeugt jede erfolgreiche Abbuchung eine Bestellung in PrestaShop, die danach Ihren normalen Kommissionier- und Versandprozess durchläuft. Genau das hält Statistiken, Rechnungen und Logistik konsistent.
Die Webhooks, auf die zu hören ist
Das ist der Kern der Integration und die Stelle, an der die Arbeit tatsächlich liegt.
Fünf Ereignisse müssen behandelt werden, jedes mit einem genauen Verhalten.
- Erfolgreiche Fälligkeitszahlung. Erzeugt die Bestellung in PrestaShop, bucht den Bestand ab, löst die Bestätigungsmail aus.
- Fehlgeschlagene Zahlung. Erzeugt keine Bestellung, setzt das Abonnement aus, startet die Mahnstrecke.
- Abonnement aktualisiert. Wechsel von Tarif, Menge oder Datum. Muss sich auf der Shopseite auswirken.
- Abonnement gekündigt. Schneidet den Zugang ab, wenn Sie Inhalte verkaufen, stoppt die Sendungen, wenn Sie Ware verkaufen.
- Ablaufendes Zahlungsmittel. Löst eine Erinnerung vor dem Fehlschlag aus und verhindert so die Unterbrechung.
Drei technische Regeln zu Webhooks. Prüfen Sie die Signatur jeder Benachrichtigung, sonst kann jeder bei Ihnen Bestellungen erzeugen. Behandeln Sie sie idempotent: Dasselbe Ereignis kann mehrfach zugestellt werden, und Sie dürfen nicht zwei Bestellungen anlegen. Und bestätigen Sie den Empfang schnell und verarbeiten Sie danach im Hintergrund, sonst wertet die Plattform den Aufruf als fehlgeschlagen und wiederholt ihn.
DataFirefly Subscriptions — Abonnements und wiederkehrende Stripe-Zahlungen für PrestaShop 8 & 9Das Abonnement-Modul für PrestaShop 8 und 9: Stripe Card-on-File, Dunning, Self-Service-Kundenbereich.169,00€
Abgelaufene Karten, größter Verlustposten
Bei einem Abonnement stammen die meisten unfreiwilligen Kündigungen von einem ungültig gewordenen Zahlungsmittel, nicht von einer Kundenentscheidung.
Drei Mechanismen greifen ineinander, um den Schaden zu begrenzen. Die automatische Kartenaktualisierung, von den Kartennetzwerken angeboten und von den Zahlungsplattformen weitergereicht, die die neue Nummer ohne Zutun übernimmt. Die Erinnerung vor Ablauf, einen Monat vor dem Gültigkeitsende ausgelöst. Und die Wiederholungsstrecke nach einem Fehlschlag, über ein bis zwei Wochen verteilt statt am Folgetag wiederholt.
Sehen Sie eine Kulanzfrist vor, in der der Dienst trotz Fehlschlags aktiv bleibt. Sofort abzuschalten macht aus einem Bankvorfall eine endgültige Kündigung.
Der Bestellprozess: nicht mischen
Eine Gestaltungsfrage, die oft zu spät entschieden wird. Ein Warenkorb mit einem Abonnement und Einmalprodukten schafft ein Problem: Das erste erzeugt eine wiederkehrende Bindung, die zweiten nicht.
Zwei vertretbare Ansätze. Der eigene Bestellprozess, in dem das Abonnement allein abgeschlossen wird, ohne die Möglichkeit, etwas hinzuzufügen. Einfacher, klarer für den Kunden, und die empfohlene Standardwahl.
Oder der gemischte Warenkorb, bei dem die erste Bestellung beides enthält, mit einer einzigen Zahlung, die die Produkte deckt und das Abonnement startet. Technisch aufwendiger, und Sie müssen sehr klar sagen, was danach abgebucht wird.
Was Sie nicht tun sollten: zwei verschiedene Abonnements im selben Warenkorb zulassen. Die Abrechnungszyklen laufen sofort auseinander und die Verwaltung wird unentwirrbar.
Die starke Kundenauthentifizierung
Die europäische Zahlungsregulierung verlangt für viele Transaktionen eine Authentifizierung des Karteninhabers. Bei einem Abonnement authentifiziert der Kunde die erste Zahlung, die folgenden fallen unter einen anderen Rahmen, da sie vom Händler ausgelöst werden.
Zwei praktische Folgen. Das Mandat muss bei der ersten Zahlung korrekt erfasst werden, was die Plattformen übernehmen, sofern die Zahlungsabsicht mit den richtigen Parametern erzeugt wird. Und einzelne Fälligkeiten können dennoch eine Authentifizierung verlangen, wofür ein Weg vorgesehen sein muss, der den Kunden zu einer Authentifizierungsseite zurückführt, statt still zu scheitern.
Der rechtliche Rahmen
Drei Pflichten, die kontrolliert und regelmäßig verfehlt werden.
Die Information vor Vertragsschluss: Laufzeit, Betrag, Zahlungsrhythmus und Kündigungsmodalitäten müssen auf der Kaufseite sichtbar sein, nicht nur in den allgemeinen Geschäftsbedingungen.
Die Kündigung online, so einfach wie der Abschluss. In Deutschland verlangt das Gesetz für online geschlossene Dauerschuldverhältnisse eine leicht zugängliche Kündigungsschaltfläche, erreichbar ohne Anmeldung.
Die Information vor der Verlängerung bei sich automatisch verlängernden Abonnements, mit einer Frist, die dem Kunden Zeit zum Widerspruch lässt.
Die drei Zahlen des Modells
Der monatlich wiederkehrende Umsatz, der die wirtschaftliche Grundlage liefert. Die monatliche Abwanderungsquote, getrennt nach freiwilligen Kündigungen und Zahlungsfehlschlägen, weil die Gegenmaßnahmen sich unterscheiden. Und die durchschnittliche Lebensdauer eines Abonnenten, die aus der zweiten folgt und bestimmt, wie viel Sie für die Gewinnung ausgeben können.
Das Modul DataFirefly Subscriptions für PrestaShop richtet diese Architektur unter PrestaShop 8 und 9 ein: Abonnements auf Stripe-Basis, automatische Bestellanlage zu jeder Fälligkeit, Webhook-Verarbeitung mit Signaturprüfung, Umgang mit Zahlungsfehlschlägen und ein Kundenbereich zum Ändern oder Kündigen.