Ich zeige dir, wie ich in wenigen Schritten ein Stripe‑Abo mit Make (ehemals Integromat) und Google Sheets automatisiere und gleichzeitig eine robuste Retry‑Logik für fehlgeschlagene Zahlungen einbaue. Das Setup ist praktisch, wenn du wiederkehrende Zahlungen verfolgst, Kund:innen bei fehlgeschlagenen Zahlungen automatisch Erinnerungen schicken willst oder Retry‑Versuche orchestrieren möchtest — ohne ein kompliziertes Backend.
Warum ich Make + Google Sheets benutze
Ich mag Make, weil es schnell geht, viele Konnektoren hat und visuelle Szenen erlaubt, die ich leicht anpassen kann. Google Sheets dient bei mir oft als leichtgewichtige Datenbank und Audit‑Trail: jede Änderung lässt sich nachvollziehen, man kann Filter, Pivot‑Tabellen oder Google‑Formeln hinzufügen. Für kleine bis mittlere Abonnentenstämme ist das eine pragmatische Kombination.
Überblick: Was das Szenario abdeckt
Wichtig ist, dass Zahlungen in Stripe transient sein können (z. B. 3‑D Secure), deshalb verwende ich PaymentIntent/Invoice‑Status als Trigger und nicht allein Webhook‑Events ohne Prüfung.
Benötigte Ressourcen
Schritt 1 — Webhook in Stripe einrichten
Ich erstelle in Stripe einen Webhook, der folgende Events an Make schickt:
Im Webhook‑Payload prüfe ich in Make den object und status, z. B. invoice.status == "open" oder "paid" bzw. "payment_intent.status". So vermeide ich Doppeltrigger.
Schritt 2 — In Make: Szenario aufsetzen
Mein Szenario besteht grob aus diesen Modulen:
Wichtige Tipps beim Erstellen:
Schritt 3 — Google Sheet Struktur (Empfehlung)
| Spalte | Beschreibung |
| customer_id | Stripe Customer ID |
| invoice_id | Stripe Invoice ID |
| status | paid / failed / pending |
| retry_count | Anzahl der bisherigen Retry‑Versuche |
| last_attempt | Timestamp letzter Versuch |
| next_attempt | Geplanter Timestamp für nächsten Retry |
| email_sent | Flag: Benachrichtigung gesendet |
| notes | Freitext für Logs |
Schritt 4 — Retry‑Logik: Prinzipien
Meine Retry‑Logik basiert auf drei Prinzipien:
Retry‑Zeitplan (Beispiel)
| Versuch | Wartezeit seit Fehler |
| 1 | Sofort (erste Erkennung) |
| 2 | 6 Stunden |
| 3 | 24 Stunden |
| 4 | 72 Stunden |
| 5 | Eskalation an Support / Kündigungsprozess |
Schritt 5 — Umsetzung des Retries in Make
So setze ich das in Make um:
Wenn du kein Server‑Side PHP/Node laufen hast, kannst du in Make den Stripe‑Konnektor nutzen — er unterstützt viele API Calls wie "Retrieve Invoice", "Pay Invoice", "Retrieve Payment Intent".
Fehlerbehandlung und Best Practices
E‑Mails und Eskalation
Meine Betreffzeilen sind klar: "Deine Zahlung bei [Produkt] ist fehlgeschlagen". Inhalte:
Im Make‑Szenario verschicke ich automatisierte E‑Mails nach dem 1. und 3. fehlgeschlagenen Versuch. Nach dem letzten Versuch setze ich eine Eskalation — Ticket im Support‑Tool oder manuelle Prüfung.
Edge Cases, die ich gelernt habe
Monitoring & Reporting
Ich überwache auf zwei Wegen:
So erkenne ich schnell, ob Retry‑Raten ansteigen — ein Indikator für größere Probleme (z. B. PSP‑Ausfall, massenhaft abgelaufene Karten).
Feineinstellungen und Skalierung
Für größere Volumina würde ich die Logik aus Sheets in eine kleine Datenbank (Postgres / Firebase) und ein kleines Backend auslagern. Make bleibt ideal für Orchestrierung und Benachrichtigung, aber bei Zehntausenden von Retries wird es teuer und langsam. Bis dahin ist das beschriebene Setup jedoch sehr wartbar und transparent.
Wenn du möchtest, kann ich dir gern eine Make‑Szenario‑Exportdatei vorbereiten oder ein Beispiel‑Google‑Sheet als Template bereitstellen — sag mir, welche Retry‑Regeln du bevorzugst und ob du Mailings selbst hostest oder einen Provider nutzt.