1.24. Mobile Device Sale

Введение

Транзакция Sale с мобильного устройства может выполняться с данными держателя карты или со ссылкой на карту, ранее созданной в процессе проверки карты либо в предыдущих транзакциях Transfer/Sale.

Значение терминов см. в Глоссарии.

Общий сценарий оплаты

@startuml autonumber title Мобильное Устройство - \nОплата 3DS skinparam ParticipantPadding 70 participant "Клиент" as client participant "Мобильное приложение" as mobile participant "Сервер \nПрисоединяющейся Стороны" as party participant "SBC" as company client <-> mobile: Аутентификация mobile -> party: Запрос \nтокена доступа mobile <-- party: Ответ с \nтокеном доступа note right accessToken end note party <- mobile: Запрос \nинициации платежа party --> mobile: Ответ \nинициации платежа mobile -> company: Обработка \nзапроса платежа mobile <-- company: Обработка \nответа платежа note right session token end note company -> party: Проверка \nзапроса платежа company <-- party: Проверка \nответа платежа company -> company: Начало обработки mobile -> company: Запрос \nстатуса платежа note left session token end note mobile <-- company: Ответ \nстатуса платежа note right state = REDIRECT_REQUEST redirectUrl end note mobile -> mobile: Открытие браузера и \nпредоставлние nredirectUrl \nдля перенаправления \nна страницу 3DS activate mobile client <-- mobile: Предоставление \nredirectUrl client -> mobile: Предоставлние \nдержателем карты \nданных аутентификации mobile -> company: Обновление статуса 3DS company --> mobile: Запрос на закрытие браузера destroy mobile company -> company: Обработка платежа party <- company: Запрос \nуведомления платежа \nсравнения карты note right server card id end note party --> company: Ответ \nуведомления платежа \nсравнения карты mobile -> company: Запрос статуса платежа note left session token end note mobile <-- company: Ответ статуса платежа note right bankorder id state = APPROVED|DECLINED end note party <- company: Запрос обратного вызова \nс финальным статусом party --> company: Ответ обратного вызова \nс финальным статусом @enduml

(1,2,3) Для выполнения аутентификации Потребителя в приложении Присоединяющейся стороны Присоединяющаяся сторона может использовать любой метод, наиболее соответствующий её потребностям. В результате сервер Присоединяющейся стороны генерирует {accessToken} и предоставляет его приложению Присоединяющейся стороны. Этот параметр будет использоваться для начала и продолжения сеанса.
(4,5) Чтобы инициировать Sale, приложение Присоединяющейся стороны отправляет {accessToken} с суммой транзакции и другими параметрами устройства на сервер Присоединяющейся стороны; они используются для начала сеанса с уникальным случайным {nonce} и зашифрованной {signature}. Сведения о реализации запроса инициирования Sale см. в Initiate Sale.
(6,7) На этом этапе приложение Присоединяющейся стороны отправляет данные держателя карты, устройства, сеанса и другие параметры непосредственно в SBC для выполнения транзакции Sale. Для реализации запроса см. выполнение Sale.
(8,9) Check sale используется в целях безопасности и позволяет SBC сравнивать данные, отправленные приложением Присоединяющейся стороны, с данными, хранящимися на сервере Присоединяющейся стороны. О реализации запроса Check sale см. Check Sale.
(11,12,21,22) Приложение Присоединяющейся стороны отправляет запрос статуса Sale в SBC, чтобы получить статус транзакции Sale. Для реализации запроса см. статус Sale.
(19,20) SBC отправляет на сервер/прокси Присоединяющейся стороны уведомление сопоставления карты Sale с созданной на её стороне ссылкой на карту — {serverCardId}. Для реализации запроса уведомления сопоставления карты Sale см. Уведомление сопоставления карты Sale.
(23,24) Если callback URL Присоединяющейся Стороны указан на уровне endpoint, Платёжный Шлюз отправляет сообщение на этот callback URL при достижении транзакцией финального статуса, независимо от того, является ли результат approved, declined или имеет другой финальный статус. Подробнее см. в Callbacks.

