Главная » Apple

Альфа банк оплата apple

Содержание
  1. Как подключить карту Альфа-Банка к Apple Pay
  2. Через мобильное приложение Альфа-Мобайл
  3. С помощью Apple Wallet
  4. Настройка оплаты картой через Apple Pay на Apple Watch
  5. Как пользоваться Apple Pay
  6. Apple Pay интернет-эквайринг
  7. Преимущества
  8. Как это работает?
  9. Как подключить Apple Pay интернет-эквайринг?
  10. Ваши деньги надежно защищены
  11. Заполните заявку
  12. Описание схем взаимодействия
  13. Одностадийные платежи
  14. Сценарий оплаты заказа (1)
  15. Отмена оплаты заказа (1)
  16. Возврат средств оплаты заказа (1)
  17. Проверка вовлечённости карты в 3DS (1)
  18. Добавление в заказ дополнительных параметров (1)
  19. Статистика по платежам за определённый период (1)
  20. Двухстадийные платежи
  21. Сценарий оплаты заказа (2)
  22. Отмена оплаты заказа (2)
  23. Возврат средств оплаты заказа (2)
  24. Проверка вовлечённости карты в 3DS (2)
  25. Добавление в заказ дополнительных параметров (2)
  26. Статистика по платежам за определённый период (2)
  27. Одностадийные автоплатежи
  28. Сценарий проведения первоначального платежа (1)
  29. Сценарий проведения автоплатежа (1)
  30. Получение списка связок клиента (1)
  31. Деактивация/активaция существующей связки (1)
  32. Изменение срока действия связки (1)
  33. Двухстадийные автоплатежи
  34. Сценарий проведения первоначального плaтежа (2)
  35. Сценaрий проведения автоплатежа (2)
  36. Получение списка связок клиента (2)
  37. Деактивация/активaция существующей связки (2)
  38. Изменение срока действия связки (2)
  39. Оплата с помощью связки на платежной странице
  40. Общее описание функционала и дополнение на платёжной странице
  41. Сценарий оплаты заказа
  42. Получение списка связок клиента
  43. Получение списка связок банковской карты
  44. Деактивация/активация существующей связки
  45. Изменение срока действия связки
  46. Использование «Альфа-клик» для оплаты заказа
  47. Краткое описание системы PayByClick
  48. Сценарии оплаты заказа через «Альфа-Клик»
  49. Использование «Альфа-Клик» и электронной коммерции
  50. Использование только «Альфа-Клик»
  51. Тестирование оплаты через «Альфа-Клик»
  52. Использование UPOP для оплаты заказа
  53. Краткое описание системы CUP
  54. Сценарии оплаты заказа
  55. Использование UPOP и электронной коммерции
  56. Использование только UPOP
  57. Тестирование оплаты через UPOP
  58. Процесс тестирования
  59. Тестовые карты China UnionPay
  60. Возврат средств оплаты заказов, оплаченных с помощью UPOP
  61. Оплата с использованием Apple Pay
  62. Действия продавца, необходимые для подключения к Apple Pay
  63. Действия в личном кабинете платёжного шлюза
  64. Создание Merchant ID
  65. Создание сертификата для Merchant ID
  66. Схема взаимодействия при оплате с помощью Apple Pay
  67. Проведение рекуррентных платежей через Apple Pay
  68. Apple Pay — ссылки на справочную информацию
  69. Сценарий оплаты Apple Pay с платёжной страницы на стороне платежного шлюза
  70. Оплата с использованием Google Pay
  71. Введение
  72. Сценарий оплаты в мобильном приложении
  73. Сценарий оплаты с перенаправлением пользователя в ACS
  74. Действия продавца, необходимые для подключения Google Pay к приложению
  75. Сценарий оплаты с платёжной страницей на стороне Продавца
  76. Действия продавца, необходимые для подключения Google Pay к веб-странице
  77. Сценарий оплаты с платёжной страницей на стороне платежного шлюза
  78. Оплата с использованием Samsung Pay
  79. Предварительные действия
  80. Схема с использованием мобильного приложения

Как подключить карту Альфа-Банка к Apple Pay

В Apple Pay – это технология бесконтактных NFC-платежей, работающая с техникой марки Apple: iPhone, iPad, Apple Watch и некоторыми другими. Для совершения бесконтактных платежей в банкоматах и терминалах оплаты разрешается подключать все карты Visa и Mastercard Альфа-Банка, даже международные карты оформленные на фирму и не поддерживающие бесконтактную оплату. Рассмотрим, как настроить оплату картой Альфа-Банка через Айфон, Айпад или часы от Эпл.

