Интеграция платёжной системы с сайтом: как устроена оплата

Интеграция платёжной системы с сайтом сводится к схеме из четырёх шагов: сайт создаёт платёж и отправляет клиента на оплату, платёжный сервис присылает серверное уведомление (webhook) об итоге, сайт сверяет статус и меняет заказ, а чек пробивается по 54-ФЗ. Простое подключение модулем CMS делается за дни, а своя интеграция с возвратами, подписками и сверкой — за недели. Главное, что проверять: заказ должен менять статус по уведомлению, а не по возврату клиента на страницу «Спасибо».

Три способа подключить оплату

Как работает платёж: схема по шагам

1. Заказ. Клиент оформляет заказ, сайт сохраняет его со статусом «ожидает оплаты».
2. Создание платежа. Сайт вызывает API платёжного сервиса и получает ссылку на оплату. Сумму, описание и номер заказа сохраняет у себя.
3. Оплата. Клиент платит картой, через СБП или другим способом на стороне сервиса.
4. Уведомление. Сервис отправляет на ваш адрес webhook о результате.
5. Проверка. Сайт убеждается, что уведомление настоящее и сумма совпадает с заказом.
6. Статус и чек. Заказ становится оплаченным, клиенту уходит письмо, формируется чек.
7. Сверка. Раз в сутки сайт сравнивает свои оплаты с реестром платежей сервиса.

Webhook: что в нём критично

На примере ЮKassa, документация которой описывает уведомления подробно (раздел Webhook): события приходят в виде «объект.статус», например payment.succeeded, а сервер должен ответить HTTP-кодом 200. Если подтверждения нет, уведомление повторяется в течение 24 часов, поэтому один и тот же webhook может прийти несколько раз. Для защиты от подделки документация рекомендует перезапросить объект по API и сверить статус, а также проверять IP-адрес отправителя.

• Идемпотентность. Повторное уведомление не должно второй раз отправлять письмо или списывать остатки.
• Сверка суммы. Сравнивайте сумму из платёжной системы с суммой заказа в вашей базе.
• Отдельный адрес. Webhook-обработчик должен быть доступен по HTTPS и не требовать входа на сайт.
• Быстрый ответ. Подтверждайте получение сразу, тяжёлую обработку выносите в очередь.
• Журнал. Храните тело каждого уведомления для разбора спорных случаев.

Что делать, когда сервер магазина недоступен в момент уведомления, разобрано в статье «Оплаты и вебхуки при сбое сервера магазина».

Чеки, СБП и комиссии

Продавец обязан выдавать чек по 54-ФЗ: его можно формировать через сервис платёжной системы или облачную кассу, но в запросе на платёж нужно передавать состав заказа, ставку НДС и признак расчёта. С 1 января 2026 года на комиссию за эквайринг начисляется НДС, это отдельно считается в статье «Эквайринг с НДС 22% или СБП». Основы приёма оплаты на сайте — в статье про эквайринг, СБП, чеки и возвраты.

Сценарии, на которых ломается стандартный модуль

• Предоплата и доплата. Заказ меняется после первого платежа.
• Частичный возврат. Нужен возврат одной позиции с корректным чеком.
• Подписка и автоплатежи. Нужно хранить привязанный способ оплаты и обрабатывать отказы по списаниям.
• Образовательные продукты. Рассрочки, чеки на услугу, справки об оплате для налогового вычета: типовой модуль такие сценарии обычно не закрывает.
• Несколько юрлиц или маркетплейс. Деньги нужно разделять между продавцами.

Чек-лист приёмки интеграции

1. Тестовый платёж успешный, неуспешный и отменённый: заказ меняет статус верно.
2. Повторный webhook не создаёт дублей.
3. Платёж с недоступным сайтом: статус обновляется после восстановления.
4. Сумма платежа не может быть изменена пользователем в форме.
5. Возврат полный и частичный создаёт корректный чек.
6. Ключи доступа хранятся на сервере, а не в коде страницы.
7. Ежедневная сверка находит расхождения и присылает уведомление.

Если нужна оплата в магазине, кабинете или подписке, мы делаем разработку интернет-магазинов и оплаты с тестовым контуром и сверкой платежей.