Логотип

Способы подключения

Подключение по API

Описание схем взаимодействия

Описание схем взаимодействия

R-логин

Информация на странице может отличаться в зависимости от типа вашей учётной записи.

Выберите логин:

логин без префикса
r-логин

i-логин

Одностадийные платежи

Сценарий оплаты заказа (1)

Одностадийная оплата с указанием карточных данных на платёжной странице

Одностадийная схема оплаты картой:

  1. Клиент оформляет заказ на ресурсе мерчанта и выбирает способ оплаты банковской картой.

  2. После того как выбран способ оплаты банковской картой, в сторону платёжного шлюза должен быть отправлен запрос регистрации заказа. Для регистрации используются такие параметры как сумма списания, номер заказа в системе магазина, а также URL возврата клиента. Спецификация запроса представлена в разделах:

  3. В ответе на запрос регистрации платёжный шлюз возвращает уникальный идентификатор заказа в платёжной системе (в параметре orderId) и URL, на который необходимо перенаправить пользователя для получения платёжной формы (в параметре formUrl).

  4. Система магазина должна передать браузеру клиента redirect на URL, полученный от платёжного шлюза в параметре formUrl в ответ на запрос регистрации заказа.

  5. Браузер клиента открывает полученный URL.

  6. Клиент получает платёжную форму.

  7. Пользователь заполняет полученную форму реквизитами карты и отправляет данные на сервер платёжного шлюза.

  8. Детали заказа передаются в систему фрод-конроля для определения вероятности мошенничества. Проверка проводится при помощи набора автоматических правил. Результатом применения правила является добавление к заказу коэффициента вероятности мошенничества (фрод-веса). Каждое правило имеет свой фрод-вес, который представляет собой число в диапазоне от 0 до 100. (Если суммарный фрод-вес заказа по всем применённым к заказу правилам превышает 100, такой заказ считается фродовым и оплата по нему будет отклонена.)

  9. В платёжный шлюз возвращаются результаты проверки заказа на мошенничество. В том случае, если в соответствии с настройками магазина платёж должен идти по SSL, то выполняется следующий шаг сценария (10).
    Если в соответствии с настройками магазина платёж должен быть 3DS, то будут выполнены следующие действия:

    • •

      Платёжный шлюз производит проверку вовлечённости карты в 3-D Secure.
      Если авторизации на ACS для данной карты не требуется, то выполняется следующий шаг сценария (10).
      Если необходима авторизация на ACS, то будут выполнены следующие действия:

      1. Шлюз отправляет браузеру клиента redirect на страницу ACS банка эмитента.

      2. Браузер клиента запрашивает у ACS форму авторизации пользователя (у каждого эмитента это делается по-своему)

      3. ACS отправляет в браузер клиента форму авторизации.

      4. Клиент заполняет форму авторизации и отправляет её в ACS.

      5. ACS обрабатывает заполненную форму и вне зависимости от результата передаёт браузеру redirect на URL страницы платёжного шлюза. Вместе с этим URL передаются зашифрованные параметры результата авторизации.

      6. Браузер клиента запрашивает страницу платёжного шлюза, передавая зашифрованные параметры результата авторизации. Если авторизация прошла успешно, то выполняется следующий шаг сценария.

  10. Платёжный шлюз производит оплату (списание денежных средств со счёта клиента)

  11. После проведения оплаты платёжный шлюз передаёт браузеру клиента URL возврата на страницу магазина (указанный ранее магазином при регистрации заказа, см. шаг 2).

  12. Браузер клиента запрашивает страницу с результатами оплаты у магазина.

  13. Система магазина запрашивает у платёжного шлюза статус оплаты заказа (по уникальному идентификатору заказа в платёжной системе, который был получен при регистрации заказа в параметре orderId). Спецификация обычного запроса состояния заказа представлена в разделах:

  14. платёжный шлюз возвращает статус оплаты.

  15. Система магазина передаёт в браузер клиента страницу с результатами оплаты — успешный платёж или неуспешный.

Отмена оплаты заказа (1)

Отмена оплаты заказа доступна магазинам при наличии соответствующих прав (по согласованию с банком). При одностадийных платежах отмена платежа возможна для заказов в состоянии «Завершён» / «Deposited». Отмена оплаты заказа осуществляется стандартными средствами:

В случае успешной операции отмены заказ будет переведён из состояния «Завершён"/"Deposited» в состояние «Отменён"/"Reversed».

Возврат средств оплаты заказа (1)

Полный или частичный возврат по оплаченным заказам (в состоянии «Завершён"/"Deposited») осуществляется стандартными средствами:

После того, как в РБС приходит запрос на возврат средств, отправленный одним из указанных выше способов, РБС осуществляет возврат указанной суммы на счёт клиента.

Проверка вовлечённости карты в 3DS (1)

Система позволяет магазину при необходимости самостоятельно проверить вовлечённость банковской карты в 3-D Secure. Это можно сделать с помощью API, посредством интерфейсов SOAP / REST. Спецификация запроса представлена в разделах:

Добавление в заказ дополнительных параметров (1)

Система позволяет в случае необходимости добавить в заказ дополнительные параметры. Это можно сделать с помощью API, посредством интерфейсов SOAP / REST. Спецификация запроса представлена в разделах:

Статистика по платежам за определённый период (1)

Система позволяет формировать статистику по платежам за определённый период с помощью API, посредством интерфейсов SOAP / REST. Спецификация запроса представлена в разделах:

Двухстадийные платежи

Сценарий оплаты заказа (2)

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

