Use cases This section describes a detailed description of the processes provided in the QR Payments solution and the appearance of the application from the end user point of view. Wallet Server Money Transfer API This section describes use cases which can be initiated using Wallet Server P2P API. This API should be used by Customers through integrated Wallet QR SDK to manage Transactions and Transaction’s Senders/Receivers, Commission calculation and determine Currencies on Wallet Server. Every method below is secured by session token. For more detailed information about non-QR functionalities offered by Money Transfer please see Money Transfer documentation . Transaction process If the user and his card are present in the Verestro system, such a user can perform QR transactions using the Verestro QR Payments Hub solution. This type of transaction allows the user to make a transfer by scanning the QR code and to track the transfer by providing his own code. QR Payment - scan code This diagram shows QR code transaction processes in the case that the user scans the "external" QR code: @startuml skinparam ParticipantPadding 30 skinparam BoxPadding 30 skinparam noteFontColor #FFFFFF skinparam noteBackgroundColor #1C1E3F skinparam noteBorderColor #1C1E3F skinparam noteBorderThickness 1 skinparam sequence { ArrowColor #1C1E3F ArrowFontColor #1C1E3F ActorBorderColor #1C1E3F ActorBackgroundColor #FFFFFF ActorFontStyle bold ParticipantBorderColor #1C1E3F ParticipantBackgroundColor #1C1E3F ParticipantFontColor #FFFFFF ParticipantFontStyle bold LifeLineBackgroundColor #1C1E3F LifeLineBorderColor #1C1E3F } participant "User" as user participant "Mobile App" as mob participant "Verestro Mobile SDK" as sdk participant "Verestro Money Transfer API" as p2p participant "Verestro THC API" as thc participant "Acquirer" as acq participant "Issuer" as acs user->mob: 1. User scans QR code mob->sdk: 2. Provides scanned QR code sdk->sdk: 3. Parses obtained QR - extract data note right of sdk: Wallet SDK uses dedicated library for QR handling - IMV Standard mob<-sdk: 4. Returns extracted data from scanned QR code user<-mob: 5. Shows all transaction data extracted from QR code - optional note right of user: If QR code is static, user provides amount user->mob: 6. Accepts transaction note right of user: 3ds authentication may be required at this point note right of user: 3ds authentication flow described on above diagram mob->sdk: 7. Performs transaction sdk->p2p: 8. Provides transaction data and execute transaction p2p->acq: 9. Perform transaction acq->acs: 10. Perform Funding from provided card if possible acq<-acs: 11. Success p2p<-acq: 12. Success + transaction id p2p->thc: 13. Store transaction with status Funding p2p<-thc: 14. Transaction has been stored successfully sdk<-p2p: 15. Transaction success mob<-sdk: 16. Transaction success user<-mob: 17. Your transaction has been sent @enduml After scanning the received QR code the Mobile SDK decomposes the data contained in the QR code. The user sees the transaction data, such as the amount that will be sent after confirming the transfer or the currency in which the transfer will be made etc. After confirming the transfer of the funds, the SDK forwards the request to the Wallet API. Wallet API in turn forwards the request to the Acquirer. Based on the data received, the Acquirer contacts the bank to complete the transaction. If the bank agrees, the funding process is carried out - collecting funds from the Sender's account. After the funding is completed, the funds are transferred to the appropriate Receiver. To facilitate understanding of the process flow, each of the steps is described below in the correct order (points highlighted in blue are performed outside the Verestro Server): User scans QR code using device (possible only if provided the device supports such functionality). Verestro Mobile SDK gets data from the scanned QR code. User confirms the transfer and authenticates himself via 3ds authentication process. After going through the 3ds process, the funds transfer process begins. The application orders the transfer of funds by communicating with the Verestro backend via the Verestro Mobile SDK. Money Transfer API communicates with Data Core to check whether the card details belong to the user and the receiver. After receiving a positive response from Data Core, Money Transfer API performs money send transaction. Acquirer receives a request to make a transfer of funds. The Acquirer communicates with the Issuer regarding the execution of the transfer. The Sender's account is debited. The Receiver’s account is credited. The Acquirer receives information from the Issuer that the operation has been performed. Acquirer informs Money Transfer API about the positive status of the ordered operation. Money Transfer API saves transaction details in the Transaction History Core API. Money Transfer API informs Mobile SDK about the positive status of the ordered operation. Mobile SDK informs Mobile Application about the positive status of the ordered operation. The Mobile Application displays to the user a successful transfer of funds. QR Payment - generate code This diagram shows QR code transaction processes in the case that the user generates QR code: @startuml skinparam ParticipantPadding 30 skinparam BoxPadding 30 skinparam noteFontColor #FFFFFF skinparam noteBackgroundColor #1C1E3F skinparam noteBorderColor #1C1E3F skinparam noteBorderThickness 1 skinparam sequence { ArrowColor #1C1E3F ArrowFontColor #1C1E3F ActorBorderColor #1C1E3F ActorBackgroundColor #FFFFFF ActorFontStyle bold ParticipantBorderColor #1C1E3F ParticipantBackgroundColor #1C1E3F ParticipantFontColor #FFFFFF ParticipantFontStyle bold LifeLineBackgroundColor #1C1E3F LifeLineBorderColor #1C1E3F } participant "User" as user participant "Payer" as payer participant "Mobile App" as mob participant "Verestro Mobile SDK" as sdk participant "Verestro Money Transfer API" as p2p participant "Verestro THC API" as thc participant "Acquirer" as acq participant "Issuer" as acs user->mob: 1. User opens QR code generating note right of user: User generates QR mob->sdk: 2. Provides data fulfilled by the user sdk->sdk: 3. Coverts obrained data into QR code note right of sdk: Wallet SDK uses dedicated library for QR handling - IMV Standard mob<-sdk: 4. Returns QR with parsed data user<-mob: 5. Shows all transaction data and generated QR code note right of user: User shows generated QR to the potential payer note right of payer: Payer scans QR code payer->payer: 6. Scans QR code mob->sdk: 7. Get transaction data from QR code mob<-sdk: 8. Returns transaction data obtained from QR code payer<-mob: 9. Shows all transaction data payer->mob: 10. Confirms money transfer and pass 3ds note right of payer: 3ds authentication may be required at this point note right of payer: 3ds authentication flow described on above diagram mob->sdk: 11. Performs transaction sdk->p2p: 12. Provides transaction data and execute transaction p2p->acq: 13. Perform transaction acq->acs: 14. Perform Funding on Payer's card if possible acq<-acs: 15. Success p2p<-acq: 16. Success + transaction id p2p->thc: 17. Store transaction with status Funding p2p<-thc: 18. Transaction has been stored successfully sdk<-p2p: 19. Transaction success mob<-sdk: 20. Transaction success payer<-mob: 21. Your transaction has been sent acq->acs: 22. Perform Credit on User's card if possible acq<-acs: 23. Success p2p<-acq: 24. Success + transaction id p2p->thc: 25. Update transaction status to CLEARED @enduml 3DS Authentication The QR Money Transfer Hub Solution supports the 3DS 2.0 process and it is required when user is initiating a transaction. This is an authentication method based on the alleged cardholder data check, biometric authentication and improved customer experience. As mentioned in the "Configuration" paragraph, a specific 3DS integration is required depending on which ACQ Verestro will connect to when making a transaction. If the integration with a given ACQ has already been made, Verestro only need to configure the appropriate merchant identifier, which should be provided by the Customer. If the integration with the required billing agent has not yet been completed, it will be one of the activities for which Verestro will be responsible. Note that integration with 3DS increases the scope of required development. In card to card transfer, the authentication process is required. It is to confirm that the user is definitely the owner of the card. This diagram shows high level 3ds authentication processes: @startuml skinparam ParticipantPadding 30 skinparam BoxPadding 30 skinparam noteFontColor #FFFFFF skinparam noteBackgroundColor #1C1E3F skinparam noteBorderColor #1C1E3F skinparam noteBorderThickness 1 skinparam sequence { ArrowColor #1C1E3F ArrowFontColor #1C1E3F ActorBorderColor #1C1E3F ActorBackgroundColor #FFFFFF ActorFontStyle bold ParticipantBorderColor #1C1E3F ParticipantBackgroundColor #1C1E3F ParticipantFontColor #FFFFFF ParticipantFontStyle bold LifeLineBackgroundColor #1C1E3F LifeLineBorderColor #1C1E3F } participant "User" as user participant "Mobile App" as mob participant "Verestro Mobile SDK" as sdk participant "Verestro Money Transfer API" as p2p participant "Acquirer" as acq participant "Mastercard/VISA" as mcvisa participant "ACS/Issuer" as acs note left of mob: User has confirmed currencies and accepted shown currency rate user->mob: 1. Enters CVC code note left of mob: In this step the application begins 3DS authentication process.  note left of mob: If the bank decides that 3ds is not required, not any action will be performed. note left of mob: Diagram shows the option requiring the user to authenticate. mob->sdk: 2. Initialize 3DS process sdk->p2p: 3. Initialize 3DS process p2p->acq: 4. Initialize 3DS process note left of acs: Bank returns decision whether it is necessary for the user to authenticate acq->mcvisa: 5. Is 3DS authentication required? acq<-mcvisa: 6. ThreeDS Method p2p<-acq: 7. ThreeDS Method p2p->acq: 8. Continue 3DS process acq->acs: 9. Continue 3DS process acq<-acs: 10. Challenge required p2p<-acq: 11. Challenge required sdk<-p2p: 12. Challenge required mob<-sdk: 13. Challenge required user<-mob: 14. Informs user that challenge is required note left of mob: Bank's page content is provided user->user: 15. Performs challenge note right of user: After a successful challenge, the Bank sends PaRes/cRes, which is intercepted by the Wallet SDK and provided to the Money Transfer API user-->mob mob-->sdk sdk->p2p: 16. Provides intercepted PaRes/cRes p2p->acq: 17. Provides obtained PaRes/cRes acq->acs: 18. Check authentication for provided PaRes/cRes acq<-acs: 19. Authentication success p2p<-acq: 20. Authentication success sdk<-p2p: 21. Authentication success mob<-sdk: 22. Authentication success user<-mob: 23. Informs about the successful completion of the authentication process @enduml To facilitate understanding of the process flow, each of the steps is described below in the correct order (points highlighted in blue are performed outside the Verestro Server) : Mobile application contacts the Verestro Server via the Verestro Mobile SDK to start 3ds process. Mobile SDK provides all necessary data to the Money Transfer API (including user/card id and 3ds authentication request id) while calling the 3ds initialization method. Having all the necessary information, Money Transfer API orders Acquirer to start the 3ds authentication process. Acquirer transfers the card and user details to ACS. If the user is the owner of the card, the ACS returns a positive answer and a decision whether the continuation of the authentication process is required (according to the diagram above, the scenario with the necessity to continue the process is described). ACS informs the Acquirer that the 3ds process continue is required. Acquirer informs Money Transfer API about ACS decision. Money Transfer API requests Acquirer to continue the authentication process (the authentication id is provided. Acquirer provide the request to continue the process to the ACS. ACS informs about the necessity to perform the Challenge process and returns necessary parameters such as: challengeHtmlFormBase64 - this field is a BASE64 encrypted html source file containing the ACS’ challenge 3DSecure frame. cReq - data for building a form such as challengeHtmlFormBase64. Acquirer informs Verestro Money Transfer API that ACS requires Challengeand provides above parameters. Verestro Money Transfer API forwards the obtained information to Verestro Mobile SDK. Verestro Mobile SDK decodes the received challengeHtmlFormBase64 parameter and transmits the received frame of the mobile application. The user is redirected to the bank's website where he performs the Challenge process. After a successful Challenge process, the bank sends the cRes / PaRes parameter. This response is intercepted by the Verestro Mobile SDK and forwarded to the Verestro Money Transfer API. Verestro Money Transfer API provides the received cRes / PaRes to Acquirer. Acquirer provides the above parameters to ACS for verification. If everything was done correctly, the ACS informs Acquirer about the successful completion of the 3ds authentication. Among other things, the following parameters are included in the response. cavv - property determined by the ACS. The value may be used to provide proof of authentication. eci - property is determined by the ACS. This property contains the two digit Electronic Commerce Indicator (ECI) value, which is to be submitted in a credit card authorization message. Acquirer provides information about successful completion of the 3ds authentication among with the above parameters obtained from the ACS to Verestro Money Transfer API. Verestro Money Transfer API provides information about successful completion of the 3ds authentication among with the above parameters obtained from the ACS to Verestro Mobile SDK. Verestro Mobile SDK provides positive response to mobile application. The information is shown to the user. User experience & screenshots This chapter introduces the main actions and processes in the application associated with QR module from the end user point of view. The rest of the processes apply to "Money Transfer" as a product as a whole are described in separate Money Transfer documentation . QR payments is one of the components of the Money Transfer product. QR Payment flow The module responsible for QR payments can be divided into two functionalities. The first one allows you to make a payment by scanning the QR code. The second functionality allows user to generate a QR code with which user can order a transfer to his card. Scan QR code The scan QR option allows user to order a money transfer by scanning the QR code issued by the potential recipient. The execution of this path depends on whether the user's device has a QR scan function. Additionally, the application may request access to the camera of the device used. The pictures below show “scan QR code” view: On the screen above the user selects the scan tab for the application to get all the information needed to make the transfer from the provided QR code. On the screen above the redirection following scanning the QR code is shown. The user can see to whom the transfer will be made and which of his cards will be debited. If the user is ready to make the transfer, he confirms the action with the confirm button. Similar to a card to card transaction, the 3ds process may be required (See “Card to card” chapter). On the screen above user is informed about the successfully money transfer. Return button will redirect the user to the main page . On the screen above user is informed about the unsuccessfully money transfer. In this case user is able to try again the transfer or return to the main page. Example reasons of the transaction fail: Luck of funds, 3ds failed, Invalid card data. Generate QR code The scan QR option allows user to generate a QR code. With the generated code, the user can have his account topped up by showing the code to another person. The pictures below show “generate QR code” view: On the screen above user chooses which of his cards will be debited, and in what currency the transfer is to be made. If the above choices have been made, the user has to enter the amount he wants to receive. On the screen above the user enters the amount he wants to receive and then confirms the selection with the green button in the lower right corner of the screen. After performing all the required actions, a QR code and information about the ordered transaction (card, currency and amount) are generated on the screen.