Käufe, Resend und typische Fehler

Bis hierhin war der Kurs linear. Diese Lektion ist anders — sie ist das Handbuch, an das du zurückkommst, sobald dein Shop läuft: wenn eine Käuferin ihr PDF nicht bekommt, wenn du einen Monatsumsatz an die Steuerberaterin exportieren musst, wenn ein Webhook stumm bleibt.

Drei Bereiche: Käufe-Tab, Resend-Flow, typische Fehlerbilder.

Der Käufe-Tab als Kommandozentrale

Jeder Kauf, den der Webhook gemeldet hat, landet im Tab Käufe unter Design → Downloads. Die Tabelle zeigt pro Zeile Datum, E-Mail, Produkt, Betrag, Zahlungsstatus, Versandstatus und die Aktions-Buttons.

Zahlungsstatus hat vier Zustände, die Stripe über den Webhook meldet:

• paid — Zahlung durch, Geld ist Stripe gutgeschrieben. Regelfall.
• pending — Zahlung läuft noch. Bei Karten praktisch nie, bei SEPA und Klarna der Zwischenstand.
• failed — Zahlung fehlgeschlagen. Bei Karten direkt, bei SEPA oft Tage später (Lastschrift platzt).
• refunded — du hast in Stripe zurückerstattet. Kauf bleibt sichtbar, ist aber neutralisiert.

Versandstatus hat sechs Zustände, die das Theme selbst setzt:

• queued — Mail-Job eingeplant, noch nicht losgelaufen.
• sending — Mail-Job läuft gerade.
• sent — Kauf-E-Mail erfolgreich rausgeschickt.
• failed — Versand nach fünf Versuchen aufgegeben.
• abandoned — Kauf nie bezahlt (z. B. Checkout abgebrochen).
• pending — Zahlung steht noch aus, Versand wartet.

Rechts oben gibt es einen CSV-Export-Button mit Datum, E-Mail, Produkt, Betrag und Stripe-Session-ID pro Zeile. Das ist der Weg, der bei uns regelmäßig an die Steuerberaterin geht.

Der Retry-Backoff im Hintergrund

Wenn der erste Mailversand fehlschlägt, gibt das Theme nicht sofort auf. Der erste erneute Versuch läuft nach zwei Minuten, der zweite nach vier, dann nach acht, sechzehn und zweiunddreißig Minuten — fünf Versuche insgesamt. Scheitert auch der letzte, setzt das Theme den Status auf failed.

Konsequenz: Verschicke Resend-Mails nicht auf Zuruf sofort. Schau zuerst in den Käufe-Tab. Steht dort queued oder sending, läuft der Backoff noch. Steht failed, ist manuelles Nachsenden sinnvoll.

Manuell eine Kauf-E-Mail erneut senden

Im Käufe-Tab hat jede Zeile einen Erneut senden-Button. Klickst du drauf, stellt das Theme den Versand-Job neu in die Queue und versucht den Versand sofort. Zwei Regeln:

• Der Kauf muss bezahlt sein. Das Theme verschickt keine Mails für unbezahlte Käufe. Steht pending oder failed bei der Zahlung, liegt das Problem davor.
• Du änderst die E-Mail-Adresse damit nicht. Das Theme nimmt die Adresse aus Stripe. Hat sich die Käuferin vertippt, musst du den Kauf in Stripe stornieren und sie bitten, ihn mit korrekter Adresse neu zu tätigen.

Der Resend-Flow für Käuferinnen

Neben dem Admin-Button gibt es einen Selbstbedienungs-Resend für Käuferinnen — ein eigener Endpoint auf deinem Blog, über den sie sich ihre Mail erneut schicken lassen können, ohne dass sie dich kontaktieren müssen.

Zwei Pfade:

1. Direkt auf der Danke-Seite. Nach einem Kauf steht in der URL ein resend_token, und der Shortcode [bap_download_thank_you] blendet bei Vorhandensein des Tokens einen Button „Datei erneut senden" ein.
2. Über eine Resend-Seite. Du kannst zusätzlich ein Partial email-resend-form.php als eigene Seite einbinden, in die die Käuferin ihren Token einträgt.

Der Resend ist bewusst nur token-basiert, nicht per E-Mail-Eingabe — sonst könnten Bots mit Mail-Listen durchprüfen, welche Adressen einen Kauf haben. Ohne den richtigen 64-Zeichen-Hex-Token geht der Resend nicht.

