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

Skirbo +
Подели

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

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

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

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

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

Результат сборки служит основанием для COMMIT в двухстадийной онлайн-схеме.

Статус заявки и возвратыПодели → платёжный контур продавцаОбсудим в составе подключения

INFO и нотификации, история возвратов с отдельным ID.

Офлайн-сверкаПодели → учёт магазинаОбсудим в составе подключения

ORDER_RECONCILIATION ограничен кассовыми операциями; банковская выписка отдельно.

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

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

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

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

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

Прочитаны официальный API, протокол и статусная модель: CREATE, COMMIT, CANCEL, REFUND, INFO, HTTP-нотификации и сверка ORDER_RECONCILIATION. API использует HTTPS, mTLS и Basic Auth. Примеры базового адреса относятся к тестовому контуру; боевой адрес выдаёт менеджер. Готовые модули CMS не являются доказательством подключения Skirbo.

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

  1. Продавец передаёт в CREATE свой идентификатор заказа, строки и финансовый состав. Предлагаемый журнал Skirbo связывает их с клиентом фулфилмента, юрлицом, магазином и SKU.
  2. Покупатель проходит оформление; платёжный контур получает WAIT_FOR_COMMIT либо читает состояние через INFO. Это ожидание подтверждения с холдом, а не окончательная оплата.
  3. Склад подтверждает собранные позиции и расхождения. Продавец проверяет, доступно ли партнёру частичное подтверждение; только при таком доступе в COMMIT передают изменённый состав и сумму не выше исходной. Без него требуется отдельное решение по заказу.
  4. Платёжный контур проверяет окончательный результат: COMMITTED ещё не равен COMPLETED. В случае отказа первого платежа товар не выдаётся автоматически.
  5. После проверенного COMPLETED и внутреннего разрешения продавца склад выполняет физическую выдачу, сохраняет её единственный идентификатор и возвращает факт в заказ.
  6. Если ответ или уведомление потеряны, INFO восстанавливает состояние существующего заказа. Повтор события не повторяет сборку, выдачу или подтверждение суммы.

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

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

Собрать и подтвердить онлайн-заказ в две стадии

Задача: Не выдавать товар только по одобрению заявки.

Когда начинается: Магазин создал заказ с двухстадийной оплатой.

  1. Продавец передаёт в CREATE свой идентификатор заказа, строки и финансовый состав. Предлагаемый журнал Skirbo связывает их с клиентом фулфилмента, юрлицом, магазином и SKU.
  2. Покупатель проходит оформление; платёжный контур получает WAIT_FOR_COMMIT либо читает состояние через INFO. Это ожидание подтверждения с холдом, а не окончательная оплата.
  3. Склад подтверждает собранные позиции и расхождения. Продавец проверяет, доступно ли партнёру частичное подтверждение; только при таком доступе в COMMIT передают изменённый состав и сумму не выше исходной. Без него требуется отдельное решение по заказу.
  4. Платёжный контур проверяет окончательный результат: COMMITTED ещё не равен COMPLETED. В случае отказа первого платежа товар не выдаётся автоматически.
  5. После проверенного COMPLETED и внутреннего разрешения продавца склад выполняет физическую выдачу, сохраняет её единственный идентификатор и возвращает факт в заказ.
  6. Если ответ или уведомление потеряны, INFO восстанавливает состояние существующего заказа. Повтор события не повторяет сборку, выдачу или подтверждение суммы.

Результат: Заказ выдан по подтверждённому финансовому результату и согласованному составу.

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

  • Если состав или сумма больше разрешённых, требуется решение продавца. Истечение жизни заявки и отказ разбираются до выдачи, а не маскируются складским статусом.
  • Ошибка COMMIT 422 order_changed означает недоступность частичного подтверждения при отличии сумм. Операция уходит продавцу: проверить сумму, согласовать отмену/новый заказ по допустимому состоянию. Слепой повтор COMMIT и автоматическое создание второго заказа запрещены проектным правилом.

Оформить частичный возврат

Задача: Сохранить идентификатор возврата и проверить результат перерасчёта.

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

  1. Склад принимает и осматривает конкретные SKU; продавец связывает их с первоначальными идентификаторами строк Подели.
  2. Уполномоченный контур оформляет REFUND с идентификатором возврата магазина и возвращаемыми количествами. Произвольную сумму refundedSum применяют только при согласованном праве партнёра.
  3. Сохраняют ответ, но не считают refund.status доказательством окончательного исполнения. Проверяют актуальный заказ, суммы и историю возвратов доступным интерфейсом.
  4. При частичном возврате график оставшихся платежей может уменьшиться без немедленного перечисления денег покупателю. Магазин объясняет результат по фактическому перерасчёту, а склад отдельно приходует пригодный товар.
  5. При таймауте ищут прежний возврат по заказу и своему refund ID; новый запрос не создают вслепую.