Двухстадийная схема оплаты картой:

  1. Клиент оформляет заказ на ресурсе мерчанта и выбирает способ оплаты банковской картой.

  2. После того как выбран способ оплаты банковской картой, в сторону платёжного шлюза должен быть отправлен запрос регистрации заказа с предавторизацией. Для регистрации используются такие параметры как сумма списания, номер заказа в системе магазина, а также URL возврата клиента. Спецификация запроса представлена в разделах:

  3. В ответе на запрос регистрации платёжный шлюз возвращает уникальный идентификатор заказа в платёжной системе (в параметре orderId) и URL, на который необходимо перенаправить пользователя для получения платёжной формы (в параметре formUrl).

  4. Система магазина должна передать браузеру клиента redirect на URL, полученный от платёжного шлюза в параметре formUrl в ответ на запрос регистрации заказа.

  5. Браузер клиента открывает полученный URL.

  6. Клиент получает платёжную форму.

  7. Пользователь заполняет полученную форму реквизитами карты и отправляет данные на сервер платёжного шлюза.

  8. Детали заказа передаются в систему фрод-конроля для определения вероятности мошенничества. Проверка проводится при помощи набора автоматических правил. Результатом применения правила является добавление к заказу коэффициента вероятности мошенничества (фрод-веса). Каждое правило имеет свой фрод-вес, который представляет собой число в диапазоне от 0 до 100. (Если суммарный фрод-вес заказа по всем применённым к заказу правилам превышает 100, такой заказ считается фродовым и оплата по нему будет отклонена.)

  9. В платёжный шлюз возвращаются результаты проверки заказа на мошенничество. В том случае, если в соответствии с настройками магазина платёж должен идти по SSL, то выполняется следующий шаг сценария (10). Если в соответствии с настройками магазина платёж должен быть 3DS, то будут выполнены следующие действия:

    • •

      Платёжный шлюз производит проверку по номеру карты, чтобы определить, требуется ли применение технологии 3-D Secure при проведении платежа.
      Если авторизации на ACS для данной карты не требуется, то выполняется следующий шаг сценария (10).
      Если необходима авторизация на ACS, то будут выполнены следующие действия:

      1. Шлюз отправляет браузеру клиента redirect на страницу ACS банка эмитента.

      2. Браузер клиента запрашивает у ACS форму авторизации пользователя (у каждого эмитента это делается по-своему)

      3. ACS отправляет в браузер клиента форму авторизации.

      4. Клиент заполняет форму и отправляет её в ACS.

      5. ACS обрабатывает заполненную форму и вне зависимости от результата передаёт браузеру redirect на URL страницы платёжного шлюза. Вместе с этим URL передаются зашифрованные параметры результата авторизации.

      6. Браузер клиента запрашивает страницу платёжного шлюза, передавая зашифрованные параметры результата авторизации. Если авторизация прошла успешно, то выполняется следующий шаг сценария.

  10. платёжный шлюз производит авторизацию платежа (холдирование средств на карточном счёте клиента).

  11. После проведения оплаты платёжный шлюз передаёт браузеру клиента URL возврата на страницу магазина (указанный ранее магазином при регистрации заказа, см. шаг 2).

  12. Браузер клиента запрашивает страницу с результатами оплаты у магазина.

  13. Система магазина запрашивает у платёжного шлюза статус оплаты заказа (по уникальному идентификатору заказа в платёжной системе, который был получен при регистрации заказа в параметре orderId).
    Спецификация обычного запроса состояния заказа представлена в разделах:

  14. Платёжный шлюз возвращает статус оплаты.

  15. Система магазина передаёт в браузер клиента страницу с результатами оплаты — успешный платёж или неуспешный.

  16. Для списания средств со счёта клиента магазин должен направить в платёжный шлюз запрос завершения оплаты. Спецификация запроса представлена в разделах:

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

Отмена оплаты заказа (2)

Отмена оплаты заказа доступна магазинам при наличии соответствующих прав (по согласованию с банком). . При двухстадийных платежах отмену платежа можно выполнить для заказа в состоянии «Подтверждён"/"Approved». Отмена оплаты заказа осуществляется стандартными средствами:

В случае успешной операции отмены заказ будет переведён из состояния «Подтверждён"/"Approved» в состояние «Отменён"/"Reversed».

Возврат средств оплаты заказа (2)

Полный или частичный возврат по оплаченным заказам (в состоянии «Завершён"/"Deposited») осуществляется стандартными средствами:

После того, как в РБС приходит запрос на возврат средств, отправленный одним из указанных выше способов, РБС осуществляет возврат указанной суммы на счёт клиента. (2)

Проверка вовлечённости карты в 3DS (2)

Система позволяет магазину при необходимости самостоятельно проверить вовлечённость банковской карты в 3-D Secure. Это можно сделать с помощью API, посредством интерфейсов SOAP / REST. Спецификация запроса представлена в разделах:

Добавление в заказ дополнительных параметров (2)

Система позволяет в случае необходимости добавить в заказ дополнительные параметры. Это можно сделать с помощью API, посредством интерфейсов SOAP / REST. Спецификация запроса представлена в разделах:

Статистика по платежам за определённый период (2)

(2) Система позволяет формировать статистику по платежам за определённый период с помощью API, посредством интерфейсов SOAP / REST. Спецификация запроса представлена в разделах:

Одностадийные автоплатежи

Сценарий проведения первоначального платежа (1)

