Обсудить задачу
Платежи

Skirbo +
Долями

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

Посмотреть сценарии

Какой обмен обсудим

Зафиксируем нужные операции, направление данных и условия приёмки.

ОперацияНаправлениеСостав и готовность
Фактический составSkirbo → продавецОбсудим в составе подключения

Основание для согласования Commit, без самостоятельного распоряжения деньгами клиента.

Заявка и финансовый результатПлатёжный контур продавца ↔ ДолямиОбсудим в составе подключения

Create/Info/Commit/Cancel/Refund и уведомления; связь по заявке и магазину.

Реестр выплатДолями → учёт продавцаОбсудим в составе подключения

Отдельная сверка возмещения; транспорт реестра согласуется по доступному кабинету.

На узком экране таблицу можно прокрутить в сторону.

Это сценарии для обсуждения. Методы API сервиса сами по себе не подтверждают готовность подключения в Skirbo.

Для какой задачи подходит сервис

Долями рассматривается как способ оплаты частями в магазине российского продавца. Для склада важны подтверждённый состав заказа и финансовое разрешение на выдачу, а для продавца — различие первого списания, последующего графика покупателя и возмещения магазину. Долями Плюс и другие условия финансирования нельзя автоматически считать тем же договорным сценарием.

Как организовать обмен

Официальная документация описывает Create, Commit, Cancel, Info и Refund, а также уведомления о переходах заявки. Для доступа нужны учётные данные партнёра и mTLS-сертификат. Уведомление проверяют по правилам сервиса и сопоставляют с актуальным состоянием через API. Реестры выплат доступны отдельно в кабинете руководителя.

Предлагаемый порядок работы

  1. Магазин сохраняет связь своего заказа с заявкой Долями и магазином продавца. Фулфилмент получает только разрешённые строки для сборки; сведения для идентификации покупателя не превращаются в складские реквизиты.
  2. По уведомлению или Info платёжный контур проверяет стадию заявки. Одобрение и блокировка средств отделяются от подтверждённого списания.
  3. Skirbo собирает заказ и передаёт продавцу фактические SKU, количество и недостачу. Продавец согласует изменения с покупателем и пересчитывает сумму с учётом предоплаты или баллов.
  4. Пока заявка ожидает подтверждения, продавец передаёт согласованный состав через Commit. Уменьшение возможно в пределах исходной суммы; более дорогая замена требует отдельного решения, а не скрытого увеличения.
  5. Платёжный контур получает подтверждение и перечитывает результат. Committed означает принятие подтверждения до списания первого платежа; Completed подтверждает это списание. Продавец определяет проверяемое правило допуска к выдаче.
  6. После разрешения склад физически передаёт заказ и фиксирует выдачу. Потерянный ответ Commit разбирают через состояние прежней заявки, не создавая автоматически новый заказ или платёж.

Практические сценарии

Предлагаемая схема для согласования и пилота. Она не означает, что описанный обмен уже настроен в Skirbo.

Подтвердить фактически собранный заказ

Задача: Согласовать сумму с наличием до окончательного подтверждения.

Когда начинается: Покупатель выбрал Долями, заявка ожидает подтверждения магазина.

  1. Магазин сохраняет связь своего заказа с заявкой Долями и магазином продавца. Фулфилмент получает только разрешённые строки для сборки; сведения для идентификации покупателя не превращаются в складские реквизиты.
  2. По уведомлению или Info платёжный контур проверяет стадию заявки. Одобрение и блокировка средств отделяются от подтверждённого списания.
  3. Skirbo собирает заказ и передаёт продавцу фактические SKU, количество и недостачу. Продавец согласует изменения с покупателем и пересчитывает сумму с учётом предоплаты или баллов.
  4. Пока заявка ожидает подтверждения, продавец передаёт согласованный состав через Commit. Уменьшение возможно в пределах исходной суммы; более дорогая замена требует отдельного решения, а не скрытого увеличения.
  5. Платёжный контур получает подтверждение и перечитывает результат. Committed означает принятие подтверждения до списания первого платежа; Completed подтверждает это списание. Продавец определяет проверяемое правило допуска к выдаче.
  6. После разрешения склад физически передаёт заказ и фиксирует выдачу. Потерянный ответ Commit разбирают через состояние прежней заявки, не создавая автоматически новый заказ или платёж.

