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

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

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

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

• 1. Клиент оформляет заказ на ресурсе мерчанта и выбирает способ оплаты банковской картой.
• 2. После того как выбран способ оплаты банковской картой, в сторону платёжного шлюза должен быть отправлен запрос регистрации заказа. Для регистрации используются такие параметры как сумма списания, номер заказа в системе магазина, а также URL возврата клиента. Спецификация запроса представлена в разделах:
• Запрос регистрации заказа (WS),
• Запрос регистрации заказа (REST).
• 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).
  Спецификация обычного запроса состояния заказа представлена в разделах:
  

• Запрос состояния заказа (WS),

• Запрос состояния заказа (REST).
  Спецификация расширенного запроса состояния заказа представлена в разделах:
  

• Расширенный запрос состояния заказа (WS),
• Расширенный запрос состояния заказа (REST).
• 14. платёжный шлюз возвращает статус оплаты.
• 15. Система магазина передаёт в браузер клиента страницу с результатами оплаты – успешный платёж или неуспешный.

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

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

• Через административную консоль (описание представлено в документе "Инструкция по работе с консолью", раздел "Работа с заказами");

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

  • Запрос отмены оплаты заказа (WS),
  • Запрос отмены оплаты заказа (REST).

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

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

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

• Через административную консоль (описание представлено в документе "Инструкция по работе с консолью", раздел "Работа с заказами");

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

  • Запрос возврата средств оплаты заказа (WS),
  • Запрос возврата средств оплаты заказа (REST).

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

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

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

• Запрос проверки вовлечённости карты в 3DS (WS),
• Запрос проверки вовлечённости карты в 3DS (REST).

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

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

• Запрос добавления дополнительных параметров к заказу (WS),
• Запрос добавления дополнительных параметров к заказу (REST).

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

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

• Запрос статистики по платежам за период (WS),
• Запрос статистики по платежам за период (REST).

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

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

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

• 1. Клиент оформляет заказ на ресурсе мерчанта и выбирает способ оплаты банковской картой.
• 2. После того как выбран способ оплаты банковской картой, в сторону платёжного шлюза должен быть отправлен запрос регистрации заказа с предавторизацией. Для регистрации используются такие параметры как сумма списания, номер заказа в системе магазина, а также URL возврата клиента. Спецификация запроса представлена в разделах:
• Запрос регистрации заказа с предавторизацией (WS) ,
• Запрос регистрации заказа с предавторизацией (REST) .
• 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).
  Спецификация обычного запроса состояния заказа представлена в разделах:
  

• Запрос состояния заказа (WS),

• Запрос состояния заказа (REST).
  Спецификация расширенного запроса состояния заказа представлена в разделах:
  

• Расширенный запрос состояния заказа (WS),
• Расширенный запрос состояния заказа (REST).
• 14. Платёжный шлюз возвращает статус оплаты.
• 15. Система магазина передаёт в браузер клиента страницу с результатами оплаты – успешный платёж или неуспешный.
• 16. Для списания средств со счёта клиента магазин должен направить в платёжный шлюз запрос завершения оплаты. Спецификация запроса представлена в разделах:
• Запрос завершения оплаты заказа (WS),
• Запрос завершения оплаты заказа (REST).
• 17. Платёжный шлюз возвращает результат обработки запроса. Статус заказа не возвращается. Для получения заказа необходимо отправить в шлюз соответствующий запрос, как описано на шаге 13.

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

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

• Через административную консоль (описание представлено в документе "Инструкция по работе с консолью", раздел "Работа с заказами");

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

  • Запрос отмены оплаты заказа (WS),
  • Запрос отмены оплаты заказа (REST).

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

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

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

• Через административную консоль (описание представлено в документе "Инструкция по работе с консолью", раздел "Работа с заказами");

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

  • Запрос возврата средств оплаты заказа (WS),
  • Запрос возврата средств оплаты заказа (REST).

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

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

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

• Запрос проверки вовлечённости карты в 3DS (WS),
• Запрос проверки вовлечённости карты в 3DS (REST).

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

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

• Запрос добавления дополнительных параметров к заказу (WS),
• Запрос добавления дополнительных параметров к заказу (REST).

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

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

• Запрос статистики по платежам за период (WS),
• Запрос статистики по платежам за период (REST).

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

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

