Оплата картой в телеграм-боте: провайдеры, чеки и возвраты

Когда клиент оформляет заказ прямо в переписке, вопрос телеграм бот оплата картой встаёт быстрее, чем кажется на старте проекта: без него бот остаётся просто каталогом, а деньги всё равно приходится принимать где-то на стороне. Ниже опишу, как эта оплата устроена технически, какие провайдеры реально подключаются через Telegram, что делать с чеками по 54-ФЗ и как оформлять возврат, если клиент передумал.

Как в Telegram работает приём оплаты картой

Telegram не проводит платежи сам, а выступает посредником между вашим ботом и платёжным провайдером. Схема на уровне Bot API выглядит так: бот вызывает метод sendInvoice, Telegram показывает пользователю форму оплаты прямо в чате, деньги списывает провайдер, а боту приходит только результат.

Порядок действий на практике:

• Бот отправляет счёт через sendInvoice с названием товара, суммой в LabeledPrice и токеном провайдера, полученным при подключении.
• Пользователь вводит данные карты во встроенной форме Telegram, сами реквизиты карты до сервера бота не доходят, их видит только провайдер.
• Telegram присылает боту pre_checkout_query, и на него нужно ответить в течение 10 секунд, подтвердив или отклонив заказ, например если товар уже раскупили.
• После подтверждения провайдер списывает деньги, а в чат приходит сообщение с полем successful_payment, где лежат telegram_payment_charge_id и provider_payment_charge_id.

Отдельно стоит учитывать разделение, которое Telegram ввёл для цифровых товаров и услуг, потребляемых прямо внутри платформы: такие продажи площадка требует проводить через внутреннюю валюту Stars, а не через банковских провайдеров. Приём оплаты картой через провайдера остаётся рабочим сценарием для физических товаров, услуг с очным или удалённым оказанием вне Telegram и пожертвований. Если вы продаёте в боте курс, PDF-гайд или доступ к закрытому каналу, сначала стоит свериться с актуальными условиями Telegram для конкретной категории, чтобы не отправить пользователя оплачивать не тем способом.

Провайдеры эквайринга для приёма платежей в боте

Провайдер подключается через BotFather: в разделе /mybots выбираете бота, открываете Payments и выбираете одну из платёжных систем, доступных в вашей стране. После подключения BotFather выдаёт provider_token, который и передаётся в sendInvoice.

Из российских платёжных систем для Telegram Payments чаще всего берут ЮKassa, CloudPayments и Т‑Банк (бывшая Тинькофф Касса). Все три подключаются к аккаунту бота одинаково, через BotFather, разница между ними не в самом факте интеграции с Telegram, а в возможностях личного кабинета и API поверх платежа.

Ставка эквайринга у каждого провайдера своя и зависит от тарифа, который вам согласуют при подключении расчётного счёта, поэтому сравнивать провайдеров по проценту комиссии смысла нет, эту цифру уточняют индивидуально в личном кабинете при подаче заявки.

Как подключить приём оплаты и написать код на aiogram

После получения provider_token остаётся написать обработчики на стороне бота. Для ботов на Python это обычно aiogram, вот минимальный рабочий пример с отправкой счёта, подтверждением и обработкой успешной оплаты.

from aiogram import Bot, Dispatcher, F
from aiogram.types import LabeledPrice, Message, PreCheckoutQuery

bot = Bot(token=BOT_TOKEN)
dp = Dispatcher()

@dp.message(F.text == "/buy")
async def buy(message: Message):
    await bot.send_invoice(
        chat_id=message.chat.id,
        title="Диагностика ноутбука",
        description="Выезд мастера, проверка железа и чистка",
        payload="order-1042",
        provider_token=PROVIDER_TOKEN,
        currency="RUB",
        prices=[LabeledPrice(label="Диагностика", amount=150000)],
        need_email=True,
        send_email_to_provider=True,
    )

@dp.pre_checkout_query()
async def process_pre_checkout(pre_checkout_query: PreCheckoutQuery):
    await pre_checkout_query.answer(ok=True)

