.. _mobile_device_card_verification:

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

.. contents::
    :local:

.. 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:`Payneteasy`, 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 "Payneteasy" 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 Payneteasy 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 Payneteasy 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 Payneteasy to get the status of verification transaction. To implement verification status request see :ref:`Verification status<api_verification_status>`.
| (19,20) Payneteasy 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>`.