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

Skirbo +
Точка Банк

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

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

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

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

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

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

ПоступлениеТочка API → SkirboОбсудим в составе подключения

Сумма, валюта, ID и состояние по проверенному методу; правило складского разрешения задаёт продавец.

Ссылка / попыткаSkirbo ↔ Точка APIОбсудим в составе подключения

Дополнительный сценарий при выбранном продукте и правах; самостоятельный ID попытки.

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

Только подтверждённое решение, без передачи лишней банковской детализации оператору.

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

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

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

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

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

Официальное введение Точка API описывает JWT для собственных компаний и OAuth2 для приложений клиентов, работу со счетами/выписками и платёжные возможности. Детальные схемы конкретного метода, подписей уведомлений и доступных прав проверяются отдельно. Дополнительно прочитаны терминология и описание webhook: подтверждены отдельное назначение merchantId и проверка подписи; payload каждого события и полнота выписки остаются предметом приёмки.

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

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

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

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

Сверка поступления по счёту

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

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

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

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

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

  • Платёжное поручение не равно поступлению.
  • Одна и та же сумма на двух счетах не означает один заказ.

Платёжная ссылка для заказа

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

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

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

Результат: Повторное открытие ссылки не создаёт новый складской заказ.

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

  • Если продукт ссылок не подключён, сценарий остаётся за пределами первой сверки выписки.

Фулфилмент обслуживает несколько компаний

Задача: Разделить право чтения финансовых данных и разрешение складу.

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

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

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

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

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

Пропущенное банковское уведомление

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

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

  1. Определить исходный продукт и сохранить компанию, счёт, заказ и известный идентификатор операции; платёжную ссылку не искать как произвольную запись другой компании.
  2. Если уведомление поступило позже, проверить подпись по опубликованной схеме банка, затем принадлежность и сумму. Не принимать неподлинное сообщение как разрешение складу.
  3. Для ссылки сверить Get Payment Operation Info; для QR-кода — Get Qr Codes Payment Status; для оплаты по реквизитам — создать и получить выписку через Init Statement и Get Statement по актуальному контракту.
  4. Финансовый ответственный сопоставляет подтверждённый результат с непогашенной суммой заказа и отдельно разрешает складское действие.
  5. Skirbo сохраняет источник решения и связывает его с единственной сборкой/выдачей, а склад фиксирует физический результат.
  6. При повторном событии обновить ту же запись. При расхождении продукта, компании или суммы оставить финансовое исключение и не повторять платёж.

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

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

  • Точная пагинация выписки и ключ уникальности конкретного payload ещё требуют чтения метода и приёмки.
  • Истечение доступа не превращает ранее подтверждённую оплату в неоплаченную.

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

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

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

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

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

  • Выбранный набор операций: выписка, платёжная ссылка или СБП.
  • Компания, accountId счёта, проверенные идентификаторы выбранного продукта и схема JWT либо OAuth2.
  • Примеры успешного результата, повторного уведомления и частичной оплаты.
Границы сценария

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

  • Введение API не является полной схемой всех методов и событий.
  • Наличие API исходящих платежей не требует включать подписание в сценарий чтения.
  • СБП, выписка, платёжная ссылка и фискальный чек имеют разные подтверждения; сроки и стоимость не обещаются.
  • Общий обработчик уведомлений не объединяет входящий банковский перевод, платёжную ссылку и СБП: у каждого события свой контракт и способ восстановления.
  • Подпись подтверждает происхождение сообщения, но принадлежность компании/заказу, повтор и допустимость складского действия всё равно проверяет интеграция.
Стоимость и запуск

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

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

Уточните один первый продукт Точка API и подготовьте обезличенные идентификаторы компании/счёта и образцы оплаты с расхождением.

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

Нужно давать право списывать деньги?

Для сценария сверки начнём с минимальных прав чтения. Создание и подписание исходящих платежей в эту задачу не входят.

Как учитывать частичную оплату счёта?

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

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

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

Почему merchantId не заменяет accountId?

accountId относится к банковскому счёту, merchantId — к торговой точке. Это подтверждает отдельный раздел терминологии Точка API. Для интернет-эквайринга и СБП используют соответствующие методы и идентификаторы; совпадение строки не делает их взаимозаменяемыми.

Если вебхук не пришёл, заказ точно не оплачен?

Нет. Сначала сверяют конкретный продукт: платёжную ссылку, QR-код или поступление по реквизитам. Отсутствие уведомления не является доказательством отсутствия денег и не повод создавать новую оплату.

Что делать с возвратом уже выданного товара?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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