@dp.message(F.successful_payment)
async def process_successful_payment(message: Message):
    payment = message.successful_payment
    charge_id = payment.provider_payment_charge_id
    telegram_charge_id = payment.telegram_payment_charge_id
    # charge_id понадобится, если клиент попросит вернуть деньги

Сумма в amount указывается в минимальных единицах валюты, для рубля это копейки, поэтому 150000 в примере это 1500 рублей. В pre_checkout_query стоит проверять только то, что реально может измениться за секунды между показом счёта и оплатой, например наличие товара на складе, и делать это по локальным данным, а не через медленный внешний запрос: у Telegram жёсткий лимит в 10 секунд на ответ, и при таймауте платёж автоматически отменяется.

Тестовый provider_token, как и рабочий, выдаёт не платёжный сервис, а BotFather: команда /mybots, нужный бот, Bot Settings, Payments, дальше выбираете провайдера и подключаетесь у него, после чего BotFather показывает список подключённых провайдеров, у каждого имя, токен и дата подключения. Для тестов в этом же списке есть отдельный провайдер Stripe TEST MODE: в нём платежи проходят без реального списания, настоящие карты не принимаются, зато работают тестовые вроде 4242 4242 4242 4242, а переключаться между тестовым и боевым режимом можно сколько угодно раз. Так весь цикл, включая pre_checkout_query и successful_payment, проверяется до запуска.

Доставка и расчёт стоимости через shipping_query

Если в боте продаётся не услуга, а физический товар с курьерской доставкой, счёт можно сделать гибким: в send_invoice выставляются флаги is_flexible и need_shipping_address, и тогда перед оплатой Telegram присылает боту shipping_query с адресом, который ввёл покупатель. В ответ нужно вернуть список вариантов ShippingOption с ценой каждого, например самовывоз бесплатно и курьерская доставка по тарифу, рассчитанному через API СДЭК. Пользователь выбирает вариант, и уже с учётом доставки формируется финальная сумма к оплате.

Такого бота нужно где-то держать постоянно запущенным. Это отдельный процесс на Python, а не PHP-скрипт на обычном хостинге сайта, поэтому под него берут VPS или другой сервер с постоянным аптаймом, который придётся администрировать и оплачивать отдельно от хостинга основного сайта.

Чеки и фискализация по 54-ФЗ

Обязанность пробивать чек при оплате картой никуда не девается только потому, что оплата прошла в мессенджере. По 54-ФЗ чек обязан появиться у покупателя в момент расчёта, и здесь ответственность фактически берёт на себя платёжный провайдер: у ЮKassa, CloudPayments и Т‑Банка есть встроенная касса, зарегистрированная на их юрлицо или на ваше в зависимости от схемы подключения, и именно она формирует и отправляет чек покупателю по email или номеру телефона.

Со стороны бота для этого нужно передать провайдеру данные о позициях заказа, включая ставку НДС, стоимость и количество. Формат этих полей у каждого провайдера свой, поэтому конкретную структуру передаваемых данных для чека нужно смотреть в актуальной документации выбранного провайдера, а не копировать структуру от другого. Если этого не сделать, провайдер либо откажет в проведении платежа, либо сформирует чек с ошибкой, и претензии по 54-ФЗ в итоге придут именно вам как продавцу.

Отдельно стоит собирать email или телефон покупателя через need_email или need_phone_number в sendInvoice, если провайдер не может доставить чек иначе. Без этого поля чек физически некуда отправить.

Данные покупателя из order_info, такие как имя, телефон и адрес доставки, я сохраняю в базе на своём сервере или сразу передаю в CRM с размещением в России. Зарубежные облачные таблицы и заметки для хранения контактов покупателей в такой схеме не использую, персональные данные клиентов по 152-ФЗ должны обрабатываться на серверах внутри страны.

Возвраты: как оформить и что автоматизировать

