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

Skirbo +
IntellectMoney

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

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

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

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

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

Заказ, позиции, количество, осмотр и версия решения; денежная сумма утверждается отдельно.

Возврат по исходному счётуПродавец / будущий адаптер → IntellectMoneyОбсудим в составе подключения

EshopId + InvoiceId либо OrderId + утверждённая OperationAmount; операция требует доступа и проверенного контракта.

Результат операцииIntellectMoney → Skirbo / учёт продавцаОбсудим в составе подключения

Проверять OperationState и Result.State, сохранять доступный InvoiceRefundId; сверка неизвестного результата отдельна.

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

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

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

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

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

Для продавца, принимающего оплату через IntellectMoney, и фулфилмента, который оформляет фактический возврат товара. Материал ограничен Merchant API и согласованием возврата по исходному счёту. Массовые выплаты Payout API — отдельный продуктовый процесс; его нельзя использовать как молчаливую замену возврата покупки.

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

В сохранённой документации описан POST purchaseToRefund с EshopId, InvoiceId либо OrderId и необязательной OperationAmount. Перед реализацией проверяются действующий контракт, подпись, доступ магазина и безопасная сверка результата; существующая связь со Skirbo не подтверждена.

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

  1. Зафиксировать акт приёмки, SKU, количество, состояние товара и исходный заказ; доступный остаток увеличивать только по решению склада.
  2. Сопоставить клиента, магазин EshopId и исходный InvoiceId либо OrderId. Отдельно связать строки возврата с суммой, согласованной продавцом.
  3. Финансовый ответственный проверяет предшествующие возвраты и утверждает OperationAmount; отсутствие суммы не использовать как значение по умолчанию для частичного возврата.
  4. После проверки доступа и контракта направить одну согласованную операцию purchaseToRefund либо выполнить её в разрешённом процессе продавца. Сохранить локальное основание до отправки.
  5. Получить OperationState и вложенный Result.State; при успешном бизнес-результате связать доступный InvoiceRefundId с основанием возврата.
  6. Сверить денежный результат у поставщика и передать в Skirbo подтверждение с суммой и ссылкой на операцию. Фискальный документ проверить в назначенной кассовой системе.
  7. При неизвестном результате, превышении остатка счёта или несовпадении магазина остановить повтор и передать финансовому ответственному сверку исходной операции.

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

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

Частичный возврат после складского осмотра

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

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

  1. Зафиксировать акт приёмки, SKU, количество, состояние товара и исходный заказ; доступный остаток увеличивать только по решению склада.
  2. Сопоставить клиента, магазин EshopId и исходный InvoiceId либо OrderId. Отдельно связать строки возврата с суммой, согласованной продавцом.
  3. Финансовый ответственный проверяет предшествующие возвраты и утверждает OperationAmount; отсутствие суммы не использовать как значение по умолчанию для частичного возврата.
  4. После проверки доступа и контракта направить одну согласованную операцию purchaseToRefund либо выполнить её в разрешённом процессе продавца. Сохранить локальное основание до отправки.
  5. Получить OperationState и вложенный Result.State; при успешном бизнес-результате связать доступный InvoiceRefundId с основанием возврата.
  6. Сверить денежный результат у поставщика и передать в Skirbo подтверждение с суммой и ссылкой на операцию. Фискальный документ проверить в назначенной кассовой системе.
  7. При неизвестном результате, превышении остатка счёта или несовпадении магазина остановить повтор и передать финансовому ответственному сверку исходной операции.

Результат: Один товарный возврат имеет прослеживаемую денежную часть; недоступный к продаже товар не становится доступным из-за возврата денег.

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

  • Успешный внешний OperationState не гарантирует успешный Result.State: документация показывает ошибку превышения доступного остатка внутри успешно обработанного запроса.
  • Потеря ответа не разрешает повторный возврат полной суммы.

Отмена или уменьшение ещё не завершённой покупки

Задача: Выбрать действие по денежному состоянию счёта до передачи товара.

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

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

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

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

  • Поздняя отмена заказа не доказывает физическое возвращение товара.
  • Нельзя подставлять прежний платёжный статус, если между чтением и действием прошла оплата.

Смена доступа для отдельного продавца

Задача: Обновить полномочия, сохранив незавершённые возвраты и границы клиентов.

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

  1. Зафиксировать, какие магазины и очереди используют заменяемый доступ; сохранить операции с неизвестным результатом для отдельной сверки.
  2. Подготовить новое хранение Bearer-токена и SignSecretKey по процессу продавца: документация предупреждает, что повторный запрос аннулирует старые доступы.
  3. Проверить разрешённый доступ без новой денежной операции и возобновить очередь только после сверки зависших оснований; журналировать версию секрета без его значения.

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

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

  • Тестовый доступ с TST описывает ограниченный набор методов и не подтверждает приёмку возвратов в рабочем магазине.

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

ДанныеОтветственный источникПравило обмена
Заказ и SKUПродавец / его учётная системаSkirbo связывает версию заказа и товарные строки; банковский идентификатор не заменяет SKU.
Остатки и отгрузкаСистема фактического складаРазрешение обработки по оплате и физическая выдача — разные события.
Деньги и платёжные статусыПоставщик платёжного или банковского продуктаСохранять исходный статус, сумму, валюту и время; соответствие складскому разрешению задаёт продавец.
ДокументыНазначенная кассовая и учётная системаПлатёжная операция не является доказательством фискализации или подписания закрывающих документов.
ВозвратСклад — товар; финансовый ответственный — деньгиФизический осмотр и денежное возмещение связаны идентификаторами, но подтверждаются отдельно.
Связь счёта и магазинаIntellectMoney и учёт продавцаEshopId и InvoiceId/OrderId сопоставляются внутри клиента; одинаковые номера заказов разных продавцов не объединяются.

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

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

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

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

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

  • Операция с пропущенной OperationAmount использует полную сумму счёта по документации; частичный возврат требует явного согласованного значения.
  • Успех обработки запроса и успех действия по счёту различаются; одного HTTP-ответа недостаточно.
  • Условия кассы, договора, суммы, валюты и доступа проверяются для конкретного продавца. Российский сценарий не определяет правила Казахстана и Узбекистана.
  • Текущие лимиты, сроки зачисления, повторяемость запросов и готовый коннектор Skirbo не подтверждены.
Стоимость и запуск

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

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

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

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

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

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

Можно просто не передавать сумму?

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

Что делать, если запрос обработан успешно, а внутри ошибка?

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

Подойдёт Payout API для того же возврата?

Это отдельная модель массовых выплат с созданием и исполнением операции. В этом сценарии используется связь с исходной покупкой; подмена её выплатой без отдельного решения продавца не предусмотрена.

В чтении платежа всё успешно, но PaymentStep=InProcess — это оплата?

Нет: успешное выполнение запроса чтения не завершает платёж. Проверяют бизнес-стадию и согласованный финансовый результат перед выдачей товара.

getPurchaseInfo заменяет проверку конкретного возврата?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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