What payment methods you can build into a bot
Telegram supports built-in payments through its API: customers enter card details directly in the messenger interface, no redirect to an external site. This works through payment providers - services that process transactions and transfer money to your account.
Main options for businesses: Stripe, PayPal, Square, Authorize.Net. All support the Telegram Payments API. Commission ranges from 2.5 to 3.5% per transaction plus either a setup fee or monthly subscription.
Second route - don't use Telegram's built-in API, generate a link to the provider's payment form inside the bot instead. Customer clicks the link, pays, bot receives notification about the payment via webhook. This works with almost any provider, even if they're not directly integrated with Telegram. Downside - extra step for the customer, some drop off at the redirect.
Third method - alternative payment systems like Cash App, Venmo, or direct bank transfers. Bot generates a payment request or QR code, customer pays through their banking app. Lower commission, but requires integration with a bank or payment processor that supports business accounts. Works best when average transaction is above $40 and customers are comfortable switching to their banking app.
How to technically connect a payment provider
First, register with the provider. You'll need: tax ID, business registration documents, description of your business, website (if you have one), link to the bot. Provider reviews your application - anywhere from a few hours to three days. They may request additional documents if your business falls into a risk category: gambling, loans, cryptocurrency, alcohol, supplements.
After approval you get API keys: a token for interacting with the provider and a provider_token for the Telegram API. These keys go into your bot code. If you're using the built-in Telegram Payments API, your bot code creates an invoice with item description, amount, and currency. Telegram shows the customer a payment form, the provider processes the payment, bot receives notification via callback.
If you're going with a link to an external form, the provider supplies an API for generating the payment page. Bot creates an order through the API, receives a URL, sends it to the customer. After payment the provider sends a webhook to your server - a POST request with payment data. Server verifies the request signature (to rule out forgery), records the payment in the database, updates order status in the bot.
Make sure you handle errors: card declined, insufficient funds, payment rejected by bank. Bot should tell the customer a clear reason and offer to retry or choose another method. Without this, customers leave confused about what happened.
Legal requirements: what's mandatory
First - you must be registered as a business entity. Payment providers don't work with individuals operating without proper business registration. Depending on your jurisdiction, this might be a sole proprietorship, LLC, or corporation.
Second - sales tax and receipt requirements. In most jurisdictions, if you're accepting payment from customers, you're required to issue receipts and collect applicable sales tax. Many providers offer automated receipt generation: you connect their system, they automatically create a receipt after payment and send it to the customer by email or inside Telegram. Check your local regulations.
Third - terms of service. This is a public agreement describing purchase conditions: what you're selling, price, how payment works, refund terms, your business details. Terms need to be accessible in the bot (usually a /terms command or button at checkout) and on your website if you have one. Without terms, a customer can dispute the payment and the bank will likely side with them.
Fourth - privacy policy. If you're collecting email, phone, name for receipt delivery - that's personal data. Privacy policy describes what you collect, why, how you store it, who you share it with. Also published in the bot, customer must agree before payment (checkbox or 'I agree' button).
Fifth - refunds. Consumer protection laws in most places give customers the right to return products or cancel services within a certain period (often 7-14 days, depends on category and jurisdiction). You're required to refund money within a similar timeframe. Provider supplies an API for refunds - done through dashboard or programmatically. Refund receipt is also generated automatically.
Contract with payment provider: what matters
The provider is an intermediary between you and the acquiring bank. You sign a service agreement with them for payment acceptance. Check several points in the contract.
Commission. Usually stated as a range: for example, 2.8% for average transaction under $70, 2.5% above. Clarify whether tax is included in the commission (matters for your accounting). Is there a monthly fee, withdrawal fee, inactivity fee (if you go a while without transactions).
Hold and fund disbursement. Money from transactions doesn't reach your business account instantly. Usually the provider holds it for 1-3 days, then transfers in a batch. If you're a new customer or work in a risky sector, hold can be 7-14 days. Factor this into your cash flow planning.
Reserve. Provider may freeze a portion of funds (5-10% of turnover) as insurance against refunds or chargebacks (customer disputes payment through their bank). Reserve is returned after 3-6 months if there were no claims.
Chargeback liability. If a customer disputes a payment and the bank sides with them, the provider refunds money to the customer and deducts the amount from you plus a penalty (usually $15-25 per chargeback). This is why it's important to keep proof of service delivery: message screenshots, signed agreements, files you sent the customer.
Taxes and reporting
All payments processed through the provider are your revenue. You pay tax according to your business structure and jurisdiction: income tax rates vary by country and business type. Keep records and file returns according to your local requirements.
The provider doesn't withhold taxes for you - they're just an intermediary. You maintain your own records and file with tax authorities. Transaction data comes from the provider's dashboard: there's an export of all payments to Excel or CSV. Use this export for your revenue records.
Depending on your jurisdiction and business type, you may need to charge and remit sales tax (VAT, GST). Some payment providers can handle sales tax calculation automatically based on customer location. Even if you're not required to charge sales tax, you still need to provide customers with proper documentation: receipt or invoice.
Provider commission can be deducted as a business expense when calculating taxable income. You'll need the provider's invoice (usually generated monthly in the dashboard) and your payment record.
Common mistakes when connecting payments
Didn't test webhook on production server. Everything works locally, in production payments go through, but bot doesn't receive notifications. Reason - provider can't reach your server: no SSL certificate (webhook must be HTTPS), wrong URL, firewall blocking requests. Check provider logs: they show whether webhook is being sent and what response it gets.
Didn't implement idempotency. Provider might send webhook twice (network hiccup, timeout). If your code doesn't check whether this payment was already processed, the order gets credited twice. Store transaction ID in database and check before processing: if that ID already exists, just return HTTP 200 without action.
Skipped test mode. All providers offer test keys for debugging. In test mode you can run through scenarios for successful payment, decline, refund without real money. Many skip this step and send customers straight to production - result is the first bug surfaces on a real transaction.
Didn't configure timeouts. Customer created invoice but didn't pay: got distracted, changed their mind, left. Invoice sits in database with 'awaiting payment' status forever. Need to set invoice lifetime (usually 15-30 minutes) and automatically cancel expired ones. Telegram API supports a need_shipping_address parameter - if you accidentally enable it, bot will demand shipping address even for digital goods.
Skipped the legal part. Connected payments, then a month later provider blocks your account: no terms of service, no privacy policy, receipts not being issued. Unblocking takes a week to a month while you sort out documentation. Customers can't pay during this time.
When built-in payments aren't necessary
If you have three customers a month, built-in payments are overkill. Provider subscription, receipt system, integration time - all this only pays off with regular flow. For one-off orders it's simpler to invoice manually or accept direct bank transfers.
If you're selling something complex with custom terms or a long sales cycle (B2B services, multi-month projects), payment in the bot is also unnecessary. What matters here is conversation, discussing details, signing contracts. Payment is the final step and usually happens via invoice through the bank.
If your target audience is businesses, built-in card payment is useless. Companies pay from business accounts via invoice, they need proper documentation with signatures. Bot can automate invoice generation and document delivery, but the payment itself happens outside Telegram.
What we do at EFIMOV DEV
We build bots with integrated payments turnkey: connect the provider, configure webhooks, code payment and refund logic, set up receipt system, prepare terms of service and privacy policy templates. Bot with payments starts at $700, exact estimate depends on logic and number of integrations. If you already have a bot, we can add payments as a separate enhancement. You discuss the project directly with whoever will be leading it - no account manager middlemen. Leave a request at efimovdev.ru.
Built-in payment in a bot converts interest into money without extra steps: customer doesn't get distracted, doesn't forget, doesn't leave. Technically you need a payment provider, API integration, webhook configuration. Legally - business registration, receipt system, terms of service, privacy policy, refund handling. Main mistakes: didn't test webhook, forgot idempotency, skipped legal requirements. If you have regular customer flow and average transaction above $7 - built-in payment pays for itself in the first month.
Frequently asked
Can I accept payment in a bot without business registration?
No, if you're conducting regular commercial activity. Payment providers require business registration and tax ID. In some jurisdictions you can operate as a sole proprietor or freelancer with simplified registration, but there are usually income limits and not all providers work with these structures.
Do I have to set up automated receipts?
Depends on your jurisdiction. In many places, if you're a registered business accepting customer payments, you must issue receipts and collect applicable sales tax. Check your local regulations. Most providers offer automated receipt generation as part of their service.
How long does it take to connect payments?
Provider registration - a few hours to three days. Integration into existing bot - two days to a week. If the bot is being built from scratch, payments are included in overall development time (usually 2-4 weeks).
What do I do if a customer disputes a payment?
Provider will send chargeback notification. You'll have 7-10 days to provide proof of service: messages, screenshots, signed agreement, delivered files. The bank reviews the dispute and makes a decision. If decision favors the customer, money is deducted from your account plus a penalty. To reduce risk, save all confirmations and clearly state refund terms in your terms of service.
What commission do payment providers charge?
2.5 to 3.5% per transaction plus possible monthly fee ($0 to $50) and setup fee. Commission depends on volume: more transactions, lower percentage. Alternative payment methods can be cheaper - 0.4-1% - but require separate integration with banks or specialized processors.