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

Skirbo +
CDEK Pay

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

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

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

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

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

Сумма, валюта и назначение; сохранение order_id/access_key.

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

Проверенный результат для однократного разрешения выдачи.

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

payment_id, сумма и причина; последующее подтверждение отдельно.

Кассовые документы и сверкаПлатёжный/кассовый контур ↔ учётОбсудим в составе подключения

Проверка чеков и расхождений; банковская выписка подключается своим способом.

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

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

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

CDEK Pay — платёжный продукт. Этот материал связывает оплату покупателя с заказом и товарными операциями в Skirbo. API доставки СДЭК, накладные и транспортные статусы относятся к отдельному процессу. Сохранённый платёжный контракт прочитан предметно; он не подтверждает готовность коннектора или всех продуктов провайдера.

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

Платёжный API описывает создание ссылок, возвратные заявки, список платежей и кассовые документы. Доступ использует логин магазина и подпись по правилам конкретного запроса. Входящие уведомления проверяются по собственной схеме подписи. Применимость редакции спецификации и доступные магазину операции нужно подтвердить с CDEK Pay до реализации.

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

  1. Skirbo фиксирует клиента фулфилмента, юрлицо продавца, магазин, состав и сумму заказа. Склад резервирует товар; владелец платежа проверяет соответствие договора и валюты.
  2. Уполномоченный платёжный контур создаёт ссылку и сохраняет выданные CDEK Pay order_id и access_key вместе с внутренним заказом. Идентификатор платежа появится отдельно; эти сущности не объединяют.
  3. Покупатель проходит оплату на форме сервиса. Возврат браузера и сама выдача ссылки не считаются доказательством получения денег.
  4. Обработчик проверяет подпись уведомления по схеме callback и сверяет магазин, идентификаторы, валюту и сумму. Для восстановления состояния читает список платежей по заказу.
  5. После подтверждённой успешной оплаты предлагаемый журнал один раз разрешает выдачу нужного состава. Склад сохраняет отдельный документ выдачи; повторное уведомление не создаёт вторую отгрузку.
  6. Если товар или сумма изменились, оператор сначала проверяет прежнюю ссылку и оплаты. Блокировка ссылки прекращает её использование, но уже прошедший платёж требует самостоятельного решения.

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

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

Получить оплату и разрешить выдачу

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

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

  1. Skirbo фиксирует клиента фулфилмента, юрлицо продавца, магазин, состав и сумму заказа. Склад резервирует товар; владелец платежа проверяет соответствие договора и валюты.
  2. Уполномоченный платёжный контур создаёт ссылку и сохраняет выданные CDEK Pay order_id и access_key вместе с внутренним заказом. Идентификатор платежа появится отдельно; эти сущности не объединяют.
  3. Покупатель проходит оплату на форме сервиса. Возврат браузера и сама выдача ссылки не считаются доказательством получения денег.
  4. Обработчик проверяет подпись уведомления по схеме callback и сверяет магазин, идентификаторы, валюту и сумму. Для восстановления состояния читает список платежей по заказу.
  5. После подтверждённой успешной оплаты предлагаемый журнал один раз разрешает выдачу нужного состава. Склад сохраняет отдельный документ выдачи; повторное уведомление не создаёт вторую отгрузку.
  6. Если товар или сумма изменились, оператор сначала проверяет прежнюю ссылку и оплаты. Блокировка ссылки прекращает её использование, но уже прошедший платёж требует самостоятельного решения.

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

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

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

Вернуть товар и отследить финансовый результат

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

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

  1. Склад оформляет физический возврат: исходная выдача, SKU, количество, состояние и решение о доступном остатке. Продавец рассчитывает денежную сумму с учётом ранее оформленных возвратов.
  2. Уполномоченный контур создаёт заявку на отмену платежа по payment_id с суммой value_refund и причиной; если договор требует кассовые строки, использует согласованный состав receipt_details.
  3. Сам факт создания или постановки заявки в очередь не закрывает возврат. Статус заявки фиксируют отдельно от статуса исходного платежа.
  4. После подтверждения результата проверяют уведомление возврата и список платежей. В контракте успешный возврат представлен отдельной записью с отрицательной суммой; исходный платёж также меняет состояние.
  5. В учёте связывают заявку, исходный платёж, возвратную запись и складской документ. Отрицательная запись и изменённый статус исходной оплаты не должны дважды уменьшать выручку.
  6. При таймауте или ошибке сначала выясняют результат прежней заявки. Повтор денежной операции допускается только после проверки; закрытие складского возврата само по себе не подтверждает расчёт с покупателем.

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

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

  • Допустимость частичной суммы, повторных частичных возвратов и сроки проверяются по договору; наличие value_refund не заменяет эти условия.
  • Статусы enqueued, system_error, failed и undefined требуют разных действий оператора, а не общей отметки «возвращено».

