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

Skirbo +
Payler

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

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

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

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

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

Уникальный order_id, сумма и схема OneStep/TwoStep; session_id для перехода на форму.

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

GetStatus по сигналу callback/redirect или при восстановлении; однократное разрешение выдачи.

Изменение холда и возвратПродавец → PaylerОбсудим в составе подключения

Retrieve до списания, Refund после списания; доступность частичных операций проверяется отдельно.

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

GetReceiptStatus по заказу; каждый receipt_id хранится отдельно.

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

Оплаты, возвраты и остатки сопоставляются с банковскими расчётами; наличие API реестра выплат не предполагается.

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

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

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

Payler рассматривается как платёжный шлюз российского магазина. Для базового процесса выбрана схема Gate: покупатель вводит карту на странице сервиса, а магазин связывает результат оплаты со своим заказом. Прямой приём карточных данных по схеме Merchant, переводы на карты и массовые выплаты имеют отдельные требования и не включаются автоматически в этот сценарий.

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

Прочитаны API платежей и общая информация, а также сохранённые инструкции Gate/Merchant, ошибок, переводов и кассовых чеков. Gate использует StartSession и переход покупателя на PayGate; результат проверяется GetStatus. Двухстадийная схема отдельно использует Charge и Retrieve, после списания применяется Refund. Настроенный callback служит сигналом для проверки состояния; готовность обмена со Skirbo не подтверждена.

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

  1. Skirbo сохраняет состав заказа, сумму, магазин и владельца товара. Платёжный контур создаёт отдельную попытку с уникальным order_id; одно внутреннее название заказа не подменяет идентификатор каждой сессии.
  2. Контур вызывает StartSession по выбранной одно- или двухстадийной схеме, сохраняет session_id и перенаправляет покупателя на PayGate. Карточные данные не проходят через складской интерфейс.
  3. Возврат браузера или callback запускает GetStatus для существующего order_id. Повторный заход на страницу результата допускается документацией и не является новой оплатой.
  4. При одностадийном процессе проверяют успешное списание; в двухстадийном Authorized означает лишь блокировку средств. Решение о дальнейшем списании связано с подтверждённым составом.
  5. Предлагаемый журнал сверяет магазин, валюту, сумму и ожидаемую стадию; только согласованный подтверждённый результат разрешает одну физическую выдачу.
  6. Если результат Pending или ответ потерян, состояние проверяют повторно с увеличением интервала. Склады не повторяют выдачу и не создают новую платёжную сессию из-за отсутствия ответа.

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

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

Оплатить заказ и подтвердить выдачу

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

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

  1. Skirbo сохраняет состав заказа, сумму, магазин и владельца товара. Платёжный контур создаёт отдельную попытку с уникальным order_id; одно внутреннее название заказа не подменяет идентификатор каждой сессии.
  2. Контур вызывает StartSession по выбранной одно- или двухстадийной схеме, сохраняет session_id и перенаправляет покупателя на PayGate. Карточные данные не проходят через складской интерфейс.
  3. Возврат браузера или callback запускает GetStatus для существующего order_id. Повторный заход на страницу результата допускается документацией и не является новой оплатой.
  4. При одностадийном процессе проверяют успешное списание; в двухстадийном Authorized означает лишь блокировку средств. Решение о дальнейшем списании связано с подтверждённым составом.
  5. Предлагаемый журнал сверяет магазин, валюту, сумму и ожидаемую стадию; только согласованный подтверждённый результат разрешает одну физическую выдачу.
  6. Если результат Pending или ответ потерян, состояние проверяют повторно с увеличением интервала. Склады не повторяют выдачу и не создают новую платёжную сессию из-за отсутствия ответа.

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

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

  • DUPLICATE_ORDER_ID требует поиска прежней сессии и статуса, а не случайной смены идентификатора.
  • Ошибка доступа или неизвестный статус оставляет операцию на разборе; её нельзя заменить отметкой «оплачено».

Скорректировать двухстадийный заказ до списания

Задача: Связать финансовое подтверждение с реально собранным составом.

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

  1. Склад возвращает менеджеру фактический состав и причину расхождения; финансовый контур проверяет, что платёж ещё Authorized.
  2. Для полной отмены рассматривают Retrieve, снимающий блокировку. Для уменьшения суммы сначала проверяют, разрешена ли частичная разблокировка данному терминалу и не истёк ли допустимый период.
  3. Если частичная операция разрешена, оператор согласует сумму освобождаемого холда. После Retrieve сохраняется новая величина блокировки; сумма заказа и выдаваемые позиции приводятся к тому же результату.
  4. Charge выполняют только для разрешённого состава и точной оставшейся суммы заблокированных средств. Уменьшенную произвольную сумму нельзя просто отправить как частичное списание.
  5. Проверяют GetStatus после операции; Charged является подтверждением списания, Reversed — полной разблокировки. В каждом случае Skirbo применяет своё действие к резерву и выдаче.
  6. Если частичная операция запрещена или период истёк, решение принимает уполномоченный менеджер вместе с платёжным оператором. Автоматическое создание второго заказа и бесконечные повторы не используются.

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

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

  • PARTIAL_RETRIEVE_NOT_ALLOWED, PARTIAL_CHARGE_NOT_ALLOWED и EXPIRED_RETRIEVE_PERIOD — отдельные причины отказа.
  • Если платёж уже списан, применяется процесс возврата, а не изменение холда.

