.. meta::
   :description: Процесс mobile device sale в SBC: инициация платежей по карте из мобильного приложения с поддержкой 3DS, recurring ID и card-not-present транзакций.

.. _mobile_device_sale:

Mobile Device Sale
==================


.. role:: ex

.. role:: code


Введение
------------

| Транзакция Sale с мобильного устройства может выполняться с данными держателя карты или со ссылкой на карту, ранее созданной в процессе :ref:`проверки карты<mobile_device_card_verification>` либо в предыдущих транзакциях Transfer/Sale.
|
| Значение терминов см. в :ref:`Глоссарии<glossary>`.

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

.. uml::
    :align: center

    @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) Для выполнения аутентификации Потребителя в приложении Присоединяющейся стороны Присоединяющаяся сторона может использовать любой метод, наиболее соответствующий её потребностям. В результате сервер Присоединяющейся стороны генерирует :ex:`{accessToken}` и предоставляет его приложению Присоединяющейся стороны. Этот параметр будет использоваться для начала и продолжения сеанса.
| (4,5) Чтобы инициировать Sale, приложение Присоединяющейся стороны отправляет :ex:`{accessToken}` с суммой транзакции и другими параметрами устройства на сервер Присоединяющейся стороны; они используются для начала сеанса с уникальным случайным :ex:`{nonce}` и зашифрованной :ex:`{signature}`. Сведения о реализации запроса инициирования Sale см. в :ref:`Initiate Sale<api_initiate_sale>`.
| (6,7) На этом этапе приложение Присоединяющейся стороны отправляет данные держателя карты, устройства, сеанса и другие параметры непосредственно в SBC для выполнения транзакции Sale. Для реализации запроса см. :ref:`выполнение Sale<api_perform_sale>`.
| (8,9) Check sale используется в целях безопасности и позволяет SBC сравнивать данные, отправленные приложением Присоединяющейся стороны, с данными, хранящимися на сервере Присоединяющейся стороны. О реализации запроса Check sale см. :ref:`Check Sale<api_check_sale>`.
| (11,12,21,22) Приложение Присоединяющейся стороны отправляет запрос статуса Sale в SBC, чтобы получить статус транзакции Sale. Для реализации запроса см. :ref:`статус Sale<api_sale_status>`.
| (19,20) SBC отправляет на сервер/прокси Присоединяющейся стороны уведомление сопоставления карты Sale с созданной на её стороне ссылкой на карту — :ex:`{serverCardId}`. Для реализации запроса уведомления сопоставления карты Sale см. :ref:`Уведомление сопоставления карты Sale<api_sale_card_mapping_notification>`.
| (23,24) Если callback URL Присоединяющейся Стороны указан на уровне endpoint, Платёжный Шлюз отправляет сообщение на этот callback URL при достижении транзакцией финального статуса, независимо от того, является ли результат :ex:`approved`, :ex:`declined` или имеет другой :ref:`финальный статус<status_list>`. Подробнее см. в :ref:`Callbacks<merchant_callbacks>`.

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

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

#. :ex:`{sourceOfFunds.reference.clientCardId}`
#. :ex:`{sourceOfFunds.reference.securityCode}`

| Instead of:
|

#. :ex:`{sourceOfFunds.card.expiry.month}`
#. :ex:`{sourceOfFunds.card.expiry.year}`
#. :ex:`{sourceOfFunds.card.holder}`
#. :ex:`{sourceOfFunds.card.holder.firstName}`
#. :ex:`{sourceOfFunds.card.holder.lastName}`
#. :ex:`{sourceOfFunds.card.number}`
#. :ex:`{sourceOfFunds.card.securityCode}`

.. uml::
    :align: center

    @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 с созданной на её стороне ссылкой на карту — :ex:`{serverCardId}`. Для реализации запроса уведомления сопоставления карты Sale см. :ref:`Уведомление сопоставления карты Sale<api_sale_card_mapping_notification>`.
| (5,6) Чтобы инициировать Sale, приложение Присоединяющейся стороны отправляет :ex:`{accessToken}` с суммой транзакции и другими параметрами устройства на сервер Присоединяющейся стороны; они используются для начала сеанса с уникальным случайным :ex:`{nonce}` и зашифрованной :ex:`{signature}`. Сведения о реализации запроса инициирования Sale см. в :ref:`Initiate Sale<api_initiate_sale>`.
| (7,8) На этом этапе приложение Присоединяющейся стороны отправляет данные держателя карты, устройства, сеанса и другие параметры непосредственно в SBC для выполнения транзакции Sale. Для реализации запроса см. :ref:`выполнение Sale<api_perform_sale>`.
| (9,10) Check sale используется в целях безопасности и позволяет SBC сравнивать данные, отправленные приложением Присоединяющейся стороны, с данными, хранящимися на сервере Присоединяющейся стороны. О реализации запроса Check sale см. :ref:`Check Sale<api_check_sale>`.

.. ifconfig:: "doc.payneteasy.com" in site_link

   ----

   .. admonition:: See also
      :class: related-cross-link

      `Multichannel integration including mPOS and SDK → <https://payneteasy.com/solutions/channels>`_

.. ifconfig:: "doc.payneteasy.ru" in site_link

   ----

   .. admonition:: См. также
      :class: related-cross-link

      `mPOS & POS SDK — приём платежей через терминалы → <https://payneteasy.ru/solutions/mpos>`_