Ratenzahlung: Folgeraten über Stripe Billing (Subscription Schedule) #7

New Issue

2026-10-16T05:54:45Z

Nick.Rosenloecher commented

2026-10-16 05:54:45 +00:00

Ziel

Bis zu drei Raten mit den exakten Beträgen aus dem Briefing (Abschnitt 7), erste Rate bei Buchung, letzte spätestens 30 Tage vor Anreise. Endlich, ohne weitere Abbuchung nach der letzten Rate.

Umgesetzt

Ratenaufteilung und Termine (src/lib/payment-plan.ts): Folgeraten auf volle 50 € abgerundet, Rest in Rate 1; reproduziert alle zwölf Vorgabewerte inklusive 1.237,50 €; Mindestabstand 14 Tage, sonst Variante serverseitig deaktiviert
Seit 05.10.2026 zieht Stripe Billing die Raten 2 und 3 über einen Subscription Schedule ein (c1ad9ad, src/lib/installment-billing.ts); vorher Off-Session-PaymentIntents durch den Worker
„Prüfung nötig“ hält den Stripe-Plan an, doppelte Pläne verhindert über Idempotenzschlüssel mit Generation (1ce7947)
Worker übersteht Stripe-Fehler einzelner Buchungen, Rechnungsentwürfe werden beim Beenden gelöscht (a28d18c)
Storno beendet den Plan und storniert offene Rechnungen; Zahlungsmethode wird nach der letzten Rate getrennt
Mit Stripe-Testuhr gegen die echte Test-API geprüft (06.10.2026): genau eine Rechnung je Folgerate, danach Ende

Offen

Rechtliche Prüfung der Ratenzahlung, Freigabe der Terminregel und Freigabe für den Livemodus (zwei Häkchen im Admin) durch den Inhaber, siehe #22 und Inhaber-Aufgaben (Sammelliste) (#32)
Stripe-Dashboard: Smart Retries und Kunden-E-Mails für fehlgeschlagene Zahlungen einstellen (docs/BETRIEB.md Abschnitt 4), siehe #22

Grundlage

docs/ARCHITEKTUR.md (ADR-3), docs/BETRIEB.md Abschnitt 4, tests/payment-plan.test.ts, tests/payments.integration.test.ts.

Status

Code: ja · Geprüft: ja (Tests und Stripe-Testuhr) · Gemergt: ja · Produktiv: ja (im Cluster belegt ausgerollt sha-5a88f3d am 13.10.2026); im Livemodus erst nach Freigabe aktiv
Stand: 2026-10-16 (Quelle: git origin/main 9785eb2, Gitea-CI-Läufe und Registry, Memory der Sessions)

## Ziel Bis zu drei Raten mit den exakten Beträgen aus dem Briefing (Abschnitt 7), erste Rate bei Buchung, letzte spätestens 30 Tage vor Anreise. Endlich, ohne weitere Abbuchung nach der letzten Rate. ## Umgesetzt - [x] Ratenaufteilung und Termine (`src/lib/payment-plan.ts`): Folgeraten auf volle 50 € abgerundet, Rest in Rate 1; reproduziert alle zwölf Vorgabewerte inklusive 1.237,50 €; Mindestabstand 14 Tage, sonst Variante serverseitig deaktiviert - [x] Seit 05.10.2026 zieht Stripe Billing die Raten 2 und 3 über einen Subscription Schedule ein (`c1ad9ad`, `src/lib/installment-billing.ts`); vorher Off-Session-PaymentIntents durch den Worker - [x] „Prüfung nötig“ hält den Stripe-Plan an, doppelte Pläne verhindert über Idempotenzschlüssel mit Generation (`1ce7947`) - [x] Worker übersteht Stripe-Fehler einzelner Buchungen, Rechnungsentwürfe werden beim Beenden gelöscht (`a28d18c`) - [x] Storno beendet den Plan und storniert offene Rechnungen; Zahlungsmethode wird nach der letzten Rate getrennt - [x] Mit Stripe-Testuhr gegen die echte Test-API geprüft (06.10.2026): genau eine Rechnung je Folgerate, danach Ende ## Offen - [ ] Rechtliche Prüfung der Ratenzahlung, Freigabe der Terminregel und Freigabe für den Livemodus (zwei Häkchen im Admin) durch den Inhaber, siehe #22 und #32 - [ ] Stripe-Dashboard: Smart Retries und Kunden-E-Mails für fehlgeschlagene Zahlungen einstellen (`docs/BETRIEB.md` Abschnitt 4), siehe #22 ## Grundlage `docs/ARCHITEKTUR.md` (ADR-3), `docs/BETRIEB.md` Abschnitt 4, `tests/payment-plan.test.ts`, `tests/payments.integration.test.ts`. ## Status Code: ja · Geprüft: ja (Tests und Stripe-Testuhr) · Gemergt: ja · Produktiv: ja (im Cluster belegt ausgerollt sha-5a88f3d am 13.10.2026); im Livemodus erst nach Freigabe aktiv Stand: 2026-10-16 (Quelle: git origin/main 9785eb2, Gitea-CI-Läufe und Registry, Memory der Sessions)