Stripe payment bot + Telegram-native admin
Subscription platform for the closed Capitalist Invest / Rynochok investment community
Capitalist Invest / Rynochok — a closed paid-subscription investment community: daily market analytics, weekly research reports, 8 themed channels (stocks, bonds, volatility, crypto, macro, commodity, research, portfolio), live chat. 500+ members, partnership with the «Ostannii Kapitalist» media.
I built two systems that work together: Stripe Payment Bot — a Telegram frontend for paying subscriptions (the only point of user interaction), and Admin Panel — Telegram-native admin for the team (promo, pricing, broadcasts, migrations).
My role: solo full-stack — from architecture to production. Stripe bot, Telegram-native admin, webhook pipeline, operational dashboard in Google Sheets, Docker deploy and Cloudflare Tunnels. Before this I ran a digital community of around 1000 people — manually doing broadcasts, customer support, repeat payments, adding and removing members. That knowledge and experience let me build a comprehensive platform for automatic membership management.
Two systems that work together: Stripe bot for users and admin panel for the team.
Structure, infrastructure and development processes.
Full subscription lifecycle: Payment Links with metadata-routing, Subscription Schedules for price migrations without harm to active subs, webhook idempotency with a 30-day TTL event registry (protection against retries and double charges), failed-payment escalation with retry logic.
Atomic 3-stage webhook event processing: ack is committed ONLY after success of all steps. Mutex-protected JSON storage with atomic writes (tempfile → rename) instead of a separate DB — justified by team size, runs for a year without incidents.
Parallel async processes (bot, webhook receiver, API server, Telegram monitor, warning/delete checkers) under tmux, with separate logs. Coordination via Stripe events + shared Sheets — no orchestrator like Celery or Kubernetes.
GitLab pipelines: lint → tests (Pytest with mocked Stripe via recorded fixtures) → build → deploy. Daily log rotation, structured logs per process. Cloudflare Tunnel for webhook ingress without a public IP.
JSON files instead of a DB, Google Sheets instead of a separate dashboard, in-memory FSM with atomic snapshots instead of Redis. Each decision is justified by team size and volume — no overkill, max maintainability.
Configs (tiers, whitelist, promo) are re-read via mtime-tracking — change without restarting the bot. Rolling deploy via Docker: a new container comes up alongside, traffic switches, the old one stops — zero disruption to active payments.
This is one of my cases. The rest is on the home page.