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

Skirbo +
PaySelection

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

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

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

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

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

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

Предварительная проверкаPaySelection ↔ контур продавцаОбсудим в составе подключения

Если отдельно включена: проверить согласованные параметры и разрешить/остановить продолжение оплаты.

Итог и сверкаPaySelection → SkirboОбсудим в составе подключения

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

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

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

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

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

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

Для продавца физических товаров и склада, которому нужно надёжное основание сборки или выдачи. Рассматривается PaySelection: платёжная попытка, серверный результат и проверка суммы/заказа. PayKassa и подписки оцениваются отдельно.

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

Прочитан официальный PHP SDK PaySelection. Он показывает операции оплаты, чтения заказа/транзакции, возврата и два разных вида webhook. Детальные подписи, статусы и условия выбранного продукта уточняются по текущей спецификации.

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

  1. Сохранить заказ, актуальную сумму, валюту и отдельный идентификатор платёжной попытки.
  2. Связать OrderId и внешний идентификатор транзакции с одним клиентским контуром; при ссылке сохранить её принадлежность к этой попытке.
  3. Если включена предварительная проверка, сверить заказ и сумму и только разрешить продолжение оплаты — это ещё не успешный платёж.
  4. Получить и проверить итоговое серверное событие или прочитать статус; после допустимого результата склад выполняет согласованную сборку/выдачу.
  5. Вернуть в Skirbo результат оплаты и отдельный факт физической передачи товара.
  6. Подтвердить приём итогового события после записи и сверить состояние через чтение заказа/транзакции при неопределённости.
  7. При неверной сумме, просроченной версии заказа или повторе события оставить исключение и не запускать второй платёж либо вторую сборку.

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

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

Оплата подтверждённого заказа

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

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

  1. Сохранить заказ, актуальную сумму, валюту и отдельный идентификатор платёжной попытки.
  2. Связать OrderId и внешний идентификатор транзакции с одним клиентским контуром; при ссылке сохранить её принадлежность к этой попытке.
  3. Если включена предварительная проверка, сверить заказ и сумму и только разрешить продолжение оплаты — это ещё не успешный платёж.
  4. Получить и проверить итоговое серверное событие или прочитать статус; после допустимого результата склад выполняет согласованную сборку/выдачу.
  5. Вернуть в Skirbo результат оплаты и отдельный факт физической передачи товара.
  6. Подтвердить приём итогового события после записи и сверить состояние через чтение заказа/транзакции при неопределённости.
  7. При неверной сумме, просроченной версии заказа или повторе события оставить исключение и не запускать второй платёж либо вторую сборку.

Результат: Предварительное разрешение, проведённая оплата и выдача товара не смешиваются.

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

  • HTTP 200 на проверочный webhook означает разрешение продолжить оплату.
  • Страница покупателя и проверочный webhook не заменяют итоговый результат.

Заказ изменился перед оплатой

Задача: Остановить оплату старой суммы в выбранной схеме проверки.

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

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

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

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

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

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

Задача: Не возвращать больше исходной оплаты и не удваивать запас.

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

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

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

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

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

Восстановление пропущенного итогового события

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

Когда начинается: Итоговый webhook не дошёл или ответ оплаты/возврата потерян.

  1. Сохранить внутреннее намерение, магазин, OrderId и известный TransactionId. Не заменять отсутствие ответа новой оплатой.
  2. Прочитать известную транзакцию либо заказ методами SDK. Если нужна сверка периода, проверить диапазон дат создания, часовой пояс, страницы и фильтр статусов.
  3. Сопоставить найденные попытки с актуальной суммой и валютой заказа; две успешные попытки оставить двумя финансовыми фактами.
  4. Финансовый ответственный принимает решение по расхождению, затем Skirbo выдаёт единственное разрешение на складское исполнение.
  5. Повторно проверить неопределённый возврат и оставшуюся сумму к возврату; товарная приёмка и фискальный результат подтверждаются отдельно.
  6. Сохранить результат сверки и очередь старых незавершённых попыток. Повтор события или страницы обновляет существующую связь, не вызывает новый расчёт и повторную выдачу.

Результат: Пропущенное событие восстановлено либо явно остаётся финансовым исключением.

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

  • Список по дате создания не объявляется потоком изменений; поздние статусы старых попыток требуют отдельного контроля.
  • Формат ответа, гарантия повторов и подпись требуют текущего security/API-контракта; работающий Skirbo-коннектор не заявляется.

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

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

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

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

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

  • Выбранный платёжный продукт, магазин и текущие правила подписи/проверки событий.
  • Решение, нужен ли предварительный webhook и какие параметры он сверяет.
  • Обезличенные успешная оплата, возврат и изменение заказа перед оплатой; отдельная схема чека.
Границы сценария

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

  • Проверочный webhook и итоговый webhook различаются; успешный ответ первого не означает оплату.
  • В SDK Confirm описан для завершения Pay/Block после 3DS; его нельзя произвольно считать универсальным подтверждением складского действия.
  • Подписки, выплаты и PayKassa не включаются автоматически; сроки и стоимость возврата не обещаются.
  • Отмена холдирования Cancel и возврат успешной оплаты Refund — разные финансовые действия; одно не подменяет другое.
  • Выборка по датам создания транзакции сама по себе не доказывает получение всех поздних изменений. Старые незавершённые попытки нужно сверять отдельно.
  • Пример Refund в README содержит несогласованные суммы Amount и ReceiptData. Его нельзя копировать как готовый корректный запрос возврата.
Стоимость и запуск

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

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

Покажите жизненный цикл одной оплаты PaySelection и решите, нужна ли проверка актуальности заказа до продолжения платежа.

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

Нужно подключать PayKassa вместе с оплатой?

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

Как обрабатывать повторное подтверждение оплаты?

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

Зачем два разных webhook?

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

Можно ли проверять только OrderId?

Нет. Нужно проверить клиентский контур, сумму, валюту, версию заказа и идентификатор попытки. Иначе старый или чужой результат может разрешить неправильную выдачу.

Когда нужна отмена, а когда возврат?

В описанном SDK Cancel относится к снятию блокировки при двухстадийной оплате, Refund — к успешной транзакции. Сначала проверяется состояние исходной попытки и допустимая сумма. Отмена складского заказа не выбирает финансовый метод автоматически.

Можно сверять только транзакции, созданные сегодня?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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