Anfang Juni wurde aus den zuvor getrennt geplanten Modulen erstmals ein zusammenhängender Ablauf. Die zentrale Frage war nicht mehr nur, welche Funktionen benötigt werden, sondern ob eine bestätigte Zahlung tatsächlich ohne manuelle Zwischenschritte zu einem nutzbaren Downloadzugang führt.
Der aktuelle Kernstand des CROPS Plugins Donate Download Managers umfasst dafür den Stripe-Webhook, die Code-Erzeugung, die Speicherung in eigenen Tabellen, den Mailversand sowie zwei Shortcodes für Danke-Seite und Downloadformular. Damit lässt sich der vollständige Weg erstmals praktisch prüfen.
Der Webhook-Endpunkt als technischer Eingang
Stripe sendet die Bestätigung an den REST-Endpunkt /wp-json/cddm/v1/stripe-webhook. Dieser Endpunkt ist bewusst unabhängig von einer sichtbaren WordPress-Seite. Er verarbeitet die serverseitige Nachricht auch dann, wenn der Nutzer den Browser nach der Zahlung sofort schließt.
Die Webhook-Konfiguration verbindet den passenden Zahlungslink mit dem Produktdatensatz. Erst nach erfolgreicher Prüfung darf die nächste Stufe, die Code-Erzeugung, ausgelöst werden.
Codes werden dauerhaft und eindeutig gespeichert
Der erzeugte Zugangscode wird nicht nur in einer E-Mail ausgegeben. Er erhält einen eigenen Datensatz in wp_cddm_codes. Dort werden die für den späteren Zugriff notwendigen Informationen zusammengeführt.
Zum Datensatz gehören unter anderem Produktbezug, Stripe-Sitzung, Erstellungszeitpunkt, Status, Laufzeit und Downloadregeln. Diese Struktur erlaubt es, einen Code später zu suchen, zu sperren oder seinen aktuellen Zustand im Kundenbereich anzuzeigen.
Downloadereignisse bleiben vom Code getrennt
Ein Code ist eine dauerhafte Berechtigung; ein Download ist ein einzelnes Ereignis. Deshalb werden Abrufe in der separaten Tabelle wp_cddm_download_logs erfasst. Diese Trennung erleichtert die Berechnung des verbleibenden Kontingents und hält den eigentlichen Code-Datensatz übersichtlich.
Im Log kann nachvollzogen werden, welche Version zu welchem Zeitpunkt ausgeliefert wurde. Für Fehleranalysen ist das wesentlich hilfreicher als eine bloße Gesamtzahl.
Die Danke-Seite zeigt den Zugang unmittelbar an
Der Shortcode [crops_thankyou_code] ist für die Seite nach der Zahlung vorgesehen. Er liest den aktuellen Zahlungskontext aus und zeigt den zugehörigen Code an, sobald die Webhook-Verarbeitung abgeschlossen ist.
Die Seite muss dabei mit kurzen Verzögerungen umgehen können. Statt einen leeren Bereich anzuzeigen, kann sie erklären, dass die Bestätigung noch verarbeitet wird. So bleibt der Nutzer auch in einem zeitkritischen Moment orientiert.
Die E-Mail schafft eine dauerhafte Kopie
Parallel zur Danke-Seite wird der Code per E-Mail übermittelt. Das Plugin verwendet dafür die bestehende WordPress-Mailfunktion. Eine eigene SMTP-Konfiguration wird nicht eingebaut, damit Zugangsdaten und Zuständigkeiten nicht doppelt verwaltet werden müssen.
Die Nachricht enthält den Code, den Link zum Downloadbereich und die wichtigsten Zugangsinformationen. Dadurch kann der Nutzer später zurückkehren, ohne den ursprünglichen Zahlungsvorgang erneut öffnen zu müssen.
Das Downloadformular prüft den aktuellen Status
Mit [crops_download_form] lässt sich das Prüf- und Downloadformular in eine beliebige WordPress-Seite einfügen. Der Nutzer gibt seinen Code ein, das System prüft Produkt, Status und Regeln und zeigt erst danach das freigegebene Release.
Die Shortcode-Lösung macht das Plugin unabhängig von einem bestimmten Theme. Betreiber können den Downloadbereich in eine bestehende CROPS-Seite integrieren und das umgebende Layout selbst gestalten.
Erste Regeln für Downloads und Updates
Für den frühen Kernstand wurde ein nachvollziehbares Modell mit einem Code pro Zahlung, einem begrenzten Downloadkontingent und einem definierten Updatezeitraum vorgesehen. Als Ausgangspunkt galten bis zu zehn Abrufe und zwölf Monate Updatezugang.
Diese Werte bilden keine starre Grenze für alle späteren Produkte. Sie schaffen zunächst testbare Regeln, auf denen flexible Laufzeiten und weitere Varianten aufbauen können.
Warum der durchgängige Test wichtiger als Einzelmodule ist
Jedes Modul kann für sich funktionieren und der Gesamtprozess dennoch scheitern. Ein Webhook kann korrekt eintreffen, aber das falsche Produkt zuordnen. Ein Code kann gespeichert werden, aber in der E-Mail fehlen. Ein Formular kann gültige Codes prüfen, aber die falsche ZIP ausliefern.
Der erste durchgängige Ablauf macht solche Übergabefehler sichtbar. Er ist deshalb ein wichtiger Meilenstein: Nicht die Zahl der Menüpunkte entscheidet, sondern die verlässliche Verbindung vom Zahlungseingang bis zur passenden Datei.
Die Grundlage für den weiteren Ausbau
Mit der funktionierenden Kernkette können Komfort- und Verwaltungsfunktionen gezielt ergänzt werden. Dazu gehören differenzierte Laufzeiten, Code-Wiederherstellung, ausführlichere Release-Ansichten und bessere Filter im Adminbereich.
Der wichtigste Fortschritt liegt jedoch bereits in der Struktur. Zahlung, Berechtigung, Kommunikation und Download sind als zusammenhängender, aber klar gegliederter Prozess umgesetzt.
Der praktische Test beginnt mit klaren Szenarien
Für den ersten vollständigen Durchlauf werden nicht nur erfolgreiche Zahlungen benötigt. Ebenso wichtig sind eine doppelte Webhook-Zustellung, eine unbekannte Produktzuordnung, ein gesperrter Code und ein Download nach ausgeschöpftem Kontingent. Jeder Fall muss einen definierten Status hinterlassen.
Die Ergebnisse werden anschließend in Danke-Seite, E-Mail, Kundenbereich und Admin-Log verglichen. Erst wenn alle Ansichten dieselbe Geschichte erzählen, ist der Prozess tatsächlich durchgängig.
Keine stille Abhängigkeit vom Browser
Ein zentraler Qualitätsmaßstab ist, dass die Berechtigung serverseitig entsteht. Die Rückleitung zur Website verbessert die Nutzererfahrung, darf aber nicht darüber entscheiden, ob der Code angelegt wird. Damit bleibt der Vorgang auch bei einem geschlossenen Tab oder einer unterbrochenen Verbindung vollständig.
Diese Entkopplung macht den Ablauf robuster und erleichtert die spätere Wiederherstellung eines Zugangs.