• 1. Клиент оформляет заказ на ресурсе магазина и выбирает способ оплаты банковской картой.
• 2. После того как выбран способ оплаты банковской картой, в сторону платёжного шлюза должен быть отправлен запрос регистрации заказа с обязательной передачей уникального идентификатора клиента в параметре clientId. Для регистрации также используются такие параметры как сумма списания, номер заказа в системе магазина, URL возврата клиента. Спецификация запроса представлена в разделах:
• Запрос регистрации заказа (WS),
• Запрос регистрации заказа (REST).
• 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).
  Спецификация обычного запроса состояния заказа представлена в разделах:
  

• Запрос состояния заказа (WS),

• Запрос состояния заказа (REST).
  Спецификация расширенного запроса состояния заказа представлена в разделах:
  

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

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

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

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

• 1. В сторону платёжного шлюза должен быть отправлен запрос регистрации заказа с обязательной передачей уникального идентификатора клиента в параметре clientId. Для регистрации также используются такие параметры как сумма списания, номер заказа в системе магазина, URL возврата клиента. Спецификация запроса представлена в разделах:
• Запрос регистрации заказа (WS),
• Запрос регистрации заказа (REST).
• 2. В ответе на запрос регистрации платёжный шлюз возвращает уникальный идентификатор заказа в платёжной системе (в параметре orderId).
• 3. Магазин отправляет запрос оплаты заказа с помощью связки, передавая номер заказа в платёжной системе, полученный на предыдущем шаге, и идентификатор связки, полученный после совершения первоначального платежа. Спецификация запроса представлена в разделах:
• Запрос проведения платежа по связке (WS),
• Запрос проведения платежа по связке (REST).
• 4. Платёжный шлюз производит оплату (списание денежных средств со счёта клиента).
• 5.

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

• Запрос состояния заказа (WS),

• Запрос состояния заказа (REST).
  Спецификация расширенного запроса состояния заказа представлена в разделах:
  

• Расширенный запрос состояния заказа (WS),
• Расширенный запрос состояния заказа (REST).
• 6. Платёжный шлюз возвращает статус оплаты (в параметре orderStatus).

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

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

• Запрос списка связок клиента (WS),
• Запрос списка связок клиента (REST).

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

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

• Запрос деактивации связки (WS),

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

• Запрос активации связки (WS),
• Запрос активации связки (REST).

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

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

• Запрос изменения срока действия связки (WS),
• Запрос изменения срока действия связки (REST).

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

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

• 1. Клиент оформляет заказ на ресурсе мерчанта и выбирает способ оплаты банковской картой.
• 2. После того как выбран способ оплаты банковской картой, в сторону платёжного шлюза должен быть отправлен запрос предварительной регистрации заказа с обязательной передачей уникального идентификатора клиента в параметре clientId. Для регистрации также используются такие параметры как сумма списания, номер заказа в системе магазина, URL возврата клиента. Спецификация запроса представлена в разделах:
• Запрос регистрации заказа с предавторизацией (WS) ,
• Запрос регистрации заказа с предавторизацией (REST) .
• 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).
  Спецификация обычного запроса состояния заказа представлена в разделах:
  

• Запрос состояния заказа (WS),

• Запрос состояния заказа (REST).
  Спецификация расширенного запроса состояния заказа представлена в разделах:
  

• Расширенный запрос состояния заказа (WS),
• Расширенный запрос состояния заказа (REST).
• 16. Платёжный шлюз возвращает статус оплаты заказа (в параметре orderStatus), а также уникальный идентификатор связки (в параметре bindingId).
• 17. Система магазина передаёт в браузер клиента страницу с результатами оплаты – успешный платёж или неуспешный.
• 18. Для списания захолдированных средств со счёта клиента магазин должен направить в платёжный шлюз запрос завершения оплаты. Спецификация запроса представлена в разделах:
• Запрос завершения оплаты заказа (WS),
• Запрос завершения оплаты заказа (REST).
• 19.

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

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

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

• 1. В сторону платёжного шлюза должен быть отправлен запрос предварительной регистрации заказа с обязательной передачей уникального идентификатора клиента в параметре clientId . Для регистрации также используются такие параметры как сумма списания, номер заказа в системе магазина, URL возврата клиента. Спецификация запроса представлена в разделах:
• Запрос регистрации заказа с предавторизацией (WS) ,
• Запрос регистрации заказа с предавторизацией (REST) .
• 2. В ответе на запрос регистрации платёжный шлюз возвращает уникальный идентификатор заказа в платёжной системе (в параметре orderId).
• 3. Магазин отправляет запрос оплаты заказа с помощью связки, передавая номер заказа в платёжной системе, полученный на предыдущем шаге, и идентификатор связки, полученный после совершения первоначального платежа. Спецификация запроса представлена в разделах:
• Запрос проведения платежа по связке (WS),
• Запрос проведения платежа по связке (REST).
• 4.

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

