Подключение онлайн‑оплаты: эквайринг и СБП с корректными статусами и возвратами

Подключение оплаты — это не “поставить кнопку”. Это деньги, юридика, безопасность, корректные статусы заказов и отсутствие потерь на каждом сбое. Мы подключаем платежные системы так, чтобы платежи стабильно проходили, правильно подтверждались (webhooks/callbacks), возвраты и частичные возвраты не превращались в хаос, а поддержка не ловила “оплата прошла, заказ не создался”.

• Кому подходит: интернет-магазины, сервисы с оплатой услуг, подписки, маркетплейс-подобные сценарии, B2B-личные кабинеты.
• Когда нужно: запускаете продажи, меняете платежку, растете и упираетесь в ошибки/отказы, нужно снизить комиссии/повысить конверсию оплаты.

Что вы получите на выходе

• Рабочий сценарий оплаты (карты/СБП/альтернативные методы — по задаче) в проде и в тестовом контуре.
• Корректные статусы: “создано → ожидает оплату → оплачено → отменено/возврат” без ручных костылей.
• Обработку webhooks с повторной доставкой, идемпотентностью и логированием.
• Возвраты (полные/частичные), отмены, спорные ситуации (chargeback/диспут — если применимо к провайдеру).
• Безопасность: токенизация, подписи запросов, ограничения по доступам, отсутствие хранения карточных данных на вашей стороне.
• Чек-лист запуска: что проверить, какие события мониторить, что делать при сбое.

Критические проблемы, которые мы закрываем (то, на чём “сыпятся” 80% интеграций)

• Оплата прошла, заказ не создался: разрыв между платежом и бизнес-операцией.
• Двойные списания/двойные заказы: отсутствие идемпотентности и защиты от повторов.
• Потерянные webhooks: нет очереди/повторов/проверки подписи → статусы не сходятся.
• Возвраты “ломают бухгалтерию”: нет корректной модели возврата и связей с заказом/оплатой.
• Слабая диагностика: не видно, где платеж упал и почему (нет логов/корреляции/метрик).

Методология подключения платежей

1) Разбор модели оплаты

• Что продаём: товары/услуги/цифровой доступ.
• Сценарии: единоразовая оплата, предоплата/доплата, подписка, счета для юрлиц (если нужно).
• Требования к фискализации/чекам/учёту (если актуально для проекта).
• Риски и ограничения: возвраты, частичные возвраты, отмены, лимиты, валюты.

2) Выбор провайдера и схема интеграции

• Подбираем схему под задачу: эквайринг/СБП/кошельки/оплата по ссылке/инвойсы (по необходимости).
• Определяем тип интеграции: редирект/виджет/SDK/сервер-сервер.
• Фиксируем события и статусы, которые должны “сходиться” в вашей системе.

3) Техническая реализация

• Создаем платежную сущность и связь с заказом (чтобы не было “деньги отдельно, заказ отдельно”).
• Реализуем создание платежа, подтверждение, отмену, возвраты.
• Подключаем webhooks: проверка подписи, повторы, защита от дублей, журналирование.
• Добавляем мониторинг критичных событий (ошибки оплаты, отказы, зависшие статусы).

4) Тестирование “как в жизни”, а не “одна успешная оплата”

• Успешная оплата.
• Отмена/отказ/таймаут, повторный платеж.
• Дубли webhooks, задержка webhooks, неверная подпись.
• Возврат полный/частичный, возврат после отгрузки (если применимо).
• Проверка письма/уведомлений/CRM-событий (если завязано).

5) Запуск и контроль

• Переход в прод по чек-листу.
• Контроль логов/метрик в первые дни после запуска.
• Фиксация “как работает” для поддержки: куда смотреть и что считать инцидентом.

Критерии “результат принят”

• Оплата проходит и отражается в заказе корректно, статусы согласованы.
• Webhooks обрабатываются надёжно: подпись, повторы, защита от дублей.
• Возвраты работают (в т.ч. частичные — если предусмотрено) и не ломают логику заказов.
• Есть тестовый контур и сценарии проверки.
• Есть журналирование/диагностика: можно понять “почему не прошло” без гаданий.

Чем мы отличаемся

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

Частые варианты работ (чтобы сразу понять объём)

• Базовая интеграция: 1 провайдер, 1 поток оплаты, webhooks, тест/прод, базовые статусы.
• Интернет-магазин: корзина/заказ, промокоды/доставка (если есть), статусы, возвраты, уведомления.
• Подписки: рекуррентные платежи, продление/отмена, пауза, списания, уведомления.
• Сложная интеграция: несколько провайдеров, фолбек-сценарии, антифрод-правила, отчеты сверки.

С этой услугой часто заказывают

• Онлайн-касса и фискализация
• Интеграция по API
• Интеграции с CRM/ERP
• Защита сайта

Чтобы начать: какая модель оплаты (товар/услуга/подписка), текущая CMS/стек, нужен ли СБП/инвойсы/фискализация, и где будет “жить” заказ (CMS/CRM/самопис). Детали согласуем по звонку.