.png?width=150&height=48&name=Finartz%20Logo%20(1).png "Finartz-Launch-Your-Payment-Initiative"){kind=small}
Last week, in the 3D Secure Masterclass, we thoroughly examined the details of the 3D Secure message structure. In today's blog post, we will discuss the concepts of Frictionless and Challenge. We will try to eliminate the perception of “If there is no verification, it is not 3D” that comes with old habits. When card payment is selected in e-commerce applications, the merchant calls one of the two services offered by the payment service provider “Payment Service Provider (PSP)” that it is integrated with in the background. These services are divided into two as secure and non-secure.
The acquirer receiving the payment request initiated with the non-secure service generates the authorization message directly and forwards it to Visa, Mastercard or BKM switch without initiating a 3D Secure transaction. In case of fraud in such transactions, the responsibility belongs to the merchant.
In Secure transactions, the merchant transmits the additional information to be used in the 3D Secure transaction to the payment service provider (PSP). If the payment service provider is also an acquirer (e.g. Garanti Bank, which provides virtual POS service), it initiates the 3D Secure transaction itself. If the PSP is not an acquirer (e.g. Craftgate), it forwards the transaction to an entity with an acquiring license and that entity initiates the 3D Secure transaction.
The information of the transaction initiated as secure by the merchant is added to the Authentication Request message by the 3DS Server used by the acquirer bank and transmitted to the DS of the card network and from there to the ACS used by the Issuer, the issuer. Up to this point, this was the transaction flow that we were familiar and accustomed to until recently. However, thanks to the Frictionless concept introduced with EMV 3D Secure, a verification method that does not require additional cardholder interaction has emerged.
frictionless Process Flow
1- Upon receiving the AReq message, ACS transmits the transaction information to the SecureScore application, which has a risk-based authentication (RBA) module and works with ACS, and requests a risk analysis.
2- SecureScore application creates a risk score based on predefined rules and transmits a recommendation based on this risk score to ACS.
a) SecureScore allows many parameters such as risk assessment of the card network, transaction amount, merchant information and device information to be used in rule creation.
b) It strengthens the risk analysis by using not only current transaction data but also historical transaction and verification data of the card.
3- ACS transmits the Verify Account message to the issuer by adding SecureScore's recommendation.
4- If the issuer does not see any extra risk after querying information such as card status and balance, it specifies transStatus: Y value in the Verify Account Response message and informs ACS that the transaction will be completed frictionlessly.
|
{ "verifyAccountRes": { "acsTransID": "a43d8477-0e93-4bfc-89e9-cd259001ed0e", "issuerTransID": "86447365-1160-4b8d-af71-f3eed493f600", "transStatus": "Y", // İşlemin frictionless tamamlanması için ACS’e iletilen değer "challengeType": null, // Ek doğrulama olmayacağı için challenge tipi de belirtilmeyecektir. "language": "tr", "cardholderInfo": "Risk Değerlendirmesi sonucunda ek doğrulamaya ihtiyaç duyulmamıştır.", // İşyeri ödeme sayfasında kullanıcıya gösterilecek ekstra bilgi. "timeStamp": 20240903134051, "version": "1.0.0", "result": { "resultCode": "00", "resultMsg": "SUCCESS", "resultDetail": "Success" } |
Frictionless Authentication Experience
Challenge Process Flow
If the issuer receiving the transaction information in the Verify Account message does not want to terminate the transaction or verify the transaction as frictionless, it specifies its preferred verification method in the Verify Account Response message by specifying transStatus: C in the challengeType field to direct the transaction to the challenge stream. According to the selected verification method, additional information (phone number to be seen on the verification page, etc.) is transmitted.
|
{ "verifyAccountRes": { "acsTransID": "a43d8477-0e93-4bfc-89e9-cd259001ed0e", "issuerTransID": "86447365-1160-4b8d-af71-f3eed493f600", "transStatus": "C", // İşlemin Challenge akış ile devam etmesi için C setlenir. "challengeType": "02", // SMS-OTP için 01, Mobil Bildirim için 02, Passkey için 03 değerleri setlenir. "language": "tr", "deviceName": "Sarac’s iPhone", "mobilePhone": { "cc": "90", "subscriber": "5317150621" }, "cardholderInfo": "Risk Değerlendirmesi sonucunda ek doğrulamaya ihtiyaç duyulmamıştır.", // İşyeri ödeme sayfasında kullanıcıya gösterilecek ekstra bilgi. "timeStamp": 20240903134051, "version": "1.0.0", "result": { "resultCode": "00", "resultMsg": "SUCCESS", "resultDetail": "Success" |
Upon receipt of the CReq message from the 3DS Server, the process proceeds to step 12 in the diagram, during which the Challenge Action message is transmitted to the issuer. This message contains additional directives based on the authentication method selected by the issuer.
|
{ "challengeActionReq": { "acsTransID": "dd290456-4b19-49a1-a8ad-5bf65b0b18be", "refNo": "SUZLXCZV", "issuerTransID": "007df537-b431-4aef-9041-f41074a18c2a", "actionType": "START_OOB", // Mobil bildirimi göndermesi için gelen actionType bilgisidir. Eğer OTP gönderilmesi istenirse bu alanda “SEND_OTP” bilgisi yer alacaktır. "notificationURL": "https://release2-acs-mysql.finartz.dev/acs/crstn", // Issuer mobil uygulaması aracılığı ile kullanıcısını doğruladıktan sonra doğrulama sonucunu ileteceği ACS URL’idir. "otpData": null, // Mobil bildirim doğrulama metodunda iletilmez, eğer SMS-OTP ile doğrulama yapılacak olsaydı kullanıcıya iletilecek OTP bilgisi burada yer alacaktı. "version": "1.0.0", "timeStamp": 20240903173831 } |
Challenge Transaction User Experience
