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