Одностадийные автоплатежи

  1. Клиент оформляет заказ на ресурсе магазина и выбирает способ оплаты банковской картой.

  2. После того как выбран способ оплаты банковской картой, в сторону платёжного шлюза должен быть отправлен запрос регистрации заказа с обязательной передачей уникального идентификатора клиента в параметре clientId. Для регистрации также используются такие параметры как сумма списания, номер заказа в системе магазина, URL возврата клиента. Спецификация запроса представлена в разделах:

  3. В ответе на запрос регистрации платёжный шлюз возвращает уникальный идентификатор заказа в платёжной системе (в параметре orderId) и URL, на который необходимо перенаправить пользователя для получения платёжной формы (в параметре ответа formUrl).

  4. Система магазина должна передать браузеру клиента redirect на URL, полученный от платёжного шлюза в параметре formUrl в ответ на запрос регистрации заказа.

  5. Браузер клиента открывает полученный URL.

  6. Клиент получает платёжную форму.

  7. Клиент заполняет полученную форму реквизитами карты и отправляет данные на сервер платёжного шлюза.

  8. Детали заказа передаются в систему фрод-конроля для определения вероятности мошенничества. Проверка проводится при помощи набора автоматических правил. Результатом применения правила является добавление к заказу коэффициента вероятности мошенничества (фрод-веса). Каждое правило имеет свой фрод-вес, который представляет собой число в диапазоне от 0 до 100. (Если суммарный фрод-вес заказа по всем применённым к заказу правилам превышает 100, такой заказ считается фродовым и оплата по нему будет отклонена.)

  9. В платёжный шлюз возвращаются результаты проверки заказа на мошенничество.

  10. Платёжный шлюз производит проверку вовлечённости карты в 3-D Secure.
    Если авторизации на ACS не требуется, то выполняется следующий шаг сценария (11).
    Если необходима авторизация на ACS, то будут выполнены следующие действия:

    1. Шлюз отправляет браузеру клиента redirect на страницу ACS банка эмитента.

    2. Браузер клиента запрашивает у ACS форму авторизации пользователя (у каждого эмитента это делается по-своему).

    3. ACS отправляет в браузер клиента форму авторизации.

    4. Клиент заполняет форму авторизации и отправляет её в ACS.

    5. ACS обрабатывает заполненную форму и вне зависимости от результата передаёт браузеру redirect на URL страницы платёжного шлюза. Вместе с этим URL передаются зашифрованные параметры результата авторизации.

    6. Браузер клиента запрашивает страницу платёжного шлюза, передавая зашифрованные параметры результата авторизации. Если авторизация прошла успешно, то выполняется следующий шаг сценария.

  11. Платёжный шлюз производит оплату (списание денежных средств со счёта клиента).

  12. В случае успешной оплаты в платёжном шлюзе будет создана связка (данные карты, которая использовалась для оплаты, привязываются к идентификатору клиента, переданному на шаге 2 в параметре clientId).

  13. После проведения оплаты платёжный шлюз передаёт браузеру клиента URL возврата на страницу магазина (указанный ранее магазином при регистрации заказа, см. шаг 2).

  14. Браузер клиента запрашивает страницу с результатами оплаты у магазина.

  15. Система магазина запрашивает у платёжного шлюза статус заказа (по уникальному идентификатору заказа в платёжной системе, который был получен на шаге 3 в параметре orderId). Спецификация обычного запроса состояния заказа представлена в разделах:

  16. Платёжный шлюз возвращает статус оплаты заказа (в параметре orderStatus), а также уникальный идентификатор связки (в параметре bindingId).

  17. Система магазина передаёт в браузер клиента страницу с результатами оплаты — успешный платёж или неуспешный.
    После успешного проведения первоначального платежа магазин на своей стороне подключает клиенту услугу «Автоплатеж» (определяет дату и сумму списания для данного клиента). В дальнейшем магазин самостоятельно отслеживает дату, когда необходимо провести очередной автоплатёж, и инициирует оплату по идентификатору связки.

Сценарий проведения автоплатежа (1)

Когда наступает дата очередного автоплатежа, магазин инициирует оплату по следующему сценарию:

  1. В сторону платёжного шлюза должен быть отправлен запрос регистрации заказа с обязательной передачей уникального идентификатора клиента в параметре clientId. Для регистрации также используются такие параметры как сумма списания, номер заказа в системе магазина, URL возврата клиента. Спецификация запроса представлена в разделах:

  2. В ответе на запрос регистрации платёжный шлюз возвращает уникальный идентификатор заказа в платёжной системе (в параметре orderId).

  3. Магазин отправляет запрос оплаты заказа с помощью связки, передавая номер заказа в платёжной системе, полученный на предыдущем шаге, и идентификатор связки, полученный после совершения первоначального платежа. Спецификация запроса представлена в разделах:

  4. Платёжный шлюз производит оплату (списание денежных средств со счёта клиента).

  5. Система магазина запрашивает у платёжного шлюза статус заказа (по уникальному идентификатору заказа в платёжной системе, который был получен на шаге 2 в параметре orderId). Спецификация обычного запроса состояния заказа представлена в разделах:

Спецификация расширенного запроса состояния заказа представлена в разделах: * Расширенный запрос состояния заказа (WS), * Расширенный запрос состояния заказа (REST). 6. Платёжный шлюз возвращает статус оплаты (в параметре orderStatus).

Получение списка связок клиента (1)

Магазин может получить список идентификаторов существующих связок для определённого clientId, отправив в платёжный шлюз соответствующий запрос. Спецификация запроса представлена в разделах:

Деактивация/активация существующей связки (1)

Система позволяет магазинам при необходимости деактивировать существующие свзяки с помощью API, посредством интерфейсов SOAP / REST. Спецификация запроса представлена в разделах:

Изменение срока действия связки (1)

Изменение срока действия связки может потребоваться в случае перевыпуска карты клиента. Сделать это можно с помощью API, посредством интерфейсов SOAP / REST. Спецификация запроса представлена в разделах:

Двухстадийные автоплатежи