• Запрос состояния заказа (WS),

• Запрос состояния заказа (REST).
  Спецификация расширенного запроса состояния заказа представлена в разделах:
  

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

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

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

• Запрос списка связок клиента (WS),
• Запрос списка связок клиента (REST).

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

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

• Запрос деактивации связки (WS),

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

• Запрос активации связки (WS),
• Запрос активации связки (REST).

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

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

• Запрос изменения срока действия связки (WS),
• Запрос изменения срока действия связки (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;".

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

        <form action="" id="formBinding" style="display: none;">
    <table cellpadding="10">
        <tbody>
        <tr valign="TOP">
            <td valign="top" width="50%" align="right">
                <span>Выберите карту:</span>
            </td>
            <td valign="top">
                <select name="bindingId">
                    <option value="" selected="selected">другая</option>
                </select>
            </td>
        </tr>
        <tr class="rbs_hidden">
            <td align="right">
                <span>Введите CVC2/CVV2/CID код :</span><br>(находится на обратной стороне карты)
            </td>
            <td>
                <input name="cvc" maxlength="4" type="password" autocomplete="off"/>
            </td>
        </tr>
        <tr class="rbs_hidden">
            <td></td>
            <td valign="top">
                <input value="Оплатить" type="button" id="buttonBindingPayment">
            </td>
        </tr>
        </tbody>
    </table>
</form>
    

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

• 1. Клиент оформляет заказ на ресурсе мерчанта и выбирает способ оплаты банковской картой.
• 2. После того как выбран способ оплаты банковской картой, в сторону платёжного шлюза должен быть отправлен запрос регистрации заказа с обязательной передачей уникального идентификатора клиента в параметре clientId. Для регистрации также используются такие параметры как сумма списания, номер заказа в системе магазина, URL возврата клиента. Спецификация запроса представлена в разделах:
• Запрос регистрации заказа (WS),
• Запрос регистрации заказа (REST).
• 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). Спецификация обычного запроса состояния заказа представлена в разделах:
• Запрос состояния заказа (WS),

• Запрос состояния заказа (REST).
  Спецификация расширенного запроса состояния заказа представлена в разделах:
  

• Расширенный запрос состояния заказа (WS),
• Расширенный запрос состояния заказа (REST).
• 14. платёжный шлюз возвращает статус оплаты.
• 15. Система магазина передаёт в браузер клиента страницу с результатами оплаты – успешный платёж или неуспешный.

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

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

• Запрос списка связок клиента" (SOAP)
• Запрос списка связок клиента" (REST)

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

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

• Запрос списка связок банковской карты " (SOAP),
• Запрос списка связок банковской карты" (REST).

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

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

• Запрос деактивации связки" (SOAP),

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

• Запрос активации связки" (SOAP),
• Запрос активации связки" (REST).

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

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

• Запрос изменения срока действия связки" (SOAP),
• Запрос изменения срока действия связки" (REST).

Использование "Альфа-клик" для оплаты заказа

Краткое описание системы PayByClick

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

• 1. Продавец принимает платежи через "Альфа-Клик" наряду с использованием электронной коммерции. В этом случае кнопка перехода в систему PayByClick располагается на платёжной странице, куда перенаправляется клиент для оплаты заказа. Описание процесса оплаты представлено в разделе "Использование "Альфа-Клик" и электронной коммерции".
• 2.

  Продавец принимает платежи только через "Альфа-Клик". В этом случае для перенаправления клиента в систему PayByClick создаётся запрос оплаты через "Альфа-Клик". Описание процесса оплаты представлен в разделе "Использование только "Альфа-Клик"".
  Система PayByClick не предусматривает возможность частичного списания предавторизованного заказа (при двухстадийном процессе), частичной оплаты, частичного или полного возврата средств (reversal или refund). Оплата возможна только в рублях. Отсутствует возможность размещения страницы ввода данных для платежа на стороне сайта магазина.
  Для сверки используются существующие реестры платежей e-invoicing.
  

Сценарии оплаты заказа через "Альфа-Клик"

Использование "Альфа-Клик" и электронной коммерции

