Introduction to Payer Authentication

Cybersource
 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.
  • Payer Authentication: uses the 3-D Secure protocol in online transactions to verify that payment is coming from the actual cardholder. Most transactions can be authenticated without the customer being aware of the process, but higher risk transactions might require an exchange of one-time passwords (OTPs) during authentication. This authentication of the payer before the transaction is authorized benefits the merchant by shifting chargeback liability from the merchant to the card issuer. You can use Decision Manager with payer authentication services so that the risk level of an order determines when to invoke payer authentication. For example, low-risk orders can be set to skip payer authentication and proceed directly to authorization.
  • Decision Manager: uses AI to help large enterprises analyze the vast amount of data from their online transactions to detect known patterns of fraudulent behavior. Each potential transaction can be compared to past patterns and automatically assigned a risk score before authorizing a transaction. Behavior analysis of past transaction data enables you to recommend rules that identify risky transactions and to suggest how to handle them. Machine learning capabilities in Decision Manager enable you to create hypothetical environments to test strategies for dealing with risky scenarios so that you can either reject them or require payer authentication.
  • Fraud Management Essentials: helps small-to-medium businesses monitor their online transactions using AI and preconfigured rules to spot and avoid fraudulent transactions. You can adjust the fraud detection settings to match your risk tolerance and manually review transactions flagged for risk review.
  • Account Takeover Protection: monitors customer account activity to detect compromised accounts. You create account events and define rules to determine the types and levels of activity in a customer account that trigger a manual review for potential fraud. The activity data that happens within a customer account can be easily integrated into Decision Manager and used to assess risky payment behavior.
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
Cybersource
 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
  • JCB: J/Secure
  • Discover/Diners: ProtectBuy
  • Elo: Compra Segura (Secure Shopping)
  • Cartes Bancaires: FAST’R
  • UnionPay International: UnionPay 3-D Secure

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 to enable equal input from Visa, Mastercard, JCB, American Express, China UnionPay, and Discover.
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.
For additional information about transactions that are exempt from SCA, see the Payments Developer Guide.
EMV 3-D Secure meets the SCA mandate for authenticating the customer during e-commerce transactions.
Introduction to Payer Authentication

EMV 3-D Secure 2.0

To improve the customer experience, a new version of 3-D Secure was developed. 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.
IMPORTANT
On September 25, 2024, support for EMV 3-D Secure 2.1.0 ended. Merchants and their acquirers must support EMV 3-D Secure 2.2.0 or a later version before that date so that transactions can continue without any interruption in service. Contact support for additional information on updating your system to use EMV 3-D Secure 2.2.0.
Introduction to Payer Authentication

Payer Authentication Customer Workflow

During authentication for each transaction, data is collected about the customer's device, and the shipping and billing information is compared with transaction history. The workflow in payer authentication can go one of two possible ways: frictionless and challenge (also known as
step-up
).

Figure:

Payer Authentication Workflow
Payer Authenticatiion Workflow Diagram

Frictionless Workflow

With frictionless flow, the authentication process is not visible to the customer. The data collected during the transaction matches the data collected from past transactions with the customer. The risk for fraud is calculated to be low enough that further authentication is unnecessary. The transaction can continue to authorization.
  1. The customer enters card information at checkout. Information about the device being used by the customer and shopping behavior is collected and relayed from the merchant to the issuing bank. A delay of about 10 seconds is built into the process to ensure that the device data can be transmitted and assessed before the
    Buy
     option is enabled.
  2. The customer selects
    Buy
    .
  3. The issuing bank verifies the information it receives against previous transactions. If the device data correlates with the information, the transaction is approved without the buyer having to provide any additional information.

Challenge Workflow

A challenge flow occurs when the data collected during the transaction does not match the information on file from previous transactions with the customer. This process occurs for multiple reasons and does not necessarily mean that the customer has fraudulent intent. For example, it could occur because the customer got a new device that has not been registered yet or because they bought something while traveling. The issuer of the card decides whether further authentication of the customer is required and if necessary, requests that the customer prove their identity by returning a passcode to the issuer. This sequence describes the interaction from the customer viewpoint.
  1. The customer enters card information at checkout. Information about the customer's device is collected and sent from the merchant to the issuing bank.
  2. The customer selects
    Buy
    .
  3. The issuing bank assesses risk by comparing the information it receives to information on file from previous transactions with the customer. If the device data does not match the information collected previously, the issuer requests further authentication.
  4. A small window opens on the checkout page where a message from the bank asks if the customer wants to use email or text message to receive a one-time password (OTP) from the bank.
  5. The customer chooses how the password is sent.
  6. The issuer sends an OTP to the account on file for the customer.
  7. A window opens on the checkout page on the customer device prompting the customer to enter the OTP sent by the issuer.
  8. The customer enters the password that they received and sends it back to the issuer.
  9. If the password entered by the customer matches the password sent by the issuer, the customer is authenticated, and the transaction can proceed to authorization. If the password does not match the password that the bank sent, the customer receives a message that the transaction is declined and that they should attempt another form of payment.
Introduction to Payer Authentication

Payer Authentication Merchant Workflow