Сценарий проведения первоначального платежа (2)

Двухстадийные автоплатежи

  1. Клиент оформляет заказ на ресурсе мерчанта и выбирает способ оплаты банковской картой.

  2. После того как выбран способ оплаты банковской картой, в сторону платёжного шлюза должен быть отправлен запрос предварительной регистрации заказа с обязательной передачей уникального идентификатора клиента в параметре clientId. Для регистрации также используются такие параметры как сумма списания, номер заказа в системе магазина, URL возврата клиента. Спецификация запроса представлена в разделах:

  3. В ответе на запрос регистрации платёжный шлюз возвращает уникальный идентификатор заказа в платёжной системе (в параметре orderId) и URL, на который необходимо перенаправить пользователя для получения платёжной формы (в параметре ответа formUrl).

  4. Система магазина должна передать браузеру клиента redirect на URL, полученный от платёжного шлюза в параметре formUrl в ответ на запрос регистрации заказа.

  5. Браузер клиента открывает полученный URL

  6. Клиент получает платёжную форму.

  7. Клиент заполняет полученную форму реквизитами карты и отправляет данные на сервер платёжного шлюза.

  8. Детали заказа передаются в систему фрод-конроля для определения вероятности мошенничества. Проверка проводится при помощи набора автоматических правил. Результатом применения правила является добавление к заказу коэффициента вероятности мошенничества (фрод-веса). Каждое правило имеет свой фрод-вес, который представляет собой число в диапазоне от 0 до 100. (Если суммарный фрод-вес заказа по всем применённым к заказу правилам превышает 100, такой заказ считается фродовым и оплата по нему будет отклонена.)

  9. В платёжный шлюз возвращаются результаты проверки заказа на мошенничество.

  10. Получив платёжные реквизиты, платёжный шлюз производит проверку вовлечённости карты в 3-D Secure.
    Если авторизации на ACS не требуется, то выполняется следующий шаг сценария (11).
    Если необходима авторизация на ACS, то будут выполнены следующие действия:

    1. Шлюз отправляет браузеру клиента redirect на страницу ACS банка эмитента.

    2. Браузер клиента запрашивает у ACS форму авторизации пользователя (у каждого эмитента это делается по-своему).

    3. ACS отправляет в браузер клиента форму авторизации.

    4. Клиент заполняет форму авторизации и отправляет её в ACS.

    5. ACS обрабатывает заполненную форму и вне зависимости от результата передаёт браузеру redirect на URL страницы платёжного шлюза. Вместе с этим URL передаются зашифрованные параметры результата авторизации.

    6. Браузер клиента запрашивает страницу платёжного шлюза, передавая зашифрованные параметры результата авторизации. Если авторизация прошла успешно, то выполняется следующий шаг сценария.

  11. Платёжный шлюз производит оплату (холдирование средств на карточном счёте клиента).

  12. В случае успешного холдирования суммы на карте в платёжном шлюзе будет создана связка (данные карты, которая использовалась для оплаты, привязываются к идентификатору клиента, переданному на шаге 2 в параметре clientId).

  13. После проведения оплаты платёжный шлюз передаёт браузеру клиента URL возврата на страницу магазина (указанный ранее магазином при регистрации заказа, см. шаг 2).

  14. Браузер клиента запрашивает страницу с результатами оплаты у магазина.

  15. Система магазина запрашивает у платёжного шлюза статус заказа (по уникальному идентификатору заказа в платёжной системе, который был получен на шаге 3 в параметре orderId).
    Спецификация обычного запроса состояния заказа представлена в разделах:

  16. Платёжный шлюз возвращает статус оплаты заказа (в параметре orderStatus), а также уникальный идентификатор связки (в параметре bindingId).

  17. Система магазина передаёт в браузер клиента страницу с результатами оплаты — успешный платёж или неуспешный.

  18. Для списания захолдированных средств со счёта клиента магазин должен направить в платёжный шлюз запрос завершения оплаты. Спецификация запроса представлена в разделах:

  19. Платёжный шлюз возвращает результат обработки запроса. Статус заказа не возвращается. Для получения заказа необходимо отправить в шлюз соответствующий запрос, как описано на шаге 15. После успешного проведения первоначального платежа магазин на своей стороне подключает клиенту услугу «Автоплатеж» (определяет дату и сумму списания для данного клиента). В дальнейшем магазин самостоятельно отслеживает дату, когда необходимо провести очередной автоплатёж, и инициирует оплату по идентификатору связки.

Сценарий проведения автоплатежа (2)

Когда наступает дата очередного автоплатежа, магазин инициирует оплату по следующему сценарию:

  1. В сторону платёжного шлюза должен быть отправлен запрос предварительной регистрации заказа с обязательной передачей уникального идентификатора клиента в параметре clientId. Для регистрации также используются такие параметры как сумма списания, номер заказа в системе магазина, URL возврата клиента. Спецификация запроса представлена в разделах:

  2. В ответе на запрос регистрации платёжный шлюз возвращает уникальный идентификатор заказа в платёжной системе (в параметре orderId).

  3. Магазин отправляет запрос оплаты заказа с помощью связки, передавая номер заказа в платёжной системе, полученный на предыдущем шаге, и идентификатор связки, полученный после совершения первоначального платежа. Спецификация запроса представлена в разделах:

  4. Платёжный шлюз производит оплату (холдирование средств на карточном счёте клиента) и возвращает результат обработки запроса. Статус заказа не возвращается. Для получения заказа необходимо отправить в шлюз соответствующий запрос.
    Спецификация обычного запроса состояния заказа представлена в разделах:

  5. Платёжный шлюз возвращает статус заказа (в параметре orderStatus).

  6. Для списания средств со счёта клиента магазин должен направить в платёжный шлюз запрос завершения оплаты. Спецификация запроса представлена в разделах:

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

