Платёжный контур веб-платформы — это не кнопка оплаты, а учёт того, кто, за что и по какому тарифу платит: счета и их статусы, подписки, возвраты и сверка с провайдером. Для аудитории Узбекистана к нему подключают Payme, CLICK и Uzum Bank, а карточные данные при этом остаются на стороне провайдера.
Коротко
Кнопка оплаты списывает деньги один раз и на этом заканчивается. Биллинг помнит, за что заплатили, по какому тарифу, что из оплаченного уже израсходовано и когда придёт следующее списание.
Разница видна там, где платёж перестаёт быть разовым: у платформы появляются тарифы с лимитами, продления, перерасчёты при смене плана и возвраты. Всё это нужно считать в одном месте, иначе цифры у продукта, у провайдера и в бухгалтерии расходятся.
Если оплата нужна ещё и внутри Telegram, её проектируют по другим правилам — об этом статья оплата в Telegram-боте и автоматические уведомления.
Контур собирается из пяти частей, и каждая из них отвечает за свой участок пути денег. Разделение важно не ради красоты архитектуры: оно позволяет добавить нового провайдера, не переписывая продукт.
Совет Заложите поддержку нескольких провайдеров с первого дня, даже если на старте подключаете одного. Переписать платёжный модуль под вторую систему всегда дороже, чем сразу отделить общую логику счёта от особенностей конкретного провайдера.
Все три системы подключаются по одной схеме: договор с провайдером, тестовая среда, реализация протокола на стороне платформы и переход на боевые ключи. Различия — в том, кто кого вызывает и какие методы нужно реализовать.
| Провайдер | Как устроена интеграция | Что ещё есть | Документация |
|---|---|---|---|
| Payme | Merchant API: провайдер вызывает биллинг платформы методами проверки, создания, проведения и отмены транзакции | Subscribe API для привязки карты, инициализация платёжной страницы, подключение Telegram-бота | developer.help.paycom.uz |
| CLICK | SHOP API: платформа реализует запросы Prepare и Complete, после чего услуга доступна во всех интерфейсах CLICK | Merchant API, CLICK Pass, платёжная ссылка и оплата по карте | docs.click.uz |
| Uzum Bank | API-интеграция платёжных методов для сайта, приложения и Telegram-бота | QR-оплата в точке: статичный и динамический QR, FastPay | merchants.uzumbank.uz |
Ключевая особенность Payme и CLICK в том, что инициатива на стороне провайдера: он обращается к вашему серверу и спрашивает, существует ли такой заказ и можно ли провести по нему платёж. Значит, биллинг должен быть доступен снаружи, отвечать быстро и одинаково на повторные запросы.
Поддержка местных систем не требуется законом, но без них платформа теряет большую часть платящей аудитории: люди платят тем приложением, которое уже стоит у них на телефоне. Карты Uzcard и Humo обслуживаются через местные шлюзы, а для оплат из-за рубежа добавляют международного провайдера.
Подписка отличается от разовой продажи тем, что её нужно вести во времени, а не просто списать деньги. Большая часть потерь в подписочных продуктах приходится не на отказы клиентов, а на технические обрывы этого цикла.
Регулярные списания карты возможны не всегда: они зависят от того, поддерживает ли провайдер привязку карты и выпуск токена, и от условий договора. Если такой возможности нет, подписка ведётся счетами и напоминаниями — для клиента это выглядит почти так же, но требует другой логики уведомлений.
Сценарии, в которых что-то пошло не по плану, стоит проектировать вместе с успешным путём, а не после запуска. Именно здесь платформа либо сохраняет клиента, либо теряет и деньги, и доверие.
Для каждого сценария нужен понятный текст для клиента и запись в журнале для поддержки. Иначе разбор одной спорной оплаты занимает больше времени, чем её сумма стоит бизнесу.
Карточные данные хранит и обрабатывает платёжный провайдер. Платформа получает только статус операции и идентификатор платежа — этого достаточно, чтобы найти операцию, оформить возврат и свести отчётность.
PCI DSS — стандарт международных платёжных систем, и он касается работы с картами Visa, Mastercard и других участников совета. Карты Uzcard и Humo обслуживаются местными шлюзами по их собственным правилам, поэтому требования по ним уточняются у провайдера и банка-эквайера. Если форма ввода карты целиком находится у провайдера, мерчанту обычно достаточно упрощённой самооценки: анкета SAQ A предназначена как раз для тех, кто не хранит, не обрабатывает и не передаёт карточные данные у себя.
Точный набор требований определяет банк-эквайер или платёжная система, поэтому его фиксируют в договоре до начала разработки, а не после первой проверки.
Сверка нужна, чтобы расхождения находились автоматически, а не в конце квартала. Деньги проходят через несколько систем, и в каждой из них операция может остаться в своём статусе.
Пример Клиент оплатил заказ, провайдер провёл платёж, но уведомление не дошло до платформы из-за сбоя сети. В отчёте провайдера операция есть, в платформе счёт висит неоплаченным, в бухгалтерии деньги пришли без основания. Ежедневная сверка находит такую операцию на следующий день, а не через три месяца.
Минимальный порядок работы выглядит так: платформа регулярно запрашивает у провайдера список операций за период, сопоставляет их со своими счетами по идентификаторам и показывает расхождения отдельным списком. У Payme для этого есть метод получения информации о транзакциях мерчанта, у остальных провайдеров — свои выгрузки.
Дальше данные уходят в учётную систему: суммы, даты, назначения и возвраты. Если на платформе есть сторонние продавцы, к контуру добавляется ещё один слой — расчёты с ними, об этом статья разработка маркетплейса.
Отдельной цены на биллинг нет: он считается частью платформы или проекта интеграции. Связать системы, которые уже работают в компании, — от 4 000 $, отдельный модуль под задачу — от 8 000 $.
Состав работ и цены — на странице услуги ERP и интеграции. Комиссия провайдера в эту сумму не входит: её компания платит отдельно по своему договору. Если платёжный контур нужен интернет-магазину, посмотрите разбор в статье запуск интернет-магазина.
Syntra Systems начинает с модели продаж: что именно покупают, как часто, что происходит при отмене и кто из сотрудников работает с деньгами. Из этого получается схема счетов и статусов, и только потом выбираются провайдеры.
Дальше мы собираем контур с запасом на второго провайдера, проверяем его на тестовой среде на всех сценариях — успешном, отменённом, повторном и возвратном — и включаем сверку до запуска, а не после первой потери платежа. Историю платежей клиента мы выносим в его личный кабинет, чтобы поддержка не пересказывала выписки руками.
Обсудим вашу задачу
Расскажите, что нужно сделать, — оценим сроки и стоимость и предложим решение.
Технически да, но это сужает аудиторию: у людей разные банки и разные привычные приложения. Обычно платформы подключают две местные системы и добавляют международного провайдера, когда появляются клиенты из других стран.
Полный аудит нужен тем, кто сам хранит и обрабатывает карточные данные. Если форма ввода карты целиком находится у провайдера, мерчанту обычно достаточно самооценки по упрощённой анкете. Точные требования определяет банк-эквайер, и их стоит зафиксировать в договоре.
Настроить повторные попытки по расписанию и уведомление с просьбой обновить способ оплаты. Доступ ограничивается постепенно, чтобы клиент мог вернуться без потери данных. Полное отключение имеет смысл только после нескольких неудачных попыток и предупреждений.
На странице провайдера карту вводит сам провайдер, и платформа не касается этих данных. Форма на сайте выглядит бесшовнее, но переносит на компанию заметно больше требований по защите. Для большинства проектов выигрыш в удобстве этого не стоит.
Местные системы работают с картами Узбекистана, поэтому для зарубежных клиентов подключают международного провайдера и добавляют его как ещё один адаптер. Валюта счёта, налоги и правила возвратов при этом задаются отдельно от местного контура.
Да, если это поддерживает провайдер: часть суммы возвращается клиенту, остаток остаётся оплаченным. Платформа должна пересчитать состав заказа, изменить статус счёта и отразить возврат в выгрузке для бухгалтерии, иначе сверка перестанет сходиться.
История хранится в базе платформы: суммы, даты, статусы и идентификаторы операций провайдера. Доступ к финансовым разделам разграничивается по ролям, а действия сотрудников пишутся в журнал. Клиент видит свою часть истории в личном кабинете.