Через мобильное приложение Альфа-Мобайл

  1. Войдите в приложение Альфа-Мобайл.
  2. Перейдите в список всех карт и укажите ту, которую решили добавить в телефон.
  3. Кликните кнопку «Добавить в Apple Wallet».
  4. Подтвердите действие одноразовым СМС паролем.
  5. Нажмите «Добавить в Apple Wallet».
  6. Укажите, куда хотите привязать карту: iPhone или Apple Watch.
  7. Согласитесь с пользовательским соглашением.
  8. Готово! Теперь можно платить с помощью Apple Pay.

Внимание. На вашем гаджете должен быть включен Touch ID и выполнена авторизация в iCloud.

С помощью Apple Wallet

  1. Войдите в приложение Wallet.
  2. Кликните в меню «Добавить карту» и затем «Далее».
  3. Заполните номер карточки самостоятельно или просто отсканируйте через камеру вашего телефона.
  4. Заполните имя владельца карты и кликните «Далее».
  5. Укажите срок действия карточки, CVC-код безопасности и нажмите «Далее».
  6. Прочитайте и согласитесь с пользовательским соглашением.
  7. Убедитесь в правильности заполненных данных и введите одноразовый SMS-пароль.
  8. Готово! Теперь можно платить с помощью Apple Pay.

Настройка оплаты картой через Apple Pay на Apple Watch

  1. Запустите программу Watch на вашем iPhone.
  2. Кликните в меню «Wallet и Apple Pay» и затем «Добавить карту».
  3. Заполните CVC-код карты и нажмите «Далее».
  4. Прочитайте и согласитесь с пользовательским соглашением.
  5. Если указанные данные корректны – подтвердите их СМС.
  6. Введите SMS-пароль из сообщения и нажмите «Далее».
  7. Поздравляем! Ваша карта привязана к Apple Watch.

Как пользоваться Apple Pay

Для того, чтобы заплатить через Apple Pay, приложите Айфон или Эпл Вотч к банковскому терминалу. На телефоне подтвердите оплату через Тач Айди, на часах – нажмите два раза кнопку сбоку.

Смотрите видео инструкцию.

Источник

Apple Pay
интернет-эквайринг

Уникальная услуга для бизнеса от Альфа-Банка

Преимущества

Минимальные сроки
рассмотрения заявок
и подключения

Мониторинг платежей
по различным параметрам
заказа

Защита платежей
с помощью Face ID
и Touch ID

Повышает конверсию
в мобильных приложениях
и веб-ресурсах

Как это работает?

Apple Pay интернет-эквайринг – услуга для бизнеса, имеющего мобильное приложение или интернет-магазин.

  • Встраиваете Apple Pay интернет-эквайринг в свое приложение или сайт с помощью простого и открытого API.
  • Пользователь попадает на сайт или приложение и подтверждает оплату через Touch ID или Face ID.
  • Ваш бизнес получает деньги на текущий счет.

Как подключить
Apple Pay интернет-эквайринг?

Заполните заявку на сайте

Мы свяжемся с вами
для уточнения некоторых вопросов

Подключение Apple Pay
интернет-эквайринг

Ваши деньги надежно защищены

Альфа-Банк — универсальный и надежный банк, который предлагает решение по обеспечению безопасности электронных платежей на уровне мировых стандартов, сертифицированное международными платежными системами с использованием технологий 3D-Secure: Verified by Visa и SecureCode от MasterCard.

Заполните заявку

АО ДБ «Альфа-Банк» использует cookie (файлы с данными об использовании сайта) для
удобства пользователей. Ознакомиться с условиями и принципами их обработки можно
здесь. Вы можете запретить сохранение cookie в настройках своего браузера.

Лицензия АРРФР на проведение банковских и иных операций и деятельности на рынке
ценных бумаг № 1.2.61/237 от 03.02.2020
Альфа-Банк является частью консорциума «Альфа-Групп»
Юридический адрес: 050059, г. Алматы, пр. Нурсултана Назарбаева, 226
© 2001—2020 Альфа-Банк

АО ДБ «Альфа-Банк» использует cookie (файлы с данными об использовании сайта) для удобства пользователей. Ознакомиться с условиями и принципами их обработки можно здесь. Вы можете запретить сохранение cookie в настройках своего браузера.

Лицензия АРРФР на проведение банковских и иных операций и деятельности на рынке ценных бумаг № 1.2.61/237 от 03.02.2020 Альфа-Банк является частью консорциума «Альфа-Групп»
Юридический адрес: 050059, г. Алматы, пр. Нурсултана Назарбаева, 226 © 2001—2020 Альфа-Банк

Источник

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

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

