Платежі в Telegram-боті в Польщі: BLIK, Przelewy24, Stripe і Telegram Stars

Які способи оплати працюватимуть

Вбудований Telegram Payments і зовнішня платіжна сторінка є різними інтеграціями. Саме підключення Stripe через BotFather не підтверджує доступності BLIK у вбудованому вікні.

Для BLIK можна розглянути Stripe Checkout або Payment Links. Доступність залежить від акаунта й налаштувань оператора. Przelewy24 у Stripe є окремим способом оплати, а не гарантією всіх можливостей прямої інтеграції P24.

Для цифрових товарів і послуг, що продаються всередині Telegram, потрібні Telegram Stars. Зовнішнє посилання не є універсальним способом обійти цю вимогу.

Тому в кошторисі варто вказати конкретний шлях покупця: вбудований рахунок, checkout оператора або Stars. Формулювання «підключимо будь-які платежі» недостатньо.

Замовлення із зовнішньою оплатою

Приклад магазину фізичних товарів: покупець обирає товар у боті, отримує посилання на checkout, оплачує замовлення та повертається в чат. Це приклад запланованого сценарію, а не демонстрація готової інтеграції.

Перехід на сторінку подяки не підтверджує оплату. Сервер має перевірити сповіщення оператора та пов'язати його з правильним замовленням. Повторне сповіщення не повинно спричиняти повторну видачу.

До розробки погоджуємо місце зберігання замовлень, статуси для покупця та сповіщення про проблеми. Платіж, що очікує підтвердження, не повинен відображатися як оплачений.

Що підготувати для оцінки

Опишіть товар або послугу, країну продавця, валюту й потрібні способи оплати. Повідомте, чи є бот, сайт, CRM та акаунт оператора. Якщо бота немає, його створення та платежі можна оцінити окремо.

Надішліть публічне посилання на бота або сайт і приклад шляху покупця. Для першого звернення не потрібні токени BotFather, ключі API, паролі або банківські реквізити.

Після оцінки погодимо доступи, відповідальність за налаштування акаунта й тестовий режим. Перевірка продавця оператором є окремою залежністю проєкту, яку розробник не може гарантувати замість вас.

Чим відрізняються проєкти

Магазину фізичних товарів можуть знадобитися залишки, доставка та передавання замовлень у CRM. Запис на офлайн-послугу потребує перевірки вільного часу й умов скасування. Це не однакові інтеграції.

Для цифрової підписки, закритого каналу або мініпрограми окремо перевіряємо правила платформи й видачу доступу. Онлайн-консультація не стає фізичною послугою лише тому, що дзвінок відбувається в іншій програмі.

Визначте, чи потрібен новий бот повністю, чи лише доопрацювання наявного. Збереження старої логіки, перенесення даних та інтеграції з обліковою системою зазначаються в обсязі робіт окремо.

Комісії, повернення та межі робіт

Розробка, комісії оператора, хостинг і подальший супровід є різними витратами. У пропозиції потрібно розділити їх та перевірити чинні тарифи обраного сервісу.

Погодьте обробку неоплачених замовлень, скасувань, повторних сповіщень і повернень. Повернення грошей та скасування видачі товару або доступу можуть бути різними операціями.

Умови продажу, документи для покупця, податки й обробку персональних даних слід визначити з профільними фахівцями. Налаштування бота не замінює юридичної та бухгалтерської перевірки бізнесу.

Що перевірити до запуску

• Замовлення створюється з правильною сумою та валютою.
• Успішна оплата змінює статус правильного замовлення.
• Скасування або помилка не виглядають як успішна покупка.
• Повторне сповіщення не створює друге замовлення.
• Повернення й звернення до підтримки мають зрозумілий порядок.

Вартість залежить від наявного бота, кількості сценаріїв та інтеграцій. Після опису завдання можна погодити обсяг, ціну й строк. Розробка та витрати платіжного оператора оцінюються окремо.