Stripe payment bot + Telegram-native admin
Abo-Plattform für die geschlossene Investment-Community Capitalist Invest / Rynochok
Capitalist Invest / Rynochok — eine geschlossene Investment-Community mit kostenpflichtigem Abo: tägliche Marktanalysen, wöchentliche Research-Reports, 8 thematische Channels (Aktien, Anleihen, Volatilität, Krypto, Makro, Commodities, Research, Portfolio), Live-Chat. 500+ Mitglieder, Partnerschaft mit dem Medium «Ostanniy Kapitalist».
Ich habe zwei Systeme gebaut, die zusammen funktionieren: Stripe Payment Bot — Telegram-Frontend für die Bezahlung von Abos (der einzige User-Interaktionspunkt), und Admin Panel — Telegram-natives Admin-Panel für das Team (Promo, Preise, Broadcasts, Migrationen).
Meine Rolle: solo full-stack — von der Architektur bis in die Produktion. Stripe-Bot, Telegram-natives Admin, Webhook-Pipeline, operatives Dashboard in Google Sheets, Docker-Deploy und Cloudflare Tunnels. Davor habe ich eine Digital-Community von rund 1000 Personen geleitet — manuelle Broadcasts, Kundensupport, Wiederholungszahlungen, Hinzufügen und Entfernen von Mitgliedern. Dieses Wissen und diese Erfahrung erlaubten mir, eine umfassende Plattform für automatisches Mitgliedschafts-Management zu bauen.
Zwei Systeme, die zusammen funktionieren: Stripe-Bot für User und Admin-Panel für das Team.
Struktur, Infrastruktur und Entwicklungsprozesse.
Voller Subscription-Lifecycle: Payment Links mit metadata-routing, Subscription Schedules für Preis-Migrationen ohne Schaden für aktive Subs, Webhook-Idempotency mit 30-Tage-TTL event-registry (Schutz vor Retries und Doppelbelastung), Failed-Payment-Eskalation mit Retry-Logik.
Atomische 3-Phasen-Verarbeitung von Webhook-Events: Ack wird NUR nach Erfolg aller Schritte committet. Mutex-geschütztes JSON-Storage mit atomic writes (tempfile → rename) statt einer separaten DB — gerechtfertigt durch Teamgröße, läuft ein Jahr ohne Incidents.
Parallele Async-Prozesse (Bot, Webhook-Receiver, API-Server, Telegram-Monitor, Warning/Delete-Checker) unter tmux, mit separaten Logs. Koordination via Stripe-Events + geteilte Sheets — ohne Orchestrator wie Celery oder Kubernetes.
GitLab-Pipelines: lint → tests (Pytest mit gemocktem Stripe via recorded fixtures) → build → deploy. Tägliche Log-Rotation, strukturierte Logs pro Prozess. Cloudflare Tunnel für Webhook-Ingress ohne öffentliche IP.
JSON-Files statt DB, Google Sheets statt separates Dashboard, In-Memory-FSM mit atomic snapshots statt Redis. Jede Entscheidung gerechtfertigt durch Teamgröße und Volumen — kein Overkill, maximale Wartbarkeit.
Configs (Tarife, Whitelist, Promo) werden via mtime-tracking neu eingelesen — Änderung ohne Bot-Restart. Rolling Deploy via Docker: neuer Container kommt parallel hoch, Traffic schaltet um, alter stoppt — null Unterbrechung aktiver Zahlungen.
Das ist einer meiner Cases. Der Rest ist auf der Hauptseite.