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.