Получение списка связок клиента (2)

Магазин может получить список идентификаторов существующих связок для определённого clientId, отправив в платёжный шлюз соответствующий запрос. Спецификация запроса представлена в разделах:

Деактивация/активация существующей связки (2)

Система позволяет магазинам при необходимости деактивировать существующие свзяки с помощью API, посредством интерфейсов SOAP / REST. Спецификация запроса представлена в разделах:

Изменение срока действия связки (2)

Изменение срока действия связки может потребоваться в случае перевыпуска карты клиента. Сделать это можно с помощью API, посредством интерфейсов SOAP / REST. Спецификация запроса представлена в разделах:

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

Общее описание функционала и дополнение на платёжной странице

Данный функционал используется для привязки номера карты к id покупателя в системе магазина (например, к логину).
Если после авторизации на сайте магазина и успешной оплаты заказа по карте клиент повторно на данном сайте оформит заказ под тем же id, то при перенаправлении на платёжную страницу ему будет предложено автозаполнение всех данных по карте, исключая CVC/ CVV.
Если для мерчанта предполагается использование функционала связок, платёжная страница может содержать форму выбора связки для оплаты заказа. Оформление формы должно удовлетворять следующим условиям:

  • •

    Форма должна иметь идентификатор id="formBinding".

  • •

    Форма должна быть скрыта по умолчанию при помощи CSS свойства "display: none;".

  • •

    Форма должна содержать выпадающий список выбора связки с именем name="bindingId".

  • •

    Выпадающий список должен содержать один вариант выбора: <option value="" selected="selected">другая</option>, при выборе которого пользователь осуществляет обычную оплату по карте, без использования функционала связок.

  • •

    Форма должна содержать поле ввода СVC/CVV с именем name="cvc".

  • •

    Форма должна содержать кнопку «Оплатить»: <input value="Оплатить" type="button" id="buttonBindingPayment"> с идентификатором id="buttonBindingPayment".

  • •

    Поле ввода CVC/CVV и кнопка «Оплатить» должны быть обрамлены элементами с классом class="rbs_hidden". При выборе варианта оплаты без использования функционала связок, эти элементы будут скрыты путем установки свойства CSS "display: none;".

Пример формы:

1<form action="" id="formBinding" style="display: none;">
2    <table cellpadding="10">
3        <tbody>
4        <tr valign="TOP">
5            <td valign="top" width="50%" align="right">
6                <span>Выберите карту:</span>
7            </td>
8            <td valign="top">
9                <select name="bindingId">
10                    <option value="" selected="selected">другая</option>
11                </select>
12            </td>
13        </tr>
14        <tr class="rbs_hidden">
15            <td align="right">
16                <span>Введите CVC2/CVV2/CID код:</span><br>(находится на обратной стороне карты)
17            </td>
18            <td>
19                <input name="cvc" maxlength="4" type="password" autocomplete="off"/>
20            </td>
21        </tr>
22        <tr class="rbs_hidden">
23            <td></td>
24            <td valign="top">
25                <input value="Оплатить" type="button" id="buttonBindingPayment">
26            </td>
27        </tr>
28        </tbody>
29    </table>
30</form>

Сценарий оплаты заказа

Оплата с помощью связки на платёжной странице

  1. Клиент оформляет заказ на ресурсе мерчанта и выбирает способ оплаты банковской картой.

  2. После того как выбран способ оплаты банковской картой, в сторону платёжного шлюза должен быть отправлен запрос регистрации заказа с обязательной передачей уникального идентификатора клиента в параметре clientId. Для регистрации также используются такие параметры как сумма списания, номер заказа в системе магазина, URL возврата клиента. Спецификация запроса представлена в разделах:

  3. В ответе на запрос регистрации платёжный шлюз возвращает уникальный идентификатор заказа в платёжной системе (в параметре orderId) и URL, на который необходимо перенаправить пользователя для получения платёжной формы (в параметре ответа formUrl).

  4. Система магазина должна передать браузеру клиента redirect на URL, полученный от платёжного шлюза в параметре formUrl в ответ на запрос регистрации заказа.

  5. Браузер клиента открывает полученный URL.

  6. Клиент получает платёжную форму.

  7. В том случае, если для данного clientIdещё не создано связки, клиент заполняет полученную форму реквизитами карты и ставит галочку «Запомнить данные этой карты». Затем клиент отправляет данные на сервер платёжного шлюза.
    Если для данного clientId существуют одна или несколько привязанных карт, то они отображаются в выпадающем списке в поле для ввода PAN. Клиент выбирает нужную карту (также есть возможность внести реквизиты новой карты). Затем клиент отправляет данные на сервер платёжного шлюза.

  8. Детали заказа передаются в систему фрод-конроля для определения вероятности мошенничества. Проверка проводится при помощи набора автоматических правил. Результатом применения правила является добавление к заказу коэффициента вероятности мошенничества (фрод-веса). Каждое правило имеет свой фрод-вес, который представляет собой число в диапазоне от 0 до 100. (Если суммарный фрод-вес заказа по всем применённым к заказу правилам превышает 100, такой заказ считается фродовым и оплата по нему будет отклонена.)

  9. В платёжный шлюз возвращаются результаты проверки заказа на мошенничество.
    Если настройки магазина требуют проведения SSL-платежа, то выполняется следующий шаг сценария (10).
    Если платёж в соответствии с настройками магазина должен быть 3DS, то будут выполнены следующие действия:

    1. Получив платёжные реквизиты, платёжный шлюз производит проверку по номеру карты, чтобы определить, требуется ли применение технологии 3-D Secure при проведении платежа. Если применение 3DS-технологии не требуется, то выполняется следующий шаг сценария (10). Если платёж должен быть 3DS, то будут выполнены следующие действия:

      1. Шлюз отправляет браузеру клиента redirect на страницу ACS банка эмитента.

      2. Браузер клиента запрашивает у ACS форму авторизации пользователя (у каждого эмитента это делается по-своему)

      3. ACS отправляет в браузер клиента форму авторизации.

      4. Клиент заполняет авторизации и отправляет её в ACS.

      5. ACS обрабатывает заполненную форму и вне зависимости от результата передаёт браузеру redirect на URL страницы платёжного шлюза. Вместе с этим URL передаются зашифрованные параметры результата авторизации.

      6. Браузер клиента запрашивает страницу платёжного шлюза, передавая зашифрованные параметры результата авторизации. Если авторизация прошла успешно, то выполняется следующий шаг сценария.

  10. Платёжный шлюз производит оплату (списание денежных средств со счёта клиента)

  11. После проведения оплаты платёжный шлюз передаёт браузеру клиента URL возврата на страницу магазина (указанный ранее магазином при регистрации заказа, см. шаг 2).

  12. Браузер клиента запрашивает страницу с результатами оплаты у магазина.

  13. Система магазина запрашивает у платёжного шлюза статус оплаты заказа (по уникальному идентификатору заказа в платёжной системе, который был получен при регистрации заказа в параметре orderId). Спецификация обычного запроса состояния заказа представлена в разделах:

  14. платёжный шлюз возвращает статус оплаты.

  15. Система магазина передаёт в браузер клиента страницу с результатами оплаты — успешный платёж или неуспешный.