Если магазин использует "Альфа-Клик" наряду с электронной коммерцией, то при создании платёжной страницы помимо стандартных требований, описанных в документе "Оформление платёжной страницы", добавляется требование разместить на странице элемент-кнопку:
<input type="button" class="alfaclick" id="buttonPaymentAlfa" value="Оплатить через Альфа-Клик" />"
Также существует возможность загрузки магазину стандартной платёжной страницы, где уже размещена кнопка для перехода к оплате через Альфа-Клик.

• 1. Клиент формирует заказ на сайте магазина.
• 2. После подтверждения заказа клиентом магазин регистрирует заказ в РБС. Для регистрации используются такие параметры как сумма списания, номер заказа в системе магазина, а также URL возврата клиента. Спецификация запроса представлена в разделах:
• Запрос регистрации заказа (WS),
• Запрос регистрации заказа (REST).
• 3. РБС возвращает ID заказа и URL перенаправления клиента на платёжную форму. В случае реализации выбора способа оплаты на стороне платёжной страницы, выполняются шаги 4-6. В случае выбора оплаты на стороне магазина, на данном шаге передается URL для продолжения на шаге 7.
• 4. Магазин передаёт клиенту redirect на URL, полученный на шаге 3.
• 5. Клиент открывает полученный URL, запрашивая платёжную форму.
• 6. Клиенту отображается форма выбора типа оплаты. При выборе "Оплатить через Альфа-Клик" происходит перенаправление клиента на PayByClick.
• 7.

  Браузер клиента запрашивает форму авторизации с передачей параметров:
  

  • ID заказа (получен на шаге 3);
  • BackURL для возврата на страницу запроса статуса заказа (переданный в запросе регистрации заказа на шаге 2).
• 8. PayByClick запрашивает данные заказа по его ID.
• 9. РБС возвращает данные заказа.
• 10. Операции аутентификации клиента "Альфа-Клик" и авторизации оплаты через "Альфа-Клик".
• 11. Операции аутентификации клиента "Альфа-Клик" и авторизации оплаты через "Альфа-Клик".
• 12. Операции аутентификации клиента "Альфа-Клик" и авторизации оплаты через "Альфа-Клик".
• 13. Операции аутентификации клиента "Альфа-Клик" и авторизации оплаты через "Альфа-Клик".
• 14. PayByClick передаёт клиенту редирект на URL РБС, полученный на шаге 7 и завершает работу. При этом статус платежа не передаётся, передаётся только ID заказа.
• 15. Браузер клиента открывает полученный BackURL страницы запроса статуса оплаты.
• 16. На странице проверяется статус оплаты заказа.
• 17. После того, как статус заказа получает необходимое значение (DEPOSITED), происходит редирект на страницу магазина для отображения статуса оплаты заказа.
• 18. Пользователь получает страницу со статусом оплаты.

Использование только "Альфа-Клик"

Ниже описан основной процесс оплаты через систему PayByClick (без негативных сценариев) в случае, если магазин принимает оплату только через систему PayByClick:

• 1. Клиент формирует заказ на сайте магазина.
• 2. После подтверждения заказа клиентом магазин регистрирует заказ в РБС. Для регистрации используются такие параметры как сумма списания, номер заказа в системе магазина, а также URL возврата клиента. Спецификация запроса представлена в разделах:
• Запрос регистрации заказа (WS),
• Запрос регистрации заказа (REST).
• 3. РБС возвращает ID заказ.
• 4. Магазин отправляет в РБС запрос оплаты заказа через "Альфа-Клик", передавая ID заказа, полученный на шаге 3. Для этого используется запрос оплаты альтернативным способом с обязательной передачей значения ALFA_ALFACLICK в параметре paymentWay, а также ID заказа. Спецификация запроса представлена в разделах:
• Запрос оплаты через внешнюю платёжную систему (WS),
• Запрос оплаты через внешнюю платёжную систему (REST).
• 5. В ответ платёжный шлюз присылает URL для перенаправления клиента в систему PayByClick.
• 6. Браузеру клиента передаётся редирект в систему PayByClick.
• 7.

  Браузер клиента запрашивает форму авторизации с передачей параметров:
  

  • ID заказа (получен на шаге 3);
  • BackURL для возврата на страницу запроса статуса заказа (переданный в запросе регистрации заказа на шаге 2).
