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

Skirbo +
kassa.com

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

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

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

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

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

Магазин, заказ, сумма, валюта и сохранённый token; точные поля текущего запроса уточняются.

Серверный результатkassa.com → SkirboОбсудим в составе подключения

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

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

Только по допустимому состоянию и актуальному контракту; не приравнивать отмену к универсальному возврату.

Разрешение выдачиSkirbo → складОбсудим в составе подключения

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

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

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

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

Для продавца физического товара, использующего продукт приёма оплаты kassa.com. Рассматриваются платёжные объекты официального PHP SDK и их связь с заказом. Доступность продукта для организации в РФ, разрешённые способы и действующие условия нужно подтвердить отдельно; наличие репозитория этого не устанавливает.

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

Прочитан официальный kassacom/php-sdk: создание, обработка, чтение и отмена платежа, обработчик серверного уведомления. Текущая спецификация и правила безопасности требуют проверки. В примере раздела capture есть несоответствие вызова, поэтому по нему нельзя реализовывать списание без уточнения.

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

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

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

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

Платёж и разрешение выдачи

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

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

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

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

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

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

Отмена до выдачи

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

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

  1. Проверить исходный payment token и текущее состояние операции.
  2. По подтверждённым правилам выполнить доступную отмену, получить результат и сверить его повторным чтением.
  3. Отдельно отменить складское задание и освободить резерв, если товар ещё не выдан.

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

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

  • cancel не объявляется универсальным возвратом уже списанных денег.
  • Если товар выдан, требуется самостоятельная обратная приёмка.

Несколько попыток одного покупателя

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

Когда начинается: По заказу обнаружены два payment token.

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

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

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

  • Дедупликация по одному номеру заказа не должна скрывать реально разные списания.

Сверка платежей по отчёту за период

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

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

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

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

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

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

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

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

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

  • Какие операции фактически доступны магазину в регионе клиента?
  • Какой метод и состояние разрешают capture и как исправлено противоречие SDK-примера?
  • Как проверяются серверные уведомления и восстанавливается результат после таймаута?
  • Как найти принятую платёжную попытку, если ответ создания и token не дошли?
  • Какие идентификаторы, статусы и границы периода содержит фактический отчёт о платежах?
Перед оценкой

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

  • Подтверждённая доступность kassa.com для организации и выбранного платёжного продукта.
  • Действующая спецификация проверки уведомлений, чтения платежа и отмены.
  • Примеры двух попыток заказа, неопределённого ответа и успешного результата; отдельный источник чека.
Границы сценария

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

  • SDK подтверждает описанный интерфейс, но не действующий договор, доступность в РФ или готовность Skirbo.
  • Раздел capture в README требует сверки с текущим контрактом; копирование неоднозначного примера недопустимо.
  • Выплаты, карты, возврат денег и кассовый чек не выводятся из наличия createPayment/cancelPayment.
  • Платёжный token может ещё не быть известен, если ответ на создание потерян. В этом случае сначала ищут операцию по согласованному контракту и журналу продавца; новая попытка не создаётся автоматически.
  • Отчёт SDK не доказывает наличие банковской выписки, корректный возврат после списания или доступность сервиса в конкретной стране.
Стоимость и запуск

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

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

Для оценки нужны подтверждённый платёжный продукт kassa.com, правила доступности вашей организации и обезличенный жизненный цикл одного token.

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

Можно использовать сервис только для подтверждений?

Рассмотрим получение идентификатора и результата уже существующей оплаты, если это допускает контракт магазина.

Чем отличаются приём платежа и выплата?

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

Можно считать callback успехом без чтения платежа?

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

Почему нельзя просто повторить создание после таймаута?

Первая попытка могла быть принята. Сохранённый token и проверка её состояния предотвращают повторную оплату и два основания для выдачи.

Как сверить оплату, если уведомление не пришло?

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

Можно уже считать kassa.com доступным для российской организации?

Нет подтверждения для вашего договора. Изученный SDK показывает интерфейс, но не правила допуска организации и страны. Для оценки нужны действующий продукт, юридическое лицо договора и подтверждённые способы расчёта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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