Получение списка связок клиента

Если на Шаге 5 сценария клиент на платёжной странице ввёл реквизиты новой карты и поставил галочку «Запомнить данные этой карты», то в случае успешной оплаты на стороне платёжного шлюза создаётся уникальный идентификатор связки. Магазин может получить список идентификаторов существующих связок для определённого clientId, отправив в платёжный шлюз соответствующий запрос. Спецификация запроса представлена в разделах:

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

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

Деактивация/активация существующей связки

Система позволяет магазинам при необходимости деактивировать существующие свзяки с помощью API, посредством интерфейсов SOAP / REST. Спецификация запроса представлена в разделах:

В дальнейшем деактивированная связка может быть снова активирована. Для этого магазин должен направить в платёжный шлюз соответствующий запрос. Спецификация запроса представлена в разделах:

Изменение срока действия связки

Изменение срока действия связки может потребоваться в случае перевыпуска карты клиента. Сделать это можно с помощью API, посредством интерфейсов SOAP / REST. Спецификация запроса представлена в разделах:

Оплата с использованием Apple Pay

В настоящее время осуществляется поддержка платежей с помощью мобильных приложений. Также, продавец может разместить на своём сайте специальную кнопку, позволяющую принимать платежи через систему Apple Pay. Описание подготовки сайта продавца к приёму платежей Apple Pay не входит в задачи настоящего документа.

Действия продавца, необходимые для подключения к Apple Pay

Действия в личном кабинете платёжного шлюза

Перед тем, как принимать платежи с помощью Apple Pay, в личном кабинете сформируйте ключевую пару и выгрузите запрос подписи сертификата открытого ключа. Процедура описана в инструкции администратора по работе с консолью.

Создание Merchant ID

Чтобы создать свой Merchant ID (Идентификатор продаваца), выполните следующие действия. Для завершения этой процедуры у вас должна быть учётная запись Apple Developer (Разработчик Apple).

  1. В личном кабинете Member Center (Партнёрский центр) Apple перейдите в раздел Certificates, Identifiers & Profiles (Сертификаты, идентификаторы и профили).

  2. На отобразившейся странице в секции Identifiers (Идентификаторы) слева выберите Merchant IDs (Идентификаторы продавцов).

  3. На отобразившейся странице щёлкните на значке + (Add (Добавить)) в правом верхнем углу.

  4. В полях Merchant ID Description (Описание идентификатора продавца) и Identifier (Идентификатор) введите описание своего идентификатора продавца Apple и сам идентификатор соответственно.
    Примечание. Идентификатор следует начать со слова merchant, указав при этом адрес вашего основного сайта в обратном порядке. Например, для сайта sale.test.ru идентификатор будет иметь значение merchant.ru.test.sale.

  5. Нажмите Continue (Продолжить).

  6. На отобразившейся странице проверьте введённые данные и нажмите Register (Зарегистрировать).

  7. На отобразившейся странице нажмите Done (Готово).

Создание сертификата для Merchant ID

Чтобы создать сертификат для своего Merchant ID (Идентификатора продавца), выполните следующие действия.

  1. В личном кабинете Member Center (Партнёрской центр) Apple перейдите в раздел Certificates, Identifiers & Profiles (Сертификаты, идентификаторы и профили).

  2. На отобразившейся странице в секции Identifiers (Идентификаторы) слева выберите Merchant IDs (Идентификаторы продавцов).

  3. Выберите свой Merchant ID (Идентификатор продавца) из списка и нажмите Edit (Редактировать).

  4. Нажмите Create Certificate (Создать сертификат), после чего нажмите Continue (Продолжить).

  5. Нажмите Choose File (Выбрать файл), укажите путь к файлу запросу подписи сертификата, выгруженному из личного кабинета платёжного шлюза.
    Примечание. Процедура создания файла запроса подписи сертификата представлена в документе «Инструкция администратора по работе с консолью».

  6. Нажмите Generate (Сгенерировать).

  7. Нажмите Download (Загрузить), чтобы загрузить созданный сертификат на компьютер.

  8. После загрузки сертификата нажмите Done (Готово). Если вы выполнили указанные выше действия, вы можете приступать к разработке взаимодействия вашего мобильного приложения или сайта с платёжным шлюзом.