Вернуть часть покупки и сверить документы

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

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

  1. Склад оформляет приём позиций и их состояние; продавец рассчитывает сумму с учётом скидок и предыдущих возвратов. Пригодный остаток восстанавливается по складскому правилу.
  2. Платёжный оператор проверяет Charged, доступность частичного возврата и возможность повторных возвратов на терминале. Refund связывается с первоначальным order_id и собственным журналом возвратной операции.
  3. После Refund сохраняют результат: amount в ответе описывает остаток списанной суммы, а не размер только что оформленного возврата. Сумму возврата хранят отдельно из согласованного запроса.
  4. При потерянном ответе сначала проверяют прежний финансовый результат через GetStatus/GetAdvancedStatus и доступную историю. Наличие необязательного reference_id не объявляется гарантией идемпотентности.
  5. Кассовый владелец оформляет предусмотренный чек возврата и проверяет его через GetReceiptStatus. Состояния created/wait/done/fail относятся к чеку и не заменяют статус платежа.
  6. Бухгалтер сопоставляет исходную оплату, суммы возвратов, остаток, чеки и перечисления по банковским документам. Платёж Charged не доказывает поступление всей выручки на счёт продавца.

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

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

  • PARTIAL_REFUND_NOT_ALLOWED и MULTIPLE_REFUND_NOT_SUPPORTED требуют предусмотренного договором решения или поддержки, а не автоматического повторения.
  • Сроки возврата и расчётов с магазином подтверждают по конкретному договору; API платежа не является универсальным реестром выплат.

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

ДанныеОтветственный источникПравило обмена
Заказ, позиции, скидки и возвращаемый составПродавецСумма денежной операции выводится из согласованного состава; внутренние SKU не подменяют order_id Payler.
Резерв, выдача и физический возвратSkirbo и складПовторный callback/redirect не выполняет складское действие повторно.
Сессия, блокировка и платёжPayler; контур продавца хранит связь идентификаторовsession_id и order_id имеют разные назначения; текущий результат запрашивается у шлюза.
Права Charge/Retrieve/Refund и секретыУполномоченный платёжный операторkey/password и разрешённые адреса доступа проверяются для терминала; склад не получает секреты.
Чеки, комиссии и перечисленияКассовый владелец и бухгалтерияПроверка чека отделена от состояния платежа, банковская сверка — от потребительской операции.

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

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

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

  • Договор Payler, параметры магазина/терминала, подтверждённая схема Gate и доступ к тестовому контуру.
  • Согласованный адрес callback; защищённое хранение key/password и требования к исходящим IP.
  • Раздельные идентификаторы внутреннего заказа, платёжной попытки, session_id и журнала возвратов; денежные значения в минимальных единицах валюты.
  • Подтверждённые ограничения частичного Retrieve, Refund и повторных возвратов; процедура действий при запрете и истечении периода.
  • Кассовые настройки и пример каждого вида чека, договорный отчёт по перечислениям и ответственный за расхождения.
Границы сценария

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

  • Authorized означает блокировку, Charged — списание, Refunded — полный возврат. Один общий статус «оплачено» не покрывает все стадии.
  • Charge требует точной суммы заблокированных средств. Частичное исполнение зависит от доступности изменения холда; API содержит ошибки запрета частичных операций.
  • Полный/частичный Refund описан в API, но частичный или последующий возврат может быть недоступен для конкретного подключения.
  • Callback в прочитанном разделе передаёт order_id; без отдельной спецификации его подлинности доверять денежному результату одного входящего сообщения нельзя. Используется проверка GetStatus.
  • Merchant требует отдельной оценки обработки карточных данных и PCI DSS. Переводы cgapi/cmapi и массовые выплаты не являются методом возврата покупки.
  • Тарифы, банковские перечисления и сроки не обещаются по API. Российские кассовые настройки и договор не переносятся на другую страну автоматически.
Стоимость и запуск

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

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

Нужно связать Payler с выдачей по одностадийной оплате или подтверждать сумму после складской сборки?

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

Покупатель закрыл вкладку после оплаты — заказ потерян?

Нет оснований создавать новую оплату только по этой причине. Документация предусматривает callback, а GetStatus позволяет выяснить результат существующего order_id. Склад получает разрешение после проверки, даже если браузер не вернулся.

Можно ли отгрузить при Authorized?

Этот статус описывает заблокированные, ещё не списанные средства. В предложенном процессе выдача требует согласованного финансового подтверждения после проверки состава. Если бизнес допускает иной момент выдачи, это отдельное правило договора и риска продавца.

Как убрать отсутствующую позицию при двухстадийной оплате?

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

Можно ли несколько раз возвращать разные позиции?

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

Почему сумма в ответе Refund отличается от суммы возврата?

Документация определяет amount в ответе как оставшуюся списанную сумму. В журнале нужны исходный платёж, сумма запроса возврата и остаток после операции; эти значения не взаимозаменяемы.

Успешный платёж означает, что чек и выплата продавцу готовы?

Чеки проверяются отдельно через GetReceiptStatus, который возвращает все чеки заказа. Фактические перечисления сверяет бухгалтер по договорным документам и выписке. Ни состояние чека, ни банковский результат нельзя вывести из одного Charged.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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