3D-Secure-solution

eCommerce popularity has increased constantly over the last ten years. In the past few years, mCommerce growth has been more than 10% in transactions and volume every year. Both mobile and internet shopping are recognized as convenient purchasing methods for cardholders and merchants, considering a wide offer in all market segments, 24/7 availability, delivery tracking, and convenient online card payment. An increase in the number of online transactions also brought a rise in fraudulent use of payment cards. It is estimated that nearly 80% of all e-commerce and m-commerce chargebacks are fraud.

3D Secure is a protocol designed for increased security during online payments using credit and debit cards (the so-called Card-Not-Present transactions). The main purpose of 3D Secure is to authenticate the cardholder during online payment on the internet or mobile purchasing. To make a parallel with in-store payment (the so-called Card-Present transactions), the cardholder is authenticated either with signature or PIN, which are not applicable during online payment.

The concept of 3D Secure is based on the ''Three-Domain'' model, including all participants involved in the financial transaction. All three domains participate in the authentication process, and compliance in all three domains results in a 100% secure transaction. Non-compliance under any of the domains moves the liability shift towards the weaker party. 3D Secure domains:
- Acquirer domain - 3D Secure transactions are initiated from the acquirer domain
- Interoperability domain - 3D Secure transactions are switched between the Acquirer domain and Issuer domain
- Issuer domain - 3D Secure transactions are authenticated in the Issuer domain

3D Secure component most relevant for Issuers is Access Control Server, ACS. Additionally to ACS, and depending on the chosen authentication method, the Issuer should have an authentication solution implemented, integrated with ACS. Upon implementation at the Issuer side, the solution needs to be certified by card schemes.

3D Secure component most relevant for Acquirers is Merchant Plug-In, MPI. This plug-in enables integration with the merchant's website. In 3D Secure 2.0, instead of MPI, 3DS Server is introduced. A segment containing additional SDK components necessary for mobile purchase applications.

3D Secure 2 specifications by EMVCo, but also card scheme 3D Secure 2 programs (MC Identity Check, Verified By Visa, etc.), are aligned with PSD2 requirements, i.e., when deploying 3D Secure 2, Issuers/Acquirers are aligned with PSD2 for Card-Not-Present online payments. Note that it covers only Card-Not-Present online payments, not account-to-account payments and other PSD2 relevant scopes.

Instead of purchasing ACS products to be implemented on bank premises, Issuing banks can use third-party service providers to outsource the 3D Secure process. Card schemes have been certifying and approving service providers who can provide this service to the Issuing bank.

ASEE has been certified as a MasterCard and VerifiedByVisa ACS service provider. By using this service, Issuing institutions minimize time to market, reduce investment and operational costs for 3D Secure compliance, and at the same time, provide their customers with ultimate fraud protection during online payment.

3D Secure 2.0 contains two authentication flows, namely: Frictionless flow and Challenge flow. Frictionless flow enables cardholders to process online payments without demanding any manual input in order to authenticate the transaction. This is possible because of Risk-Based Authentication, a mechanism that assesses the risk level of a particular transaction based on historical data, including transaction history and provided cardholder information. If a transaction is deemed low risk, frictionless flow is applied. This eliminates the need to require additional authentication steps from the cardholder.

3D Secure 2.0 contains two authentication flows, namely: Frictionless flow and Challenge flow. Challenge flow is applied in cases where the Issuer's ACS deems a transaction as risky. In such cases, the cardholders are required to verify their identity using an appropriate authentication method (e.g., OTP, fingerprint, face recognition).

Trides ACS enables Issuers to provide 3D Secure processing with MasterCard, VISA, Amex, JCB, and Mir cards with two-factor strong authentication in compliance with the existing 3D Secure v1.0.2, as well as the new 3D Secure v2.1 protocol.

Trides MPI v1.0.2 and Trides 3DS Server v2.1.0 with Android and iOS SDK are solutions that enable Acquirers and Merchants to integrate web and mobile purchase applications with multiple interoperability domains and initiate online payments within 3D Secure scheme. ASEE also offers 3DS Mobile SDK implementation.

With 3D Secure mobile SDK, the merchants are able to build in all 3D Secure screens into their mobile purchase application to provide a faster and smoother checkout experience. Without it, the cardholders need to switch to the web browser during 3D secure authentication, inarguably disturbing the checkout process.

If you have any additional questions regarding our 3D Secure solutions or hosting services, need advice or support related to 3D Secure online fraud protection for your customers, don't hesitate to contact your ASEE Key Account Manager, Sales Representative or send an email at mailto:trides@asseco-see.hr.

Enterprise Appsec: The Ultimate Security Checklist

Summary:

Enterprise mobile application security
Recap of the most significant mobile data breaches of 2021
Enterprise mobile application security threats landscape
Enterprise mobile application security checklist
Enterprise mobile security suite by ASEE

Fill out the form and download the document.