Результат: Возврат товара и финансовая корректировка имеют прослеживаемую связь.

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

  • REFUNDED используется и для частичного возврата, а состояние может вновь стать COMPLETED после расчётов по остаточному графику. Поэтому один ярлык не заменяет историю сумм.

Сверить кассовые оплаты и возвраты

Задача: Не принять офлайн-реестр за универсальную сверку всех онлайн-заказов.

Когда начинается: Ответственный закрывает период продаж торговой точки.

  1. Для кассового сценария запрашивают ORDER_RECONCILIATION с периодом, детализацией и при необходимости выбранной кассой/торговым центром. Подтверждённая область этого метода — офлайн-заказы.
  2. Разбивают период на допустимые интервалы и сопоставляют оплаты с заказами, а возвраты — по дате запроса возврата, даже если исходная покупка была раньше.
  3. Сверяют сумму, идентификаторы и состояние с журналом магазина. Онлайн-заказы проверяют через INFO и согласованный финансовый отчёт; покрытие не расширяют предположением.
  4. Бухгалтер отдельно сопоставляет возмещение с банковской выпиской. Обнаруженное расхождение заводит на разбор, не меняя задним числом факт выдачи товара.

Результат: У магазина есть проверенная сверка в границах подтверждённого метода.

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

  • Прочитанный API ограничивает период ORDER_RECONCILIATION 24 часами; timezone и включённые границы проверяют при реализации. Метод не доказывает получение денег на банковский счёт.

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

ДанныеОтветственный источникПравило обмена
Коммерческий заказ и позицииПродавецID строки хранится отдельно от артикула и складского SKU.
Холд, оплата и графикПоделиAPPROVED, WAIT_FOR_COMMIT, COMMITTED и COMPLETED не объединяются.
Физическая выдача и возвратSkirbo / складПовтор финансового события не повторяет движение товара.
Возврат магазинаУполномоченный продавецСобственный ID возврата и возвращаемое количество позволяют разбирать повтор.
Сверка и возмещениеБухгалтер продавцаОфлайн-операции и банк имеют отдельные источники доказательства.

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

  • Какая схема оплаты включена для магазина и где принимают решение о COMMIT?
  • Нужны онлайн-заказы, кассовый QR или оба процесса с разными правилами?
  • Как подтверждается завершение возврата и сверяется возмещение продавцу?
Перед оценкой

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

  • Партнёрский договор, выбранная одно- или двухстадийная онлайн-схема и доступ к тестовому контуру.
  • Логин/пароль, mTLS-сертификат и согласованный callback; боевой адрес получают у менеджера.
  • Таблица заказ → строки Подели → SKU → клиент/магазин и пример частичного возврата.
  • Владелец подтверждения, право задавать сумму возврата и правило восстановления после потерянного ответа.
  • Подтверждение доступности частичного COMMIT для партнёра; правило обработки order_changed, включая владельца решения об отмене и новом заказе.
Границы сценария

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

  • Офлайн-покупки по QR описаны как одностадийные; двухстадийный онлайн-процесс нельзя переносить на кассу.
  • COMMITTED — подтверждение магазина, COMPLETED — успешный первый платёж. Погашение всех будущих платежей покупателем — другой процесс.
  • X-Correlation-ID служит диагностике запроса; его наличие не доказывает бизнес-идемпотентность повторного возврата.
  • Синхронный ответ CANCEL, нотификации и refund.status имеют разные значения; запрет повторов определяется операцией, а не одним HTTP-кодом.
  • ORDER_RECONCILIATION подтверждён для офлайн-заказов. Тарифы, расчёт с магазином, правила фискализации и доступность вне РФ проверяются отдельно.
  • Частичное подтверждение не универсально: COMMIT может вернуть 422 order_changed при изменении суммы. Доступ проверяется по договору и тестовому сценарию до внедрения.
Стоимость и запуск

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

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

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

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

Одобрение уже разрешает выдачу?

Нет: APPROVED означает одобрение, а WAIT_FOR_COMMIT — холд в двухстадийной схеме. Склад должен получить разрешение после проверенного успешного результата, который договорились использовать для выдачи.

Можно убрать отсутствующую позицию?

Изменённый состав через COMMIT допустим только при доступном партнёру частичном подтверждении и сумме не выше исходной. Если возвращён 422 order_changed, продавец проверяет суммы и согласует дальнейшее действие по состоянию заказа. Система не повторяет запрос вслепую и не оформляет второй заказ автоматически.

Почему возврат не вернулся деньгами на карту сразу?

Частичный возврат сначала может уменьшить оставшийся график. Непосредственное перечисление зависит от соотношения возврата и оставшихся платежей; складская приёмка этого не определяет.

Что означает refund.status?

API прямо отделяет статус обработки запроса от конечного результата возврата. Проверяются заказ, история и суммы; один успешный HTTP-ответ недостаточен.

Можно одним методом сверить онлайн и офлайн?

У прочитанного ORDER_RECONCILIATION указана область офлайн-заказов. Для онлайн нужна отдельная проверка INFO и согласованного отчёта; универсальный реестр не обещается.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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