1.21. Mobile Device Сard Verification

Introduction

Mobile Device Сard Verification allows Consumer to make transfer and sale transactions easier with a single verification process. During the process, the card is being validated by ConnPay, mapped to reference on Connecting Party’s server. It allows 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 Glossary.

Mobile Device Сard Verification Flow

@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 "ConnPay" 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 {accessToken} with other device parameters to Connecting Party’s server. To implement initiate verification request see Initiate verification.
(6,7) Connecting Party’s app sends cardholder, device, session data and other parameters straight to ConnPay to check the card for being valid. To implement perform validation request see Perform validation.
(8,9) Check verification is used for security purposes and allows ConnPay 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 Check verification.
(11,12,21,22) Verification status request is made by Connecting Party’s app to ConnPay to get the status of verification transaction. To implement verification status request see Verification status.
(19,20) ConnPay sends Verification card mapping notification request to Connecting Party’s server/proxy with created on its side card reference - {serverCardId}. To implement verification card mapping notification request see 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 approved, declined or has other final status. See more in Callbacks.