Результат: Собранные строки, согласованная сумма и подтверждение оплаты связаны одним заказом.

Если возникло исключение

  • Отказ или отмена не списывает остаток склада. Ожидание подтверждения, срок действия заявки и возможное охлаждение проверяются для выбранного продукта; точные тайминги здесь не обещаются.

Вернуть одну позицию с баллами или иной предоплатой

Задача: Не вернуть через Долями сумму, оплаченную другим способом.

Когда начинается: Продавец согласовал возврат части покупки.

  1. Склад принимает конкретные единицы и фиксирует качество; деньги возвращает уполномоченный контур продавца, а не сотрудник склада по одному сканированию.
  2. По исходной корзине рассчитывают возвращаемые товары и распределение суммы между Долями и предоплатой. Документация Refund отдельно учитывает сумму предоплаты при частичном возврате.
  3. Продавец оформляет Refund либо выполняет возврат в подключённой системе/кабинете; сохраняет основание, исходную заявку и сумму.
  4. Финансовый результат проверяют отдельно от приёмки. При потерянном ответе выясняют, принят ли прежний возврат, прежде чем отправлять новый. Пригодность товара и пополнение остатка подтверждает склад.

Результат: Сохраняется история товара, частичного возврата и распределённых сумм.

Если возникло исключение

  • Баллы и другую предоплату продавец обрабатывает в их исходном контуре. Изменение графика покупателя нельзя считать банковским перечислением всей суммы возврата.

Сверить исполнение и возмещение магазину

Задача: Отделить выполненную продажу от фактических расчётов с продавцом.

Когда начинается: Бухгалтер проверяет период продаж и возвратов.

  1. Из кабинета руководителя получают реестр выплат за нужный период. Отдельно берут заказы продавца, подтверждения исполнения и журнал финансовых возвратов.
  2. Сопоставляют записи по сохраняемым идентификаторам заявки и магазина, а не по одной сумме или фамилии. Формат реестра и поля связи проверяются на обезличенном примере перед автоматизацией.
  3. Разбирают пропущенные записи, частичные возвраты и отличие суммы возмещения от товарной суммы; банковскую выписку сверяют отдельным доказательством.
  4. Исправление финансовой сверки возвращают в учёт продавца. Уже подтверждённую физическую выдачу не выполняют повторно при повторной загрузке реестра.

Результат: Продавец видит расхождения между продажей, возвратом и возмещением.

Если возникло исключение

  • График выплат, комиссия и окончательные суммы определяются договором. Публичная справка о реестрах не подтверждает API их выгрузки.

Кто управляет данными

ДанныеОтветственный источникПравило обмена
Заказ, цена, скидки и предоплатаПродавецИтоговая сумма согласуется по фактическому составу.
Заявка и график платежейДолямиСклад не пересчитывает график клиента самостоятельно.
SKU, резерв и выдачаSkirbo / обслуживаемый складФинансовое событие разрешает действие, но не доказывает физическую передачу.
Возмещение и банковская сверкаБухгалтер продавцаРеестр выплат и выписка проверяются отдельно от складского статуса.
Физический возвратСкладПриход и качество товара отделены от финансового возврата.

Что обсудить перед пилотом

  • Включено ли автоматическое подтверждение и успевает ли склад сообщить расхождения?
  • Кто согласует распределение баллов/предоплаты при частичном возврате?
  • Какая связь идентификаторов доступна в реестре выплат конкретного магазина?
Перед оценкой

