Оплата внутри оформления
Карта, СБП, кошелёк или рассрочка — в одном сценарии, без ухода на чужую страницу и обратно. Меньше шагов значит меньше брошенных корзин.
Платежи и финансы
Интеграции: Платежи и финансы
Деньги приходят на счёт, а статус заказа меняется сам
Оплата — момент, когда заказ перестаёт быть намерением. Делаем платёжный слой так, чтобы провайдера можно было заменить или добавить второго без переписывания заказов, возврат оформлялся одной операцией, а сверка с учётом не превращалась в ежемесячную выгрузку из личного кабинета.
Какие задачи закрывает платёжная категория
Речь не только о приёме денег: важно, что происходит после оплаты — какой статус получает заказ, как оформляется возврат и как суммы попадают в учёт.
Статус заказа по факту платежа
Оплаченный заказ переходит в нужный статус сам. Менеджер не сверяет выписку и не меняет состояние заказа руками.
Возвраты из админки
Возврат и частичная отмена оформляются по исходному платежу одной операцией, с записью в журнал и отражением в учёте.
Рекуррент и подписки
Регулярные списания с понятной обработкой неудачных попыток: клиент получает уведомление, подписка не обрывается молча.
Сверка с учётом
Платежи, возвраты и комиссии сравниваются с заказами и реестром провайдера. Расхождение видно сразу, а не при закрытии месяца.
Один платёжный слой
Несколько провайдеров работают через общий интерфейс, поэтому замена или добавление эквайринга не затрагивает логику заказов.
Путь платежа от заказа до учёта
У каждого шага своя сторона-источник: заказ задаёт сумму, провайдер подтверждает факт оплаты, учёт фиксирует выручку. Размытое направление обмена — главная причина «зависших» оплат.
Сущность
Направление
Что важно учесть
Сумма и состав заказа
Заказ → платёжный провайдер
Платёж создаётся на стороне заказа: сумма, валюта и назначение фиксируются до открытия платёжной формы.
Форма или виджет оплаты
Провайдер → покупатель
Оплата проходит в виджете или на странице провайдера. Возврат покупателя на сайт сам по себе оплату не подтверждает.
Подтверждение оплаты
Провайдер → заказ
Уведомление обрабатывается идемпотентно: повторный вебхук не создаёт второй платёж и не меняет статус заказа дважды.
Возвраты и отмены
Заказ → провайдер
Возврат идёт по исходному платежу. Частичный возврат уменьшает его сумму, а не создаёт новую операцию.
Рекуррентные списания
Провайдер ↔ подписка
Привязка карты и расписание хранятся у провайдера, а состояние подписки и доступ клиента — в вашей системе.
Реестр операций и комиссии
Провайдер → учёт
Выгружается по расписанию и сравнивается с заказами. Комиссия отражается отдельно от суммы продажи.
Смена провайдера или версии его API затрагивает адаптер: сценарии оформления, возвратов и статусов заказа остаются прежними.
Правила, на которых держится платёжный контур
Это не рекомендации, а условия, при которых оплата, возврат и учёт всегда описывают одну и ту же операцию.
- Статус заказа меняется только по подтверждённому уведомлению провайдера, а не по возврату покупателя на сайт
- Повторное уведомление не создаёт второй платёж: операция сопоставляется по идентификатору платежа
- Возврат всегда привязан к исходному платежу, включая частичные суммы
- Неудачное списание не отменяет подписку: выполняется повторная попытка и уведомляется клиент
- Комиссия провайдера учитывается отдельно от суммы заказа — выручка и издержки не смешиваются
- Если провайдер недоступен, оформление не блокируется: заказ сохраняется, а оплату предлагается повторить
С чего начать: платёжный сценарий
Порядок работ для этой категории. Сценарии оплаты и возвратов описываются до разработки — на тестовом контуре провайдера.
Выбрать провайдера и способы оплаты
Карты, СБП, рассрочка, подписка. От этого зависит сценарий оформления и объём настроек в личном кабинете провайдера.
Определить источник правды по статусу
Оплату подтверждает только уведомление провайдера. Переход по ссылке «оплата успешна» статус заказа не меняет.
Описать возвраты заранее
Полный и частичный возврат, отмена до отгрузки, возврат после доставки — у каждого случая свой порядок и свои проводки.
Настроить сверку и мониторинг
Реестр операций и комиссий по расписанию, отчёт о расхождениях и оповещение, если обмен с провайдером встал.
Интеграции категории
Часто эти интеграции внедряются вместе — например, CRM и телефония, или магазин и маркетплейсы.
ЮKassa
Оплата, возвраты и сверка без ручной работы
Интеграция с ЮKassa: приём платежей, возвраты, рекуррентные списания и автоматическая сверка с учётом.
ПодробнееCloudPayments
Платежи и подписки на одном шлюзе
Интеграция с CloudPayments: эквайринг, подписки, рекуррент и платёжные виджеты.
ПодробнееТинькофф
Эквайринг с рассрочкой и выплатами
Интеграция с Тинькофф: интернет-эквайринг, рассрочка, выплаты партнёрам и сверка операций.
ПодробнееПлатёжные интеграции
Один платёжный слой — разные провайдеры
Платёжные интеграции под ключ: эквайринг, рекуррент, рассрочка, выплаты и сверка.
ПодробнееЧто делает платёжный контур надёжным
У провайдера бывают сбои и плановые работы. Оплата не должна теряться, а заказ — оставаться в неопределённом состоянии.
Идемпотентность
Повторная доставка одного и того же события не создаёт вторую сделку, второй заказ или второй платёж.
Очередь и повторные попытки
Если внешняя система недоступна, операция ждёт и повторяется по расписанию, а не теряется.
Журнал обмена
Видно, что и когда ушло, что вернулось и что не прошло. Неудачную операцию можно повторить вручную.
Лимиты провайдера
Учитываем ограничения по частоте запросов, чтобы не получить блокировку со стороны сервиса.
Сверка расхождений
Регулярная сверка ключевых сущностей между системами: расхождение видно в отчёте, а не в конце квартала.
Мониторинг и оповещения
При остановке обмена приходит уведомление ответственным, а не выясняется из жалобы клиента.
Все категории интеграций
Обмен редко ограничивается одной категорией: магазин обычно связан и со складом, и с платежами, и с маркетплейсами.
Частые вопросы о платёжных интеграциях
Если вашего вопроса здесь нет — задайте его в форме ниже.
Покупатель оплатил, а уведомление от провайдера не пришло. Заказ зависнет?
Нет. Успешная оплата подтверждается только уведомлением провайдера, и если оно потерялось, платёж подтягивается опросом по расписанию. Заказ переходит в оплаченный статус, как только подтверждение найдено — вручную сверять выписку не нужно.
Можно ли добавить второго провайдера и переключаться между ними?
Да. Провайдеры описываются адаптерами с общим интерфейсом, а выбор способа оплаты задаётся правилами: по сумме, типу клиента или способу платежа. Добавление второго эквайринга не требует переписывать логику заказов и возвратов.
Как устроены возвраты и частичные возвраты?
Возврат оформляется из админки по исходному платежу: полный или на часть суммы. Каждая операция пишется в журнал, а статус заказа и данные в учёте обновляются согласованно, чтобы возврат не превращался в отдельный «ручной» платёж.
Что нужно от нас, чтобы начать работы?
Договор с провайдером и доступы к его API, описание того, как сейчас меняется статус заказа после оплаты, и порядок работы с возвратами. Тестовый контур провайдера ускоряет проверку: сценарии прогоняются до вывода в продакшен.
Как проверяется, что суммы в заказах и в кабинете провайдера совпадают?
Настраивается регулярная сверка: реестр операций и комиссий сравнивается с заказами и возвратами. Расхождения попадают в отчёт с конкретными платежами, поэтому разбор не требует ручных выгрузок в таблицы.
Разберём ваш сценарий оплаты
Напишите, какой провайдер используете, как сейчас обрабатываете возвраты и как сверяете платежи с заказами. Предложим схему и назовём сроки.
Бесплатный аудит
Разбор технической части сайта: скорость, SSR, фильтры
Аудит текущей рекламы: где сливается бюджет
Анализ конкурентов в вашей нише
Прогноз CPL, ROAS и окупаемости
План действий на первый месяц
Получите бесплатный аудит интернет-магазина
За 3 рабочих дня разберём: где вы теряете заявки, какие каналы недооценены, и что даст рост в первые 30 дней.
За этот месяц
42 компании получили аудит
30 мин
реакция
3 дня
аудит
100%
доступ к кабинетам
Заявка на аудит
Без обязательств. С конкретными цифрами.