• 8. PayByClick запрашивает данные заказа по его ID.
• 9. РБС возвращает данные заказа.
• 10. Операции аутентификации клиента "Альфа-Клик" и авторизации оплаты через "Альфа-Клик".
• 11. Операции аутентификации клиента "Альфа-Клик" и авторизации оплаты через "Альфа-Клик".
• 12. Операции аутентификации клиента "Альфа-Клик" и авторизации оплаты через "Альфа-Клик".
• 13. Операции аутентификации клиента "Альфа-Клик" и авторизации оплаты через "Альфа-Клик".
• 14. PayByClick передаёт клиенту редирект на URL РБС, полученный на шаге 7 и завершает работу. При этом статус платежа не передаётся, передаётся только ID заказа.
• 15. Браузер клиента открывает полученный BackURL страницы запроса статуса оплаты.
• 16. На странице проверяется статус оплаты заказа.
• 17. После того, как статус заказа получает необходимое значение (DEPOSITED), происходит редирект на страницу магазина для отображения статуса оплаты заказа.
• 18. Пользователь получает страницу со статусом оплаты.

Тестирование оплаты через "Альфа-Клик"

• 1. Зарегистрируйте заказ в платёжном шлюзе. Регистрацию заказа можно осуществить с помощью REST / SOAP.
• 2.

  Переход в систему PayByClick осуществляется:
  

  • После нажатия кнопки "Можно оплатить через Альфа-Клик" на платёжной странице, если клиент был на неё перенаправлен после регистрации заказа,
  • После отправки запроса проведения оплаты через "Альфа-Клик" (REST / SOAP).
• 3.

  Откроется страница оплаты через "Альфа-Клик" по адресу http://217.12.96.193/PayByClick/login.xhtml?faces-redirect=true:
  
  

• 4.

  Введите логин и пароль "Альфа-Клик", а затем нажмите кнопку "Продолжить". Тестовые реквизиты:
  

  • Логин "Альфа-Клик": 6819507
  • Пароль "Альфа-Клик": 000000
• 5.

  Откроется страница "Авторизация":
  
  

• 6. Введите одноразовый пароль и нажмите кнопку "Продолжить". Тестовый одноразовый пароль: 0000.
• 7.

  Откроется страница выбора счёта списания:
  
  

• 8. Из выпадающего списка выберите счет счёт списания я нажмите кнопку "Оплатить". Произойдёт перенаправление на страницу магазина, указанную при регистрации заказа.
• 9. После этого оплата считается формально завершённой. При возврате на сайт магазина после оплаты в системе "Альфа-Клик" не передаётся статус платежа. Поэтому магазину для уточнения статуса оплаты необходимо опрашивать систему РБС через стандартный запрос состояния заказа (getOrderStatus) и ожидать, когда заказ перейдёт в состояние DEPOSITED (средства списаны).

Использование UPOP для оплаты заказа

Краткое описание системы CUP

Инструмент UPOP является платежным средством платёжного шлюза, который позволяет совершать оплату через систему China UnionPay (CUP). При этом схема взаимодействия интернет-магазина и платёжного шлюза не изменяется.
Оплата через UPOP доступна для держателей карт China UnionPay.
Схема интеграции зависит от способа использования платёжного средства UPOP.

• Продавец принимает платежи через UPOP наряду с использованием электронной коммерции. В этом случае кнопка перехода в систему CUP располагается на платёжной странице, куда перенаправляется клиент для оплаты заказа. Описание процесса оплаты представлено в разделе "Использование UPOP и электронной коммерции".

• Продавец принимает платежи только через UPOP. В этом случае для перенаправления клиента в систему CUP создаётся запрос оплаты через UPOP. Описание процесса оплаты представлен в разделе "Использование только UPOP".
  Система CUP не предусматривает возможность двухстадийной оплаты.
  

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

Использование UPOP и электронной коммерции

Если магазин использует "UPOP" наряду с электронной коммерцией, то при создании платёжной страницы помимо стандартных требований, описанных в документе "Оформление платёжной страницы", добавляется требование разместить на странице элемент-кнопку:
<input type="button" class="alfaclick" id="buttonPaymentUpop" value="Оплатить через UPOP" />"
По нажатию кнопки выполняется запрос проведения оплаты с помощью UPOP. Описание запроса представлено в разделах:

• Запрос оплаты через внешнюю платёжную систему" (WS),

• Запрос оплаты через внешнюю платёжную систему" (REST).
  Также существует возможность загрузки магазину стандартной платёжной страницы, где уже размещена кнопка для перехода к оплате через UPOP.
  Ниже описан основной процесс оплаты через систему CUP (не учитываются негативные сценарии):
  
  

