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

Skirbo +
Mandarin

Спроектировать передачу складского результата уполномоченному платёжному контуру, чтобы отмена резерва не путалась с возвратом списанных средств, а выплата — с возвратом покупателю.

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

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

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

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

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

Выбор денежной операцииПлатёжный контур ↔ MandarinНужна проверка

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

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

Склад хранит связь и итог, не предполагает успех по отправленному запросу.

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

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

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

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

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

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

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

  1. Сопоставить клиента, заказ и платёжную связь в контуре Mandarin. Склад проверяет, что товар ещё не передан, и фиксирует отмену задачи сборки.
  2. Платёжный ответственный получает подтверждённое текущее состояние операции. Само слово «оплачен» в интерфейсе склада недостаточно для выбора действия.
  3. Разделить снятие ещё действующей блокировки и возврат уже списанной суммы. В прочитанном API команда reversal используется в обоих случаях, но с разной исходной транзакцией; тип Refund в справочнике не означает параметр action=refund. Разрешённый переход и сумму проверяет платёжный ответственный.
  4. Уполномоченный контур выполняет действие и сохраняет его отдельный идентификатор, сумму и результат. В Skirbo возвращается подтверждение принятого решения, а не секреты карты.
  5. Склад освобождает резерв по согласованному правилу и подтверждает фактическое наличие товара. Финансовый результат сверяется отдельно до закрытия расчёта с покупателем.
  6. При неизвестном состоянии или потере ответа операция отправляется на финансовую сверку. Повтор сообщения об отмене не вызывает второй Refund или Payout.

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

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

Отменить сборку с правильным финансовым действием

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

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

  1. Сопоставить клиента, заказ и платёжную связь в контуре Mandarin. Склад проверяет, что товар ещё не передан, и фиксирует отмену задачи сборки.
  2. Платёжный ответственный получает подтверждённое текущее состояние операции. Само слово «оплачен» в интерфейсе склада недостаточно для выбора действия.
  3. Разделить снятие ещё действующей блокировки и возврат уже списанной суммы. В прочитанном API команда reversal используется в обоих случаях, но с разной исходной транзакцией; тип Refund в справочнике не означает параметр action=refund. Разрешённый переход и сумму проверяет платёжный ответственный.
  4. Уполномоченный контур выполняет действие и сохраняет его отдельный идентификатор, сумму и результат. В Skirbo возвращается подтверждение принятого решения, а не секреты карты.
  5. Склад освобождает резерв по согласованному правилу и подтверждает фактическое наличие товара. Финансовый результат сверяется отдельно до закрытия расчёта с покупателем.
  6. При неизвестном состоянии или потере ответа операция отправляется на финансовую сверку. Повтор сообщения об отмене не вызывает второй Refund или Payout.

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

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

  • После физической передачи нужен процесс возврата товара, а не отмена сборки задним числом.

Согласовать сумму после частичной сборки

Задача: Использовать фактический состав как основание финансового решения.

Когда начинается: Часть заказанных единиц отсутствует.

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

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

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

  • Возможность частичного завершения блокировки не выводится из одного перечня типов операций.

Не заменить возврат выплатой

Задача: Не потерять связь денежных действий с исходной покупкой.

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

  1. Склад подтверждает товарную часть, продавец — сумму и основание.
  2. Выбирается проверенный процесс Refund, связанный с исходным списанием.
  3. Payout рассматривается только как отдельная договорная задача, если она действительно нужна, со своим основанием.

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

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

  • Binding подтверждает привязку карты, а не оплату конкретного заказа.

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

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

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

  • Какие операции уже реализованы вашим платёжным контуром?
  • Кто подтверждает неизвестный исход и исключает повтор денежного действия?
Перед оценкой

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

  • Примеры реальных платёжных связей без секретов, роли и договорная схема.
  • Таблица складских событий и разрешённых финансовых действий.
  • Отдельный контракт методов, статусов и проверки результата перед автоматизацией.
Границы сценария

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

  • Список типов не подтверждает endpoint, идемпотентность, webhook или срок удержания.
  • Тарификация и поддержка расчётов в Казахстане/Узбекистане не проверены.
  • Автоматические списания и выплаты со стороны Skirbo не заявляются.
Стоимость и запуск

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

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

Где выполняются платежи Mandarin и какие складские события должны инициировать финансовую проверку?

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

Auth и Pay одинаковы?

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

Reversal подходит после любого платежа?

В справочнике Reversal означает снятие блокировки, а Refund — возврат списанных средств. Однако API приёма платежей использует action=reversal также для возврата по успешному pay. Выбирать действие нужно по контракту и исходной транзакции, сохраняя раздельный финансовый смысл.

Payout можно считать возвратом?

Это отдельный тип выплаты. Его нельзя подменять возвратом исходной покупки без договорного основания и проверки связей.

Есть ли готовая автоматизация Skirbo?

Нет доказательства. Материал даёт предметную модель и вопросы к контракту; первый вариант предполагает подтверждение финансовым ответственным.

Auth и Preauth одинаково завершают частичную сборку?

Нет оснований считать их одинаковыми. Раздел расчётов описывает для preauth частичное списание с освобождением остатка, а для auth — предварительную отмену разницы. Применимость этих переходов подтверждают для схемы магазина.

Получили id транзакции — платёж завершён?

Это идентификатор созданной операции. Финансовый результат проверяют отдельно; ожидание или неизвестное состояние не разрешает повторное списание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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