Что нужно уточнить

  • Договор и конкретный продукт Долями для магазина; уполномоченный владелец платёжных операций.
  • Партнёрский тестовый доступ, mTLS-сертификат и спецификация проверки уведомлений; секреты передаются через защищённый процесс подключения.
  • Обезличенный заказ с частичной сборкой, предоплатой/баллами и пример соответствующего возврата.
  • Правило выдачи, права фулфилмента и отдельный доступ бухгалтера к реестрам выплат.
Границы сценария

Что учесть заранее

  • Изменить подтверждаемый состав можно на допустимой стадии и без увеличения исходной суммы. Поведение автоматического подтверждения нужно учесть до подключения склада.
  • API Completed подтверждает первый платёж, а кабинетное «Оплачено» в справке означает завершение всех долей; ярлыки разных интерфейсов не сливаются.
  • Возврат, перерасчёт графика и возмещение магазину имеют разный смысл. Тарифы, SLA и срок выплаты не обещаются по исторической статье.
  • Фискализация — отдельная настройка кассы и учёта продавца; российские правила не распространяются автоматически на другие страны.
Стоимость и запуск

Оценим ваш набор операций

На объём работ влияют версии систем, доступы, число кабинетов, направление обмена и обработка ошибок. После разбора задачи согласуем реализацию, стоимость и сроки.

Подготовьте один заказ Долями с неполной сборкой, его заявку и обезличенный реестр выплат — определим первый проверяемый процесс.

Вопросы о подключении

Можно подтвердить только то, что есть на складе?

Документация допускает изменение состава при ожидании подтверждения, если итоговая сумма не выше исходной. Склад передаёт факт, а продавец согласует корзину и выполняет Commit.

Покупатель вернулся на success_url — можно выдавать?

Сам редирект не подтверждает финансовый результат. Нужны проверенные данные заявки и согласованное правило выдачи; одобрение, холд и списание первого платежа различаются.

Почему после частичного возврата заказ ещё подтверждён?

Кабинетная справка допускает такой статус при пересчитанном графике и оставшихся долях. Для сверки нужны возвращённые суммы и позиции, а не только подпись статуса.

Нужно ждать, пока покупатель оплатит все доли?

График покупателя и расчёты с магазином — разные процессы. Правило выдачи и возмещения устанавливают по договору и подтверждённым событиям; склад не ожидает произвольно весь график.

Кто отвечает за чек?

Продавец согласует кассу и порядок формирования чеков. Документация предусматривает отдельное подключение онлайн-кассы; складское подтверждение само по себе не является готовым фискальным документом.

Интеграция уже готова?

Изучаем возможность связи со Skirbo. Материал описывает предложенный процесс; работающий коннектор, запуск и сроки подключения не подтверждены. Перед запуском подтвердим состав операций и проверим результат на согласованном сценарии.

Официальные материалы сервиса

Используем для оценки возможностей внешней системы. Документация не является подтверждением готовности коннектора Skirbo.

Посмотрите другие сценарии

Весь каталог →
Ваш процесс → следующий шаг

Что хотите связать со Skirbo?

Выберите сервисы и расскажите, какие данные нужно передавать. Можно описать одну интеграцию или связку из нескольких систем.

  1. Разберём задачуУточним роли, склады и операции.
  2. Проверим возможностьОпределим доступы, ограничения и состав работ.
  3. Согласуем запускОбсудим стоимость, сроки и критерии готовности.

Оценка заявки не означает, что подключение уже готово или разработка согласована. Пароли, API-ключи и данные покупателей в форму не добавляйте.

1. Какие сервисы подключить?

До 5 сервисов в одной заявке.

Укажите роль — подскажем, какие особенности процесса описать.

2. Какие задачи решить?

Выберите от 1 до 8 задач.

Компания и объём заказов необязательно
3. Как с вами связаться?
Проверяем возможность отправки. Вы также можете подготовить запрос и передать его поддержке.
Открыть поддержку в Telegram

Копирование и переход в Telegram сами по себе не отправляют заявку.

Названия и логотипы используются для обозначения сервисов. Состав подключения и условия уточняем для вашей задачи.