Rate-Limits gegen Missbrauch: 3 Versuche pro Token und Stunde, 10 pro IP und Stunde. In der Praxis reicht das locker — eine ehrliche Käuferin braucht vielleicht zwei Klicks, bis sie merkt, dass die Mail im Spam liegt.

Die sechs häufigsten Fehlerbilder

Aus der Agentur-Praxis, nach Häufigkeit sortiert:

1. Falsche Price ID im Produkt. Käuferin klickt auf Buy-Button, landet nicht bei Stripe oder sieht einen leeren Checkout. In 90 % der Fälle wurde statt price_... eine prod_... ID eingetragen. Tab Produkte öffnen, ID kontrollieren — muss mit price_ beginnen.

2. Falsches Webhook Secret. Käufe laufen in Stripe durch, erscheinen aber nicht im Käufe-Tab. In Stripe auf der Webhook-Detailseite den Reiter Events öffnen. 403-Fehler dort → Signing Secret neu aus Stripe kopieren, zurück ins Theme → Einrichtung → Webhook Secret neu einfügen, speichern.

3. Datei nicht im geschützten Ordner. Beim Speichern des Produkts rote Fehlermeldung zum Dateipfad. Über das Upload-Feld im Produktformular neu hochladen, das übernimmt Einspielen und Registrieren in einem Schritt.

4. Mailversand ohne SMTP. Alles bis zur Zahlung läuft, Webhook feuert mit 200 OK, Versandstatus sent — aber die Käuferin bekommt nichts. Testmail aus dem Einrichtungs-Tab abholen. Kommt sie nicht, ist die Mailstrecke kaputt, SMTP-Plugin prüfen.

5. Danke-Seite unter falschem Slug. Nach der Zahlung landet die Käuferin auf einer 404-Seite. Unter Seiten prüfen, ob eine Seite mit Slug danke und dem Shortcode [bap_download_thank_you] existiert. Umbenennen oder neu anlegen. Der Kauf selbst ist sauber gelaufen — die Käuferin hat die Mail bekommen, nur der Browser-Fluss war unschön.

6. Käufe erscheinen mit pending und bleiben dort. Meistens hast du im Webhook nur checkout.session.completed aktiviert und kein SEPA/Klarna-Event. Bei einer SEPA-Käuferin feuert dann nur das erste Event (pending), das zweite fehlt. Abhilfe: In Stripe Webhook-Detailseite öffnen, checkout.session.async_payment_succeeded und checkout.session.async_payment_failed nachtragen.

Der Developer-Account-Weg für die Agentur

Ein praktischer Schluss, weil wir diese Frage im Onboarding oft hören: Wenn du merkst, dass dir das ganze Key-, Webhook- und Ordner-Thema auf Dauer zu technisch ist, gibt es den Agentur-Weg. Wir legen uns einmal als Developer-Account in deinem Stripe und in deinem WordPress an, richten den kompletten Flow ein (Keys, Produkt, Webhook, Danke-Seite, SMTP-Test) und übergeben dir ein laufendes Setup.

Danach brauchst du nur noch den Produkte-Tab: neues Produkt, Name, Slug, Preis-Anzeige, neue Price ID aus Stripe (die du nur einmal beim Anlegen in Stripe generierst) und Datei-Upload. Keys und Webhook bleiben unangetastet. Für die meisten Foodblogs reicht diese laufende Produktpflege, und sie kostet keine halbe Stunde pro neuem Produkt.

Was du jetzt hast und wo du ansetzen kannst

Du weißt, wie du den Käufe-Tab liest, wie der Retry-Backoff arbeitet, wie du eine E-Mail per Admin-Button nachschickst, wie der Selbstbedienungs-Resend läuft und welche sechs Fehlerbilder den allermeisten Produktionsproblemen zugrunde liegen.

Leg im nächsten Schritt dein echtes erstes Produkt an. Den ganzen Kurs hast du im Testmodus gespielt; für den Livegang wiederholst du nur: Stripe-Keys auf Live-Modus umstellen, Product im Live-Modus neu anlegen, die neue Price ID ins Theme eintragen, Webhook im Live-Modus neu anlegen und das Signing Secret austauschen. Der Flow ist identisch, die Stolperfallen kennst du aus dem Testmodus alle schon.

Wenn dir doch etwas unklar wird, schreib uns kurz — in der Agentur sitzen wir ohnehin jeden Tag an genau dieser Schnittstelle zwischen Stripe, Theme und Posteingang.