Сценарий оплаты заказа (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 ).
    Спецификация обычного запроса состояния заказа представлена в разделах:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Система позволяет формировать статистику по платежам за определённый период с помощью API, посредством интерфейсов SOAP / 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 ).
    Спецификация обычного запроса состояния заказа представлена в разделах:

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

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

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

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

    Читайте также:  Адаптеры для айфона 12 оптом

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

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

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

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

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

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

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

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

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

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

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

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

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

    (2)
    Система позволяет формировать статистику по платежам за определённый период с помощью API, посредством интерфейсов SOAP / 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 ).
    Спецификация обычного запроса состояния заказа представлена в разделах:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Изменение срока действия связки может потребоваться в случае перевыпуска карты клиента. Сделать это можно с помощью API, посредством интерфейсов SOAP / 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 ).
    Спецификация обычного запроса состояния заказа представлена в разделах:

    Запрос состояния заказа (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.

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

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

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

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

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

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

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

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

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

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

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

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

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

    • Форма должна иметь идентификатор id=»formBinding» .
    • Форма должна быть скрыта по умолчанию при помощи CSS свойства «display: none;» .
    • Форма должна содержать выпадающий список выбора связки с именем name=»bindingId» .
    • Выпадающий список должен содержать один вариант выбора: , при выборе которого пользователь осуществляет обычную оплату по карте, без использования функционала связок.
    • Форма должна содержать поле ввода СVC/CVV с именем name=»cvc» .
    • Форма должна содержать кнопку «Оплатить»: с идентификатором id=»buttonBindingPayment» .
    • Поле ввода CVC/CVV и кнопка «Оплатить» должны быть обрамлены элементами с классом class=»rbs_hidden» . При выборе варианта оплаты без использования функционала связок, эти элементы будут скрыты путем установки свойства CSS «display: none;» .

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

    • 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, то будут выполнены следующие действия:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Если магазин использует «Альфа-Клик» наряду с электронной коммерцией, то при создании платёжной страницы помимо стандартных требований, описанных в документе «Оформление платёжной страницы», добавляется требование разместить на странице элемент-кнопку:
    »
    Также существует возможность загрузки магазину стандартной платёжной страницы, где уже размещена кнопка для перехода к оплате через Альфа-Клик.

    • 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:

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

    • Логин «Альфа-Клик»: 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» наряду с электронной коммерцией, то при создании платёжной страницы помимо стандартных требований, описанных в документе «Оформление платёжной страницы», добавляется требование разместить на странице элемент-кнопку:
    »
    По нажатию кнопки выполняется запрос проведения оплаты с помощью UPOP. Описание запроса представлено в разделах:

    Запрос оплаты через внешнюю платёжную систему» (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:
    Дебетовые карты:

    Тип сведений о карте Значение
    Card number 6223 1649 9123 0014
    Mobile phone number +130 12345678
    PIN 111111
    CVN2 123
    Expiration Date month 12 year 33
    SMS Code on PC 111111
    SMS Code on Mobile 123456
    Тип сведений о карте Значение
    Card number 6250 9470 0000 0014
    Mobile phone number +852 11112222
    CVN2 123
    Expiration Date month 12 year 33
    SMS Code on PC 111111
    SMS Code on Mobile 123456

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

    Тип сведений о карте Значение
    Card number 4938 8112 3456 2006
    Mobile phone number 11112222
    CVN2 123
    Expiration Date month 11 year 22
    SMS Code on PC 111111

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

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

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

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

    Запрос возврата средств оплаты заказа» (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 :

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

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

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

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

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

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

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

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

    • Запрос регистрации заказа с предавторизацией (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.

    Реализация способа оплаты Описание
    Из мобильного приложения Оплата осуществляется из мобильного приложения с мобильного устройства пользователя. В этом сценарии приложение запрашивает зашифрованные данные у Google Pay. Эти данные необходимо передать в платёжный шлюз.
    Сценарий оплаты с перенаправлением пользователя в ACS Если пользователь выбрал вариант оплаты через Google Pay нетокенизированной картой, в ответе на запрос оплаты в платёжный шлюз вернутся данные для перенаправления пользователя на ACS эмитента. Ниже представлена схема взаимодействия.
    С веб страницы, при этом платёжная страница расположена на стороне продавца Оплата осуществляется с веб-страницы. Пользователь выбирает оплату на сайте продавца, при этом продавец запрашивает зашифрованные платёжные данные у системы 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://web.rbsuat.com/ab/acsRedirect.do?orderId= , где — уникальный номер заказа клиента.

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

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

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

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

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

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

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

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

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

    • Запрос на оплату Google Pay (WS) ;
    • Запрос на оплату Google Pay (REST) .
  • 6. Платёжный шлюз расшифровывает полученные данные и производит оплату.
  • 7. РБС возвращает результат оплаты в систему интернет-магазина.
  • 8. Результат оплаты отображается клиенту.

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

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

    Подключение веб-страницы к Googel Pay API:

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

    Рекомендации для подключения веб-страницы к Google Pay:

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

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

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

    • Запрос регистрации заказа с предавторизацией (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.

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

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

    Источник

    Читайте также:  Черная тема вконтакте айфон
    Оцените статью
    © 2024 Ваши гэджеты