Приём платежей на сайте: ЮKassa, подписки и криптоплатежи

Сайт никогда не работает с банковскими картами напрямую — между ним и банками стоит платёжный агрегатор. В России для большинства бизнесов это ЮKassa: она принимает карты, СБП и другие способы, проводит платёж и сообщает сайту результат. Сайт отвечает за свою часть: создать платёж, дождаться подтверждения и выдать пользователю оплаченный товар или доступ.

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

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

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

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

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

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

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

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

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