• 1. Клиент формирует заказ и подтверждает его;
• 2. После подтверждения заказа клиентом магазин регистрирует заказ в РБС. Для регистрации используются такие параметры как сумма списания, номер заказа в системе магазина (буквенно-цифровое значение длиной от 8-ми до 32-х символов), а также URL возврата клиента. Спецификация запроса представлена в разделах:
• Запрос регистрации заказа (WS), (в случае оплаты через UPOP номер заказа в системе магазина должен быть буквенно-цифровым значением длиной от 8-ми до 32-х символов);
• Запрос регистрации заказа (REST), (в случае оплаты через UPOP номер заказа в системе магазина должен быть буквенно-цифровым значением длиной от 8-ми до 32-х символов).
• 3. РБС возвращает ID заказа и URL перенаправления клиента на платёжную форму.
• 4. Магазин передаёт клиенту redirect на URL, полученный на шаге 3.
• 5. Клиент открывает полученный URL, запрашивая платёжную форму.
• 6. Клиент перенаправляется на платёжную страницу, принадлежащую Банку. На платёжной странице отображается доступный способ оплаты через UPOP (кнопка "Оплата через UPOP").
• 7. Клиент выбирает оплату через UPOP (нажимает кнопку).
• 8. истема РБС запрашивает оплату заказа в платёжном шлюзе UPOP.
• 9. Система UPOP запрашивает у клиента данные для проведения оплаты.
• 10. Клиент отправляет свои данные.
• 11. Система UPOP проводит платёж.
• 12. Клиент перенаправляется на страницу с результатом платежа.
• 13. Клиент перенаправляется на страницу с результатом платежа.
• 14. Система РБС вызывает систему UPOP для проверки статуса оплаты.
• 15. Система UPOP проверяет результат оплаты и возвращает его в систему РБС.
• 16. Обновляется статус Заказа в системе РБС.
• 17. Результат отображается Клиенту.

Использование только UPOP

Ниже описан основной процесс оплаты через систему CUP (без негативных сценариев) в случае, если магазин принимает оплату только через систему CUP:

• 1. Клиент формирует заказ на сайте магазина.
• 2.

  После подтверждения заказа клиентом магазин регистрирует заказ в РБС. Для регистрации используются такие параметры как сумма списания, номер заказа в системе магазина (буквенно-цифровое значение длиной от 8-ми до 32-х символов), а также URL возврата клиента. Спецификация запроса представлена в разделах:
  

  • Запрос регистрации заказа (WS), (в случае оплаты через UPOP номер заказа в системе магазина должен быть буквенно-цифровым значением длиной от 8-ми до 32-х символов);
  • Запрос регистрации заказа (REST), (в случае оплаты через UPOP номер заказа в системе магазина должен быть буквенно-цифровым значением длиной от 8-ми до 32-х символов).
• 3. РБС возвращает ID заказ.
• 4.

  Магазин отправляет в РБС запрос оплаты заказа через UPOP, передавая ID заказа, полученный на шаге 3. Для этого используется запрос оплаты альтернативным способом с обязательной передачей значения UPOP в параметре paymentWay, а также ID заказа. Спецификация запроса представлена в разделах:
  

  • "Запрос оплаты через внешнюю платёжную систему" (SOAP),
  • "Запрос оплаты через внешнюю платёжную систему" (REST).
• 5. В ответ платёжный шлюз присылает URL для перенаправления клиента в систему CUP.
• 6. Браузеру клиента передаётся редирект в систему CUP.
• 7.

  Браузер клиента запрашивает форму авторизации с передачей параметров:
  

  • ID заказа (получен на шаге 3);
  • BackURL для возврата на страницу запроса статуса заказа (переданный в запросе регистрации заказа на шаге 2).
• 8. Клиент получает форму авторизации в системе CUP.
• 9. Клиент заполняет и отправляет форму в систему CUP.
• 10. Система UPOP проводит платёж.
• 11. Клиент перенаправляется на страницу с результатом платежа.
• 12. Клиент перенаправляется на страницу с результатом платежа.
• 13. Система РБС вызывает систему UPOP для проверки статуса оплаты.
• 14. Система UPOP проверяет результат оплаты и возвращает его в систему РБС.
• 15. Обновляется статус заказа в системе РБС.
• 16. Результат отображается клиенту.

Тестирование оплаты через UPOP

Процесс тестирования

Чтобы протестировать проведение оплаты через UPOP:

