Интеграция через редирект

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

На платежной странице клиент может оплатить заказ новой картой или использовать сохраненные платежные данные.

Схема интеграции

Регистрация заказа

1. Клиент инициирует покупку товара или услуги на сайте Партнера.

2. Партнер отправляет в Платежный сервис Роутер один из следующих запросов на регистрацию заказа:

• register.do для одностадийной оплаты, или
• registerPreAuth.do для двухстадийной оплаты.

Подробнее об этих видах оплаты см. в разделе Двухстадийные платежи.

Пример запроса:

curl --request POST \
'https://api.router.rbsuat.com/v1/register.do' \
-H 'Content-Type: application/json' \
--data-raw \
'{
    "orderNumber": "order_123473",
    "amount": 1234,
    "currency": "643",
    "language": "ru",
    "returnUrl": "https://mybestmerchantreturnurl.com/success",
    "userName": "test_user",
    "password": "test_user_password",
    "clientId":"client_10001"
}'

3. Платежный сервис Роутер проверяет данные Партнера и регистрирует заказ.

Перенаправление на платежную страницу

4. В ответ на запрос Платежный сервис Роутер передает Партнеру ссылку на платежную страницу в параметре formUrl.

Пример ответа:

{
    "errorCode": "0",
    "formUrl": "https://router.rbsuat.com/wl/payment.html?mdOrder=2dc811e7-8d1c-407a-bd25-a4f41f96cc60&language=en",
    "orderId": "2dc811e7-8d1c-407a-bd25-a4f41f96cc60",
    "orderNumber": "order_123457"
}

5. Партнер перенаправляет Клиента на платежную страницу.

6. Клиент переходит на платежную страницу.

7. Платежная страница запрашивает в Платежном сервисе параметры платежа: связки, доступные способы оплаты.

8. Платежный сервис Роутер проверяет наличие связок клиента во всех банках.

9. Платежный сервис Роутер передает обнаруженные связки клиента со всех банках на платежную страницу. Если одна и та же карта привязана в разных банках, отображается только самая "свежая" связка по дате создания.

10. (Опционально) Клиент выбирает платежный инструмент Оплата картой. Выбор платежного инструмента доступен только если в запросе на регистрацию заказа были явно указаны те или иные способы оплаты (например, Alfa Pay, SberPay и т.п.). По умолчанию используются только оплата картой и связкой, и платежная страница сразу отображает форму ввода карточных данных и, при наличии связок, — выбора связки клиента.

Оплата на платежной странице картой или связкой

11. Клиент указывает платежные данные карты (или выбирает связку) и нажимает кнопку Оплатить.

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

Пример white label платежной страницы при оплате картой:

Пример white label платежной страницы при оплате связкой:

Оплата без ввода CVC

Партнер может выполнять оплату без ввода CVC-кода при использовании карты или связки. Для этого потребуются соответствующие разрешения в банках. Если разрешения на оплату без CVC есть только в некоторых банках (в одном или нескольких, но не во всех), то Роутер может запросить ввод CVC после нажатия на кнопку Оплатить в зависимости от того, куда будет направлена оплата.

Чтобы использовать эту возможность, обратитесь в службу поддержки.

Функции платежной страницы

Функции, доступные на платежной странице, могут отличаться в зависимости от параметров регистрации заказа:

• Флажок Запомнить карту отображается только в том случае, если при регистрации заказа был указан clientId. Если Клиент установит этот флажок, то после оплаты новой картой будет создана связка.
• Если в запросе регистрации передан bindingId — идентификатор существующей связки, то на платежной странице будет доступна только одна связка. При этом заказ можно будет оплатить только этой связкой.
• Если при регистрации передать defaultBindingId, то по умолчанию в списке будет выбрана связка с этим идентификатором. Оплатить заказ можно будет любым способом, доступным на платежной странице.

Также на платежной странице может быть доступна возможность удаления связки — см. Удаление eCom-связки

Маршрутизация оплаты

12. Платежный сервис Роутер осуществляет выбор нужного банка на основе правил маршрутизации. Подробнее о маршрутизации см. Маршрутизация оплат.

13. Платежный сервис Роутер отправляет в выбранный банк запрос на регистрацию заказа.

14. Банк передает в Платежный сервис Роутер результат регистрации заказа.

15. Платежный сервис Роутер отправляет в выбранный банк запрос на оплату заказа. Если для завершения оплаты необходим 3DS, то выполняются соответствующие операции. На странице подтверждения необходимо ввести проверочный код.

16. Выбранный банк осуществляет операцию оплаты и направляет ответ в Платежный сервис Роутер.

17. Платежный сервис Роутер перенаправляет Клиента на финальную страницу в зависимости от результата платежа: в случае ошибки на failUrl, а в случае успешной оплаты на returnUrl. При этом к URL адресу будет добавлен query-параметр orderId=[идентификатора заказа в Платежном сервисе]. На данных страницах Партнер должен отобразить клиенту статус платежа.

18. Клиент переходит на указанный адрес.

Финальный статус заказа

19. Клиент (финальная страница) отправляет в Платежный сервис Роутер запрос для получения финального статуса заказа getOrderStatusExtended.do, используя query-параметр orderId.

20. Платежный сервис Роутер запрашивает в выбранном банке статус заказа.

21. Банк отправляет статус заказа в Платежный сервис Роутер.

22. Платежный сервис Роутер передает статус заказа на финальную страницу.