Repeat Общий сценарий оплаты

После успешной процедуры Card mapping новые транзакции Sale с теми же данными держателя карты можно выполнять проще для Покупателя.
Приложение Присоединяющейся стороны создаёт новые запросы Sale, используя {clientCardId} вместо данных держателя карты. SBC отправляет этот {clientCardId} на сервер Присоединяющейся стороны в «Check sale request» и получает сопоставленный с ним {serverCardId} в «Check sale response». Этот {serverCardId} используется для продолжения обработки транзакции Sale.
Процесс транзакции остаётся прежним: Initiate Sale -> Perform sale -> Check Sale.
Если не требуется изменять данные потребителя (адрес, телефон и т. д.), «запрос выполнения Sale» для повторного Sale можно отправить без необязательных параметров. Если данные потребителя нужно изменить, необходимо создать новую ссылку на исходную карту.
Если {clientCardId} используется в «Perform sale request», {serverCardId} должен быть включён в «Check sale response» и подпись.
Если {clientCardId} был сопоставлен с {serverCardId} в транзакции со значением {consumer.email}, новые «запрос на выполнение продажи» и «ответ Check sale» с этим {clientCardId} также должны содержать то же значение {consumer.email}.

Для потока Repeat Sale используйте следующие параметры в запросе Perform Sale:

  1. {sourceOfFunds.reference.clientCardId}

  2. {sourceOfFunds.reference.securityCode}

Instead of:

  1. {sourceOfFunds.card.expiry.month}

  2. {sourceOfFunds.card.expiry.year}

  3. {sourceOfFunds.card.holder}

  4. {sourceOfFunds.card.holder.firstName}

  5. {sourceOfFunds.card.holder.lastName}

  6. {sourceOfFunds.card.number}

  7. {sourceOfFunds.card.securityCode}

@startuml autonumber title Мобильное Устройство - \nСсылки на карту для повторного платежа participant "Мобильное Устройство" as mobile participant "Сервер \nПрисоединяющейся Стороны" as party participant "Платёжный Шлюз" as company skinparam ParticipantPadding 80 == Последняя стадия предыдущей транзакции == party <- company: Запрос на уведомление \nсравнения карты note right serverCardId end note party --> company: Ответ уведомления \nсравнения карты party --> party: Создание clientCardId для serverCardId party -> mobile: Созранение ссылки в приложении или \nотправка Клиенту по запросу note right clientCardId end note == Новый платёж == mobile -> party: Запрос на инициацию \nпроведения платежа mobile <-- party: Ответ на инициацию \nпроведения платежа mobile -> company: Обработка запроса \nна проведение оплаты note left clientCardId end note mobile <-- company: Обработка ответа \nна проведение оплаты party <- company: Проверка запроса \nна проведение оплаты note right clientCardId end note party --> company: Проверка ответа \nна проведение оплаты note left serverCardId end note company -> company: Обработка оплаты @enduml

(1,2) SBC отправляет на сервер/прокси Присоединяющейся стороны уведомление сопоставления карты Sale с созданной на её стороне ссылкой на карту — {serverCardId}. Для реализации запроса уведомления сопоставления карты Sale см. Уведомление сопоставления карты Sale.
(5,6) Чтобы инициировать Sale, приложение Присоединяющейся стороны отправляет {accessToken} с суммой транзакции и другими параметрами устройства на сервер Присоединяющейся стороны; они используются для начала сеанса с уникальным случайным {nonce} и зашифрованной {signature}. Сведения о реализации запроса инициирования Sale см. в Initiate Sale.
(7,8) На этом этапе приложение Присоединяющейся стороны отправляет данные держателя карты, устройства, сеанса и другие параметры непосредственно в SBC для выполнения транзакции Sale. Для реализации запроса см. выполнение Sale.
(9,10) Check sale используется в целях безопасности и позволяет SBC сравнивать данные, отправленные приложением Присоединяющейся стороны, с данными, хранящимися на сервере Присоединяющейся стороны. О реализации запроса Check sale см. Check Sale.