Схема взаимодействия при оплате с помощью Apple Pay

При оплате с использованием Apple Pay взаимодействие происходит по следующей схеме.

Схема взаимодействия при оплате с помощью Apple Pay
Описание схемы приведено ниже.

  1. Пользователь выбирает вариант оплаты с помощью Apple Pay.

  2. Сведения о платеже направляются на обработку в систему Apple Pay.

  3. Для обработки данных о платеже в системе Apple Pay создаётся объект PKPaymentToken Object, который содержит свойство paymentData (здесь и далее подробнее см. документацию Apple Pay — на английском языке).

  4. Apply Pay направляет продавцу (мобильному приложению или сайту) ответ.

  5. Продавец извлекает из полученного объекта PKPaymentToken Object свойство paymentData и кодирует его содержимое в Base64.

  6. Продавец создаёт запрос на оплату, содержащий в том числе свойство paymentData, полученное из ответа системы Apple Pay и закодированное в Base64, и отправляет его на обработку в платёжный шлюз — см. секции Запрос на оплату через Apple Pay (Web-Service) и Запрос на оплату через Apple Pay (REST).

  7. Платёжный шлюз обрабатывает запрос.

  8. Платёжный шлюз и возвращает ответ с результатом.

  9. Мобильное приложение или сайт отображает пользователю результат оплаты.

Проведение рекуррентных платежей через Apple Pay

Чтобы инициировать рекуррентные платежи, необходимо создать соответствующую связку. Для этого необходимо сделать запрос на проведение платежа и указать в запросе значение clientId:

Для последующих запросов на проведение рекуррентных платежей используется запрос recurrentPayment:

Apple Pay — ссылки на справочную информацию

В таблице ниже представлены ссылки на справочную информацию об Apple Pay.

ОписаниеСсылка
Раздел сайта apple.com, содержащий общие сведения об Apple Pay.https://www.apple.com/apple-pay
Раздел сайта apple.com, предназначенный для разработчиков и содержащий ссылки на различные документы и справочную информацию, касающуюся Apple Pay.https://developer.apple.com/apple-pay
Раздел сайта apple.com, содержащий информацию о тестировании.https://developer.apple.com/support/apple-pay-sandbox
Документ в формате PDF, содержащий общие сведения об Apple Pay и ссылки на справочную информацию.https://developer.apple.com/apple-pay/Getting-Started-with-Apple-Pay.pdf
Документ в формате PDF, содержащий рекомендации по оформлению сайтов и мобильных приложений в стиле Apple.https://developer.apple.com/apple-pay/Apple-Pay-Identity-Guidelines.pdf
Раздел сайта apple.com, содержащий справочник по программированию.https://developer.apple.com/library/ios/ApplePay_Guide
Раздел справочного руководства по App Store, посвящённый приложениям Apple Pay.https://developer.apple.com/app-store/review/guidelines/#apple-pay
Справочник API (программный интерфейс для приложений).https://developer.apple.com/library/ios/documentation/UserExperience/Reference/PassKit_Framework/index.html#//apple_ref/doc/uid/TP40012158
Описание структуры PKPaymentToken Object.https://developer.apple.com/library/ios/documentation/PassKit/Reference/PaymentTokenJSON/PaymentTokenJSON.html#//apple_ref/doc/uid/TP40014929
Страница входа в среду разработки.https://devforums.apple.com/community/ios/connected/applepay

Оплата с использованием Google Pay

Введение

Возможны несколько вариантов реализации возможности оплаты с помощью системы Google Pay.

Реализация способа оплатыОписание
Из мобильного приложенияОплата осуществляется из мобильного приложения с мобильного устройства пользователя. В этом сценарии приложение запрашивает зашифрованные данные у Google Pay. Эти данные необходимо передать в платёжный шлюз.
С веб страницы, при этом платёжная страница расположена на стороне продавцаОплата осуществляется с веб-страницы. Пользователь выбирает оплату на сайте продавца, при этом продавец запрашивает зашифрованные платёжные данные у системы Google Pay. Затем продавец должен отправить эти данные в платёжный шлюз.
С веб страницы, при этом платёжная страница расположена на стороне платёжного шлюзаОплата осуществляется с веб-страницы. Продавец перенаправляет пользователя на страницу платёжного шлюза, дальше платёжный шлюз обменивается данными с сисемой Google Pay, после чего производится платёж.

Сценарий оплаты в мобильном приложении

Сценарий оплаты в мобильном приложении

  1. Клиент выбирает способ оплаты Google Pay.

  2. Приложение запрашивает Google Pay информацию о маскированных карточных данных.

  3. Google Pay возвращает в приложение маскированные карточные данные.

  4. Приложение отображает клиенту маскированные данные карты, добавленной в Google Pay.

  5. Клиент подтверждает оплату с помощью добавленной в Google Pay карты.

  6. Приложение запрашивает Google Pay зашифрованные карточные данные.

  7. Google шифрует данные, используя открытый ключ — соответствующий ему закрытый ключ расположен в платёжном шлюзе.

  8. Google возвращает в приложение зашифрованные данные о платеже.

  9. Приложение отправляет в платёжный шлюз запрос на оплату Google Pay, указывая полученный от системы Google Pay токен:

  10. Платёжный шлюз расшифровывает полученный токен и производит оплату.

  11. Платёжный шлюз возвращает результат оплаты в приложение.

  12. Приложение отображает результат оплаты клиенту.

