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

Skirbo +
Инвойсбокс

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

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

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

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

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

Подтверждён create-order; Skirbo даёт фактический состав как основание согласования.

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

Принятие заказа, оплата и разрешение выдачи разделены.

Возврат и документыПродавец ↔ Инвойсбокс / складОбсудим в составе подключения

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

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

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

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

Рассматривается API Инвойсбокс v3 для создания платёжного заказа. В нём различаются внешний merchantOrderId, ID Инвойсбокс, корзина, плательщик, ссылка оплаты и состояние. Для склада важно получать подтверждённое финансовое основание выдачи, а не ориентироваться на открытие страницы успешной оплаты.

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

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

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

  1. Зафиксировать организацию, merchantId, заказ продавца и неизменный merchantOrderId. Сопоставить SKU, количество, цену единицы и итог строки; фискальные реквизиты задаёт продавец по актуальным справочникам.
  2. Проверить, что сумма заказа равна сумме строк, а налоговые суммы соответствуют принятой модели. Изменение фактической сборки не исправляет уже выставленную корзину без согласования.
  3. Создать платёжный заказ под проверенным токеном и сохранить полученные id и paymentUrl. Адрес возврата покупателя в магазин не является серверным доказательством оплаты.
  4. После подтверждённого финансового результата склад получает разрешение на выдачу и повторно сверяет состав. Состояние hold не объединяют с окончательным списанием.
  5. Склад фиксирует фактическую передачу; платёжный контур подтверждает, что результат относится к нужному merchantId и заказу. Документы сверяются отдельным ответственным.
  6. Если ответ создания потерян, сначала найти заказ по merchantOrderId и сверить магазин, сумму и корзину. Несколько совпадений требуют ручного разбора; параллельные создатели блокируются на стороне интеграции.

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

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

Создать один платёжный заказ по согласованной корзине

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

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

  1. Зафиксировать организацию, merchantId, заказ продавца и неизменный merchantOrderId. Сопоставить SKU, количество, цену единицы и итог строки; фискальные реквизиты задаёт продавец по актуальным справочникам.
  2. Проверить, что сумма заказа равна сумме строк, а налоговые суммы соответствуют принятой модели. Изменение фактической сборки не исправляет уже выставленную корзину без согласования.
  3. Создать платёжный заказ под проверенным токеном и сохранить полученные id и paymentUrl. Адрес возврата покупателя в магазин не является серверным доказательством оплаты.
  4. После подтверждённого финансового результата склад получает разрешение на выдачу и повторно сверяет состав. Состояние hold не объединяют с окончательным списанием.
  5. Склад фиксирует фактическую передачу; платёжный контур подтверждает, что результат относится к нужному merchantId и заказу. Документы сверяются отдельным ответственным.
  6. Если ответ создания потерян, сначала найти заказ по merchantOrderId и сверить магазин, сумму и корзину. Несколько совпадений требуют ручного разбора; параллельные создатели блокируются на стороне интеграции.

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

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

  • Включённая проверка уникальности у поставщика не возвращает автоматически результат первого запроса; ID всё равно нужно получить сверкой.

Истёкший срок оплаты

Задача: Не удерживать товар бесконечно из-за старой платёжной ссылки.

Когда начинается: Истёк expirationDate неоплаченного заказа.

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

Результат: Резерв соответствует актуальному заказу.

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

  • Время действия из примера документации не применяется к рабочему счёту.

Вернуть часть принятого товара

Задача: Развести возвратное складское событие и платёжную операцию.

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

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

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

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

  • Отмена оплаченного заказа может иметь денежный эффект; её нельзя считать безобидной заменой возврата.

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

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

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

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

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

  • Версия v3/l3, merchantId, токен и подтверждённый способ уведомлений.
  • Правило уникальности номера и защита от параллельного создания.
  • Корзина с проверенной арифметикой, плательщик и актуальные фискальные справочники.
Границы сценария

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

  • v3 и l3 нельзя смешивать по форме токена и адресам.
  • Прочитанная документация не заменяет актуальную проверку налоговых правил, ставок и договорных способов оплаты.
  • Контракт уведомлений требует проверки подписи и состояния заказа; X-Event-Id сам по себе не доказывает подлинность, а короткая выборка по createdAt не покрывает поздние изменения старых заказов.
Стоимость и запуск

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

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

Какая версия биллинга, организация-плательщик и политика отгрузки используются?

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

HTTP 200 при проверке токена достаточно?

Нет. Документ отмечает анонимный ответ с userId:null; проверяют непустой идентификатор и правильный контекст доступа.

merchantOrderId сам защищает от дублей?

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

Можно отгрузить после перехода на successUrl?

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

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

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

Почему нельзя удалить дубли только по id заказа?

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

После возврата заказ всё ещё completed — это ошибка?

Само по себе нет: возврат — отдельный заказ со своими состояниями. Финансовая сверка должна учитывать и исходную оплату, и соответствующие возвратные операции.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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