Приём платежей на микросайте: агрегаторы и кассы

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

Как устроен путь денег

Платёж проходит четыре звена: страница сайта, платёжный провайдер (агрегатор или банк), платёжная система и ваш учёт. Каждое звено решает свою задачу, и путать их — главная причина «деньги списались, а заказа нет».

Сайт формирует заказ: сумма, назначение, идентификатор в вашей базе. Провайдер открывает защищённую страницу оплаты, где покупатель вводит данные карты. После подтверждения провайдер отправляет на ваш адрес уведомление — вебхук — и только оно считается доказательством оплаты. Страница «Спасибо, оплата прошла» в браузере ничего не подтверждает: её адрес покупатель может открыть вручную.

Отдельная часть схемы — фискализация. В большинстве юрисдикций продавец обязан выдать покупателю чек, и агрегаторы обычно берут это на себя, если вы подключили кассу в их кабинете. Конкретные требования зависят от страны и налогового режима, поэтому сверяйте их с официальными источниками и условиями провайдера, а не с чужими статьями.

Что выбрать: агрегатор, банк или готовый модуль

Агрегатор — сервис, который уже подключён к нескольким платёжным системам и берёт на себя договоры, чеки и поддержку. Прямая интеграция с банком означает отдельный договор эквайринга и собственную техническую обвязку. Третий вариант — модуль в конструкторе сайтов: быстро, но с ограничениями по сценариям и внешнему виду.

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

Документацию удобно читать до регистрации: у ЮKassa и Stripe Checkout описаны одинаковые базовые шаги — создание платежа, страница оплаты, вебхук. Если схема в документации кажется непонятной, скорее всего, провайдер не подходит для вашего уровня.

Пошаговое подключение

1. Шаг 1: определите, что именно продаёте

   Одна услуга с фиксированной ценой подключается проще всего: ссылка на оплату с суммой и назначением. Подписки и произвольные суммы требуют отдельного сценария, поэтому решите это до выбора провайдера.

2. Шаг 2: зарегистрируйте продавца и подключите кассу

   Заполните данные о себе, добавьте способ получения выплат и проверьте, какие чеки обязан выдавать ваш режим. Без этого платежи могут проходить, а выплаты — задерживаться.

3. Шаг 3: создайте платёж на сервере

   Сумму и назначение формируйте на сервере, а не в скрытом поле формы: иначе покупатель подменит цену. Ключи держите в переменных окружения, а не в HTML.

   POST /v3/payments
   {
     "amount": {"value": "15000.00", "currency": "KZT"},
     "capture": true,
     "description": "Консультация, 60 минут",
     "confirmation": {"type": "redirect",
                      "return_url": "https://example.kz/thanks"},
     "metadata": {"order_id": "1042"}
   }

4. Шаг 4: примите и проверьте вебхук

   Обработчик должен сначала проверить подпись или контрольную сумму, затем найти заказ по идентификатору и только потом выдать товар. Одинаковый вебхук может прийти дважды — повторная обработка не должна выдавать второй доступ.

   # псевдокод обработчика
   event = parse(request.body)
   verify_signature(request.headers, request.body, secret)
   if payment_status(event) != "succeeded":
       return 200
   grant_access(event.metadata.order_id)   # идемпотентно
   return 200

5. Шаг 5: протестируйте сценарии отказа

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

6. Шаг 6: настройте возвраты и сверку

   Заранее решите, кто и как делает возврат: через кабинет или API. Раз в неделю сверяйте успешные платежи в кабинете с записями на сайте — расхождения обычно означают потерянный вебхук.

Подводные камни

• Доверие к странице возврата. Покупатель может открыть адрес «спасибо» вручную, не заплатив. Выдавайте доступ только по статусу из API или вебхука.
• Вебхук без проверки подписи и без идемпотентности. Так появляются бесплатные заказы и дубли выдач. Проверяйте подпись и храните идентификатор платежа в своей базе.
• Сумма из формы. Если цена приходит из браузера, её подменят. Пересчитывайте стоимость на сервере по своему прайсу.
• Ключи в репозитории. Секретный ключ в HTML или в публичном репозитории даёт доступ к платежам и возвратам. Храните его в переменных окружения и меняйте при утечке.
• Забытые тестовые настройки. Перед запуском проверьте, что боевой ключ и боевая касса включены, а тестовый режим выключен.

Форма оплаты — такая же точка входа, как любая другая: её стоит защитить от спама и автоматических отправок, о чём подробно написано в материале про защиту форм от спама. А чтобы не собирать заказы вручную, свяжите оплату с таблицей или ботом — принципы разобраны в статье про автоматизацию рутины.

Контрольный чек-лист

• [ ] Выбран провайдер и проверены комиссия, сроки выплат и способы оплаты.
• [ ] Подключена касса и понятно, какие чеки выдаются покупателю.
• [ ] Сумма и назначение формируются на сервере.
• [ ] Ключи хранятся в переменных окружения, тестовый режим отделён.
• [ ] Вебхук проверяет подпись и обрабатывается идемпотентно.
• [ ] Доступ выдаётся только после подтверждённого статуса платежа.
• [ ] Проверены отказ банка, повторная оплата и возврат.
• [ ] Настроена еженедельная сверка платежей с кабинетом.

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

Можно ли принимать оплату на статичном сайте без сервера?

Да, если у провайдера есть готовая платёжная ссылка или виджет: вы вставляете кнопку, а результат платежа приходит на вебхук. Для этого нужен хотя бы минимальный обработчик — функция в облаке, Google Apps Script или Telegram-бот. Полностью без кода обойтись можно только при ручной проверке зачисления, и это плохо масштабируется.

Зачем проверять подпись вебхука, если адрес секретный?

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

Что выбрать: агрегатор или прямую интеграцию с банком?

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

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

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

Приём платежей на микросайте — это не «прикрутить кнопку», а короткая цепочка с одним правилом: доверять только подтверждённому статусу от провайдера. Выберите агрегатор под свой объём, продумайте чеки и возвраты, проверьте отказы на тестовых картах — и оплата перестанет быть перепиской с ручными переводами. Смежные материалы: лид-магнит и форма захвата и таблицы для учёта заказов.