• 1. Зарегистрируйте заказ в платёжном шлюзе. Регистрацию заказа можно осуществить с помощью REST / SOAP (номер заказа в системе магазина, передаваемый в запросе регистрации заказа, должен быть буквенно-цифровым значением длиной от 8-ми до 32-х символов).
• 2.

  Переход в систему CUP осуществляется:
  

  • После нажатия кнопки "Оплатить через UPOP" на платёжной странице, если клиент был на неё перенаправлен после регистрации заказа,
  • После отправки запроса проведения оплаты через UPOP (REST / SOAP).
• 3.

  Откроется страница авторизации в системе CUP по адресу http://202.101.25.184/beta/index.action?transNumber=201311062352028710592:
  
  

• 4. Введите номер карты и нажмите "Next". Реквизиты тестовых карт приведены в следующем разделе.
• 5.

  Откроется страница подтверждения:
  
  

• 6. Введите PIN-код и SMS-код подтверждения.
• 7.

  Нажмите "Confirm and Pay". Откроется страница с результатом оплаты:
  
  По нажатии кнопки Return Merchant происходит перенаправление обратно на страницу магазина, указанную при регистрации заказа в параметре returnUrl (если регистрация делалась посредством REST/ SOAP), либо в параметре адрес возврата (при регистрации через форму).
  

• 8. После этого оплата считается формально завершённой. При возврате на сайт магазина после оплаты в системе CUP не передается статус платежа. Поэтому магазину для уточнения статуса оплаты необходимо опрашивать систему РБС через стандартный запрос состояния заказа (getOrderStatus) и ожидать, когда заказ перейдёт в состояние DEPOSITED (средства списаны).

Тестовые карты China UnionPay

Карты, представленные в данном разделе, предназначены только для тестирования оплаты через UPOP:
Дебетовые карты:

Карта, выпущенная за пределами Китая:

Возврат средств оплаты заказов, оплаченных с помощью UPOP

Полный или частичный возврат по заказам, оплаченным через UPOP, осуществляется стандартными средствами:

• Через административную консоль (описание представлено в документе "Инструкция по работе с консолью", раздел "Работа с заказами");

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

  • Запрос возврата средств оплаты заказа" (WS),

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

Оплата с использованием 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 (Готово).

Данное значение необходимо указать в поле Apple Id в личном кабинете интерент-эквайринга в разделе "Работа с ключами Apple Pay"

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

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

• 1. В личном кабинете Member Center (Партнёрской центр) Apple перейдите в раздел Certificates, Identifiers & Profiles (Сертификаты, идентификаторы и профили).
• 2. На отобразившейся странице в секции Identifiers (Идентификаторы) слева выберите Merchant IDs (Идентификаторы продавцов).
• 3. Выберите свой Merchant ID (Идентификатор продавца) из списка и нажмите Edit (Редактировать).
• 4. Нажмите Create Certificate (Создать сертификат) в блоке Apple Pay Payment Processing Certificate (Сертификат Apple Pay), после чего нажмите 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:

• Запрос на оплату через Apple Pay (WS).
• Запрос на оплату через Apple Pay (REST).

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

• Запрос на проведение рекуррентных платежей через Apple Pay (WS).

• Запрос на проведение рекуррентных платежей через Apple Pay (REST).
  При использовании запроса recurrentPayment не используется процедура зашифрования и расшифрования данных о платеже.
  

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

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

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

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

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

  • Одностадийная оплата:
    

    • Запрос регистрации заказа (WS),
    • Запрос регистрации заказа (REST).

  • Двухстадийная оплата:
    

    • Запрос регистрации заказа с предавторизацией (WS) ,
    • Запрос регистрации заказа с предавторизацией (REST) .
• 3. Платёжный шлюз возвращает уникальный номер заказа в системе платёжного шлюза и URL-адрес на который необходимо перенаправить клиента.
• 4. Система магазина перенаправляет браузер клиента на URL-адрес полученный на шаге 3.
• 5. Браузер клиента открывает URL-адрес.
• 6. В качестве страницы по указанному URL-адресу браузер клиента получает платёжную форму.
• 7. Клиент выбирает способ оплаты Apple Pay (кнопка отображается на устройствах, которые поддерживают оплату Apple Pay).
• 8. Происходит обмен данными между платёжным шлюзом и системой Apple Pay - платёжный шлюз получает платёжные данные.
• 9. Платёжный шлюз производит оплату.
• 10. Клиента перенаправляют на финальную страницу магазина.
• 11. Браузер клиента открывает финальную страницу.
• 12. Статус отображается показывается клиенту.

