.. meta::
   :description: Mobile device card verification in Payer-Gateway: verify cardholder identity from a mobile app via 3DS-enabled verification flow before saving the card.

.. _mobile_device_card_verification:

Mobile Device Сard Verification
===============================


.. role:: ex

.. role:: code

Introduction
------------

| Mobile Device Сard Verification allows :code:`Consumer` to make transfer and sale transactions easier with a single verification process. During the process, the card is being validated by :code:`Payer-Gateway`, mapped to reference on :code:`Connecting Party’s server`. It allows :code:`Consumer` to avoid entering card data for each transfer or sale transaction. Integration is based on HTTP POST requests/responses with JSON data.
|
| See terms definitions in :ref:`Glossary<glossary>`.

Mobile Device Сard Verification Flow
------------------------------------

.. uml::

    @startuml
    autonumber
    title Mobile Device - 3-D Secure card verification
    skinparam ParticipantPadding 70
    participant "Consumer" as client
    participant "Mobile App" as mobile
    participant "Connecting Party's Server" as party
    participant "Payer-Gateway" as company
    client <-> mobile: Authentication
    mobile -> party: Request access token
    mobile <-- party: Response access token
    note right
    accessToken
    end note
    mobile -> party: Initiate verification request
    mobile <-- party: Initiate verification response
    mobile -> company: Perform validation request
    mobile <-- company: Perform validation response
    note right
    session token
    end note
    party <- company : Check verification request
    party --> company : Check verification response
    company -> company: Start processing
    mobile -> company: Verification status request
    note left
    session token
    end note
    mobile <-- company: Verification status response
    note right
    state = PROCESSING
    end note
    mobile -> mobile: Open browser and provide \nredirectUrl to redirect to 3DS page
    activate mobile
    client <- mobile: Provide redirectUrl
    client -> mobile: The cardholder provides auth data
    mobile -> company: 3DS status update
    company --> mobile: Close browser request
    destroy mobile
    company -> company: Process verification
    party <- company: Verification card mapping notification request
    note right
    server card id
    end note
    party --> company: Verification card mapping notification response
    mobile -> company: Verification status request
    note left
    session token
    end note
    mobile <-- company: Verification status response
    note right
    state = APPROVED|DECLINED
    end note
    party <- company: Callback with final status request
    party --> company: Callback with final status response
    @enduml

| (1,2,3) To perform authentication of Consumer in Connecting Party’s app, Connecting Party can use any method which fits best to his needs. As a result, Connecting Party’s server generates {accessToken} and provides it to Connecting Party’s app. This parameter will be used to start and continue session.
| (4,5) To initiate card verification, Connecting Party’s app sends :ex:`{accessToken}` with other device parameters to Connecting Party’s server. To implement initiate verification request see :ref:`Initiate verification<api_initiate_verification>`.
| (6,7) Connecting Party’s app sends cardholder, device, session data and other parameters straight to Payer-Gateway to check the card for being valid. To implement perform validation request see :ref:`Perform validation<api_perform_validation>`.
| (8,9) Check verification is used for security purposes and allows Payer-Gateway to compare the data sent by Connecting Party’s app with the data stored on Connecting Party’s server. To implement check verification request see :ref:`Check verification<api_check_verification>`.
| (11,12,21,22) Verification status request is made by Connecting Party’s app to Payer-Gateway to get the status of verification transaction. To implement verification status request see :ref:`Verification status<api_verification_status>`.
| (19,20) Payer-Gateway sends Verification card mapping notification request to Connecting Party’s server/proxy with created on its side card reference - :ex:`{serverCardId}`. To implement verification card mapping notification request see :ref:`Verification card mapping notification<api_verification_card_mapping_notification>`.
| (23,24) If Connecting Party callback URL is specified on endpoint level, Payment Gateway sends message to this callback URL whenever transaction reaches final status, no matter if the result is :ex:`approved`, :ex:`declined` or has other :ref:`final status<status_list>`. See more in :ref:`Callbacks<merchant_callbacks>`.

.. 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>`_