Telegram bot · card payments · web admin panel
A client picks a service, a specialist and an open time slot, pays a deposit by card and gets reminders. Staff run the schedule in a web panel — bookings made in the bot show up there immediately.
Demo login: demo / demo123 — every section is open, editing is disabled.
The bot speaks Russian; the interface is fully translatable.
Screens captured on demo data — the same ones you get when you open the live demo.
Appointment booking looks simple right up until you try to write it. These are the places where it turns out not to be, and how each is handled.
A client hits "Confirm" at the exact moment the front desk enters a walk-in. Three layers guard it: a lock on the specialist-and-day pair, an overlap check under that lock, and a unique index in the database in case a write ever bypasses the service layer.
Minutes pass between "Confirm" and the money arriving, and the slot stays reserved that whole time. If payment never comes, the slot returns to sale on its own.
Telegram redelivers the payment update until it is acknowledged, so a repeat is routine rather than a failure. Amounts are verified against our own database, and reprocessing the same update changes nothing.
Including cases you cannot reproduce by hand: a payment landing in the final second of the hold, two clients racing for one slot, two reminder cron runs firing in parallel.
Prices, durations, shifts, per-service deposit size, salon name and contacts — all of it is configured in the panel, with no code changes.
Switching from test mode to live is a single setting. The payment provider here is YooKassa; another Telegram Payments provider can be wired in instead.
Set up on your server: domain, HTTPS with auto-renewal, database backups. Updates ship with one command.
Tell me about the business: how many specialists, whether you need deposits, and what you already run. I will tell you what the existing system covers and what needs writing.