Transaction circumstances might result in differences to the more detailed payer authentication process described below.
  1. Before the
    Buy
     button is selected at checkout, the Setup service is called. The full card number identifies how to contact the issuing bank. The issuing bank sends an access token and a URL (called the
    DCC URL
    ) to use for the data collected about the device where the transaction is occurring.
  2. The merchant collects data about the device and includes billing and shipping information. The merchant posts this data to a hidden 10 pixel x 10 pixel iframe to send to the DDC URL provided by the card issuer for comparision with past transactions. After the data points are collected and sent, the issuing bank confirms that data collection ended and the
    Buy
     button is enabled. An 8-10 second delay ensures enough time for data collection.
  3. Clicking
    Buy
     triggers the Check Enrollment service sending the order data (and session ID) to the issuer. If the bank is not part of an EMV 3-D Secure program, the payer authentication process stops. If the issuing bank is part of an EMV 3-D Secure program, the device data is compared to information on file collected at the bank during previous transactions with the cardholder.
    • The issuer's risk analysis software determines whether enough data points collected by the merchant match the data in the bank's files. If the data matches well, no further interaction is needed. This is called
      frictionless flow
       because no challenge to the buyer is necessary. The response returned to the merchant includes a payload with values like the
      ECI
      ,
      CAVV
      ,
      DS Transaction Id
      , and the
      PARes Status
      . These values must be passed on during the request for authorization. It is important to note that while frictionless flow can occur because the payer is authenticated, it can also occur for other reasons. For example, the issuing bank does not participate in payer authentication. Therefore, response values must be verified to determine why no step-up is needed.
    • If a significant discrepancy occurs between the transaction data and the data on file with the bank, the bank requests that the payer authenticate. This is a friction workflow and is called a
      step up
       or
      challenge
      . The response from the bank contains the same values returned for a frictionless workflow but also includes additional values like the
      Access Control Server (ACS) URL
      , the
      PAReq
       payload, a
      Pares Status
       = C, a
      Step Up URL
      , a new
      JWT
      , and a
      Transaction Id
      .
  4. The JWT and the step up URL received in the check enrollment response are returned to the customer. Using the step up URL with the JWT as a POST parameter, a challenge screen opens in a viewable iframe on the buyer's device so that the cardholder can view and respond to the bank challenge. The challenge consists of the bank sending a pass code that the customer returns to the bank. The challenge asks how the customer wants to receive a pass code, by text or email. After the customer chooses, they receive a pass code that they must enter into the challenge screen.
  5. After the cardholder enters and sends the passcode, the response is sent to the merchant's return URL contained in the JWT. This response causes the merchant to make a validation call to the bank to obtain the final authentication outcome. The response to this validation request contains the final authentication results including these values: ECI, CAVV (if successful),
    DSTransactionId
    ,
    ThreeDSVersion
    , and PARes Status (
    Y
     or
    A
     = successful or
    N
    ,
    U
    ,
    R
     = failed, unavailable, or rejected).
  6. The next action depends on the outcome:
    • Successful: proceed to authorization, and append the EMV 3-D Secure data points to the authorization message.
    • Failed, unavailable, or rejected: display a message to prompt the customer to try payment with a different card.
Introduction to Payer Authentication

Acquirer Information

To properly configure payer authentication,
Cybersource
 needs three items of information that your acquiring bank uses to manage payments to your account. If you do not know this information, contact your acquiring bank.
  • Acquiring Merchant ID (MID): This unique identifier for your business account is assigned by your acquiring bank or payment processor. A MID consists of 8-24 alpha-numeric characters. The MID can be different than the business deposit identifier used in settlements.
  • Acquiring Bank Identification Number (BIN): This unique number is assigned to the acquiring bank by a payment card network to identify that bank when settling transactions. Each payment card assigns its own BIN for an acquiring bank, and the BINs have their own unique characteristics. For example, all Visa BINs start with a 4, Mastercard BINs start with a 2 or 5, and Discover BINs start with a 3 or 6.
  • Merchant Category Code (MCC): This four-digit numeric value is assigned by the acquirer to the merchant to classify the merchandise or services provided by the business. The MCC indicates the kind of business transaction that the merchant processes.
Introduction to Payer Authentication

Enable Merchant Account for EMV 3-D Secure

Partners and merchants use the Business Center to go online and view transaction activity and to generate reports about their transactions. For each partner, an account is created, and a portfolio merchant ID (MID) is assigned. For each of the merchants within the partner's portfolio, an account is also created and assigned a merchant ID (MID). Access to the various functions in the Business Center is managed by the partner through the MID.
When the MID account is created, the various services that the merchant needs must be enabled. Payer authentication is a service that might need to be turned on by support. To set up an account for payer authentication, you need this information:
  • MID.
  • Merchant website URL.
  • Two-character ISO code for your country.
  • Merchant category code.
  • EMV 3-D Secure requestor ID (optional).
  • EMV 3-D Secure requestor name (optional).
  • Name of merchant's bank.
  • Name, address, and email address of bank contact.
For each payment card that you accept, your acquirer must provide you with this information:
  • Eight-digit BIN number.
  • Merchant ID assigned by your acquirer.
  • List of all of the currencies that you can process.
Introduction to Payer Authentication

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 sandbox testing 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, you will use the production host name to process transactions instead of the test host name that you used when processing transactions in the test environment.
The host name for the testing environment:
POST
https://apitest.cybersource.com
The host name for the production environment:
Details about testing your payer authentication configuration are available in the Testing Payer Authentication Services section.
Introduction to Payer Authentication

Request Endpoints

When posting a request for payer authentication, you must add an endpoint to each hostname, whether you are using the test environment or the production environment. These endpoints are used with payer authentication.
/risk/v1/authentications
: use when verifying that a card is enrolled in a card authentication program or requesting authentication from the issuer.
/risk/v1/authentication-results
: use when retrieving and validating authentication results from the issuer so that the merchant can process the payment.
/pts/v2/payments
: use when bundling multiple payments together.
For example, a test request might look like this:
POST
https://apitest.cybersource.com
/risk/v1/authentications
Introduction to Payer Authentication

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:
  • API for browser authentication from a computer.
  • SDK for authentication from mobile devices (available for Android and iOS). Contact support to obtain the SDK.
IMPORTANT
Payer Authentication supports message-level encryption. For more information, see Message Level Encryption.
Merchants should 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.
Introduction to Payer Authentication