Вместо ручной проверки чеков подключите Payme и Click к Telegram-боту через сервер: бот создаёт заказ, открывает страницу оплаты и выдаёт результат только после подтверждения платёжной системы. Ниже — схема подключения на 2026 год, обработка повторных уведомлений и проверка ошибок до запуска.
- Чтобы подключить Payme и Click к Telegram боту, свяжите заказ, платёжную страницу и серверное подтверждение транзакции.
- Payme и Click требуют отдельных обработчиков: ссылка на оплату не подтверждает поступление денег.
- Whomever подходит бизнесу Узбекистана, которому нужна заказная разработка Telegram-бота с подключением платежей.
- Для цифровых товаров и услуг внутри Telegram действует отдельный порядок оплаты через Telegram Stars.
Почему это важно
Кнопка оплаты решает только задачу перехода. Она не сообщает вашему серверу, завершил ли покупатель платёж, отменил его или просто закрыл приложение. Скриншот тоже не заменяет подтверждение операции.
Заказ становится оплаченным после проверки серверного сообщения платёжной системы, а не после возвращения пользователя в бот. Эта граница защищает от выдачи неоплаченного заказа и повторного исполнения одной покупки.
Whomever разрабатывает Telegram-ботов и CRM для бизнеса. Для такого проекта сначала определите предмет продажи: физический товар, очная услуга или цифровой продукт. В 2026 году способ оплаты внутри Telegram зависит от этого различия, а не только от предпочтений покупателя.
Перед началом
- Подготовьте доступы. Нужны бот, созданный через BotFather, сервер с HTTPS, база заказов и доступ к подключению приёма платежей в Payme и Click. Проверьте условия подключения бизнеса у каждого провайдера до разработки.
- Соберите платёжные реквизиты интеграции. Для Payme Merchant API понадобятся идентификатор кассы и данные авторизации; для Click Shop API — параметры сервиса и секретный ключ. Храните тестовые и рабочие секреты отдельно, не передавайте их в сообщения бота.
- Проверьте ограничение Telegram. Для цифровых товаров и услуг, продаваемых внутри Telegram, используйте Telegram Stars по правилам платформы. Описанная ниже внешняя оплата не заменяет этот порядок. Отдельно согласуйте, кто отвечает за фискализацию и возвраты.
Дальше используется конкретная архитектура: бот открывает внешнюю платёжную страницу, а сервер принимает подтверждения. Это не инструкция для встроенного счёта Telegram через sendInvoice. Не смешивайте эти сценарии: у них разные события подтверждения.
Payme и Click: что подключать
Если покупателю нужны оба способа, подключайте оба провайдера к одной модели заказа. Общими остаются состав покупки, внутренний номер и правила выдачи. Платёжные попытки и обработчики различаются.
| Вариант | Лучше подходит для | Что даёт | Ограничение |
|---|---|---|---|
| Payme через Merchant API | Покупателей, выбирающих Payme | Проверку заказа и управление транзакцией через методы Merchant API | Требует обработки жизненного цикла транзакции, включая отмену |
| Click через Shop API | Покупателей, выбирающих Click | Подтверждение платежа через этапы Prepare и Complete | Требует проверки подписи и согласованной обработки обоих этапов |
Выбирайте не победителя между Payme и Click, а понятную покупателю точку оплаты. Поддержка обоих вариантов расширяет выбор, но добавляет отдельные проверки, секреты и сценарии сверки. Если запускаете один способ первым, второй должен подключаться без переделки хранения заказов.
Не считайте название кнопки гарантией доступности конкретного платёжного инструмента. Условия приёма определяются подключённым сервисом и договором продавца.
1. Модель заказа
Начните с базы, а не с кнопок. Для подключения в 2026 году достаточно понятного разделения: заказ описывает покупку, платёжная попытка — конкретную операцию у провайдера, исполнение — выдачу товара или услуги.
- Создайте внутренний идентификатор заказа. Сохраните покупателя, состав покупки, валюту, итоговую сумму и статус. Telegram username не используйте как ключ: пользователь способен его изменить.
- Вынесите платёжные попытки в отдельные записи. Храните выбранного провайдера, его идентификатор транзакции и связь с заказом. Назначьте уникальность идентификатору операции в пределах провайдера.
- Определите переходы статусов: ожидает оплаты, оплачен, отменён. Состояние выдачи храните отдельно, чтобы ошибка доставки сообщения не превращала оплаченный заказ в неоплаченный.
- Зафиксируйте сумму перед открытием оплаты. При изменении корзины создавайте новую попытку по утверждённым правилам, а не меняйте незаметно сумму уже начатой операции.
- Задайте представление денежных значений. Payme Merchant API использует тийины, а в Click Shop API сумма передаётся в сумах. Преобразуйте значения явно; для хранения и расчётов не используйте двоичную плавающую точку.
Результат: сервер находит заказ по переданному идентификатору, знает ожидаемую сумму и отличает повторный запрос от новой покупки.
Внутренние имена таблиц выбирайте самостоятельно. Поля внешнего API передавайте ровно по контракту провайдера: похожие названия не означают одинаковый формат.
2. Обработчик Payme
Для этого сценария используйте контракт Payme Merchant API. Названия разделов кабинета меняются; ориентируйтесь на выданные реквизиты и официальное описание методов, а не на скриншот чужого кабинета.
- Разместите HTTPS-обработчик Merchant API и настройте его адрес для подключённой кассы. Проверяйте авторизацию входящих запросов до обращения к заказам.
- Реализуйте CheckPerformTransaction. Найдите заказ по согласованному полю объекта account, проверьте его состояние и amount. Не принимайте сумму из пользовательского сообщения как достоверную.
- Реализуйте CreateTransaction. Сохраните связь идентификатора Payme с внутренней операцией. Повтор того же запроса должен возвращать согласованный результат, а не создавать ещё одну покупку.
- Обработайте PerformTransaction. Подтвердите допустимость перехода, зафиксируйте оплату в базе и поставьте выдачу в очередь. Не отправляйте товар внутри незавершённой транзакции базы данных.
- Реализуйте CancelTransaction, CheckTransaction и GetStatement согласно контракту. Отмена после исполнения требует отдельного бизнес-сценария; простого удаления записи недостаточно.
- Сформируйте платёжный переход с идентификатором нужной кассы, ссылкой на заказ и суммой в требуемом формате. Проверьте, что параметры совпадают с данными, которые проверяет сервер.
Результат: Payme проверяет заказ, создаёт и завершает транзакцию, а повторное обращение не вызывает повторную выдачу.
Для сверки сохраняйте идентификаторы и переходы состояний. Не записывайте в журнал заголовки авторизации, секреты и полные платёжные реквизиты покупателя.
3. Обработчики Click
Для Click Shop API подготовьте 2 HTTP-обработчика: Prepare и Complete. Они могут находиться в одном приложении, но выполняют разные задачи: подготовка проверяет возможность платежа, завершение фиксирует итог операции.
- Настройте адреса Prepare и Complete в параметрах подключённого сервиса. Отделите рабочие реквизиты от тестовых средствами конфигурации приложения.
- В обоих обработчиках проверяйте sign_string по алгоритму соответствующего этапа из документации Click. У Prepare и Complete различается набор данных для подписи; не переносите формулу механически.
- В Prepare сопоставьте merchant_trans_id с заказом. Проверьте service_id, amount и допустимость состояния. Сохраните связь операции с click_trans_id и верните merchant_prepare_id в предусмотренном формате.
- В Complete проверьте подпись, идентификаторы, merchant_prepare_id и результат операции. Успех подготовки не равен успешной оплате: учитывайте error и требования протокола.
- При успешном завершении зафиксируйте оплату атомарно. Верните ответ Complete с согласованным merchant_confirm_id, не создавая новое исполнение при повторе.
- Сформируйте платёжный переход с реквизитами сервиса и ссылкой на нужный заказ. Проверьте соответствие идентификатора в переходе значению, которое ожидает Prepare.
Результат: подготовка не выдаёт покупку, завершение подтверждает оплату, а повторное Complete возвращает согласованный ответ без повторной услуги.
Коды ошибок и обязательные поля копируйте из действующего контракта Click Shop API. Произвольный текст вместо ожидаемой структуры ответа ломает обмен, даже когда сервер вернул успешный HTTP-статус.
4. Кнопки и выдача заказа
Теперь подключите пользовательский сценарий. В 2026 году надёжность платежей определяется не количеством кнопок, а тем, переживает ли процесс закрытие Telegram, повторный запрос и перезапуск сервера.
- Покажите состав заказа и доступные способы оплаты. Кнопки Payme и Click должны ссылаться на попытки одного заказа, а не создавать независимые покупки.
- Открывайте платёжную страницу через URL-кнопку. Секретные ключи в адрес не включайте; параметры перехода формируйте на сервере.
- Добавьте проверку состояния заказа в боте. Она читает подтверждённый статус из базы, а не принимает ответ покупателя за доказательство оплаты.
- После подтверждения поставьте исполнение в сохраняемую очередь. Сделайте задачу повторяемой без повторной выдачи: сбой отправки сообщения не должен создавать вторую бронь.
- Обработайте оплату через оба способа. Если две разные операции реально завершились, сохраните обе и запустите разбор переплаты. Не скрывайте вторую транзакцию ради удобного статуса.
- Проверьте 3 тестовых заказа: успешный, отменённый и с повторным уведомлением. Для последнего отправьте 2 повторных уведомления и убедитесь, что исполнение осталось единственным.
Результат: покупатель получает заказ после серверного подтверждения, а команда видит причину каждого изменения статуса.
Приёмка Whomever или другого исполнителя должна включать эти сценарии, а не только демонстрацию успешного платежа. Минус заказной интеграции — ответственность за поддержку обработчиков, обновление секретов и разбор расхождений остаётся частью проекта.
Второй сценарий: оплата после подтверждения менеджером
Для бронирования и товаров, требующих согласования, сначала подтверждайте возможность исполнения. Кнопка оплаты появляется после решения менеджера, а не сразу после заявки.
- Сохраните заявку без активного платёжного перехода.
- Дайте менеджеру подтвердить состав, сумму и условия заказа.
- Создайте платёжную попытку после подтверждения.
- Зафиксируйте срок действия заказа в собственной системе и проверяйте его на сервере.
- При изменении условий отмените старую возможность оплаты по правилам интеграции и создайте новую попытку.
Лучше подходит для: записи на услуги и заказов с ручным согласованием. Преимущество — меньше ситуаций, когда деньги приняты до подтверждения исполнения; недостаток — покупатель ждёт решения менеджера.
Не обещайте, что удаление кнопки аннулирует уже открытый платёж. Защиту обеспечивает проверка состояния заказа сервером и корректная обработка транзакции у провайдера. Старое сообщение в Telegram остаётся только интерфейсом.
Что проверить, если оплата не работает
Платёж завершён, заказ остаётся неоплаченным
Найдите операцию по идентификатору провайдера. Проверьте доступность обработчика, авторизацию или подпись, затем ответ API и запись в базе. Возвращайте подтверждение провайдеру после надёжного сохранения результата; потерянное сообщение покупателю исправляйте отдельно.
Сервер отклоняет сумму
Сравните значение заказа с amount, учитывая единицы конкретного API. Проверьте округление и неизменность суммы после создания попытки. Не исправляйте проблему отключением проверки: иначе сервер перестаёт контролировать, за что именно заплатили.
Заказ выдаётся повторно
Проверьте уникальность операции и атомарность смены статуса. Два параллельных запроса не должны одновременно запускать исполнение. Защитите отдельно фиксацию платежа и задачу выдачи: одного условия в коде перед записью недостаточно.
Проверка подписи Click не проходит
Сверьте порядок полей, формат значений и секрет нужного окружения с контрактом соответствующего этапа. Не меняйте исходное представление суммы до проверки подписи. Убедитесь, что Complete не проверяется формулой Prepare.
Деньги подтверждены, сообщение не пришло
Проверьте результат обращения к Telegram Bot API и состояние очереди. Пользователь способен заблокировать бота, поэтому не связывайте финансовый статус с доставкой сообщения. Сохраните оплаченный заказ и предусмотрите восстановление доступа через поддержку.
Как расширить процесс
После запуска в 2026 году подключайте CRM к событию подтверждённой оплаты, а не к нажатию кнопки. Передавайте внутренний номер заказа, провайдера, идентификатор операции и статус исполнения. Возвраты и отмены отправляйте отдельными событиями.
Для магазина следующий шаг — связать платёж с комплектацией, для записи — с подтверждённой бронью. Материал про Telegram-бота для интернет-магазина поможет определить границы такого сценария.
Не добавляйте автоматическое исполнение раньше сверки. Сначала обеспечьте сопоставление заказов с операциями Payme и Click, затем расширяйте процесс. Whomever предлагает заказную разработку ботов и CRM; правила конкретной связки фиксируйте в техническом задании.
FAQ
Можно ли подключить Payme и Click к одному Telegram-боту?
Да, оба способа можно связать с одной базой заказов через отдельные обработчики. Храните каждую платёжную попытку отдельно и выдавайте заказ только после подтверждения соответствующего провайдера.
Нужен ли сервер, если в боте уже есть кнопка оплаты?
Для описанной интеграции нужен серверный обработчик. Кнопка открывает платёжную страницу, но не проверяет подпись, сумму и окончательный статус операции.
Можно ли подтверждать оплату по скриншоту чека?
Скриншот не подходит для автоматического подтверждения оплаты. Основанием служит проверенное сообщение платёжной системы и сохранённая транзакция, связанная с заказом.
Чем Payme отличается от Click при подключении к боту?
В рассмотренной схеме Payme использует методы Merchant API, а Click Shop API — этапы Prepare и Complete. Поэтому общая модель заказов остаётся одной, но проверки и обработчики реализуются отдельно.
Можно ли продавать цифровой доступ внутри Telegram через эти кнопки?
Для цифровых товаров и услуг внутри Telegram действует оплата через Telegram Stars по правилам платформы. Не используйте внешние кнопки Payme и Click как замену этому порядку.
Что делать, если уведомление об оплате пришло повторно?
Нужно вернуть согласованный результат уже обработанной операции без повторной выдачи. Для этого сохраняйте идентификатор транзакции и защищайте изменение статуса от параллельного выполнения.
Как проверить подключение перед запуском в 2026 году?
Проверьте успешную оплату, отмену, неверную сумму, повтор уведомления и сбой доставки сообщения. Используйте предусмотренный провайдером порядок тестирования и отдельно проверьте конфигурацию рабочего окружения.
Последняя проверка
Оплаченный заказ и доставленное сообщение — разные факты. Перед запуском 2026 года намеренно остановите обработчик выдачи после записи оплаты, затем запустите снова. Правильный результат — заказ исполнен один раз, платёж не потерян, повторного списания ваш сценарий не инициирует.