Сверить оплаты, возвраты, чеки и выплаты

Задача: Обнаружить расхождение по операции и назначить ответственного, сохранив разные источники факта.

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

  1. Читают список платежей и возвратов по заказам с пагинацией и согласованной сортировкой. Контроль количества записей помогает не принять первую страницу за весь результат.
  2. Сверяют payment ID, order_id, access_key, валюту, знак суммы и состояние с внутренним журналом. Дубликаты и возвраты обрабатываются по их идентичности, а не только по дате.
  3. Кассовые документы проверяют через отдельный раздел receipts. Если используется предоплата, связь с чеком полного расчёта согласуется с кассовым владельцем и фактом передачи товара.
  4. Перечисления на счёт продавца сопоставляют с договорными документами и банковской выпиской. Статус успешной оплаты покупателя не равен подтверждению выплаты магазину.
  5. Различия — пропущенная оплата, лишняя возвратная запись, незавершённый чек, удержание или непоступившее перечисление — попадают конкретному владельцу. Склад уточняет товарный факт, бухгалтер — денежный.
  6. Повторная сверка сохраняет исходное расхождение и основание его закрытия. История выдачи товара не переписывается из-за позднего финансового события.

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

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

  • Схема содержит уведомление payout, но оно не доказывает универсального API банковских выплат. Область и полноту таких данных нужно подтвердить отдельно.
  • Чек и маркировка требуют самостоятельной проверки кассового контракта; наличие полей не доказывает регистрацию или вывод товара из оборота.

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

ДанныеОтветственный источникПравило обмена
Коммерческий заказ, строки и суммаПродавецСумма для платёжной ссылки должна соответствовать согласованному составу.
Остатки, резерв, выдача и приём возвратаSkirbo и складДенежный callback не создаёт повторного движения товара.
Платёжная ссылка и денежные операцииCDEK Pay; владелец доступа магазинаorder_id/access_key — заказ провайдера; id/payment_id — платёж. Ключи хранятся раздельно.
Возвратная заявка и её разрешениеПродавец и финансовый операторОператор проверяет остаток возвратной суммы и завершение ранее созданных заявок.
Чеки и банковская сверкаКассовый владелец и бухгалтерияКассовый документ, платёж и перечисление продавцу имеют отдельные подтверждения.

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

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

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

  • Договор CDEK Pay, магазин и ответственный за логин/секрет; отдельные права на оплату, возврат и просмотр отчётов.
  • Подтверждённая редакция API для магазина и разбор расхождений типов сохранённой схемы до реализации.
  • Таблица внутренних заказов, order_id, access_key и payment_id; денежные суммы в целых минимальных единицах.
  • Согласованный callback и тесты его подписи; очередь событий, журнал операций и процедура восстановления после таймаута.
  • Примеры полной и частичной отмены, кассового документа и банковского реестра; владелец каждого источника.
Границы сценария

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

  • Перед реализацией нужно проверить спецификацию и согласовать неоднозначные типы данных с провайдером; готовность автоматически сгенерированного клиента не подтверждена.
  • Снимок 2.0.0 описывает опубликованный контракт на дату сохранения, а не все API, продукты и действующие договоры CDEK Pay.
  • В GET списка платежей обнаружены расхождения типов access_key и signature с другими схемами и описаниями. Автоматическую генерацию клиента без проверки типов не рекомендуем считать завершённой.
  • Блокировка платёжной ссылки, статус возвратной заявки, возвратный платёж и выплата продавцу имеют разные значения.
  • Сроки зачисления, комиссии, правила частичных возвратов и доступ к отчётам определяются договором. Правила кассы и маркировки РФ не распространяются автоматически на другие страны.
  • Актуальность спецификации и поведение методов нужно подтвердить с провайдером до реализации.
Стоимость и запуск

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

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

Какой заказ CDEK Pay нужно связать с выдачей и какой документ сейчас подтверждает возврат?

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

Это тот же обмен, что доставка СДЭК?

Материал относится к оплате через CDEK Pay. Накладные, маршруты и события доставки сюда не входят; при совместном процессе платежи и доставка связываются с заказом отдельными идентификаторами.

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

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

Блокировка ссылки возвращает уже уплаченные деньги?

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

Как учитывать отрицательную сумму в списке платежей?

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

Почему успешная заявка ещё не закрывает всю сверку?

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

Можно сразу строить подключение по открытой схеме API?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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