Bot API не даёт универсальной команды «вернуть платёж» для оплат через банковского провайдера, в отличие от Stars, где для этого есть отдельный метод. Возврат по карте оформляется на стороне провайдера: заходите в личный кабинет ЮKassa, CloudPayments или Т‑Банка, находите операцию по provider_payment_charge_id, который вы сохранили при обработке successful_payment, и запускаете возврат оттуда или через API провайдера.

Что стоит сделать на стороне бота:

• Сохранять charge_id и сумму каждого платежа в своей базе сразу при получении successful_payment, иначе искать операцию в кабинете провайдера придётся вручную по времени и сумме.
• После возврата через API провайдера отправлять пользователю сообщение в бота с подтверждением, потому что сам провайдер сообщением в Telegram клиента не уведомит.
• Если возвраты частые, например из-за отмены записи на услугу, имеет смысл сделать в боте админскую команду, которая дёргает API провайдера по сохранённому charge_id, а не заставляет каждый раз открывать личный кабинет руками.

Уведомления о новых оплатах и возвратах я обычно завожу не только в сам бот, но и в CRM отдельным потоком, чтобы менеджер видел статус заказа без переключения между чатами. Для такой связки между ботом и Bitrix24 или amoCRM удобно использовать автоматизацию в n8n: вебхук от бота приходит в сценарий n8n, а тот уже создаёт сделку и прикрепляет к ней charge_id для будущего возврата.

Сколько стоит и сколько занимает разработка бота с оплатой

Голый бот-каталог без оплаты и бот с полноценным приёмом платежей, чеками и обработкой возвратов это разные по объёму задачи. Во втором случае добавляется логика pre_checkout, хранение платежей в базе, админские команды для возвратов и синхронизация с CRM или таблицей заказов.

Свою разработку телеграм-бота с оплатой я оцениваю от 30 000 ₽, срок зависит от того, нужна ли только оплата и чек или ещё и админ-панель с историей заказов и статистикой возвратов. Если платежи нужно тянуть дальше в CRM или таблицу, отдельно считается автоматизация в n8n от 25 000 ₽. Разовая консультация по выбору провайдера и структуре чека под вашу схему налогообложения стоит от 3 000 ₽.

На рынке за похожую задачу студии и фрилансеры называют самые разные суммы, разброс сильно зависит от того, входит ли в цену фискализация и обработка возвратов или только сама отправка счёта, поэтому при сравнении предложений уточняйте, что именно входит в объём работ, а не только итоговую цифру.

Условия и возможности Telegram меняются, поэтому перед запуском я уточняю их у самого сервиса.

Частые вопросы

Можно ли принять оплату картой в боте физическому лицу без ИП?

Нет, provider_token выдаётся на юрлицо, ИП или самозанятого, у которого есть расчётный счёт и договор с провайдером. Как обычное физическое лицо получить токен для приёма платежей через Telegram Payments нельзя, это условие самих провайдеров, а не Telegram.

Нужен ли отдельный сервер, чтобы бот принимал платежи?

Да, боту на aiogram нужен постоянно работающий процесс на Python, то есть VPS или другой сервер с непрерывным аптаймом, а не обычный хостинг сайта. Это отдельная точка обслуживания: сервер нужно администрировать, обновлять и оплачивать помесячно отдельно от хостинга основного сайта.

Что произойдёт, если бот не успеет ответить на pre_checkout_query?

Если ответ не пришёл в течение 10 секунд, Telegram сам отменяет платёж и списание не происходит. Поэтому проверки в обработчике pre_checkout_query должны быть быстрыми и опираться на данные, которые уже есть локально, без обращения к внешним медленным сервисам.

Как вернуть деньги клиенту после успешной оплаты?

Через личный кабинет или API платёжного провайдера, используя provider_payment_charge_id из successful_payment. Bot API не проводит возврат за вас для карточных платежей, поэтому этот идентификатор обязательно нужно сохранять в базе при получении каждого платежа, а после возврата отдельно уведомлять клиента сообщением в самом боте.