[Subscriptions · Payments] interactive prototype

Subscription Telegram service

A clickable subscription flow showing plan selection, a safe payment-provider hand-off and access states. Real payments and a backend are not connected here.

case status

A clickable journey before backend implementation

interactive prototype
try itPlan → payment mock-up → access

Every key state is walkable directly on this page.

shownThe complete user journey

Period selection, payment return, activation and renewal reminder.

boundaryNo money is charged

YooKassa, webhooks, backend and real access delivery are not connected.

prototype · payments and access are simulated
  1. {{ step.num }} {{ step.label }}
SB
Subscription Bot {{ statusText }}
/demo
This is an interface prototype: it creates no invoice and charges no money. Tap /start below 👇
/start
Hi! This is a paid subscription service. Pick a plan:
{{ chosenLabel }}
Invoice Subscription · {{ chosenName }}
Merchant: {{ brandName }} {{ chosenPrice }} ₽
Paid ✓ Access granted 
plan:    {{ chosenName }}
key:     dY7k-4fA2-x9Q1
access:  until {{ paidUntil }}
status:  active · auto-renew
Three days before expiry, the bot sends a reminder and renews automatically.
Secure payment // flow demonstration
{{ chosenPrice }} ₽ Subscription · {{ chosenName }}
The real bot opens the certified payment provider's secure page. Re:dnd never asks for or stores bank-card details.
payment and access loop

From plan selection to managed access

This diagram shows the intended production logic. On this page, every step runs locally and never contacts YooKassa or a backend.

01

The customer selects a plan

The Telegram bot shows the options, billing period and total without a separate account area.

02

YooKassa handles payment

The bot creates an invoice; bank details stay on the payment provider's protected page.

03

A webhook triggers verification

The service reads the current payment status from YooKassa before connecting it to the customer and plan.

04

Access stays in sync

The subscription period updates, access is issued and the bot reminds before renewal.

→ TARGET FLOW

Access is active

In production, access should change only after server-side verification.

→ EXPIRING

Send a reminder

The customer sees a clear next step before access ends.

→ UNPAID

Revoke access

The status changes consistently and remains visible to the admin.

01 · problem

Design a clear path from plan selection to managed access and validate it with the client before backend development.

02 · solution

An interactive client-side prototype: plans, a mock secure hand-off to YooKassa, access states and reminders. Backend, webhooks and production monitoring are a separate implementation stage.

03 · verified result

The user journey can be tested before backend development. This prototype does not prove live payment automation.

Python Bot API YooKassa VPS
next case: networking CRM →