Enterprise Appsec: The Ultimate Security Checklist (#100)

First Name

Last Name

Company Name

Phone number (optional)

participants

In order to have efficient protection with 3D Secure, it must be implemented on the Issuer and on the Acquirer domain. Therefore, Issuers (financial institutions who issue payment cards), Acquirers, and Merchants who accept cards have to deploy the protocol.

This depends on the card scheme (VISA, MC, AMEX, Diners...). Each of them can have different requirements, milestone deadlines, also considering the geo-location. VISA, for instance, does not mandate the VerifiedByVISA program, but MasterCard mandates MasterCard IdentityCheck in the EU region. However, in the EU region, PSD2 requires SCA authentication for mCommerce and eCommerce payments. By applying 3D Secure, this mandatory requirement is met.

Yes. After the transition period, latest on October 2022, 3D Secure v1.0.2 will no longer be supported by card schemes. Therefore, banks need to migrate to the new version.

Within the 3D Secure environment, even if two-factor strong authentication is applied (as required by PSD2 and 3D Secure 2.1), the Issuer is liable for chargebacks for fraudulent transactions. However, if a cardholder has to pass through another layer of authentication and authenticate themselves during payment, it is less likely that the card is being used in a fraudulent manner. 3D Secure reduces the number of fraudulent online transactions and potential chargebacks.

Issuers have to be aware that card schemes (VISA, MasterCard, etc.) are stakeholders of 3D Secure and promote its acceptance. Through 3D Secure, card schemes introduce liability shift as the main benefit for Merchants and Acquirers. This means that when a Merchant proves a transaction to be a fraudulent one, and the Issuer is enrolled in 3D Secure (or that particular type of card is enrolled in 3D Secure), the Issuer is liable for the chargeback.

If you are a part of any domain, yes, you should implement a solution covering 3D Secure authentication. Cards from Issuers that do not use ACS are more often used in card-not-present transactions simply because fraudulent entities are targeting the weaker part of the chain.

benefits

(1) 3DS Requestor Initiated (3RI) payments – enabling a merchant to initiate a transaction even if the cardholder is offline.
(2) Decoupled authentication – allowing cardholder authentication to occur even if the cardholder is offline.
(3) Expansion of existing data elements to promote communication of pre-checkout authentication events and associated data as part of the EMV 3DS transaction from systems such as those supporting the FIDO Alliance standards.

The initial version of 3D Secure was launched in 2001 and had a few minor releases. In October 2016, EMVCo released 3D Secure v2.0, and one year later, in October 2017, 3D Secure v2.1 emerged. 3D Secure 2.0 is more than just an upgrade of an old standard. It is designed with the intent to create a frictionless online payment experience for cardholders. It does this by facilitating richer data exchange, allowing Risk-Based Authentication on the Issuer side for low-risk transactions. This eliminates authentication challenges and makes the authentication process almost invisible to the cardholder.

Recognizing the necessity to support new and evolving payment channels, 3D Secure 2.0 includes the ability to support authentication of App-based transactions on mobile and other consumer devices. As mentioned, 3D Secure 2.0 introduces state-of-the-art authentication methods such as fingerprint, face recognition, and voice recognition (biometric authentication).

To summarize, 3D Secure 2.0 brings the following benefits:
- Applicable for mobile device web browser purchasing
- Integration with mobile applications to provide consistent service for mobile application based purchasing services
- Simplified user experience
- Elimination of sign up process during online shopping
- Enables up-to-date authentication methods such as fingerprint, face recognition, voice recognition - Provides Risk Scoring and Risk-Based Authentication
- Enables ''frictionless'' or the so-called silent authentication based on customer and transaction data with no additional demands towards the end-user
- Increased conversion rate

By using the ASEE Trides solution, Issuers are able to provide added value to their cardholders such as user portal or user mobile application which enables the cardholder to monitor their 3D Secure online transactions, maintaining risk parameters such as online purchase limits, geographical restrictions, setup of SMS/push warnings in cases of unexpected purchase, lock/unlock card, define preferred authentication method, change language, etc.

First of all, the buyer will feel more confident knowing that additional fraud prevention was deployed. Secondly, even in case of fraud, card schemes (VISA, MasterCard) granted the so-called Liability shift for the merchant. That means that the issuing bank is liable for fraud and dispute costs, and the merchant won't suffer any losses.

Z

Zero Trust Policy is a security framework that requires all users, inside or outside the organization's network, to be authorized, authenticated, and continuously validated in order to gain access to company applications and data.

A zero-day vulnerability, also called a zero-day exploit, is a vulnerability in a system or device that has been disclosed but is not yet patched. A zero-day vulnerability is exploited before cybersecurity researchers and developers get the chance to detect it themselves. An attack conducted through a zero-day vulnerability is called a zero-day exploit.

V

The Internet of Things (IoT) describes the network of physical objects—"things"— embedded with sensors, software, and other technologies for the purpose of connecting and exchanging data with other devices and systems over the internet. These devices range from ordinary household objects to sophisticated industrial tools. Examples of IoT devices are smartwatches, smart door locks, smart refrigerators, etc.

T

TLS, short for Transport Layer Security, is a protocol enabling end-to-end protection of data transferred between two internet applications. It is an evolution of the SSL protocol.

VPN, short for Virtual Private Network, enables a protected network connection while using a public one through encryption. VPN disguises the user's online identity by encrypting their internet traffic.

S

SCA exemptions are particular payment scenarios introduced by PSD2 which do not demand an additional authentication step. This approach enables a frictionless online payment experience for the cardholder, as well as reducing cart abandonment rates which is a benefit for the merchants. SCA exempted scenarios are the following: low-risk transactions, low-value payments (LVP), merchant whitelisting, corporate payments, recurring payments. However, since issuing bank is the one that approves if a transaction will, in fact, be exempted or not, not all mentioned scenarios will automatically be exempted. This means that even if a transaction is qualified as an SCA exemption, the issuing bank might request additional authentication.

Strong Customer Authentication (SCA) is an additional layer of security used for protecting online payments, which means the CH is going to be asked for authentication.

It is based on at least two out of three security elements, namely:
- knowledge (what the cardholder knows, e.g., PIN, password)
- possession (what the cardholder has, e.g., phone, hardware token)
- inherence (what the cardholder is, e.g., facial recognition, fingerprints)

SSO, short for Single Sign-On, is an authentication method that enables users to securely access multiple applications using a single set of credentials.

Single-Factor Authentication is a low-security authentication method commonly using a password as the single factor necessary to access an account or a service.

Social engineering, in terms of information security, is the act of luring users into revealing sensitive information that is later used for fraudulent actions. Phishing attacks are good examples of social engineering.

Source code is a set of instructions written in a programming language that is easily read and understood by humans. Source code contains instructions about how a programmer wants a certain application/website/software to function. Source code is typically written in a text-based program and later translated into a format readable by a computer program. The translation is done by using a compiler. Once a source code undergoes such translation, it becomes an object code.

Spoofing, in terms of cyber security, refers to imitating any entity involved in information technology (users, computers, networks, companies) in order to conduct fraudulent actions.

Spyware is a type of malicious software designed to gather information about the user by tracking their actions on the device (smartphone, laptop, tablet). The stolen data is later forwarded to a third party without the user's consent and used for fraudulent purposes.

SSL, short for Secure Sockets Layer, is a standard technology that keeps the internet connection secure and protects any sensitive data that is being transferred between two systems. SSL prevents bad actors from gaining access and modifying the information in transit. It protects both server-to-server and server-to-client communication.

R

Ransomware is a type of malware that, when initiated, encrypts the target's data, making it inaccessible until a certain amount of money is paid to the designer of the attack.

Reverse engineering in cyber security refers to deconstructing the software in order to extract useful information about its design and architecture with the end goal of duplicating or enhancing the software.

Risk-Based Authentication or RBA is a mechanism used for fraud prevention by determining the risk level of a particular transaction. Based on risk assessment, an appropriate authentication method is required from the cardholder; or in case of high-risk detection, the transaction is terminated. This method is proven to work well when it comes to account takeover attacks and mobile payment fraud. RBA is also known as step-up authentication or adaptive authentication.

RASP, short for Runtime Application Self-Protection, is a security component built in the application's runtime environment, enabling protection from the inside. Since Runtime Application Self-Protection is an integral part of the application, it allows monitoring in real-time and detection of any anomaly in the mobile app's runtime behavior. With continuous monitoring of the app's behavior, RASP protects the mobile application from data breaches, various mobile app security threats (e.g., hooking and emulator attacks), and tampering - without any human intervention.

P

PSD2 terminology implies that the payee is the merchant, an entity selling goods/services online.

PSD2 terminology implies that the ''Payee's PSP'' is the Acquirer for card payments.

PSD2 terminology implies that the ''Payer'' is the consumer, a customer buying goods/services online.

PSD2 terminology implies that the ''Payer's PSP'' is the Issuer for card payments.

Payment gateway is an online payment service necessary for the functioning of an eCommerce webshop. It is a channel used for making and receiving payments. The primary role of a payment gateway is to verify transactions between cardholders and merchants. It is a mechanism that transfers funds between the cardholder's issuing bank and the merchant's acquiring bank.

Penetration testing, also known as pen testing, is a simulation of a cyberattack on a system aiming to uncover existing vulnerabilities. The process of pen testing includes numerous application systems that are prone to containing vulnerabilities such as malicious code injection. The results of a pentest are generally used for fine-tuning security policies and patching the detected flaws within the system.

Phishing is a cybercrime commonly conducted through mediums such as e-mail, telephone, or direct messages. The bad actor is presenting themselves as a trustworthy individual, often a government body or a reputable CEO, and prompts the user to provide them with some type of sensitive information (user credentials, credit card details, sensitive company information, etc.). The content of the message usually mentions urgency. Possible outcomes of a phishing attack include identity theft and illicit withdrawal of funds.

Authorized PISPs are able to move funds on the customer's behalf upon connecting to the bank account. An example of a practical use case is the automatic transfer of funds to a customer's savings account.

Look under ''Asymmetric Cryptography''.

PoC, short for Proof of Concept, summarizes evidence proving that a particular business plan or a project is feasible.

PSD2 or The Second Payment Services Directive is a comprehensive set of rules whose main goal is to achieve simple, efficient, and secure online payments across Europe. The main goals of the directive include offering a broader supply and better pricing for the end-users, creating more competition, ultimately bringing more efficiency, and working on improving consumer trust. The most notable suggestions covered in PSD2 striving to level the payments playing field are expanding the EU payments market, empowering consumers, and restricted interchange fees.

Payment Service Providers or PSPs are responsible for enabling merchants to accept payments, both credit, and debit, from cardholders. It is an entity that connects merchants, cardholders, card schemes, issuing banks, and acquiring banks.

Users of any of the service providers: TPPs, PISPs, ASPSPs, AISPs.

A push notification is a pop-up message appearing on a user's smartphone, web browser, or desktop prompting the user to take a certain action. In terms of authentication, push notification authentication enables the user to verify their identity through a push notification appearing on their mobile device instead of submitting their password for a particular service. Push notification authentication is a popular method in mobile/internet banking.

O

One-Click-Payment is a form of Card-On-File payment. By saving the card details on a particular site, the cardholder is able to skip authentication and process a payment with a single click on the ''buy'' button.

Out-Of-Band (OOB) Authentication is a form of two-factor authentication (2FA) that implies a secondary communication channel necessary for successful authentication. The use of two separate communication channels significantly reduces the attacker's chances of compromising a particular account. It is widely used in the financial industry for online payment authorization. A typical use case is receiving an SMS OTP or push notification on your mobile phone in order to successfully process an online transaction. Common forms of OOB authentication are authorization codes sent via SMS, use of voice channel, push notification containing an authorization code, etc.

Open Source Software is software released under a license that grants the holder permission to access the code as well as examine, modify, and distribute the code with its original rights.

One Time Password (OTP) is an authentication method involving an automatically generated alphanumeric code that corresponds to only one login session or transaction authorization. Think of it as a ''disposable'' code that is used for authorizing a single transaction. Generated OTPs are usually sent to the end-user via SMS and are widely used in online banking.

N

Non-Payment Authentication enables merchants to submit an authentication request when it is necessary for a non-payment use case. Such use cases can be adding a card to a merchant's website, modifying stored cardholder information, or issuer cardholder verification during token provisioning.

M

Machine Learning (ML) is a type of Artificial Intelligence (AI) and computer science that uses data and algorithms with the goal of imitating the human learning process that results in improved, more accurate predictions.

Malware is software specifically designed to gain unauthorized access, damage, or disrupt a system or a network.

Man-in-the-Browser (MitB) is a type of a Man-in-the-Middle attack where the bad actor inserts themselves into the communication between two trusting parties by compromising the web browser used by one of the parties. The motivation behind Man-in-the-Browser data includes data theft, eavesdropping, and session tampering.

A Man-in-the-Middle (MitM) attack is a term used for malicious interception of a conversation between the user and an app (or another user). The process involves impersonating the other party, making it seem like a standard exchange of information. The main motivations behind a Man-in-the-Middle attack are either impersonation or eavesdropping.

The goal of a Man-in-the-Middle attack is to steal sensitive information (e.g., personal, financial, enterprise data). The most common targets of a Man-in-the-Middle attack are financial apps, users, e-commerce websites and other services requiring login credentials. The consequences of a Man-in-the-Middle attack vary from account takeover, identity theft to illicit fund transfers.

The most simple parallel for a Man-in-the-Middle attack would be the scenario in which a mailman opens your personal mail, makes a copy of the contents, and reseals the envelope.

Merchant Whitelisting, or Trusted Beneficiaries, enables cardholders to choose known merchants who they trust in order to skip the additional authentication step. Regardless of the transaction amount or merchant fraud rate, SCA won't be applied.

Multi-Factor Authentication, or MFA, is a way of confirming the user's identity by checking at least two or more security elements. The mentioned security elements include something the user knows (PINs, passwords), something the user owns (phone, card), something the user is (fingerprint, face recognition).

Mobile application management (MAM) is software used for remote access to enterprise applications on the end user side. This includes access to both personal and corporate devices (smartphones and tablets).

Mobile application management is used for applying corporate policies and limiting data transfers between applications. Another feature MAM cover is the separation of personal and corporate content stored on the same device. Additional features a Mobile application management software enables are software delivery (mostly by using the enterprise app store), license management, application configuration, as well as inventory and app lifecycle management.

Mobile application security is a general term used for securing mobile apps and the users' digital identities from malicious attacks. Mobile application security aims to safeguard mobile applications from reverse engineering attacks, tampering, malware, debugging, and emulator attacks, as well as some platform-specific mobile threats such as screen recording (iOS).

A solid mobile application security strategy should implement a layered approach and incorporate multiple mobile app security measures such as RASP mechanism and code obfuscation.

To aid them in the debugging process, programmers use debuggers. A debugger is a tool that enables you to view the application code while it is running. You can stop the execution of the program, analyze variable values, execute the program in steps (line after line), set breakpoints on specific lines which stop the execution, and more. This detailed view of the code in its running mode enables you to understand flows and application logic, as well as to detect errors within the code.

Although mobile debuggers are convenient tools for making sure that the application code is running properly, mobile debuggers can also be used for malicious practices. In case a bad actor uses a debugger on a legitimate application, they can easily assemble a malicious copy of the app by understanding the application logic revealed by the debugger.

Mobile Device Management (MDM) is software that enables IT to control, secure, and automate administrative policies on employees' devices connected to the organization's network. Generally, the goal of Mobile Device Management software is to optimize device support, enhance enterprise functionality and security while preserving flexibility (e.g., BYOD policies).

Mobile emulators are tools designed for running tests on mobile devices using desktop computers, particularly useful when it comes to testing mobile applications. They allow developers to simulate, imitate, and optimize mobile app software and hardware behavior without the need to use multiple types of devices.

L

Liability shift is a scenario in which chargeback responsibility shifts from merchant to the issuing bank when a credit card is 3D secured. When a 3D Secure transaction proves to be a fraudulent one, Issuing bank is the one that needs to return those funds to the damaged cardholder.

K

The Know Your Customer/Client (KYC) principle, present in the financial service's guidelines, demands that the institution makes necessary checks in order to verify the identity, suitability, and risks involved with maintaining a business relationship with its customer/client.

J

Jailbreaking (specific for iOS devices) means unlocking your phone from manufacturing restrictions made by the manufacturer, allowing the user to have root access to the device. The user can download any mobile application they wish or customize the phone’s appearance. On the downside, a jailbroken phone is more vulnerable and susceptible to hacker attacks and data leakage.

JavaScript is a programming language that enables the implementation of complex features on web pages. JavaScript enables dynamic content updates, multimedia control, image animation, etc.

I

The Issuing bank, or the Issuer, is the financial institution that issues cards to cardholders to make payments with.

H

A hacker is an individual that uses their technical skills to gain unauthorized access to computers/services/networks.

Hooking covers a wide range of code modification methods aimed at altering the behavior of the mobile application in question. This is done by intercepting function calls, messages, or events passed between the software components. The code used for function interception is called a hook. It applies to changing the behavior of operating systems and software components.

HTTP, short for Hypertext Transfer Protocol, is a protocol used for transferring files, including text, sound, video, images, etc., over the web. HTTP enables communication between the web browser and the web server.

HTTPS, short for Hypertext Transfer Protocol Secure, is the secure version of HTTP – the primary protocol used for communication between web browsers and web servers. HTTPS provides more security since it is encrypted in order to keep the data in transfer secure. HTTPS is especially important in cases where a user submits sensitive data such as credit card information on a website.

F

False declines are legitimate transaction attempts that are declined becaus of suspected fraud. They are also called ''false positives'', fully valid transactions classified and invalid, and rejected by the ACS.

A false positive, in terms of cyber security, is an alert incorrectly informing the body in charge about malicious activity.

Frictionless flow enables Issuing banks to authenticate an online transaction without interacting with the cardholder. This is possible because of Risk-Based Authentication performed in the ACS. If ACS (Issuer) deems that transaction risk is lower than the set threshold, the cardholder is not required to apply any additional authentication.

Friendly fraud differs from conventional card-not-present fraud because the fraudster is the actual owner of the payment card being used to commit a fraudulent purchase. The initial intent of the fraudster in question is to receive and retain goods and services while asking for chargeback under the claim that they are not the ones who made the purchase or that the goods were never delivered.

E

End-to-end encryption (E2EE) provides secure communication by preventing the third party from accessing the data in transfer. By implementing end-to-end encryption, the data in transfer is encrypted on the sender's side and the recipient is the only one who can decrypt the message. The data in transfer cannot be accessed by any ISP (Internet service provider), ASP (application service provider), hacker, or any other third party.

EMVCo is a global standard for credit and debit payments established by Europay, MasterCard, and VISA. It facilitates worldwide interoperability and acceptance of secure payments, as well as managing the specification of 3D Secure 2.

Encryption is a method of making the data unreadable for parties without authorized access to read the encrypted message. The plaintext – a message readable for everyone, is converted to ciphertext – incomprehensible text made up of seemingly random characters. Encryption takes simple, readable data and converts it to a seemingly random set of characters in order to make it unreadable to the unauthorized party.

D

DDoS Attack, or Disturbed Denial of Service Attack, aims to overwhelm the network with increased internet traffic in order to prevent legitimate users from accessing a particular service. The motivation behind a DDoS attack varies from financial gain, disrupting the competition and hacktivism to simply making a statement.

Decoupled authentication is an authentication method that allows cardholder authentication to be separate from the payment workflow, and without the customer interacting with the online merchant. This method verifies the customer's identity and authenticates the transaction via a separate channel, for example, a push notification. Authentication responsibility shifts to the issuing bank, enabling the execution of cardholder authentication even though the cardholder in question is offline. It allows the cardholder several days to complete the authentication process, and it is ideal when the cardholder is not immediately available for authentication, but authentication is mandatory. Therefore, decoupled authentication is a type of Merchant Initiated Transaction (MIT), and it is applicable to all device channels: browser, app, and 3RI.

Device information is data provided by the device being used in the authentication process.

A dictionary attack is a type of brute-force attack using words from a dictionary to access a password-protected network or a service. A dictionary attack is also used to discover keys for encrypting a document or a message. Although trivial, dictionary attacks have proven to be successful in the past in breaching company networks since many businesses insisted on using ordinary words as passwords. It is highly unlikely that a dictionary attack would be a successful method of breaching a system in today's cybersecurity environment.

A digital certificate is a password or a file proving the authenticity of a user, server, or device through the use of PKI technology and cryptography. Digital certificates help assure that only trusted users and devices are accessing the company's network. Other use cases for digital certificates include confirming the authenticity of a website (SSL certificates).

Information contained on a digital certificate includes the user's name, company, department, and the device's IP address/serial number. The certificates contain a public key obtained from the certificate holder and a corresponding private key to verify its authenticity. The body in charge of inspecting and verifying the identity of the certificate holder (device/user) is the Certificate Authority (CA).

Directory Server is a 3D Secure component managed by card networks/schemes operating in the Interoperability domain. Roles of the directory server include: - validating 3DS Server, SDK, and 3DS Requestor -authenticating 3DS Server and ACS - routing messages between 3DS Server and ACS - defining specific program rules (logos, time-out values, etc.) - onboarding 3DS Server and ACS - maintaining ACS and DS Start and End Protocol Versions and 3DS Method URLs

Dynamic linking demands that each transaction is assigned a unique authentication code and is specific to the transaction amount and recipient. The end goal of dynamic linking is to prevent social engineering attacks such as ''man-in-the-middle'' attack, where the fraudster attempts to interrupt the connection established between the payer and the payee, alters transaction details, and finally authorizes a fraudulent transaction. When applying dynamic linking, ''man-in-the-middle'' attacks would prove to be unsuccessful because the authentication code would automatically fail if any of the transaction details are altered.

C

A card scheme is a payment network providing the infrastructure for card issuing and card payment processing, for example, Visa and MC. To make the payment possible, both Issuing and Acquiring banks need to be members of the same network as the card being used to process a payment.

Card-not-present fraud is a type of payment card fraud where the merchant is not able to physically examine the card being used because it is used for making an online or mobile purchase. It is a broad term that includes all payment card fraud where the physical credit/debit card is not showcased.

A Card-On-File transaction is a transaction where a cardholder allows the merchant to save their payment card details to avoid manual input in the future.

Cart Abandonment Rate is a common KPI used for measuring the performance of a web store. It indicates how many customers added an item to their online shopping cart but never finalized the purchase. In other words, it showcases the rate of customers who showed interest in a particular product/service by adding it to the cart but left without making the purchase, compared to the total number of completed transactions.

The formula for calculating Cart Abandonment Rate is as follows:
1 - ( transactions completed/transactions initiated * 100 )

Chargebacks are a way of customer protection that guarantees a return of funds in particular cases. Common reasons for incoming chargeback disputes include fraudulent transactions, item not received, processing issues, etc. If the cardholder has any reason to believe that their payment card was/is used in a fraudulent manner, e.g., an unfamiliar transaction on their billing statement appears, they are able to file a dispute and initiate the chargeback process.

Clickjacking refers to the malicious practice of concealing hyperlinks beneath seemingly clickable content in order to lure the user into unknowingly performing actions such as triggering the installation of malware.

CNP Fraud, short for Card-Not-Present Fraud, refers to all types of credit card fraud where a credit card is not physically present. CNP Fraud typically occurs in online transactions and MOTO (Mail Order/Telephone Order) transactions. CNP fraud is generally harder to prevent, taking into consideration the fact that the merchant cannot examine the physical credit card used for a purchase.

Code injection refers to all attack types that include injecting malicious code executed by the targeted application. The attacker uses a vulnerable end-point of an application to inject malicious code that changes the execution course of the application in question.

Code obfuscation is the process of altering the initial code in a way that can't be interpreted by a hacker while the code remains fully functional. For a layered approach and enhanced security, use several different code obfuscation techniques on top of each other. Code obfuscation is an effective method for preventing reverse engineering attacks that aim to disassemble the software in order to understand its logic and finally copy the entire application. Some popular code obfuscation techniques are rename obfuscation, packing, dummy code insertion, and metadata and unused code removal.

Credential stuffing is an automated cyberattack that uses stolen credentials and injects them into website/service forms in order to gain unauthorized access to the accounts.

Challenge request signals that cardholder interaction is necessary for successful authentication. In an app-based scenario, CReq is sent by the mobile SDK, and in a browser scenario, it is sent by 3DS Server.

Challenge response signals the result of cardholder authentication (sent by the ACS), successful or unsuccessful.

A cryptographic key is a string of characters resulting from an encryption algorithm. Just like a standard key, a cryptography key has the ability to lock (encrypt) and unlock (decrypt) data, so only the entity owning the ''right'' key can gain access to the encrypted message.

Cryptography studies secure communication methods that assure that only the sender and the intended recipient of a message can access its contents.

Cybersecurity is a proactive measure that includes the protection of networks, programs and systems from attacks. Cyberattacks aim to change, access or destroy sensitive information, money extortion from unsuspecting users, or interrupt businesses from daily operations.

B

A backup refers to making copies of original (digitally stored) documents in or to prevent loss in case the original gets altered or deleted. Other use cases for a backup include preserving historical data in order to meet the data retention policies or to compare them with current data.

Behavioral authentication is the process of authenticating the user based on their unique patterns of interaction with the device used for authentication. Examples of behavioral authentication factors are keyboard pressure, typing speed, and the angle at which a user holds the device (smartphone, tablet).

Biometric Authentication is a way of verifying someone's identity by using unique biological characteristics. It is based on comparing biometric data captured, e.g., for the sake of authenticating a transaction, with biometric data stored in the database. Types of biometric authentication include face recognition, fingerprint scanning, and voice recognition.

A bot, which is short for robot, refers to a specific type of software application able to perform scripted, automated tasks upon command.

A brute-force attack, due to the simplicity of its execution, is one of the most popular hacking methods out there. A brute-force attack involves guessing a series of usernames and passwords until the targeted account is finally cracked. A more sophisticated form of a brute-force attack would involve an automated script that runs the combinations of user credentials on its own. A popular way of obtaining rich lists of user credentials and commonly used passwords is through the dark web.

BYOD, short for Bring Your Own Device, is a policy enforced by companies and enterprises that enables employees to use their own devices (smartphones, laptops, tablets) for work purposes.

A

Account Takeover Fraud, or ATO fraud, happens when a fraudster gains access to the victim's login credentials and uses the stolen account for their personal profits. That includes activities such as making online purchases using the stolen account and saved card data (card-on-file), using loyalty points, selling the account or the extracted account data on the dark web.

A typical ATO flow:
- The fraudster uses stolen credentials and accesses the victim's account
- The attacker makes necessary changes regarding account details (e.g., recovery email or phone number) so that the victim is unable to stop the attack
- The fraudster uses the account for making unauthorized online purchases or sells the account details to someone else

Merchant's bank. A bank acquiring funds for merchants from cardholders.

Access Control Server (ACS) is a 3D Secure component that operates in the Issuing domain. The role of ACS is to verify whether authentication is available for the given card number and device type, authenticate cardholders, and confirm account information for 3RI transactions.

AI, or Artificial Intelligence, simulates human intelligence through machines, predominantly computer systems. Common AI use cases include expert systems, speech recognition, natural language processing (NLP), and machine vision.

Artificial Intelligence is based on the input of labeled training data in large amounts and data analysis of the provided data. The extensive data analysis results in detecting patterns and correlations. The discovered patterns are used for making future predictions. A common example of AI would be a website chatbot programmed to recognize text and provide adequate next steps to the user.

Providers that are able to ask for permission to connect to a bank account using an API. They use that bank account information in order to provide a service. Having access to such data implies a ''read-only'' approach, i.e., they can't move the funds from the account.

An antifraud system is a software that detects and prevents fraudulent actions, most commonly fraudulent transactions. The software is based on analyzing every transaction and flagging it in accordance with its legitimacy level. Usually, an antifraud system includes a fraud-prevention system, a fraud-analysis system, and a fraud-detection system.

An API, or Application Programming Interface, is an intermediary that enables the communication between two individual applications.

A message requesting cardholder authentication. It usually contains transaction information such as cardholder name, payment information, and device details.

A message from the ACS indicating successful authentication or demanding further action in order to authenticate the transaction.

A customer's issuing bank that provides and maintains payment accounts. They publish APIs so that the customers are able to share their account data with Third-Party Providers (TPPs) in case they want them to initiate payments on their behalf.

Asymmetric cryptography, also known as asymmetric encryption or PKI (Public Key Infrastructure), is a type of cryptography that uses a mathematically connected keypair – a public key and a private key – to encrypt and decrypt the contents of the message in transfer.

Attack surface, in terms of cyber security, is the total number of entry points where a system can be attacked and data can be extracted/tampered with. A smaller attack surface would be easier to protect.

An attack vector, in terms of cyber security, is a pathway for achieving unauthorized access to a network in order to conduct a cyber attack. Attack vectors enable cybercriminals to take advantage of existing vulnerabilities within the system and gain unauthorized access to sensitive information, PII (Personally Identifiable Information), and other sensitive data available upon a data breach.

Authentication is the process of proving that an identity is valid, i.e., that the user is really who they claim to be. The most common ways of validating someone's identity nowadays include: OTP by SMS/email, biometrics (face recognition or fingerprint), and push notification.

An authentication factor is a security credential used for verifying the identity of the user gaining access or exchanging information with a particular system or a service. Today there are five main authentication factors (the first three are recognized as the official authentication factors by regulation bodies):
- Knowledge (password) - Possession (HW token)
- Inherence (fingerprint/face recognition)
- Location (IP address)
- Behavior (typing speed/pattern)

An authentication server is used for facilitating the authentication of an entity attempting to access a service or a network. An authentication server verifies whether the provided credentials match with the ones stored in the credential database.

Authorization is the process of enabling a user or a service to access particular resources. The simplest explanation of the term authorization would be ''to give permission''.

0

Two-Factor Authentication, or 2FA, is a way of confirming the user's identity by checking two out of three security elements. It is a subset of Multi-Factor Authentication and requires exactly two out of three security elements. The mentioned security elements include something the user knows (PINs, passwords), something the user owns (phone, card), or something the user is (fingerprint, face recognition).

3D Secure 1.0, also known as 3DS1, is a protocol launched by VISA in 2001 with the intention of assuring an additional security layer for online payments. VISA users are familiar with it under the name VerifiedBy Visa, but the protocol is also used by other major card schemes, including MasterCard, Amex, JCB, and Diners Club. Authentication is done by using a password or PIN during checkout as an additional step for verifying the cardholder's identity. This protocol was originally designed for browsers and had poor performance on mobile devices.

3D Secure 2.0, also known as 3DS2, is a new version of the protocol motivated by issues revolving around the initial version, 3DS1. By having access to enriched transaction and customer data, 3DS2 enabled risk assessment and frictionless (no need for CH authentication) online payments. Moreover, it introduced additional authentication methods, including biometrics, and provides a smooth user experience on mobile devices.

3D Secure protocol is an eCommerce authentication protocol enabling secured processing of online payments, non-payment, and account confirmation card transactions.

3DS Requestor is a 3D Secure component responsible for initiating the 3D Secure Authentication Request within a purchase flow, i.e., 3DS Requestor initiates the AReq message.

3D Secure SDK is software designed to facilitate cardholder authentication within a merchant's app allowing the fully in-app experience. In order to verify the cardholder's identity during an in-app purchase, 3DS SDK initiates challenge flow and displays authentication windows to the CH.

3DS Server is a 3D Secure component present on the Merchant and Acquirer side. Its role is to:
- handle online transactions and facilitate communication between the 3DS Requestor and the Directory Server
- Validate Directory Server (DS), 3DS SDK, and 3DS Requestor
- Authenticate Directory Server (DS)

3RI transactions, also known as merchant initiated transactions, are introduced in 3D secure 2. They offer merchants the possibility to generate required authentication data necessary for customer authentication without the end-user being directly involved in the process, for example, in recurring transactions like subscriptions. 3RI transactions enable merchants to reference the previous authentication where the customer was actually involved.

Secure Sign Whitepaper

Key takeaways:

Semi-digital document processing challenge
Why use Digital Signature Tools?
What should a good digital signature tool provide?
Secure Sign as your digital signing solution

Fill out the form and download the document.

Downloads Secure Sign Whitepaper (#98)

First Name

Last Name

Company Name

Phone number (optional)

AML Datasheet

Key takeaways:

Why is AML more important than ever?
How to implement an intelligent Anti-Money Laundry prevention and detection solution
Modular architecture and key benefits of the AML system

Fill out the form and download the document.

Downloads AML Datasheet (#97)

First Name

Last Name

Company Name

Phone number (optional)

Leveraging the full potential of payment data

Summary:

Mobile commerce statistics: The state of mCommerce in 2022
How to decrease cart abandonment rate on mobile?
Frictionless transactions and fresh data powered by mobile
Merchant guide for eliminating friction and lowering cart abandonment
How 3DS Mobile SDK compliments your mCommerce business

Fill out the form and download the document.

Downloads Leveraging the full potential of payment data (#94)

First Name

Last Name

Company Name

Phone number (optional)

Mobile application security: Is your app among prime targets?

Summary:

State of mobile application security in our mobile-first world
Runtime Application Self-Protection: a game-changer in mobile application security
Is your industry among prime targets?
Mobile app security powered by App Protector

Fill out the form and download the document.

Downloads Mobile application security: Is your app among prime targets? (#87)

First Name

Last Name

Company Name

Phone number (optional)

3D Secure 2 Takeover: Top Online Payments Security Trends and Predictions till 2026

Summary:

Assess your need for modularity of the solution
User-friendly administration portal as a must
Look for flexible API interface (ACS and 3DSS)
Choose ACS user interface with local/multiple language support
Apply customer-centric approach through ACS API
Opt for local country and language support
Look for omnichannel 24/7 HelpDesk service
Assure that know-how and best practices are included

Fill out the form and download the document.

Downloads 3D Secure 2 Takeover eBook (#85)

First Name

Last Name

Company Name

Phone number (optional)

How to Choose the Right 3D Secure Software

Summary:

Assess your need for modularity of the solution
User-friendly administration portal as a must
Look for flexible API interface (ACS and 3DSS)
Choose ACS user interface with local/multiple language support
Apply customer-centric approach through ACS API
Opt for local country and language support
Look for omnichannel 24/7 HelpDesk service
Assure that know-how and best practices are included

Fill out the form and download the document.

Downloads How to Choose the Right 3D Secure Software eBook (#84)

First Name

Last Name

Company Name

Phone number (optional)

Credem Case Study

Key takeaways:

Secured transactions
Improved merchant conversion
Smooth integration
Better user experience

Fill out the form and download the document.

Downloads Credem Case Study (#83)

First Name

Last Name

Company Name

Phone number (optional)

3DS Server and Mobile SDK Datasheet

Key takeaways:

Smooth integration with mobile SDK
Reduced chargeback expenses
Solution architecture
Improved in-app checkout experience
Heightened security measures
Purpose of 3DS Mobile SDK

Fill out the form and download the document.

Downloads 3D Server Datasheet (#82)

First Name

Last Name

Company Name

Phone number (optional)

Risk Scoring Datasheet

Key takeaways:

Flexible solution for fraud prevention
Business benefits of the solution
Technical features
Multi-purpose system

Fill out the form and download the document.

Downloads Risk Scoring Datasheet (#79)

First Name

Last Name

Company Name

Phone number (optional)

ACS Datasheet

Key takeaways:

Regulatory compliance
Solution benefits
Solution architecture
Key features

Fill out the form and download the document.

Downloads ACS Datasheet (#74)

First Name

Last Name

Company Name

Phone number (optional)

SxS Authentication Datasheet

Key takeaways:

Multifactor strong customer authentication
Authentication overview
Multiple authentication solutions tailored by customer needs
Key benefits

Fill out the form and download the document.

Downloads SxS Authentication (#78)

First Name

Last Name

Company Name

Phone number (optional)

FINA Case Study

Key takeaways:

Fill out the form and download the document.

Downloads FINA Case Study (#76)

First Name

Last Name

Company Name

Phone number (optional)

CMS Datasheet

Key takeaways:

The concept of CMS
Deployment options
Key benefits
Key features

Fill out the form and download the document.

Downloads CMS Datasheet (#75)

First Name

Last Name

Company Name

Phone number (optional)

Secure Sign Datasheet

Secure Sign

Learn how to move your pencil to cloud. Make digital signing secured while eliminating administrative burden forever.

Key takeaways:

Improved user experience and cost reduction
eIDAS and legal regulations
Creating a signing workflow
Key benefits
Supported platforms

Fill out the form and download the document.

Downloads Secure Sign Brochure (#77)

First Name

Last Name

Company Name

Phone number (optional)

App Protector Datasheet

Key takeaways:

App Protector Portal & SDK
Setting configuration
App Protector implementation
Main components
Key benefits

Fill out the form and download the document.

Downloads App Protector Datasheet (#70)

First Name

Last Name

Company Name

Phone number (optional)

mToken Datasheet

Key takeaways:

Strong authentication at your fingertips
How to use mToken
Key benefits
Features and technical specification
Use cases

Fill out the form and download the document.

Downloads mToken (#69)

First Name

Last Name

Company Name

Phone number (optional)

Bankart Case Study

Key takeaways:

Flexible solution implementation
Card management system integration
GDPR alignment
Adoption of 3D Secure 2

Fill out the form and download the document.

Downloads Bankart Case Study (#68)

First Name

Last Name

Company Name

Phone number (optional)

3DS Sandbox

Fill the form below. Once the form is submitted we will send you a Sandbox activation link on your e-mail. We hope you will enjoy using our 3DS Sandox interface.

Sandbox activation (#64)

First Name

Last Name

Company Name

Phone number (optional)

3DS API integration

This page describes the Asseco 3DS Service and the integration procedure with the 3DS Server.

Introduction

Service methods

The service consists of the following methods:

v2Supported – method that will check the supported version of the 3D Secure protocol for a card. The use of this method is optional and could be used in environments where fallback to 3DS 1.0.2 should be supported.
createTransaction – method that performs the AReq/ARes part of the flow and returns the status of the check for browser-initiated transactions.
authenticationResult – method that returns the authentication status for a specific 3D Secure transaction.

Security

All communication between 3DS Requestor and 3DS Service is done through a mutually authenticated TLS1.2 channel. SSL and other versions of TLS are not supported.

Integration

In order to successfully perform 3DS2 transactions, PGW’s should integrate themselves with the Asseco 3DS Server.

There are two types of 3DS2 transactions:

Transactions where the Issuer has determined that Challenge isn’t necessary. Issuer will determine whether the transaction should be authorized or not, depending on the status of the transaction.

Transactions where the cardholder will have to authenticate himself in order to successfully finish the transaction.

Fallback to 3DS v1

Fallback to v1 is not in the scope of this document since 3DS Server doesn’t handle fallback to v1 internally. It is up to the 3DS Requestors to implement the fallback functionality based on the response received from 3DS Server.

User enters card details and selects checkout
3DS Requestor initializes the transaction and calls the v2Supported method of 3DS Server.
3DS Server checks the cache and returns the response to v2Supported
3DS Requestor checks the status of the response v2Supported method
If status equals V1_SUPPORTED the 3DS Requestor should fallback to v1. Optionally, since status ERROR means that some unexpected error occurred 3DS requestors can also fallback to v1.
1. 3DS Requestor should call MPI to check the enrollment of card in 3DS v1
2. MPI sends the VEReq to Directory Server for v1
3. Directory Server checks the enrollment and returns the VERes to MPI
4. MPI evaluates the received VERes and returns the enrollment response to 3DS Requestor
5. 3DS Requestor handles the transaction according to the received enrollment status.

3DS Method Handling

The 3DS Method allows for additional browser information to be gathered by an ACS prior to receipt of the AReq message to help facilitate the transaction risk assessment. The use of the 3DS Method by an ACS is optional.

If the response of the v2Supported method has the 3dsMethodUrl set the 3DS Requestor should invoke the 3DS Method URL.
1. Create a JSON object with the 3DS Method Data elements, then Base64url encode the JSON object.
2. Render a hidden HTML iframe in the Cardholder browser and send a form with a field named threeDSMethodData containing the JSON Object via HTTP POST to the ACS 3DS Method URL.
3. If the 3DS Method completes within 10 seconds, then the 3DS Requestor will notify the 3DS Server to set the 3DS Method Completion Indicator = Y. If the 3DS Method does not complete in 10 seconds, set the 3DS Method Completion Indicator to = N.
Otherwise, the 3DS Requestor will use the value U for 3DS Method Completion Indicator parameter of createTransaction method.

Allowed values for 3DS Method Completion Indicator are:

Y - Successfully completed
N - Did not successfully complete
U - Unavailable - 3DS Method URL was not present in the PRes message data for the card range associated with the Cardholder Account Number.

The following table defines the data elements sent in the 3DS Method. The data is exchanged between the 3DS Requestor via the cardholder browser.

The HTTP field name is threeDSMethodData.

The property is a JSON object that consists of two parameters:

Data Element/Field Name	Description
threeDSMethodNotificationURL	The URL that will receive the notification of 3DS Method completion from the ACS. This is sent in the initial request to the ACS from the 3DS Requestor executing the 3DS Method.
threeDSServerTransID	A unique identifier for the transaction that will be the same as the 3DS Server Transaction ID in the AReq message.

3DS Server transaction ID: 25c1b02f-ec99-4b95-bc74-f257fd66b2ee

3DS Method Notification URL: https://nestpay.tr/core/tdsMethodCallback

Generated threeDSMethodData object:

{
    "threeDSMethodNotificationURL":https://nestpay.tr/core/tdsMethodCallback",
    "threeDSServerTransID":"25c1b02f-ec99-4b95-bc74-f257fd66b2ee"
}

Base64 encoded threeDSMethodData:

base64Encoded(Generated threeDSMethodData)

Generated HTML form containing the threeDSMethodData:

<form name="MethodForm" action="<3dsMethodUrl>" method="POST">
    <input type="hidden" name="threeDSMethodData" value="base64Encoded(Generated threeDSMethodData)">
</form>

Transaction flow

The flow of a 3DS2 transaction is as follows, this doesn’t include steps before checkout, but only after it has been determined that 3DS2 is necessary.

Call the v2Supported method in order to check whether 3DS2 is supported for the card identified by PAN and channel on which the transaction is being executed.
- If the response has been received check the received status:
  - V2_VERSION_NOT_SUPPORTED – The supported version of 3DS2 by the Issuer is not supported by the 3DS Server. Because of that the processing should stop and the transaction should not be authorized.
  - ERROR – There has been some error on the 3DS Server. It is up to 3DS Requestor to decide whether they want to terminate the transaction or fallback to 3DS v1.
  - V1_SUPPORTED – Card is not found inside of 3DS Servers cache, meaning v2 is not supported, so it is assumed that v1 is supported. 3DS Requestor sholud fallback to 3DS v1.
V2_SUPPORTED – 3DS2 is possible for the card and the processing should continue.
- If 3dsMethodUrl parameter is set, do the steps described in 3DS Method Handling chapter
- Fetch the cardholder and transaction data necessary for createTransaction method.
- Call the createTransaction method.
- If the call returned the response, check the returned transactionStatus
  - If the transStatus != C, Challenge isn’t necessary, fetch the authentication data from the response.
    - If transStatus == Y or transStatus == A, fetch the authenticationValue and eci values and use them in authorization request for the transaction.
    - Otherwise
      - terminate the processing and don’t authorize the transaction.
      - fetch the cardholderInfo, and if it contains any data, show that information to the cardholder on the merchant’s site.
  - Otherwise perform the challenge of the cardholder
    - Generate and prepare the response as described in chapter CReq request
    - Send the generated request to the cardholder
  - If the response is received on the Notification URL, call the authenticationResult method of the 3DS Server
    - If the method returned a result, check the authenticated parameter
      - If authenticated == true, fetch the authenticationValue and eci values and use them in authorization request for the transaction.
      - Otherwise, terminate the processing and don’t authorize the transaction.
    - Otherwise, terminate the processing and don’t authorize the transaction.
  - In case of timeout, also call the authenticationResult method of the 3DS Server
    - If the method returned a result, check the authenticated parameter
      - If authenticated == true, fetch the authenticationValue and eci values and use them in authorization request for the transaction.
      - Otherwise, terminate the processing and don’t authorize the transaction.
    - Otherwise, terminate the processing and don’t authorize the transaction.
  - Otherwise, terminate the processing and don’t authorize the transaction.
- Otherwise, terminate the processing and don’t authorize the transaction.

Note: Only transactions with transStatus A or Y are considered authenticated and should have the authenticationValue and eci set.

In case of transactions with Mastercard cards, eci flag will be set for all transaction statuses except status E.

When checking the Authentication results of a transaction the following procedure should be done:

Cardholder info

If the transaction is declined during the initial AReq/ARes exchange, meaning there haven’t been any authentication requests towards users, issuers can set the cardholderInfo property of the ARes response which contains additional information for cardholders that might be necessary for the successful execution of 3DS2 transaction.

3DS Server will return cardholderInfo in the response of the authenticationResult method.

The recommendation is to show this information, if available, to users on the merchant’s screen.

Request timeouts

Since at one point in the transaction the processing will be done between ACS and the cardholder, timeouts for requests/responses should be enforced.

This is especially important when waiting for a response from the ACS on the Notification endpoint.

PGW’s should have the option to define a timeout, so that after it has been reached the authentication light box/iframe should be closed/hidden, and authenticationResult of the 3DS Server should be called.

The further processing should depend on the returned authentication status.

Methods

Method v2Supported

The method that checks whether the card can be used to perform a 3DS2 transaction or not. The method will also return the 3DS Method URL if defined by the Issuer of the card.

Depending on the received status, 3DS Requestor should continue with the 3DS v2 transaction, fallback to v1 or end processing.

Path	/v2Supported/check
Supported methods	POST
Consumes	application/json
Produces	application/json

Parameter	Type	Description
pan	String	13-19 digit string representing a valid card PAN.
deviceChannel	String	Indicates the type of channel interface being used to initiate the transaction. Values accepted: 01 = App-based (APP) 02 = Browser (BRW) 03 = 3DS Requestor Initiated (3RI)

The response code when the input (PAN) is invalid should be 405. Otherwise, the service should return the status and the URL of the 3DS Server Transaction ID and 3DS Method.

The status can be one of the following values:

V2_VERSION_NOT_SUPPORTED – The supported version of 3DS2 by the Issuer is not supported by the 3DS Server. Because of that the processing should stop and the transaction should not be authorized.
ERROR – There has been some error on the 3DS Server. It is up to 3DS Requestor to decide whether they want to terminate the transaction or fallback to 3DS v1.
V1_SUPPORTED – Card is not found inside of 3D Servers cache, meaning v2 is not supported, so it is assumed that v1 is supported. 3DS Requestor should fallback to 3DS v1.
V2_SUPPORTED – 3DS2 is possible for the card and the processing should continue.

{
    "pan": 4308331682827506,
    "deviceChannel": "02"
}

{
    “versionStatus”: “V2_SUPPORTED”,
    “3dsMethodUrl”: “https://nekiurl.con/3dsmethod”,
    “3dssTransactionId”: “123e4567-e89b-12d3-a456-556642440000”
}

Method createTransaction

The method that generates the AReq message and forwards it to the Directory Server to see if Frictionless or Challenge flow should be performed.

Path	/createTransaction
Path with transaction id	/createTransaction/{3DSS_TRANSACTION_ID}
Supported methods	POST
Consumes	application/json
Produces	application/json

3DSS_TRANSACTION_ID is an optional parameter. If set the same value as received in the response of v2Supported method should be used. Otherwise, 3DSS will generate and return the value for 3DSS_TRANSACTION_ID in the response.

Values for some arguments of createTransaction are derived from functionalities and/or values available in 3DS requestor environment.

Those values should be generated by the 3DS Requestor the following way:

addrMatch is a parameter that defines whether the billing and shipping addresses are the same.

The parameter can have the following values:

Y = Shipping Address matches Billing Address
N = Shipping Address does not match Billing Address

3DS Requestor should compare the two addresses and set the appropriate value for addrMatch.

payTokenInd is an optional flag that says whether the Cardholder’s PAN has been de-tokenized by the 3DS Requestor.

The only accepted value for payTokenInd is true.

If there hasn’t been any de-tokenization of Account Number on 3DS Requestor side, this parameter should not be included in the call of the createTransaction method.

Parameter	Type	Mandatory	Description
messageCategory	int	Mandatory	Message category. Can have one of two values: Payment AuthenticationNon Payment Authentication
deviceChannel	String	Mandatory	Indicates the type of channel interface being used to initiate the transaction. Values accepted: 01 = App-based (APP) 02 = Browser (BRW) 03 = 3DS Requestor Initiated (3RI)
threeRiData	JSON Object	Optional	Indicates the type of 3RI request.
threeDSCompInd	String	Mandatory	Indicates whether the 3DS Method successfully completed. Values accepted: Y = Successfully completed N = Did not successfully complete U = Unavailable - 3DS Method URL was not present in the PRes message data for the card range associated with the Cardholder Account Number.
pan	String	Mandatory	13-19 digit string representing a valid card PAN.
cardExpiry	String	Mandatory	Expiry date of the card or token. String, 4 characters Format accepted: YYMM
payTokenInd	String	Mandatory	A value of True indicates that the transaction was de-tokenised prior to being received by the ACS. This data element will be populated by the system residing in the 3-D Secure domain where the de-tokenisation occurs (i.e., the 3DS Server or the DS). Note: The Boolean value of true is the only valid response for this field when it is present.
3dsrMerchantId	String	Deprecated	3DS Requestor assigned Merchant identifier. String, maximal length 35 characters. Unused
merchantId	String	Mandatory	Merchant identifier registered at directory server. String, maximal length 40 characters.
acquirerBin	String	Mandatory	Acquiring institution identification code as assigned by the DS. String, maximal length 11 characters.
threeDSRequestor	JSON object	Mandatory	JSON Object containing 3DS requestor info.
billingAddress	JSON object	Mandatory (if available), unless market or regional mandate restricts sending this information.	JSON object containing the billing address for the transaction.
shippingAddress	JSON object	Mandatory (if available), unless market or regional mandate restricts sending this information.	JSON object containing the shipping address for the transaction.
addrMatch	String	Mandatory	A parameter that defines whether the billing and shipping addresses are the same. Y: Shipping Address matches Billing Address N: Shipping Address does not match Billing Address
email	String	Mandatory (if available), unless market or regional mandate restricts sending this information.	Email of the Cardholder. String, maximum 254 characters Value accepted: Shall meet requirements of Section 3.4 of IETF RFC 5322.
cardholderName	String	Mandatory (if available), unless market or regional mandate restricts sending this information.	Name of the Cardholder, 2 – 45 characters.
homePhone	JSON Object	Mandatory (if available), unless market or regional mandate restricts sending this information.	JSON Object containing information about Cardholders home phone.
mobilePhone	JSON Object	Mandatory (if available), unless market or regional mandate restricts sending this information.	JSON Object containing information about Cardholders mobile phone.
workPhone	JSON Object	Mandatory (if available), unless market or regional mandate restricts sending this information.	JSON Object containing information about Cardholders work phone.
merchant	JSON Object	Mandatory	JSON object containing Merchant data.
purchase	JSON Object	Mandatory	JSON object containing Purchase data.
transType	String	Mandatory	Identifies the type of transaction being authenticated. String 2 characters.
acctType	String	Mandatory	Indicates the type of account. Length: 2 characters Values accepted: 01 = Not Applicable 02 = Credit 03 = Debit
acctID	String	Optional	Additional information about the account optionally provided by the 3DS Requestor. String, maximum 64 characters.
account	JSON Object	Mandatory	Refer to Table A.8 of the Protocol and Core Functions Specification for data elements.
purchaseInstalData	String	Conditional Required if 3DS Requestor Authentication Indicator = 03. Omitted if not an instalment payment authentication.	Three numerical characters. Value should be greater than 1.
merchantRiskIndicator	JSON Object	Optional	Merchant’s assessment of the level of fraud risk for the specific authentication for both the cardholder and the authentication being conducted. Refer to *Table A.9* of the Protocol and Core Functions Specification for data elements.
recurringExpiry	String	Conditional Required if 3DS Requestor Authentication Indicator = 02 or 03.	Date after which no further authorizations shall be performed.
recurringFrequency	String	Conditional Required if 3DS Requestor Authentication Indicator = 02 or 03.	Indicates the minimum number of days between authorizations.
browser	JSON Object	Mandatory (if available), unless market or regional mandate restricts sending this information.	JSON object containing browser data.
notificationUrl	String	Mandatory	Notification URL is the URL of an endpoint in the 3DS Requestor environment which will receive the requests from ACS containing the final *CRes* message. The endpoint is usually a part of the Merchant/PGW site.
challengeWindowSize	String	Mandatory	Dimensions of the challenge window that has been displayed to the Cardholder. Values accepted: 01 - 250 x 400 02 - 390 x 400 03 - 500 x 600 04 - 600 x 400 05 - Full screen
protocolVersion	String	Mandatory	Version of 3DS protocol to be used.

Parameter	Type	Mandatory	Description
transStatus	String	Mandatory	Character value defining the status of the execution. In case a valid *ARes* has been received the value should be equal to *transStatus* of the *ARes* message, or in case of an error the status should be E.
threeDSServerTransID	String	Mandatory	Identifier of the 3DS Server transaction.
additionalData	JSON Object	Optional	Optional transaction data that might be returned.
errorCode	String	Optional	Code defining the type of error that as occurred.
errorDescription	String	Optional	Textual description of the error.
eci	String	Optional	Electronic Commerce Indicator. In case of Visa cards, should be only present in case status is A, Y or C. But in case of Mastercard cards can be present for all returned statuses.
authValue	String	Optional	Authentication value generated by the ACS for the transaction, should be only present in case status is A or Y, should be only present in case status is A or Y.
dsTransID	String	Optional	Directory Server identifier of the transaction.
cardholderInfo	String	Optional	Short text, 128 characters, provided by the ACS/Issuer to Cardholder during a Frictionless transaction that was not authenticated by the ACS. The Issuer can optionally provide information to Cardholder. For example, "Additional authentication is needed for this transaction, please contact (Issuer Name) at xxx-xxx-xxxx."
creq	String	Optional	Base64url encoded value of the *CReq* message that should be sent to the ACS.
acsURL	String	Optional	URL of ACS endpoint to which the *CReq* message should be sent.

Example request when calling the method with the 3DS Server identifier e.g. createTransaction/050d09cc-f096-4f97-8043-b34889837887.

{
    "messageCategory": "02",
    "deviceChannel": "02",
    "threeDSCompInd": "Y",
    "pan": "4308331682827506",
    "cardExpiry": "2212",
    "3dsrMerchantId": "3dsr Merchant Id",
    "merchantId": "merchant Id",
    "threeDSRequestor": {
        "id": "239",
        "name": "EMVCo 3DS Test Requestor",
        "url": "http://www.ul.com/144213bb-f034-410d-84fe-42723ff028b6",
        "threeDSRequestorAuthenticationInd": "01"
    },
    "billingAddress": {
        "line1": "Bill Address Line 1",
        "line2": "Bill Address Line 2",
        "line3": "Bill Address Line 3",
        "city": "Bill City Name",
        "postalCode": "Bill Post Code",
        "state": "USA",
        "country": "840"
    },
    "shippingAddress": {
        "line1": "Bill Address Line 1",
        "line2": "Bill Address Line 2",
        "line3": "Bill Address Line 3",
        "city": "Bill City Name",
        "postalCode": "Bill Post Code",
        "state": "USA",
        "country": "840"
    },
    "email": "x.y@mail.com",
    "cardholderName": "cardholderName",
    "homePhone": {
        "cc": "123",
        "subscriber": "123456789"
    },
    "workPhone": {
        "cc": "123",
        "subscriber": "123456789"
    },
    "mobilePhone": {
        "cc": "123",
        "subscriber": "123456789"
    },
    "merchant": {
        "mcc": "7922",
        "countryCode": "840",
        "name": "Test Merchant"
    },
    "purchase": {
        "amount": "19995",
        "currency": "191",
        "exponent": "2",
        "date": "20190523102223"
    },
    "transType": "01",
    "acctType": "03",
    "acctID": "acct ID",
    "account": {
        "chAccAgeInd": "05",
        "chAccDate": "20170101",
        "chAccChangeInd": "04",
        "chAccChange": "20170101",
        "chAccPwChangeInd": "05",
        "chAccPwChange": "20170101",
        "shipAddressUsageInd": "04",
        "shipAddressUsage": "20170101",
        "txnActivityDay": "1",
        "txnActivityYear": "1",
        "provisionAttemptsDay": "0",
        "nbPurchaseAccount": "1",
        "suspiciousAccActivity": "01",
        "shipNameIndicator": "01",
        "paymentAccInd": "05",
        "paymentAccAge": "20170101"
    },
    "purchaseInstalData": "555",
    "merchantRiskIndicator": {
        "shipIndicator": "01",
        "deliveryTimeframe": "02",
        "deliveryEmailAddress": "example@example.com",
        "reorderItemsInd": "01",
        "preOrderPurchaseInd": "01",
        "preOrderDate": "20300101",
        "giftCardAmount": "1",
        "giftCardCurr": "840",
        "giftCardCount": "01"
    },
    "recurringExpiry": "20170101",
    "recurringFrequency": "3",
    "browser": {
        "ip": "10.135.154.11",
        "language": "en",
        "javaEnabled": true,
        "acceptHeader": "text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8",
        "userAgent": "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101                 Firefox/47.0",
        "colorDepth": "32",
        "screenHeight": "800",
        "screenWidth": "600",
        "timeZone": "0"
    },
    "notificationURL": "https://3dsrequestor.asseco-see.hr/notification",
    "challengeWindowSize": "02",
    "protocolVersion": "2.1.0"
}

{
    "transStatus": "C",
    "threeDSServerTransID": "050d09cc-f096-4f97-8043-b34889837887",
    "errorCode": null,
    "errorDescription": null,
    "eci": null,
    "authValue": null,
    "dsTransID": null,
    "creq":                 "eyJ0aHJlZURTU2VydmVyVHJhbnNJRCI6IjA1MGQwOWNjLWYwOTYtNGY5Ny04MDQzLWIzNDg4OTgzNzg4NyIsIm1lc3NhZ2VUeXBlIjoiQ1JlcSIsImFjc1RyYW5zSUQiOiIyLjEuMCIsImNoYWxsZW5nZVdpbmRvd1NpemUiOiIwMiIsIm1lc3NhZ2VWZXJzaW9uIjoiMi4xLjAifQ==",
    "acsURL": "http://localhost:1234/dummy-acs-url",
    "cardholderInfo": null,
    "additionalData": {
        "ares": {
            "messageType": "ARes",
            "messageVersion": "2.1.0",
            "threeDSServerTransID": "050d09cc-f096-4f97-8043-b34889837887",
            "acsReferenceNumber": "00001ACS00001",
            "acsURL": "http://localhost:1234/dummy-acs-url",
            "acsTransID": "3cbd0751-24cd-44a2-80a9-c854e7edc3bd",
            "dsReferenceNumber": "MSIGNIA_MOCK_DS",
            "dsTransID": "1ad8dd99-cf08-405a-9607-f4a2414587af",
            "acsChallengeMandated": "Y",
            "acsOperatorID": "mX21mRFudf",
            "authenticationType": "02",
            "authenticationValue": "rsycufapnyqbdzebtdtaweekgida",
            "eci": "xs",
            "transStatus": "C"
        }
    }
}

The full list of possible transaction statuses. Some of the statuses might not be returned in the response of createTransaction response.

Status	Description
Y	Authentication/ Account Verification Successful
N	Not Authenticated /Account Not Verified; Transaction denied
U	Authentication/ Account Verification Could Not Be Performed; Technical or other problem, as indicated in *ARes* or *RReq*
A	Attempts Processing Performed; Not Authenticated/Verified, but proof of attempted authentication/verification is provided
C	Challenge Required; Additional authentication is required using the *CReq/CRes*
R	Authentication/ Account Verification Rejected; Issuer is rejecting authentication/verification and request that authorisation not be attempted.
E	3DSS error; Technical or other problem

Error codes are divided into two categories:

EMVCo 3D Secure protocol error codes
- Returned by DS and part of Erro message in additionalData object
3DSS error codes
- Returned by 3DSS in errorCode field

Value	Error Code	Error Description	Error Detail
101	Message Received Invalid	One of the following: Message is not *AReq, ARes, CReq, CRes, PReq, PRes, RReq, or RRes* Valid Message Type is sent to or from an inappropriate component (such as *AReq* message being sent to the 3DS Server) Message not recognised	One of the following: Invalid Message Type Invalid Message for the receiving component Invalid Formatted Message
102	Message Version Number Not Supported	Message Version Number received is not valid for the receiving component.	All supported Protocol Version Numbers in a comma-delimited list.
201	Required Data Element Missing	A message element defined as required is missing from the message.	Name of required element(s) that was omitted; if more than one element is detected, this is a comma-delimited list. Parent Example: messageType Parent/Child Example: acctInfo.chAccAgeInd
202	Critical Message Extension Not Recognised	Critical message extension not recognised.	ID of critical Message Extension(s) that was not recognised; if more than one extension is detected, this is a comma-delimited list of message identifiers that were not recognised.
203	Format of one or more Data Elements is Invalid according to the Specification	Data element not in the required format or value is invalid as defined in Table A.1 Message Version Number does not match the value set by the 3DS Server in the *AReq* message.	Name of the invalid element(s); if more than one invalid data element is detected, this is a comma-delimited list.
204	Duplicate Data Element	The valid data element presents more than once in the message.	Name of duplicated data element; if more than one duplicate data element is detected, this is a comma-delimited list.
301	Transaction ID Not Recognised	Transaction ID received is not valid for the receiving component.	The Transaction ID received was invalid.
302	Data Decryption Failure	Data could not be decrypted by the receiving system due to technical or other reasons.	Description of the failure.
303	Access Denied, Invalid Endpoint	Access denied, invalid endpoint.	Description of the failure.
304	ISO Code Invalid	ISO code not valid per ISO tables (for either country or currency), or code is one of the excluded values listed in Table A.5.	Name of the invalid element(s); if more than one invalid element is detected this is a comma-delimited list If Challenge Request, Purchase currency and Challenge Request.Purchase exponent form an invalid pair, list both as Error Description.
305	Transaction data not valid	If in response to an *AReq* message: Cardholder Account Number is not in a range belonging to Issuer If in response to a *CReq, and a CReq* message was incorrectly sent, one of the following: *CReq* message was received by the wrong ACS *CReq* message was not sent, based on the values in the *ARes* message *CReq* message with this ACS Transaction ID has already been received and processed	Name of element(s) that caused the ACS to decide that the *AReq* message or *CReq* message was incorrectly sent; if more than one invalid element is detected this is a comma-delimited list.
306	Merchant Category Code (MCC) Not Valid for Payment System	Merchant Category Code (MCC) not valid for Payment System.	For example, Invalid MCC received in the AReq message.
307	Serial Number not Valid	Serial Number not valid.	For example, Invalid Serial number in the PReq/PRes message (e.g., too old, not found).
402	Transaction Timed Out	Transaction timed-out.	For example, Timeout expiry reached for the transaction.
403	Transient System Failure	Transient system failure.	For example, a slowly processing back-end system.
404	Permanent System Failure	Permanent system failure.	For example, a critical database cannot be accessed.
405	System Connection Failure	System connection failure.	For example, the sending component is unable to establish the connection to the receiving component.

Error Code	Error Description	Error Detail	Action
001	Acquirer not defined	The acquirer sent in *createTransaction* request is not defined in *TDSS_ACQUIRER_BIN* table	Add the acquirer and assign it a DS
003	Invalid Response	DS returned an unexpected response	Examine the EMVCo 3DS Erro in *additionalData* to determine the problem
004	Transaction is not defined	A caller attempted to recall a transaction with an ID that is not present in the system	Check the ID being sent
005	Transaction data missing or is not valid	A mandatory data element has not been provided or is in invalid format	Examine the EMVCo 3DS Erro or *errorDescription* and *errorDetail* fields to determine the problem
006	Error generating CReq request	The *CReq* request could not be generated because of the system failure	Examine the other fields describing the error
007	Transaction timed out on DS	The timeout occurred when contacting DS	Check DS URL and if it is available to 3DSS
008	General DS communication failure	All other communication problems while contacting DS	Check DS URL and if it is available to 3DSS
009	Bad request	Data in the request are not by specification	Correct the request data
010	3D Secure Version 2 is not available	Account number (PAN) provided in *createTransaction* request is not participating in 3D Secure 2.0
011	The card range cache is empty	No information about card ranges participating in 3D Secure 2.0 is present in the database	Make sure that 3DSS initiated and downloaded card range cache (PR cache) from DS

If createTransaction method returned transStatus=C, that means that Challenge of the user should be performed.

When the deviceChannel=02 (Browser) i.e. the transaction is initiated through a browser and not through a mobile app the 3DS Requestor should generate a response that contains the returned CReq message that should be submitted to ACS.

Optional data used to accommodate the different methods 3DS Requestor systems handle session information.

If the 3DS Requestor system does not maintain a session for a given authentication session, the 3DS Requestor Session Data field can carry any data the 3DS Requestor needs to continue the session.

If the 3DS Requestor system can associate the final post with the original session without further assistance, the 3DS Requestor Session Data field may be missing.

Because the content of this field varies by 3DS Requestor implementation, the ACS must preserve the content unchanged and without assumptions.

After the authentication has been finished, the ACS will send information about the authentication status to the Notification endpoint located in the 3DS Requestor environment.

The URL of the endpoint is defined by createTransaction parameter notificationUrl.

When 3DS Requestor receives a request to the endpoint defined in notificationUrl it should call the authenticationResult method to get the final authentication results for the transaction.

Method authenticationResult

Method that returns the authentication result for the defined 3DS Server transaction id.
Depending on the type of 3DS transaction the method has an optional parameter cres which can contain a final CRes or Erro message.

Path	/authenticationResult/{3DSS_TRANSACTION_ID}
Supported methods	GET
Consumes	application/json
Produces	application/json

3DSS_TRANSACTION_ID is the identifier of the 3DS Server transaction.

Parameter	Type	Mandatory	Description
cres	String	Optional	Optional argument that contains the Base64url encoded final *CRes* or *Erro* message received by 3DS requestor on the Notification endpoint.

The method returns the status of the authentication and in case of successful authentication the Authentication Value and ECI flag.

Parameter	Type	Mandatory	Description
authenticated	boolean	Mandatory	Indicates that the authentication was successful. true – transaction authenticated false – transaction not authenticated or Erro message received.
transStatus	String	Mandatory	The final transaction status for the transaction. The list of possible transaction statuses is described in the chapter Transaction statuses.
authenticationValue	String	Optional	Authentication value generated by the ACS for the transaction should be only present in case the status is A or Y.
eci	String	Optional	Electronic Commerce Indicator.
dsTransId	String	Optional	DS Transaction Identifier, present if available.

Example request when calling the method with the 3DS Server transaction identifier identifier e.g. authenticationResult/050d09cc-f096-4f97-8043-b34889837887

{
    "authenticated": false,
    "transStatus": "N",
    "authenticationValue": "",
    "eci": "xs",
    "dsTransID": "1ad8dd99-cf08-405a-9607-f4a2414587af"
}

NOTE: After data is fetched the first time, the authentication value will be deleted from the database and an empty string will be returned every time after for the authentication value.

JSON objects

JSON object containing 3DS Requestor info consists of the following data:

id – identifier of the 3DS Requestor. String, maximum 35 characters.
name – 3DS requestor name. String, maximum 40 characters.
url – URL of the 3DS Requestor. String, should be a fully qualified URL, maximum 2048 characters
challengeIndicator – Optional, indicates whether a challenge is requested for this transaction. Possible values:
- 01 = No preference
- 02 = No challenge requested
- 03 = Challenge requested: 3DS Requestor Preference
- 04 = Challenge requested: Mandate
threeDSRequestorAuthenticationInd - Indicates the type of Authentication request. Possible values:
- 01 = Payment transaction
- 02 = Recurring transaction
- 03 = Instalment transaction
- 04 = Add card
- 05 = Maintain card
- 06 = Cardholder verification as part of EMV token ID&V
authInfo - Optional information about how the cardholder authenticated during login to their 3DS Requestor account.
priorAuthInfo - Optional information about a 3DS cardholder authentication that occurred prior to the current transaction.

Example:

“threeDSRequestor” : {
    "id":"az0123456789",
    "name":"Example Requestor name",
    "url":“https://threedsrequestor.adomainname.net“,
    "threeDSRequestorAuthenticationInd": "01”
}

JSON object containing optional information about how the cardholder authenticated during login to their 3DS Requestor account.

threeDSReqAuthData - Data that documents and supports a specific authentication process. In the current version of the specification, this data element is not defined in detail, however the intention is that for each 3DS Requestor Authentication Method, this field carry data that the ACS can use to verify the authentication process. For example, for method:
- 02 - field can carry generic 3DS Requestor authentication information
- 03 - data element can carry information about the provider of the federated ID and related information
- 04 - data element can carry the FIDO attestation data (including the signature). In future versions of the specification, these details are expected to be included.
- Length: maximum 2048 bytes
- JSON Data Type: String
- Value accepted: Any
threeDSReqAuthMethod - Mechanism used by the Cardholder to authenticate to the 3DS Requestor.
- Length: 2 characters
- JSON Data Type: String
- Values accepted:
  - 01 = No 3DS Requestor authentication occurred (i.e. cardholder “logged in” as guest)
  - 02 = Login to the cardholder account at the 3DS Requestor system using 3DS Requestor’s own credentials
  - 03 = Login to the cardholder account at the 3DS Requestor system using federated ID
  - 04 = Login to the cardholder account at the 3DS Requestor system using issuer credentials
  - 05 = Login to the cardholder account at the 3DS Requestor system using third-party authentication
  - 06 = Login to the cardholder account at the 3DS Requestor system using FIDO Authenticator
threeDSReqAuthTimestamp - Date and time in UTC of the cardholder authentication.
- Length: 12 characters
- JSON Data Type: String
- Format accepted:
  - Date format = YYYYMMDDHHMM

JSON object containing optional information about a 3DS cardholder authentication that
occurred prior to the current transaction.

threeDSReqPriorAuthData - Data that documents and supports a specific authentication process.
- In the current version of the specification this data element is not defined in detail, however the intention is that for each 3DS Requestor Authentication Method, this field carry data that the ACS can use to verify the authentication process. In future versions of the specification, these details are expected to be included.
- Length: maximum 2048 bytes
- Format: Any
threeDSReqPriorAuthMethod - Mechanism used by the Cardholder to previously authenticate to the 3DS Requestor.
- Length: 2 characters
- JSON Data Type: String
- Values accepted:
  - 01 = Frictionless authentication occurred by ACS
  - 02 = Cardholder challenge occurred by ACS
  - 03 = AVS verified
  - 04 = Other issuer methods
threeDSReqPriorAuthTimestamp - Date and time in UTC of the prior cardholder authentication.
- Length: 12 characters
- JSON Data Type: String
- Format accepted:
  - Date format = YYYYMMDDHHMM
threeDSReqPriorRef - This data element provides additional information to the ACS to determine the best approach for handing a request.
- Length: 36 characters
- JSON Data Type: String
- Value accepted:
  - This data element contains an ACS Transaction ID for a prior authenticated transaction (for example, the first recurring transaction that was authenticated with the cardholder).

JSON object containing address info used for billingAddress and shippingAddress:

line1 – First line of the street address or equivalent local portion of the address. String, maximum 50 characters.
line2 – Second line of the street address or equivalent local portion of the Cardholder address. String, maximum 50 characters.
line3 – Third line of the street address or equivalent local portion of the address. String, maximum 50 characters.
city - The city of the Cardholder address. String, maximum 50 characters.
postalCode - ZIP or other postal code of the Cardholder address. String, maximum 16 characters.
state - The state or province of the Cardholder address. String, maximal 3 characters. Should be the country subdivision code defined in ISO 3166-2.
country - The country of the Cardholder address. ISO 3166-1 numeric three-digit country code, other than exceptions listed in the table below:

ISO Code	Value Not Permitted for 3-D Secure	Definition
ISO 4217	955	European Composite Unit
ISO 4217	956	European Monetary Unit
ISO 4217	957	European Unit of Account 9
ISO 4217	958	European Unit of Account 17
ISO 4217	959	Gold
ISO 4217	960	I.M.F.
ISO 4217	961	Silver
ISO 4217	962	Platinum
ISO 4217	963	Reserved for testing
ISO 4217	964	Palladium
ISO 4217	999	No currency is involved
ISO 4217	901–999	Reserved by ISO to designate country names not otherwise defined

Example:

“billingAddress” : {
    "line1":"Bill Address Line 1",
    "line2":"Bill Address Line 2",
    "line3":"Bill Address Line 3",
    "city":"Bill City Name",
    "postalCode":"Bill Post Code",
    "state":"CO",
    "country":"840"
}

JSON object defining the phone number. Consists of the following fields:

cc – Country code. String, 1 – 3 characters.
subscriber – Subscriber number. String, maximum 15 characters.

Example:

"mobilePhone": {
    "cc":"123",
    "subscriber":"123456789"
}

Refer to ITU-E.164 for additional information on format and length.

JSON object defining merchant. Consists of the following fields:

mcc - Merchant Category Code, String 4 characters.
countryCode - Merchant Country Code. String 3 characters, ISO 3166-1 numeric three-digit country code.
name - Merchant Name. String, maximal 40 characters.

JSON Object defining Purchase. Consists of the following fields:

amount - Purchase amount in minor units of currency with all punctuation removed. String, maximum 48 characters, e.g. If the purchase amount is USD 123.45, element will contain the value 12345.
currency - ISO 4217 three-digit currency code.
exponent - Minor units of currency as specified in the ISO 4217 currency exponent. 1 character.
date - Date and time of the purchase, expressed in UTC. String, 14 characters
- Formatted: YYYYMMDDHHMMSS

JSON object containing Browser info. Consists of the following fields:

ip - IP address of the browser as returned by the HTTP headers to the 3DS Requestor. String, maximum 45 characters
language - Value representing the browser language as defined in IETF BCP47. String, 1–8 characters
javaEnabled - Boolean that represents the ability of the cardholder browser to execute Java. Accepted values are true or false.
acceptHeader - Exact content of the HTTP accept headers as sent to the 3DS Requestor from the Cardholder’s browser. String, maximum 2048 characters
userAgent - Value representing the bit depth of the color palette for displaying images, in bits per pixel. String, 1-2 characters.
colorDepth - Value representing the bit depth of the color palette for displaying images, in bits per pixel. String, 1-2 characters.
screenHeight - Total height of the Cardholder’s screen in pixels. String, 1–6 characters.
screenWidth - Total width of the cardholder’s screen in pixels. String, 1–6 characters.
timeZone - Time difference between UTC time and the Cardholder browser local time, in minutes. String, 1–5 numerical characters.

JSON object containing the 3RI Indicator.

3RI transaction is a 3-D Secure transaction initiated by the 3DS Requestor for the purpose of confirming an account is still valid. The main use case is recurrent transactions (TV subscriptions, utility bill payments, etc.) where the merchant wants to perform a Non-Payment transaction to verify that a subscription user still has a valid form of payment.

threeRIInd - Indicates the type of 3RI request.
- Values accepted:
  - 01 = Recurring transaction
  - 02 = Instalment transaction
  - 03 = Add card
  - 04 = Maintain card information
  - 05 = Account verification

Example:

"threeRiData": {
    "threeRIInd": "01"
}

This webinar covers the following topics:

Fill out the form and download the webinar.

Key takeaways:

Fill out the form and download the document.

Challenges:

Fill out the form and download the document.

Challenges:

Fill out the form and download the document.

Summary:

Fill out the form and download the document.

Summary:

Fill out the form and download the document.

Sumario:

COMPLETA EL FORMULARIO Y DESCARGA EL DOCUMENTO.

Summary:

Fill out the form and download the document.

Key takeaways:

Fill out the form and download the document.

Key takeaways:

Fill out the form and download the document.

Summary:

Fill out the form and download the document.

Summary:

Fill out the form and download the document.

Summary:

Fill out the form and download the document.

Summary:

Fill out the form and download the document.

Key takeaways:

Fill out the form and download the document.

Key takeaways:

Fill out the form and download the document.

Key takeaways:

Fill out the form and download the document.

Key takeaways:

Fill out the form and download the document.

Key takeaways:

Fill out the form and download the document.

Key takeaways:

Fill out the form and download the document.

Key takeaways:

Fill out the form and download the document.

Secure Sign

Key takeaways:

Fill out the form and download the document.

Key takeaways:

Fill out the form and download the document.

Key takeaways:

Fill out the form and download the document.

Key takeaways:

Fill out the form and download the document.

Introduction

Service methods

Security

Integration

Fallback to 3DS v1

3DS Method Handling

Transaction flow

Cardholder info

Request timeouts

Methods

Method v2Supported

Method createTransaction

Method authenticationResult

JSON objects

Example:

Example:

Example:

Example:

Reduce fraud chargeback expenses

Key Product Features