Платежи

Статусы, периодический опрос и сверка платежей

Проверяйте статус с вашего бэкенда, пока не получите банковское заключение. callback, возврат SCA или закрытие виджета не считаются финансовым подтверждением.

Запрос с бэкенда

: "${WR_API_KEY:?Defina WR_API_KEY en el entorno seguro de su backend}"

curl --request POST 'https://api.wealthreader.com/payments/?action=status' \
  --header 'Content-Type: application/json' \
  --header "X-API-Key: ${WR_API_KEY}" \
  --data '{
    "payment_intent_id": "11111111-1111-4111-8111-111111111111",
    "refresh": true
  }'

refresh необязательно и true по умолчанию. Wealth Reader ограничивает внешние запросы по намерениям; применяйте backoff также на вашем бэкенде и не создавайте другое намерение, пока результат неоднозначен.

Три разных измерения

Поле	Основные ценности	Что ты ответишь
`state`	`ready`, `authorization_required`, `processing`, `reconciliation_required`, терминалы	Длительное состояние потока.
`interaction_status`	`not_started`, `authorization_required`, `processing`, `completed`, `finished`	Завершилось ли техническое взаимодействие или продолжается.
`payment_status`	`not_initiated`, `pending`, `unknown`, `settled`, `rejected`, `cancelled`, `expired`, `failed`	Нормализованный финансовый результат.

Единственное положительное подтверждение — payment_status: settled, полученное из явного статуса банка, подтверждающего окончательное исполнение платежа. Технический результат DONE, interaction_status: completed или payment_status: pending никогда не означает окончательное исполнение платежа.

Неоднозначный результат

Нераспознанный отключение сети, тайм-аут или ответ после запуска меняют намерение на reconciliation_required и открывают payment_status: unknown. Старт не повторяется автоматически.

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

В таком случае:

сохраните идентификатор и ключ идемпотентности;
не создавайте новое платёжное намерение и не авторизуйте платёж повторно;
Просматривайте аутентифицированный статус Wealth Reader и сохраняйте свою надёжную ссылку на сверку;
свяжитесь с технической поддержкой; не продолжайте проверять статус, когда automatic_recovery false.

Для замысла, требующего ручной сверки, сервер-сервер-сервер запрос может включать:

{
  "payment_status": "unknown",
  "reconciliation_required": true,
  "reconciliation": {
    "automatic_recovery": false,
    "reference": "wrp_recon_0123456789abcdef0123",
    "request_id": "11111111-1111-4111-8111-111111111111",
    "correlation_id": "22222222-2222-4222-8222-222222222222",
    "reason": "initiation_rejected"
  }
}

Эти идентификаторы — ссылки для службы поддержки, из которых удалены конфиденциальные данные. Они не передаются виджету и не позволяют клиенту запрашивать или восстанавливать внутреннее состояние провайдера.

reason — это Wealth Reader-код, никогда не текст поставщика. initiation_rejected указывает, что поставщик ответил окончательным отказом от инициации; initiation_response_unavailable, что не было узнаваемого ответа. В обоих случаях инициация уже была передана, поэтому она не повторяется: сохраняйте ссылку и обращайтесь в техническую поддержку.

Повторный вызов и повтор

Возврат после SCA поступает в callback, предназначенный исключительно для платежей. Wealth Reader проверяет соответствие запросу, передаёт параметры банка провайдеру без изменений (неожиданные имена параметров регистрируются, но не приводят к отклонению уже авторизованного возврата), обрабатывает возврат только один раз и сохраняет конфиденциальное состояние в зашифрованном виде. Повторный запрос возвращает только HTTP 409; не полагайтесь на внутренний код ошибки в теле ответа.

Аутентификация может потребовать нескольких перенаправлениях. Каждое проверенное REDIRECT продолжается в том же окне SCA и открывает новую контрольную точку callback; она не создаёт новую инициацию. Результат DECOUPLED сохраняет намерение в processing для виджета запроса статуса. Явный RETRY повторяет только уже подготовленное завершение с ограниченным ожиданием и количеством попыток. ERROR, PASSWORD, MORE_INFO, SELECT_OPTION, неизвестный результат или исчерпание этих лимитов заканчиваются сверкой, никогда не новой инициацией.

Продавцу не нужно публиковать или обрабатывать этот callback. Эта версия не отправляет продавцу вебхуки: публичный контракт подтверждения платежа основан на периодических запросах статуса между серверами.

Закрытие виджета

flow_closed сообщает о завершении видимого взаимодействия. Фронтенд может закрыть модальное окно, но не должен показывать «оплачено» на основании этого события. Бэкенд по-прежнему отвечает за подтверждение или сверку платежа.

Следующий шаг

Дополните список Безопасность и тестирование.

Последнее обновление 2026-09-10