Описание схем взаимодействия
Одностадийные платежи
Сценарий оплаты заказа (1)
Одностадийная схема оплаты картой:
Клиент оформляет заказ на ресурсе мерчанта и выбирает способ оплаты банковской картой.
После того как выбран способ оплаты банковской картой, в сторону платёжного шлюза должен быть отправлен запрос регистрации заказа. Для регистрации используются такие параметры как сумма списания, номер заказа в системе магазина, а также URL возврата клиента. Спецификация запроса представлена в разделе: Запрос регистрации заказа (REST).
В ответе на запрос регистрации платёжный шлюз возвращает уникальный идентификатор заказа в платёжной системе (в параметре orderId) и URL, на который необходимо перенаправить пользователя для получения платёжной формы (в параметре formUrl).
Система магазина должна передать браузеру клиента redirect на URL, полученный от платёжного шлюза в параметре formUrl в ответ на запрос регистрации заказа.
Браузер клиента открывает полученный URL.
Клиент получает платёжную форму.
Пользователь заполняет полученную форму реквизитами карты и отправляет данные на сервер платёжного шлюза.
Детали заказа передаются в систему фрод-конроля для определения вероятности мошенничества. Проверка проводится при помощи набора автоматических правил. Результатом применения правила является добавление к заказу коэффициента вероятности мошенничества (фрод-веса). Каждое правило имеет свой фрод-вес, который представляет собой число в диапазоне от 0 до 100. (Если суммарный фрод-вес заказа по всем применённым к заказу правилам превышает 100, такой заказ считается фродовым и оплата по нему будет отклонена.)
В платёжный шлюз возвращаются результаты проверки заказа на мошенничество. В том случае, если в соответствии с настройками магазина платёж должен идти по SSL, то выполняется следующий шаг сценария (10).
Если в соответствии с настройками магазина платёж должен быть 3DS, то будут выполнены следующие действия:- •
Платёжный шлюз производит проверку вовлечённости карты в 3-D Secure.
Если авторизации на ACS для данной карты не требуется, то выполняется следующий шаг сценария (10).
Если необходима авторизация на ACS, то будут выполнены следующие действия:Шлюз отправляет браузеру клиента redirect на страницу ACS банка эмитента.
Браузер клиента запрашивает у ACS форму авторизации пользователя (у каждого эмитента это делается по-своему)
ACS отправляет в браузер клиента форму авторизации.
Клиент заполняет форму авторизации и отправляет её в ACS.
ACS обрабатывает заполненную форму и вне зависимости от результата передаёт браузеру redirect на URL страницы платёжного шлюза. Вместе с этим URL передаются зашифрованные параметры результата авторизации.
Браузер клиента запрашивает страницу платёжного шлюза, передавая зашифрованные параметры результата авторизации. Если авторизация прошла успешно, то выполняется следующий шаг сценария.
Платёжный шлюз производит оплату (списание денежных средств со счёта клиента)
После проведения оплаты платёжный шлюз передаёт браузеру клиента URL возврата на страницу магазина (указанный ранее магазином при регистрации заказа, см. шаг 2).
Браузер клиента запрашивает страницу с результатами оплаты у магазина.
Система магазина запрашивает у платёжного шлюза статус оплаты заказа (по уникальному идентификатору заказа в платёжной системе, который был получен при регистрации заказа в параметре orderId).
Спецификация обычного запроса состояния заказа представлена в разделе: Запрос состояния заказа (REST).
Спецификация расширенного запроса состояния заказа представлена в разделе: Расширенный запрос состояния заказа (REST).платёжный шлюз возвращает статус оплаты.
Система магазина передаёт в браузер клиента страницу с результатами оплаты — успешный платёж или неуспешный.
Отмена оплаты заказа (1)
Отмена оплаты заказа доступна магазинам при наличии соответствующих прав (по согласованию с банком). При одностадийных платежах отмена платежа возможна для заказов в состоянии «Завершён» / «Deposited». Отмена оплаты заказа осуществляется стандартными средствами:
- •
Через административную консоль (описание представлено в документе «Инструкция по работе с консолью», раздел «Работа с заказами»);
- •
С помощью API, посредством интерфейсов REST. Спецификация запроса представлена в разделе: Запрос отмены оплаты заказа (REST).
В случае успешной операции отмены заказ будет переведён из состояния «Завершён"/"Deposited» в состояние «Отменён"/"Reversed».
Возврат средств оплаты заказа (1)
Полный или частичный возврат по оплаченным заказам (в состоянии «Завершён"/"Deposited») осуществляется стандартными средствами:
- •
Через административную консоль (описание представлено в документе «Инструкция по работе с консолью», раздел «Работа с заказами»);
- •
С помощью API, посредством интерфейсов REST. Спецификация запроса представлена в разделе: Запрос возврата средств оплаты заказа (REST).
После того, как в РБС приходит запрос на возврат средств, отправленный одним из указанных выше способов, РБС осуществляет возврат указанной суммы на счёт клиента.
Проверка вовлечённости карты в 3DS (1)
Система позволяет магазину при необходимости самостоятельно проверить вовлечённость банковской карты в 3-D Secure. Это можно сделать с помощью API, посредством интерфейсов REST. Спецификация запроса представлена в разделе: Запрос проверки вовлечённости карты в 3DS (REST).
Добавление в заказ дополнительных параметров (1)
Система позволяет в случае необходимости добавить в заказ дополнительные параметры. Это можно сделать с помощью API, посредством интерфейсов REST. Спецификация запроса представлена в разделе: Запрос добавления дополнительных параметров к заказу (REST).
Статистика по платежам за определённый период (1)
Система позволяет формировать статистику по платежам за определённый период с помощью API, посредством интерфейсов REST. Спецификация запроса представлена в разделе: Запрос статистики по платежам за период (REST).
Двухстадийные платежи
Сценарий оплаты заказа (2)
Двухстадийная схема оплаты картой:
Клиент оформляет заказ на ресурсе мерчанта и выбирает способ оплаты банковской картой.
После того как выбран способ оплаты банковской картой, в сторону платёжного шлюза должен быть отправлен запрос регистрации заказа с предавторизацией. Для регистрации используются такие параметры как сумма списания, номер заказа в системе магазина, а также URL возврата клиента. Спецификация запроса представлена в разделе: Запрос регистрации заказа с предавторизацией (REST).
В ответе на запрос регистрации платёжный шлюз возвращает уникальный идентификатор заказа в платёжной системе (в параметре orderId) и URL, на который необходимо перенаправить пользователя для получения платёжной формы (в параметре formUrl).
Система магазина должна передать браузеру клиента redirect на URL, полученный от платёжного шлюза в параметре formUrl в ответ на запрос регистрации заказа.
Браузер клиента открывает полученный URL.
Клиент получает платёжную форму.
Пользователь заполняет полученную форму реквизитами карты и отправляет данные на сервер платёжного шлюза.
Детали заказа передаются в систему фрод-конроля для определения вероятности мошенничества. Проверка проводится при помощи набора автоматических правил. Результатом применения правила является добавление к заказу коэффициента вероятности мошенничества (фрод-веса). Каждое правило имеет свой фрод-вес, который представляет собой число в диапазоне от 0 до 100. (Если суммарный фрод-вес заказа по всем применённым к заказу правилам превышает 100, такой заказ считается фродовым и оплата по нему будет отклонена.)
В платёжный шлюз возвращаются результаты проверки заказа на мошенничество. В том случае, если в соответствии с настройками магазина платёж должен идти по SSL, то выполняется следующий шаг сценария (10). Если в соответствии с настройками магазина платёж должен быть 3DS, то будут выполнены следующие действия:
- •
Платёжный шлюз производит проверку по номеру карты, чтобы определить, требуется ли применение технологии 3-D Secure при проведении платежа.
Если авторизации на ACS для данной карты не требуется, то выполняется следующий шаг сценария (10).
Если необходима авторизация на ACS, то будут выполнены следующие действия:Шлюз отправляет браузеру клиента redirect на страницу ACS банка эмитента.
Браузер клиента запрашивает у ACS форму авторизации пользователя (у каждого эмитента это делается по-своему)
ACS отправляет в браузер клиента форму авторизации.
Клиент заполняет форму и отправляет её в ACS.
ACS обрабатывает заполненную форму и вне зависимости от результата передаёт браузеру redirect на URL страницы платёжного шлюза. Вместе с этим URL передаются зашифрованные параметры результата авторизации.
Браузер клиента запрашивает страницу платёжного шлюза, передавая зашифрованные параметры результата авторизации. Если авторизация прошла успешно, то выполняется следующий шаг сценария.
платёжный шлюз производит авторизацию платежа (холдирование средств на карточном счёте клиента).
После проведения оплаты платёжный шлюз передаёт браузеру клиента URL возврата на страницу магазина (указанный ранее магазином при регистрации заказа, см. шаг 2).
Браузер клиента запрашивает страницу с результатами оплаты у магазина.
Система магазина запрашивает у платёжного шлюза статус оплаты заказа (по уникальному идентификатору заказа в платёжной системе, который был получен при регистрации заказа в параметре orderId).
Спецификация обычного запроса состояния заказа представлена в разделе: Запрос состояния заказа (REST).
Спецификация расширенного запроса состояния заказа представлена в разделе: Расширенный запрос состояния заказа (REST).Платёжный шлюз возвращает статус оплаты.
Система магазина передаёт в браузер клиента страницу с результатами оплаты — успешный платёж или неуспешный.
Для списания средств со счёта клиента магазин должен направить в платёжный шлюз запрос завершения оплаты. Спецификация запроса представлена в разделе: Запрос завершения оплаты заказа (REST).
Платёжный шлюз возвращает результат обработки запроса. Статус заказа не возвращается. Для получения заказа необходимо отправить в шлюз соответствующий запрос, как описано на шаге 13.
Отмена оплаты заказа (2)
Отмена оплаты заказа доступна магазинам при наличии соответствующих прав (по согласованию с банком). . При двухстадийных платежах отмену платежа можно выполнить для заказа в состоянии «Подтверждён"/"Approved». Отмена оплаты заказа осуществляется стандартными средствами:
- •
Через административную консоль (описание представлено в документе «Инструкция по работе с консолью», раздел «Работа с заказами»);
- •
С помощью API, посредством интерфейсов REST. Спецификация запроса представлена в разделе: Запрос отмены оплаты заказа (REST).
В случае успешной операции отмены заказ будет переведён из состояния «Подтверждён"/"Approved» в состояние «Отменён"/"Reversed».
Возврат средств оплаты заказа (2)
Полный или частичный возврат по оплаченным заказам (в состоянии «Завершён"/"Deposited») осуществляется стандартными средствами:
- •
Через административную консоль (описание представлено в документе «Инструкция по работе с консолью», раздел «Работа с заказами»);
- •
С помощью API, посредством интерфейсов REST. Спецификация запроса представлена в разделе: Запрос возврата средств оплаты заказа (REST).
После того, как в РБС приходит запрос на возврат средств, отправленный одним из указанных выше способов, РБС осуществляет возврат указанной суммы на счёт клиента. (2)
Проверка вовлечённости карты в 3DS (2)
Система позволяет магазину при необходимости самостоятельно проверить вовлечённость банковской карты в 3-D Secure. Это можно сделать с помощью API, посредством интерфейсов REST. Спецификация запроса представлена в разделе: Запрос проверки вовлечённости карты в 3DS (REST).
Добавление в заказ дополнительных параметров (2)
Система позволяет в случае необходимости добавить в заказ дополнительные параметры. Это можно сделать с помощью API, посредством интерфейсов REST. Спецификация запроса представлена в разделе: Запрос добавления дополнительных параметров к заказу (REST).
Статистика по платежам за определённый период (2)
(2) Система позволяет формировать статистику по платежам за определённый период с помощью API, посредством интерфейсов REST. Спецификация запроса представлена в разделе: Запрос статистики по платежам за период (REST).
Одностадийные автоплатежи
Сценарий проведения первоначального платежа (1)
Клиент оформляет заказ на ресурсе магазина и выбирает способ оплаты банковской картой.
После того как выбран способ оплаты банковской картой, в сторону платёжного шлюза должен быть отправлен запрос регистрации заказа с обязательной передачей уникального идентификатора клиента в параметре clientId. Для регистрации также используются такие параметры как сумма списания, номер заказа в системе магазина, URL возврата клиента. Спецификация запроса представлена в разделе: Запрос регистрации заказа (REST).
В ответе на запрос регистрации платёжный шлюз возвращает уникальный идентификатор заказа в платёжной системе (в параметре orderId) и URL, на который необходимо перенаправить пользователя для получения платёжной формы (в параметре ответа formUrl).
Система магазина должна передать браузеру клиента redirect на URL, полученный от платёжного шлюза в параметре formUrl в ответ на запрос регистрации заказа.
Браузер клиента открывает полученный URL.
Клиент получает платёжную форму.
Клиент заполняет полученную форму реквизитами карты и отправляет данные на сервер платёжного шлюза.
Детали заказа передаются в систему фрод-конроля для определения вероятности мошенничества. Проверка проводится при помощи набора автоматических правил. Результатом применения правила является добавление к заказу коэффициента вероятности мошенничества (фрод-веса). Каждое правило имеет свой фрод-вес, который представляет собой число в диапазоне от 0 до 100. (Если суммарный фрод-вес заказа по всем применённым к заказу правилам превышает 100, такой заказ считается фродовым и оплата по нему будет отклонена.)
В платёжный шлюз возвращаются результаты проверки заказа на мошенничество.
Платёжный шлюз производит проверку вовлечённости карты в 3-D Secure.
Если авторизации на ACS не требуется, то выполняется следующий шаг сценария (11).
Если необходима авторизация на ACS, то будут выполнены следующие действия:Шлюз отправляет браузеру клиента redirect на страницу ACS банка эмитента.
Браузер клиента запрашивает у ACS форму авторизации пользователя (у каждого эмитента это делается по-своему).
ACS отправляет в браузер клиента форму авторизации.
Клиент заполняет форму авторизации и отправляет её в ACS.
ACS обрабатывает заполненную форму и вне зависимости от результата передаёт браузеру redirect на URL страницы платёжного шлюза. Вместе с этим URL передаются зашифрованные параметры результата авторизации.
Браузер клиента запрашивает страницу платёжного шлюза, передавая зашифрованные параметры результата авторизации. Если авторизация прошла успешно, то выполняется следующий шаг сценария.
Платёжный шлюз производит оплату (списание денежных средств со счёта клиента).
В случае успешной оплаты в платёжном шлюзе будет создана связка (данные карты, которая использовалась для оплаты, привязываются к идентификатору клиента, переданному на шаге 2 в параметре clientId).
После проведения оплаты платёжный шлюз передаёт браузеру клиента URL возврата на страницу магазина (указанный ранее магазином при регистрации заказа, см. шаг 2).
Браузер клиента запрашивает страницу с результатами оплаты у магазина.
Система магазина запрашивает у платёжного шлюза статус заказа (по уникальному идентификатору заказа в платёжной системе, который был получен на шаге 3 в параметре orderId).
Спецификация обычного запроса состояния заказа представлена в разделе: Запрос состояния заказа (REST).
Спецификация расширенного запроса состояния заказа представлена в разделе: Расширенный запрос состояния заказа (REST).Платёжный шлюз возвращает статус оплаты заказа (в параметре orderStatus), а также уникальный идентификатор связки (в параметре bindingId).
Система магазина передаёт в браузер клиента страницу с результатами оплаты — успешный платёж или неуспешный.
После успешного проведения первоначального платежа магазин на своей стороне подключает клиенту услугу «Автоплатеж» (определяет дату и сумму списания для данного клиента). В дальнейшем магазин самостоятельно отслеживает дату, когда необходимо провести очередной автоплатёж, и инициирует оплату по идентификатору связки.
Сценарий проведения автоплатежа (1)
Когда наступает дата очередного автоплатежа, магазин инициирует оплату по следующему сценарию:
В сторону платёжного шлюза должен быть отправлен запрос регистрации заказа с обязательной передачей уникального идентификатора клиента в параметре clientId. Для регистрации также используются такие параметры как сумма списания, номер заказа в системе магазина, URL возврата клиента. Спецификация запроса представлена в разделе: Запрос регистрации заказа (REST).
В ответе на запрос регистрации платёжный шлюз возвращает уникальный идентификатор заказа в платёжной системе (в параметре orderId).
Магазин отправляет запрос оплаты заказа с помощью связки, передавая номер заказа в платёжной системе, полученный на предыдущем шаге, и идентификатор связки, полученный после совершения первоначального платежа. Спецификация запроса представлена в разделе: Запрос проведения платежа по связке (REST).
Платёжный шлюз производит оплату (списание денежных средств со счёта клиента).
Система магазина запрашивает у платёжного шлюза статус заказа (по уникальному идентификатору заказа в платёжной системе, который был получен на шаге 2 в параметре orderId).
Спецификация обычного запроса состояния заказа представлена в разделе: Запрос состояния заказа (REST).
Спецификация расширенного запроса состояния заказа представлена в разделе: Расширенный запрос состояния заказа (REST).Платёжный шлюз возвращает статус оплаты (в параметре orderStatus).
Получение списка связок клиента (1)
Магазин может получить список идентификаторов существующих связок для определённого clientId, отправив в платёжный шлюз соответствующий запрос. Спецификация запроса представлена в разделе: Запрос списка связок клиента (REST).
Деактивация/активация существующей связки (1)
Система позволяет магазинам при необходимости деактивировать существующие свзяки с помощью API, посредством интерфейсов REST. Спецификация запроса представлена в разделе: Запрос деактивации связки (REST).
В дальнейшем деактивированная связка может быть снова активирована. Для этого магазин должен направить в платёжный шлюз соответствующий запрос. Спецификация запроса представлена в разделе: Запрос активации связки (REST).
Изменение срока действия связки (1)
Изменение срока действия связки может потребоваться в случае перевыпуска карты клиента. Сделать это можно с помощью API, посредством интерфейсов REST. Спецификация запроса представлена в разделе: Запрос изменения срока действия связки (REST).
Двухстадийные автоплатежи
Сценарий проведения первоначального платежа (2)
Клиент оформляет заказ на ресурсе мерчанта и выбирает способ оплаты банковской картой.
После того как выбран способ оплаты банковской картой, в сторону платёжного шлюза должен быть отправлен запрос предварительной регистрации заказа с обязательной передачей уникального идентификатора клиента в параметре clientId. Для регистрации также используются такие параметры как сумма списания, номер заказа в системе магазина, URL возврата клиента. Спецификация запроса представлена в разделе: Запрос регистрации заказа с предавторизацией (REST).
В ответе на запрос регистрации платёжный шлюз возвращает уникальный идентификатор заказа в платёжной системе (в параметре orderId) и URL, на который необходимо перенаправить пользователя для получения платёжной формы (в параметре ответа formUrl).
Система магазина должна передать браузеру клиента redirect на URL, полученный от платёжного шлюза в параметре formUrl в ответ на запрос регистрации заказа.
Браузер клиента открывает полученный URL
Клиент получает платёжную форму.
Клиент заполняет полученную форму реквизитами карты и отправляет данные на сервер платёжного шлюза.
Детали заказа передаются в систему фрод-конроля для определения вероятности мошенничества. Проверка проводится при помощи набора автоматических правил. Результатом применения правила является добавление к заказу коэффициента вероятности мошенничества (фрод-веса). Каждое правило имеет свой фрод-вес, который представляет собой число в диапазоне от 0 до 100. (Если суммарный фрод-вес заказа по всем применённым к заказу правилам превышает 100, такой заказ считается фродовым и оплата по нему будет отклонена.)
В платёжный шлюз возвращаются результаты проверки заказа на мошенничество.
Получив платёжные реквизиты, платёжный шлюз производит проверку вовлечённости карты в 3-D Secure.
Если авторизации на ACS не требуется, то выполняется следующий шаг сценария (11).
Если необходима авторизация на ACS, то будут выполнены следующие действия:Шлюз отправляет браузеру клиента redirect на страницу ACS банка эмитента.
Браузер клиента запрашивает у ACS форму авторизации пользователя (у каждого эмитента это делается по-своему).
ACS отправляет в браузер клиента форму авторизации.
Клиент заполняет форму авторизации и отправляет её в ACS.
ACS обрабатывает заполненную форму и вне зависимости от результата передаёт браузеру redirect на URL страницы платёжного шлюза. Вместе с этим URL передаются зашифрованные параметры результата авторизации.
Браузер клиента запрашивает страницу платёжного шлюза, передавая зашифрованные параметры результата авторизации. Если авторизация прошла успешно, то выполняется следующий шаг сценария.
Платёжный шлюз производит оплату (холдирование средств на карточном счёте клиента).
В случае успешного холдирования суммы на карте в платёжном шлюзе будет создана связка (данные карты, которая использовалась для оплаты, привязываются к идентификатору клиента, переданному на шаге 2 в параметре clientId).
После проведения оплаты платёжный шлюз передаёт браузеру клиента URL возврата на страницу магазина (указанный ранее магазином при регистрации заказа, см. шаг 2).
Браузер клиента запрашивает страницу с результатами оплаты у магазина.
Система магазина запрашивает у платёжного шлюза статус заказа (по уникальному идентификатору заказа в платёжной системе, который был получен на шаге 3 в параметре orderId).
Спецификация обычного запроса состояния заказа представлена в разделе: Запрос состояния заказа (REST).
Спецификация расширенного запроса состояния заказа представлена в разделе: Расширенный запрос состояния заказа (REST).Платёжный шлюз возвращает статус оплаты заказа (в параметре orderStatus), а также уникальный идентификатор связки (в параметре bindingId).
Система магазина передаёт в браузер клиента страницу с результатами оплаты — успешный платёж или неуспешный.
Для списания захолдированных средств со счёта клиента магазин должен направить в платёжный шлюз запрос завершения оплаты. Спецификация запроса представлена в разделе: Запрос завершения оплаты заказа (REST).
Платёжный шлюз возвращает результат обработки запроса. Статус заказа не возвращается. Для получения заказа необходимо отправить в шлюз соответствующий запрос, как описано на шаге 15. После успешного проведения первоначального платежа магазин на своей стороне подключает клиенту услугу «Автоплатеж» (определяет дату и сумму списания для данного клиента). В дальнейшем магазин самостоятельно отслеживает дату, когда необходимо провести очередной автоплатёж, и инициирует оплату по идентификатору связки.
Сценарий проведения автоплатежа (2)
Когда наступает дата очередного автоплатежа, магазин инициирует оплату по следующему сценарию:
В сторону платёжного шлюза должен быть отправлен запрос предварительной регистрации заказа с обязательной передачей уникального идентификатора клиента в параметре clientId. Для регистрации также используются такие параметры как сумма списания, номер заказа в системе магазина, URL возврата клиента. Спецификация запроса представлена в разделе: Запрос регистрации заказа с предавторизацией (REST).
В ответе на запрос регистрации платёжный шлюз возвращает уникальный идентификатор заказа в платёжной системе (в параметре orderId).
Магазин отправляет запрос оплаты заказа с помощью связки, передавая номер заказа в платёжной системе, полученный на предыдущем шаге, и идентификатор связки, полученный после совершения первоначального платежа. Спецификация запроса представлена в разделе: Запрос проведения платежа по связке (REST).
Платёжный шлюз производит оплату (холдирование средств на карточном счёте клиента) и возвращает результат обработки запроса. Статус заказа не возвращается. Для получения заказа необходимо отправить в шлюз соответствующий запрос.
Спецификация обычного запроса состояния заказа представлена в разделе: Запрос состояния заказа (REST).
Спецификация расширенного запроса состояния заказа представлена в разделе: Расширенный запрос состояния заказа (REST).Платёжный шлюз возвращает статус заказа (в параметре orderStatus).
Для списания средств со счёта клиента магазин должен направить в платёжный шлюз запрос завершения оплаты. Спецификация запроса представлена в разделе: Запрос завершения оплаты заказа (REST).
Платёжный шлюз возвращает результат обработки запроса. Статус заказа не возвращается. Для получения заказа необходимо отправить в шлюз соответствующий запрос, как описано на шаге 4.
Получение списка связок клиента (2)
Магазин может получить список идентификаторов существующих связок для определённого clientId, отправив в платёжный шлюз соответствующий запрос. Спецификация запроса представлена в разделе: Запрос списка связок клиента (REST).
Деактивация/активация существующей связки (2)
Система позволяет магазинам при необходимости деактивировать существующие свзяки с помощью API, посредством интерфейсов REST. Спецификация запроса представлена в разделе: Запрос деактивации связки (REST).
В дальнейшем деактивированная связка может быть снова активирована. Для этого магазин должен направить в платёжный шлюз соответствующий запрос. Спецификация запроса представлена в разделе: Запрос активации связки (REST).
Изменение срока действия связки (2)
Изменение срока действия связки может потребоваться в случае перевыпуска карты клиента. Сделать это можно с помощью API, посредством интерфейсов REST. Спецификация запроса представлена в разделе: Запрос изменения срока действия связки (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>
Сценарий оплаты заказа
Клиент оформляет заказ на ресурсе мерчанта и выбирает способ оплаты банковской картой.
После того как выбран способ оплаты банковской картой, в сторону платёжного шлюза должен быть отправлен запрос регистрации заказа с обязательной передачей уникального идентификатора клиента в параметре clientId. Для регистрации также используются такие параметры как сумма списания, номер заказа в системе магазина, URL возврата клиента. Спецификация запроса представлена в разделе: Запрос регистрации заказа (REST).
В ответе на запрос регистрации платёжный шлюз возвращает уникальный идентификатор заказа в платёжной системе (в параметре orderId) и URL, на который необходимо перенаправить пользователя для получения платёжной формы (в параметре ответа formUrl).
Система магазина должна передать браузеру клиента redirect на URL, полученный от платёжного шлюза в параметре formUrl в ответ на запрос регистрации заказа.
Браузер клиента открывает полученный URL.
Клиент получает платёжную форму.
В том случае, если для данного clientIdещё не создано связки, клиент заполняет полученную форму реквизитами карты и ставит галочку «Запомнить данные этой карты». Затем клиент отправляет данные на сервер платёжного шлюза.
Если для данного clientId существуют одна или несколько привязанных карт, то они отображаются в выпадающем списке в поле для ввода PAN. Клиент выбирает нужную карту (также есть возможность внести реквизиты новой карты). Затем клиент отправляет данные на сервер платёжного шлюза.Детали заказа передаются в систему фрод-конроля для определения вероятности мошенничества. Проверка проводится при помощи набора автоматических правил. Результатом применения правила является добавление к заказу коэффициента вероятности мошенничества (фрод-веса). Каждое правило имеет свой фрод-вес, который представляет собой число в диапазоне от 0 до 100. (Если суммарный фрод-вес заказа по всем применённым к заказу правилам превышает 100, такой заказ считается фродовым и оплата по нему будет отклонена.)
В платёжный шлюз возвращаются результаты проверки заказа на мошенничество.
Если настройки магазина требуют проведения SSL-платежа, то выполняется следующий шаг сценария (10).
Если платёж в соответствии с настройками магазина должен быть 3DS, то будут выполнены следующие действия:Получив платёжные реквизиты, платёжный шлюз производит проверку по номеру карты, чтобы определить, требуется ли применение технологии 3-D Secure при проведении платежа. Если применение 3DS-технологии не требуется, то выполняется следующий шаг сценария (10). Если платёж должен быть 3DS, то будут выполнены следующие действия:
Шлюз отправляет браузеру клиента redirect на страницу ACS банка эмитента.
Браузер клиента запрашивает у ACS форму авторизации пользователя (у каждого эмитента это делается по-своему)
ACS отправляет в браузер клиента форму авторизации.
Клиент заполняет авторизации и отправляет её в ACS.
ACS обрабатывает заполненную форму и вне зависимости от результата передаёт браузеру redirect на URL страницы платёжного шлюза. Вместе с этим URL передаются зашифрованные параметры результата авторизации.
Браузер клиента запрашивает страницу платёжного шлюза, передавая зашифрованные параметры результата авторизации. Если авторизация прошла успешно, то выполняется следующий шаг сценария.
Платёжный шлюз производит оплату (списание денежных средств со счёта клиента)
После проведения оплаты платёжный шлюз передаёт браузеру клиента URL возврата на страницу магазина (указанный ранее магазином при регистрации заказа, см. шаг 2).
Браузер клиента запрашивает страницу с результатами оплаты у магазина.
Система магазина запрашивает у платёжного шлюза статус оплаты заказа (по уникальному идентификатору заказа в платёжной системе, который был получен при регистрации заказа в параметре orderId).
Спецификация обычного запроса состояния заказа представлена в разделе: Запрос состояния заказа (REST).
Спецификация расширенного запроса состояния заказа представлена в разделе: Расширенный запрос состояния заказа (REST).платёжный шлюз возвращает статус оплаты.
Система магазина передаёт в браузер клиента страницу с результатами оплаты — успешный платёж или неуспешный.
Получение списка связок клиента
Если на Шаге 5 сценария клиент на платёжной странице ввёл реквизиты новой карты и поставил галочку «Запомнить данные этой карты», то в случае успешной оплаты на стороне платёжного шлюза создаётся уникальный идентификатор связки. Магазин может получить список идентификаторов существующих связок для определённого clientId, отправив в платёжный шлюз соответствующий запрос. Спецификация запроса представлена в разделе: Запрос списка связок клиента» (REST)
Получение списка связок банковской карты
При наличии соответствующих разрешений магазин может запросить список всех связок, относящихся к определённой банковской карте. Сделать это можно по номеру карты или по известному идентификатору связки. Спецификация запроса представлена в разделе: Запрос списка связок банковской карты» (REST).
Деактивация/активация существующей связки
Система позволяет магазинам при необходимости деактивировать существующие свзяки с помощью API, посредством интерфейсов REST. Спецификация запроса представлена в разделе: Запрос деактивации связки» (REST).
В дальнейшем деактивированная связка может быть снова активирована. Для этого магазин должен направить в платёжный шлюз соответствующий запрос. Спецификация запроса представлена в разделе: Запрос активации связки» (REST).
Изменение срока действия связки
Изменение срока действия связки может потребоваться в случае перевыпуска карты клиента. Сделать это можно с помощью API, посредством интерфейсов REST. Спецификация запроса представлена в разделе: Запрос изменения срока действия связки» (REST).
Оплата с использованием Alfa Pay
Термины, определения и сокращения
| Термин | Описание |
|---|---|
| Альфа Банк | АО «Альфа Банк», он же Заказчик, в рамках данного документа допустимо использование сокращения «Банк» |
| Платёжный шлюз (ПШ) | Автоматическая система, предоставляющая магазину принимать, а Клиенту отправлять платежи через интернет с использованием банковских карт. |
| Клиент | Физическое лицо, осуществляющее Платеж. |
| ТСП | Торгово-сервисное предприятие, продающее товары или оказывающее услуги. В рамках данного документа допустимо название Продавец или Мерчант. |
| Формат данных | Требование к формату данных параметров запросов/ответов:
|
Ограничения
Проверка 3DS при оплате методом /alfapay/payment.do НЕ выполняется. Оплата методом Alfa Pay с кастомизированных страниц продавца (не через API ПШ) не поддерживается.
Сценарий работы
Клиент переходит на ПС Продавца.
Клиент нажимает на кнопку оплаты Alfa Pay.
Продавец передаёт в ПШ API-запрос /alfapay/payment.do для регистрации заказа и инициации оплаты. <ссылка на запрос rest>Запрос на оплату Alfa Pay (REST)
ПШ взаимодействует с Сервисом Банка и регистрирует заказ.
ПШ возвращает Продавцу API-ответ с указанием redirect (URL Сервиса Банка) и orderId (идентификатора заказа).
ПС Продавца перенаправляет Клиента на адрес Сервиса Банка, указанный в redirect.
Клиент переходит напрямую в Сервис Банка на адрес redirect и указывает, какую карту использовать при оплате.
Сервис Банка отправляет в ПШ данные карты Клиента.
ПШ выполняет оплату заказа картой.
ПШ возвращает в Сервис Банка ответ, содержащий адрес возврата, указанный в параметре returnURL при регистрации заказа на шаге 3.
Сервис Банка перенаправляет Клиента на адрес возврата.
Клиент переходит на страницу Продавца.
Шаги 13-14 выполняются на усмотрение Продавца.Продавец передаёт в ПШ запрос статуса заказа (стандартный метод getOrderStatusExtended.do). Расширенный запрос состояния заказа (REST).
ПШ возвращает Продавцу информацию о заказе. Продавец отображает Клиенту результат оплаты.