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

Skirbo +
Payture

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

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

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

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

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

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

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

Подтверждён метод списания заблокированных средств с явным Amount.

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

Отдельная сверка Id/OrderId и готовности чека.

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

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

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

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

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

Прочитаны Charge, GetState, Refund, Unblock и чтение фискального статуса Payture API. Подпись уведомлений, доступ терминала и правила оставшейся блокировки проверяются для договора отдельно. Рабочие денежные операции в рамках подготовки статьи не выполнялись.

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

  1. Сопоставить клиентскую организацию, заказ, платёжный терминал Payture и OrderId. Номер отгрузки не должен подменять ID платежа.
  2. Склад подтверждает собранные SKU, количество и расхождения. Продавец согласует окончательный состав с покупателем и рассчитывает сумму по своей ценовой модели.
  3. Перед решением о Charge проверить, что платёж ещё Authorized. Явно задать согласованную сумму в копейках; пропуск Amount по документации означает полное списание.
  4. Уполномоченный платёжный контур выполняет списание, проверяет Success, OrderId, фактический Amount и ошибку при отказе. Склад получает разрешение только по согласованному подтверждённому результату.
  5. Физически выдать товар и сохранить событие передачи. Фискальный результат сверить отдельно: принятие задания чека и готовый чек имеют разный смысл.
  6. При таймауте или промежуточном состоянии сначала выяснить фактический результат платежа. Не повторять денежное действие из-за отсутствия локального ответа или чека.

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

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

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

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

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

  1. Сопоставить клиентскую организацию, заказ, платёжный терминал Payture и OrderId. Номер отгрузки не должен подменять ID платежа.
  2. Склад подтверждает собранные SKU, количество и расхождения. Продавец согласует окончательный состав с покупателем и рассчитывает сумму по своей ценовой модели.
  3. Перед решением о Charge проверить, что платёж ещё Authorized. Явно задать согласованную сумму в копейках; пропуск Amount по документации означает полное списание.
  4. Уполномоченный платёжный контур выполняет списание, проверяет Success, OrderId, фактический Amount и ошибку при отказе. Склад получает разрешение только по согласованному подтверждённому результату.
  5. Физически выдать товар и сохранить событие передачи. Фискальный результат сверить отдельно: принятие задания чека и готовый чек имеют разный смысл.
  6. При таймауте или промежуточном состоянии сначала выяснить фактический результат платежа. Не повторять денежное действие из-за отсутствия локального ответа или чека.

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

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

  • Истёкшая или закрытая авторизация требует отдельного решения продавца; склад не создаёт новую попытку оплаты сам.

Разобрать частичный возврат

Задача: Не потерять историю возвращённых сумм при сохранении основного статуса платежа.

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

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

Результат: Частичный возврат не скрыт за общим состоянием исходного платежа.

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

  • Наличие Refunded требуется для полного возврата; отсутствие этого статуса само по себе не опровергает частичный.

Дождаться готового чека без повторной оплаты

Задача: Отделить фискальный сбой от платёжного.

Когда начинается: Платёж подтверждён, но чек ещё не готов.

  1. Запросить статус чека по его Id либо связанному OrderId.
  2. Различить принятие, создание и ошибку; сохранить готовые фискальные данные и ссылку только из подтверждённого ответа.
  3. При проблеме фискализации передать её ответственному, не повторяя Charge.

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

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

  • Признак отправки чека не гарантирует получение его покупателем.

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

ДанныеОтветственный источникПравило обмена
Заказ, SKU и ценыПродавецСостав после сборки согласуется до изменения суммы.
Остаток и выдачаSkirbo / складФизические действия не выводятся из платёжного состояния.
Платёж и сумма возвратаPayture / уполномоченный платёжный контурOrderId и терминал различают платежи клиентов.
ЧекФискальный контур PaytureГотовность чека и его отправка имеют отдельные признаки.
Физический возвратСкладПриёмка и пригодность не зависят от скорости возврата денег.

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

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

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

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

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

  • Публичные методы не доказывают договорный доступ терминала, правила остатка блокировки после частичного Charge или защиту уведомлений.
  • Тарифы, срок удержания и SLA не подтверждены.
  • Фискальные правила России и доступность в других странах проверяются отдельно.
Стоимость и запуск

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

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

Кто принимает решение о списании, где хранится платёжный OrderId и допускается ли частичная сборка?

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

Authorized уже означает оплату?

В документе это блокировка средств без списания. Разрешение отгрузки определяется согласованной политикой продавца, а состояния не объединяются.

Что будет без Amount?

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

Почему частичный возврат не стал Refunded?

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

Ошибка чека требует повторить платёж?

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

GetState вернул Success=True — можно выдавать товар?

Это означает, что запрос состояния выполнен. Для разрешения выдачи проверяют State, сумму, терминал и заказ; само успешное чтение не является оплатой.

Можно вернуть часть оплаты без Amount?

Нет: документация Refund определяет отсутствие Amount как полный возврат. Сумму частичного возврата утверждают и передают явно, затем сверяют оставшуюся списанную сумму.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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