Платежи

Типичный сценарий

POST /api/v1/integration/transactions — создать платёж.

Получить в ответе ссылку / данные для оплаты (или запросить H2H).

Дождаться webhook со статусом

При необходимости подтвердить чтением:

GET /api/v1/integration/transactions/{uuid}

GET /api/v1/integration/transactions/by-external-id/{externalId}

Не делайте polling единственным источником истины.

Создание платежа

Передайте сумму в минорных единицах, валюту, метод оплаты и свой external_id.

external_id должен быть уникален в рамках мерчанта: так вы сможете безопасно повторять create при сетевых сбоях и потом найти платёж без UUID Smerch.

Точный набор полей — в OpenAPI (integrationCreateTransaction).

Статусы

Статусы асинхронные. Ориентируйтесь на финальные значения из webhook/GET (например paid / failed / expired — см. схему ответа).
Промежуточные статусы нормальны: платёж может «висеть», пока провайдер не подтвердит оплату.

Список платежей

GET /api/v1/integration/transactions — постраничный список (cursor).
Используйте для сверки и кабинета, не как замену webhook.

Реквизиты «как есть» (H2H)

GET /api/v1/integration/transactions/{uuid}/h2h

Нужен, когда вы сами показываете плательщику реквизиты (QR/счёт/инструкцию), без редиректа на чужую форму.
Если у метода есть redirect URL — часто достаточно редиректа, H2H не обязателен.

В OpenAPI это названо «реквизиты для оплаты на вашей стороне», не «магический H2H».

Типичный сценарий#

Создание платежа#

Статусы#

Список платежей#

Реквизиты «как есть» (H2H)#

Типичный сценарий

Создание платежа

Статусы

Список платежей

Реквизиты «как есть» (H2H)