Оплата с использованием 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 токен:
  

  • Запрос на оплату Google Pay (WS);
  • Запрос на оплату Google Pay (REST).
• 10. Платёжный шлюз расшифровывает полученный токен и производит оплату.
• 11. Платёжный шлюз возвращает результат оплаты в приложение.
• 12. Приложение отображает результат оплаты клиенту.

Сценарий оплаты с перенаправлением пользователя в ACS

• 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 токен:
  

  • Запрос на оплату Google Pay (WS);
  • Запрос на оплату Google Pay (REST).
• 10. Платёжный шлюз расшифровывает полученный токен и проверяет карту, токенизирована она или нет.
• 11. При условии, что карта вовлечена в 3-D Secure, платёжный шлюз отправляет ответ на запрос на оплату, в котором содержится ссылка перенаправления на сервер ACS.
• 12. Пользователя перенаправляет на сайт ACS.
• 13.

  Пользователь переходит на сайт ACS и аутентифицируется.
  

  Чтобы клиент попал на страницу ACS, продавец перенаправляет его на страницу платёжного шлюза следующего вида:
  https://alfa.rbsuat.com/payment/acsRedirect.do?orderId=< >, где < > - уникальный номер заказа клиента.
  

• 14. После успешной аутентификации пользователя перенаправляют с сайта ACS на старницу платёжного шлюза.
• 15. Пользователь переходит на страницу платёжного шлюза.
• 16. Платёжный шлюз возвращает результат оплаты.

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

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

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

• https://developers.google.com/pay/api/android/

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

• https://developers.google.com/pay/api/android/guides/tutorial

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

• https://developers.google.com/pay/api/android/guides/brand-guidelines

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

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

• 1. Клиент формирует заказ на сайте интернет-магазина и выбирает способ оплаты Google Pay.
• 2. Система интернет-магазина формирует запрос на оплату в Google Pay.
• 3. Система Google Pay формирует зашифрованные платёжные данные.
• 4. Система интернет-магазина получает зашифрованные платёжные данные
• 5.

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

  • Запрос на оплату Google Pay (WS);
  • Запрос на оплату Google Pay (REST).
• 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.

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

  • Одностадийная оплата:
    

    • Запрос регистрации заказа (WS),
    • Запрос регистрации заказа (REST).

  • Двухстадийная оплата:
    

    • Запрос регистрации заказа с предавторизацией (WS) ,
    • Запрос регистрации заказа с предавторизацией (REST) .
• 3. Платёжный шлюз возвращает уникальный номер заказа в системе платёжного шлюза и URL-адрес на который необходимо перенаправить клиента.
• 4. Система магазина перенаправляет браузер клиента на URL-адрес полученный на шаге 3.
• 5. Браузер клиента открывает URL-адрес.
• 6. В качестве страницы по указанному URL-адресу браузер клиента получает платёжную форму.
• 7. Клиент выбирает способ оплаты Google Pay и подтверждает свой выбор.
• 8. Происходит обмен данными между платёжным шлюзом и системой Google Pay - платёжный шлюз получает платёжные данные.
• 9. Платёжный шлюз производит оплату.
• 10. Клиента перенаправляют на финальную страницу магазина.
• 11. Браузер клиента открывает финальную страницу.
• 12. Статус отображается показывается клиенту.

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

Предварительные действия

Перед тем, как принимать платежи через Samsung Pay, продавец должен зарегистрироваться на партнёрском портале Samsung. После этого в личном кабинете платёжного шлюза продавец должен сгенерировать ключевую пару, экспортировать запрос подписи сертификата и загрузить его на партнёрском портале Samsung.

Схема с использованием мобильного приложения

Ниже представлена схема взаимодействия при проведения платежа с использованием мобильного приложения.

• 1. Плательщик выбирает способ оплаты Samsung Pay.
• 2. Приложение отправляет сведения о платеже в Samsung.
• 3. Samsung проверяет приложение.
• 4. Samsung отправляет в приложение ответ содержащий, среди прочего, парамер 3ds.data с зашифрованными данными о платеже.
• 5. Продавец отправляет запрос на оплату в платёжный шлюз, при этом в параметр paymentToken включает содержимое 3ds.data, полученное от Samsung:
• Запрос на оплату через Samsung Pay (WS).
• Запрос на оплату через Samsung Pay (REST).
• 6. Платёжный шлюз расшифровывает содержимое paymentToken и производит оплату.
• 7. Платёжный шлюз отправляет в приложение результатом оплаты.
• 8. Приложение отображает плательщику результат оплаты.