Telegram Bots with Payments: Business Examples That Actually Collect Money

A Telegram bot with payments is not one product. A course creator needs access control after a one-time invoice. A salon needs a calendar and a deposit so no-shows stop eating the day. A shop needs a cart, delivery, and a fiscal receipt. Same messenger, same “Pay” button - different domain, different failure modes.

Below are seven shapes I actually build. Use them as a menu: pick the closest example, then strip what you do not need. I already wrote the payment plumbing (invoices, webhooks, Mono / LiqPay / Stripe / crypto). This piece is the product layer - who pays, for what, and what happens after the webhook says paid.

1. Seven payment-bot examples at a glance

Each row is a different job. The checkout is similar; the fulfillment is not.

• Online shop: catalog, variants, cart, delivery (Nova Poshta / courier), card or Apple Pay, fiscal receipt, status messages. Mini App almost always.
• Courses and digital goods: pay once (or in parts), then unlock a private channel, files, or a lesson Mini App. Telegram user id is the license.
• Bookings with a deposit: beauty, clinics, tutors. Calendar + 20-50% prepayment. The unpaid slot is still free; the paid one is real.
• Event tickets: one SKU, a date, a QR or invite link, a refund window. High spike at launch - the bot must not double-sell a seat.
• Subscriptions and memberships: gym, content club, monthly service. Recurring charge or a monthly invoice. Failed payment → grace → revoke access.
• Food delivery: visual menu, cart, kitchen/POS, courier statuses. I wrote a full build guide for this one.
• Utility and service bills: OSBB, ISP, monthly invoices, PDF receipts. High volume, low ticket, must be boringly reliable.

2. Chat bot, native invoice, or Mini App?

Do not start with a Mini App because it looks like a product. Start with the checkout job.

• Text bot + one invoice: one SKU, known amount, no catalog. Donations, a single course, a fixed monthly bill. Fastest to ship.
• Native Telegram invoice (Payments API): the pay form stays inside Telegram. Good for cards via a connected provider. Weak for Apple Pay / Google Pay habits in Ukraine - there a hosted Mono or LiqPay page often converts better.
• Mini App: catalog, calendar, cart, maps, variants. Pay via openInvoice, a bank checkout, or a wallet. This is the shop, the salon, the delivery menu.

3. The production payment loop (same for every example)

Pretty UI does not collect money if this loop is sloppy. I keep it boring on purpose.

• Create an order in your database first, status pending, with a unique id. Never generate a payment link without a row you can reconcile.
• Call the provider (Monobank, LiqPay, Stripe, Telegram invoice, crypto) from the backend. Return a URL or invoice payload. The client must not hold secret keys.
• Treat the webhook as the source of truth. Verify the signature. Idempotent handler: the same paid event twice must not unlock twice or charge twice.
• Fulfill in the same transaction of record: grant the channel invite, mark the slot taken, push the order to POS, send the PDF. Then message the user in Telegram. Never fulfill only because the frontend said “success”.

4. How to pick the first example to build

If you already sell in Direct and collect cards in a chat - start with the bot that replaces that thread, not a marketplace. One offer, one payment method that your customers already use, webhooks, a receipt. Then add catalog, calendar, or subscriptions.

Conclusion: pick an example, then we wire the money

I build these bots as a senior web engineer: Next.js Mini Apps where the UI needs a catalog or a calendar, Node backends, Monobank / LiqPay / Stripe / Telegram invoices, and the unglamorous webhook work that stops double charges. If you want a payment bot that matches one of the examples above - shop, course, booking, tickets, or a subscription - write via the form and we will scope the smallest version that can take a real payment this month.