has a variety of products to manage and minimize the risk of fraud that merchants face in their daily transactions. While these risk management products can operate independently to address specific areas of risk, the best results are achieved when the entire suite of products works in concert to detect patterns of fraud in a business's online activity.

This guide documents the payer authentication aspect of fraud management and how payer authentication can be used to satisfy the Strong Customer Authentication (SCA) requirement of the Payment Services Directive (PSD2) that applies to the European Economic Area (EEA) and the United Kingdom. SCA requires banks to perform additional verification when customers make payments to confirm their identity. Access to the documentation for other aspects of the risk management portfolio requires a support license for that product.

Transactions where the card is not present have a high risk of fraud, so authenticating a payer before processing a transaction greatly reduces the merchant risk for chargebacks. Payer authentication is a way of verifying that a customer making an e-commerce purchase is the owner of the payment card being used. The protocol that is followed to authenticate customers during online transactions is called EMV 3-D Secure.

This EMV 3-D Secure protocol is used by all major payment cards to implement payer authentication, but payment companies usually brand it under a different name:

• Visa: Visa Secure
• Mastercard: Mastercard Identity Check
• American Express: American Express SafeKey

Supported Card Networks

These card networks support using EMV 3-D Secure during transactions:

• Amex

• Mastercard
• Visa

Why Payer Authentication Is Needed

As e-commerce developed, the number of fraudulent transactions also grew, taking advantage of the difficulty authenticating a cardholder during a transaction when the card is not present. To create a standard for secure payment card processing, Europay, Mastercard, and Visa collaborated as EMV. Other card providers wanted input on creating new payment standards, so a consortium called EMVCo was formed with equal input from these card networks:

• Visa
• Mastercard

• American Express

EMVCo developed 3-D Secure as the protocol to provide customer authentication during an online transaction. EMV 3-D Secure reduced chargebacks to merchants, and when the buyer was authenticated, the issuing bank assumed any liability when a chargeback occurred.

The same need to reduce fraud prompted Europe to develop a standard called Strong Customer Authentication (SCA) to regulate authentication during electronic payments. The use of SCA is mandated by the European Banking Authority in the Payment Services Directive (PSD2) that took effect in 2018 to promote and regulate the technical aspects of financial transactions between merchants and their customers in Europe. SCA requires two-factor authentication. A customer must be able to authenticate by providing two of these three factors:

• Something the customer knows (such as a password, PIN, or challenge questions)
• Something the customer has (such as a phone or hardware token)
• Something the customer is (biometric data, such as fingerprint or face recognition)

Although SCA is required for almost all online transactions, some exceptions are allowed. If a payment is considered low risk, you can request an exemption from SCA to bypass authentication of the customer. The issuing bank must approve the exemption before the transaction can be exempted from SCA. Although an exemption from SCA results in a frictionless transaction, liability is not shifted to the issuing bank, and the merchant assumes responsibility for any chargeback that occurs. An exemption from SCA might apply to these types of transactions:

• Payer authentication is unavailable because of a system outage.
• Payment cards used specifically for business-to-business transactions are exempt.
• Payer authentication is performed outside of the authorization workflow.
• Follow-on installment payments of a fixed amount are exempt after the first transaction.
• Follow-on recurring payments of a fixed amount are exempt after the first transaction.
• Fraud levels associated with this type of transaction are considered a low risk.
• Low transaction value does not warrant SCA.
• Merchant-initiated transactions (MITs) are follow-on transactions that are also exempt.
• Stored credentials were authenticated before they were stored, so stored credential transactions are exempt.
• Trusted merchants registered as trusted beneficiaries, are exempt.

EMV 3-D Secure meets the SCA mandate for authenticating the customer during e-commerce transactions.

EMV 3-D Secure 2.0

To improve the customer experience, a new version of 3-D Secure is available. EMV 3-D Secure 2.x uses a less intrusive process to authenticate a buyer, which provides a better customer experience.

Enhancements to 3-D Secure 2.x include:

• More robust device data collection to improve risk analysis by the issuing bank.
• Small screens that pop up on your webpage to avoid full-page redirects.
• SDK version for mobile devices like phones and tablets.
• Streamlined shopping experience.

For a description of the customer-facing frictionless and challenge workflows, and the underlying merchant integration workflow, see How Payer Authentication Works.

Payer Authentication Configuration Testing

After the payer authentication functionality is enabled for your account and you have installed and configured the software, you must run tests to ensure that payer authentication is working properly. You must ensure that the proper data is being collected and sent to the issuer and that the proper status for a particular circumstance is returned. To ensure that the proper statuses are returned under all possible circumstances, extensive testing is required before you go live with payer authentication.

A test environment is provided to resolve any bugs in your system. In this testing environment, you can simulate various transaction scenarios with the types of payment cards that you accept. Test card numbers for the various types of payment cards are provided so that you can run transaction simulations. You can verify that the values generated during the simulations are the correct values that should occur during that transaction scenario.

When your test results are correct, contact customer support and request to go live. When you go live, use the production host name to process transactions instead of the test host name used in the test environment.

The host name for the testing environment:

POST

The host name for the production environment:

POST

Details about testing your payer authentication configuration are available in the Testing Overview section.

Payer Authentication Integrations

Payer authentication was designed to authenticate buyers during online transactions. During the early growth of internet transactions, e-commerce was conducted only on computers. Mobile phones had limited capabilities. When mobile phones (and tablets) could access the internet, online transactions quickly grew, and now they comprise almost half of all e-commerce transactions. A key part of updating the EMV 3-D Secure protocol from 1.0 to 2.0 was to ensure that payer authentication became available for e-commerce done on mobile devices.

Two types of payer authentication integration are available for merchants:

• REST API for browser authentication from a computer.
• SDK for authentication from mobile devices (available for Android and iOS). Contact support to obtain the SDK.

Integrate payer authentication for online shopping on both types of devices. The next sections in this guide describe how to integrate payer authentication into those shopping experiences.

Next Steps

For the customer and merchant workflows, see How Payer Authentication Works.

To get started with the Direct API implementation — from merchant account setup through final authentication validation — see Direct API Implementation.

For the SDK overview, see SDK Version 2.0.

For use cases, see Use Cases.

For testing, see Testing Overview.