Действия продавца, необходимые для подключения Google Pay к приложению

Перед тем, как принимать платежи с помощью Google Pay, ознакомьтесь со всеми требованиями и условиями со стороны Google.

Подключение Android приложения к Googel Pay API:

Документация по подключению:

Рекомендации для подключения Android приложения к Google Pay:

Сценарий оплаты с платёжной страницей на стороне Продавца

Если платёжная страница расположена на стороне Google Pay, платёж происходит по следующей схеме.

Сценарий оплаты с платёжной страницей на стороне ТСП

  1. Клиент формирует заказ на сайте интернет-магазина и выбирает способ оплаты Google Pay.

  2. Система интернет-магазина формирует запрос на оплату в Google Pay.

  3. Система Google Pay формирует зашифрованные платёжные данные.

  4. Система интернет-магазина получает зашифрованные платёжные данные

  5. Система интернет-магазина формирует запрос в платёжный шлюз на оплату Google Pay, указывая полученные зашифрованные платёжные данные:

  6. Платёжный шлюз расшифровывает полученные данные и производит оплату.

  7. РБС возвращает результат оплаты в систему интернет-магазина.

  8. Результат оплаты отображается клиенту.

Действия продавца, необходимые для подключения Google Pay к веб-странице

Перед тем, как принимать платежи с помощью Google Pay, ознакомьтесь со всеми требованиями и условиями со стороны Google.

Подключение веб-страницы к Googel Pay API: — https://developers.google.com/pay/api/web/

Документация по подключению: — https://developers.google.com/pay/api/web/guides/tutorial

Рекомендации для подключения веб-страницы к Google Pay: — https://developers.google.com/pay/api/web/guides/brand-guidelines

Сценарий оплаты с платёжной страницей на стороне платежного шлюза

Сценарий оплаты с платёжной страницей на стороне Банка

  1. Клиент формирует заказ на сайте продавца.

  2. Продавец регистрирует заказ в платёжном шлюзе.

  3. Платёжный шлюз возвращает уникальный номер заказа в системе платёжного шлюза и URL-адрес на который необходимо перенаправить клиента.

  4. Система магазина перенаправляет браузер клиента на URL-адрес полученный на шаге 3.

  5. Браузер клиента открывает URL-адрес.

  6. В качестве страницы по указанному URL-адресу браузер клиента получает платёжную форму.

  7. Клиент выбирает способ оплаты Google Pay и подтверждает свой выбор.

  8. Происходит обмен данными между платёжным шлюзом и системой Google Pay — платёжный шлюз получает платёжные данные.

  9. Платёжный шлюз производит оплату.

  10. Клиента перенаправляют на финальную страницу магазина.

  11. Браузер клиента открывает финальную страницу.

  12. Статус отображается показывается клиенту.

Оплата с использованием AlfaPay

Термины, определения и сокращения

ТерминОписание
Альфа БанкАО «Альфа Банк», он же Заказчик, в рамках данного документа допустимо использование сокращения «Банк»
Платёжный шлюз (ПШ)Автоматическая система, предоставляющая магазину принимать, а Клиенту отправлять платежи через интернет с использованием банковских карт.
КлиентФизическое или юридическое лицо, осуществляющее Платеж.
ТСПТоргово-сервисное предприятие, продающее товары или оказывающее услуги. В рамках данного документа допустимо название Продавец или Мерчант.
Формат данных

Требование к формату данных параметров запросов/ответов:

  • •

    Форматы допустимых символов:

    • •

      A - буквы (латиница);

    • •

      N - арабские цифры;

    • •

      S - специальные символы;

  • •

    Форматы длин значений:

    • •

      число - точная длина (например, N 2 - строго две цифры);

    • •

      число - максимальная длина (например, N..2 - не более двух цифр);

    • •

      число..число - минимальная и максимальная длина (например, N1..2 - от одной до двух цифр).

Ограничения

Проверка 3DS при оплате методом /alfapay/payment.do НЕ выполняется. Оплата методом AlfaPay с кастомизированных страниц продавца (не через API ПШ) не поддерживается.

Сценарий работы

Сценарий работы

  1. Клиент переходит на ПС Продавца.

  2. Клиент нажимает на кнопку оплаты AlfaPay.

  3. Продавец передаёт в ПШ API-запрос /alfapay/payment.do для регистрации заказа и инициации оплаты. <ссылка на запрос rest>Запрос на оплату AlfaPay (REST)

  4. ПШ взаимодействует с Сервисом Банка и регистрирует заказ.

  5. ПШ возвращает Продавцу API-ответ с указанием redirect (URL Сервиса Банка) и orderId (идентификатора заказа).

  6. ПС Продавца перенаправляет Клиента на адрес Сервиса Банка, указанный в redirect.

  7. Клиент переходит напрямую в Сервис Банка на адрес redirect и указывает, какую карту использовать при оплате.

  8. Сервис Банка отправляет в ПШ данные карты Клиента.

  9. ПШ выполняет оплату заказа картой.

  10. ПШ возвращает в Сервис Банка ответ, содержащий адрес возврата, указанный в параметре returnURL при регистрации заказа на шаге 3.

  11. Сервис Банка перенаправляет Клиента на адрес возврата.

  12. Клиент переходит на страницу Продавца.
    Шаги 13-14 выполняются на усмотрение Продавца.

  13. Продавец передаёт в ПШ запрос статуса заказа (стандартный метод getOrderStatusExtended.do). Расширенный запрос состояния заказа (REST).

  14. ПШ возвращает Продавцу информацию о заказе. Продавец отображает Клиенту результат оплаты.