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