MyBankMatch

Подготовка подключения

1. У вас должна быть активная лицензия с продуктом MY_BANK_MATCH и доступной квотой.
2. Откройте Клиенты · MyBankMatch в аутентифицированной сессии с соответствующей лицензией.
3. Нажмите Connect bank и пройдите аутентификацию в окне, размещённом Wealthreader. Токенизированное подключение привязывается к вашему api_key; банковский токен не передаётся в браузер и не является параметром запроса.
4. Обновите статус в разделе «Клиенты». Если банк требует повторной аутентификации, используйте Reconnect. Панель также позволяет выполнить явную проверку IBAN/имени и показывает последние запросы в замаскированном виде.

Эмитент использует одноразовую подписанную ссылку и продолжение, привязанное к браузеру. Если срок действия ссылки истёк или это продолжение утеряно, запросите новую ссылку в разделе «Клиенты».

Отправка запроса с бэкенда

POST https://api.wealthreader.com/my-bank-match/
Content-Type: application/x-www-form-urlencoded

JSON не отправляется, и X-API-Key не используется: ключ передаётся в теле, закодированном как форма, так же как в /entities/.

curl --request POST 'https://api.wealthreader.com/my-bank-match/' \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'api_key=<SU_API_KEY>' \
  --data-urlencode 'iban=ES9321005707250200257112' \
  --data-urlencode 'name=Wealthreader S.L.'

<SU_API_KEY> — это заполнитель, а не рабочий ключ. IBAN и имя иллюстрируют запрос из приёмочного теста; здесь не проверялось, что они дают конкретный вердикт. Запрос может быть платным: не запускайте его как автоматическое обновление интерфейса.

MyBankMatch возвращает вердикт банка. Он не подменяет этот ответ локальным расчётом сходства имён. Он также не создаёт, не авторизует и не исполняет платёжное поручение.

Интерпретация ответа

HTTP 200 означает, что от продукта получен результат, но не обязательно то, что имя совпадает. Проверьте success, а затем payload.result.

Иллюстративный пример частичного совпадения (имя и SESSION вымышлены):

{
  "success": true,
  "payload": {
    "result": "PARTIAL_MATCH",
    "suggested_name": "TITULAR DE EJEMPLO S.L."
  },
  "statistics": {
    "SESSION": "0000000000000000",
    "execution_time": 0.42,
    "warnings": []
  }
}

statistics.SESSION идентифицирует этот запрос для диагностики, а execution_time указывается в секундах. Успешный ответ не содержит объекта error и не возвращает токен банковского подключения.

При частичном совпадении показывайте введённое имя и suggested_name по отдельности; не заменяйте первое незаметно для пользователя. Если вы выводите их в HTML, экранируйте их как текст.

URL настройки для NOT_CONFIGURED и REAUTH_REQUIRED:

https://www.wealthreader.com/clients/#my-bank-match

Например, при повторной аутентификации может вернуться такой payload:

{
  "result": "REAUTH_REQUIRED",
  "setup_url": "https://www.wealthreader.com/clients/#my-bank-match",
  "reason_code": 2000
}

reason_code должен быть целым числом от 2000 до 2999; например, 2000 означает ошибку учётных данных. Переподключитесь в разделе «Клиенты», а не повторяйте проверку бесконечно.

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

Валидация, квота и ошибки

Ошибки валидации или лицензии используют обычную структуру ответа: success: false, payload, error.code, error.message и statistics с SESSION, длительностью и предупреждениями. Контролируемые проверки возвращают HTTP 400; сообщение может содержать диагностическую информацию и не должно использоваться как стабильный идентификатор.

Ошибки ввода и неокончательные результаты не расходуют квоту платных запросов. Квота расходуется, когда банк возвращает MATCH, PARTIAL_MATCH или NO_MATCH; если её одновременно исчерпает другой вызов, возвращается ошибка лимита, а не подтверждение результата как успешного.

Цена 0,10 EUR относится только к трём окончательным результатам контракта. Режим тарификации за запрос и исключение проверенных сессий привязки реализованы, но требуют предварительной схемы, а также активации и проверки запросов тарификации оператором; эта страница не подтверждает такое развёртывание. Исключить сессию из стандартного подсчёта учётных данных/продуктов позволяет только проверенная привязка на стороне сервера: operation_id из браузера недостаточно. Просроченные, не прошедшие аудит или исторические попытки без такого происхождения не освобождаются автоматически, и никакие другие эффекты бесплатного учёта в счётчике не гарантируются.

Ограничения этой версии

• Проверка использует собственное токенизированное подключение клиента к Santander для частных лиц. Реальная совместимость с банками ещё не подтверждена, и публикация этой страницы не гарантирует коммерческую доступность.
• Размещённый сценарий поддерживает учётные данные и подтверждения OTP/push, выбор способа и ограниченный растровый QR-код. Подтверждения через скрипт, OAuth, CAPTCHA или с несколькими договорами не реализованы и завершаются безопасной ошибкой; вы можете запросить новую ссылку в разделе «Клиенты».
• Панель требует аутентифицированной сессии. Загрузка статуса, возврат из окна банка и обновление истории не отправляют проверки в банк: только явная отправка формы выполняет потенциально платный запрос.
• Храните api_key на своём сервере и не записывайте учётные данные, банковские токены или полные имена в ненужные журналы интеграции. Используйте SESSION для обращений в поддержку и различайте вердикт, ошибку и состояние настройки.