On This Page

Step 3: Payer Authentication Check Enrollment Service

Request the Check Enrollment service only after you receive the device data collection response. Checking enrollment before receiving the device data collection response stops the data collection process. Data collection can take up to 10 seconds. The merchant should set a timer that expires after 10 seconds of waiting for a response to the data collection so that the check enrollment service starts even when the device data collection response was not received.
You must include these 11 browser field values in the check enrollment request. These fields provide the information that that ensures a transaction qualifies as an EMV
3-D Secure
 transaction. The information in these fields provides a backup for the occasions when the device data collection fails to complete.
  • consumerAuthenticationInformation.deviceChannel
  • deviceInformation.httpAcceptContent
  • deviceInformation.httpBrowserColorDepth
  • deviceInformation.httpBrowserJavaEnabled
  • deviceInformation.httpBrowserJavaScriptEnabled
  • deviceInformation.httpBrowserLanguage
  • deviceInformation.httpBrowserScreenHeight
  • deviceInformation.httpBrowserScreenWidth
  • deviceInformation.httpBrowserTimeDifference
  • deviceInformation.ipAddress
  • deviceInformation.userAgentBrowserValue
With the device data collected, the issuer runs a risk assesment that results in one of these outcomes:
  • Frictionless success (low risk)
  • Challenge required (moderate risk)
  • Frictionless failure or decline (high risk)

Figure:

Process Flow for Checking Enrollment in Payer Authentication
Process flow diagram for checking enrollment in Payer Authentication

Best Practices

Follow these practices for this step to achieve optimal performance:
  • Do not start checking enrollment until the device data collection is complete.
  • Notifiy cardholders to contact their bank for instructions if a problem occurs. Information about additional action required of the cardholder should be displayed on the checkout page. Providing instructions to the customer avoids multiple attempts to resubmit the same card.

Request Fields

The
consumerAuthenticationInformation.referenceId
 field is mapped from the
consumerAuthenticationInformation.referenceId
 field as discussed in Step 1: Setup Service.
The
consumerAuthenticationInformation.returnUrl
 value is set to the URL to which the issuing bank redirects the customer as discussed in Step 4: Step-Up Iframe.
To request the Check Enrollment service, you must send the encrypted payment data or a token or some other equivalent of card data used by your integration. The request fields can include any of these:
  • paymentInformation.card.number
  • paymentInformation.fluidData.descriptor
  • paymentInformation.fluidData.value
  • paymentInformation.customer.customerID
  • tokenInformation.transientToken
These fields are required (merchant ID is in the header):
  • buyerInformation.mobilePhone
     (if no other phone number is available)
  • buyerInformation.workPhone
     (if no other phone number is available)
  • consumerAuthenticationInformation.referenceId
  • consumerAuthenticationInformation.returnUrl
  • deviceInformation.ipAddress
  • orderInformation.amountDetails.currency
  • orderInformation.amountDetails.totalAmount
  • orderInformation.billTo.address1
  • orderInformation.billTo.administrativeArea
  • orderInformation.billTo.country
  • orderInformation.billTo.email
  • orderInformation.billTo.firstName
  • orderInformation.billTo.lastName
  • orderInformation.billTo.phoneNumber
     (if no other phone number is available)
  • orderInformation.billTo.postalCode
  • paymentInformation.card.expirationMonth
  • paymentInformation.card.expirationYear
  • paymentInformation.card.cardType
  • paymentInformation.card.number
You can send additional request data to reduce your issuer step-up authentication rates. Send all available fields. As a backup, if device data collection fails, include the 11 device information fields listed among the optional fields for the Check Enrollment service in your request. If a failure does occur, adding these device information fields ensures a transaction is not downgraded. If you do not have data for a field, do not send dummy data.
The size of the step-up iframe discussed in Step 4: Step-Up Iframe can vary depending on the EMV
3-D Secure
 version of the transaction. You can request the size of the challenge window in the
consumerAuthenticationInformation.acsWindowSize
 request field.
Requesting a specific window size does not guarantee this size. Parsing the PAReq as described in Step 4: Step-Up Iframe determines the actual size.

Interpreting the Check Enrollment Response

It is important to check the status values in the response. These possible statuses are the same for all card types.

PENDING_AUTHENTICATION

  • VERes enrolled =
    Y
  • PARes status =
    C
The account number is enrolled in payer authentication. The cardholder is challenged to authenticate. Authenticate the cardholder before authorizing the transaction.

AUTHENTICATION_SUCCESSFUL

Frictionless authentication was successful/Stepup authentication is not required.
  • VERes enrolled =
    Y
  • PARes status =
    Y
The account is enrolled in payer authentication, and the cardholder was successfully authenticated. If enrollment and authorization are made in separate calls, the payer authentication data must be included in the authorization request to receive liability shift protection.

Attempt Stand-in Frictionless Authentication

  • VERes enrolled =
    Y
  • PARes status =
    A
This status indicates that the account is enrolled in payer authentication, but the issuer does not support the program. This is called
stand-in authentication
. If check enrollment and authorization are made in separate calls, the payer authentication data must be included in the authorization request to receive liability shift protection.

Card Not Enrolled

  • VERes enrolled =
    B
     or
    U
This status indicates that the account is not eligible for a payer authentication program, authentication was bypassed, or an error or timeout occurred. If enrollment and authorization are made in separate calls, you can request authorization, but there is no liability shift protection.

Unavailable Frictionless Authentication

  • VERes enrolled =
    Y
  • PARes status =
    U
This status indicates that the account is enrolled in payer authentication, but authentication is currently unavailable. The merchant can attempt to retry authentication or proceed with authorization. If enrollment and authorization are made in separate calls, you can continue and request authorization, but there is no liability shift protection. Without authentication of the customer, the merchant remains liable for any chargeback.

AUTHENTICATION_FAILED

Failed Frictionless Authentication

  • VERes enrolled =
    Y
  • PARes status =
    N
This status indicates that the account is enrolled in payer authentication but frictionless authentication failed. Merchants cannot submit this transaction for authorization. Instead, ask for another form of payment.

Rejected Frictionless Authentication

  • VERes enrolled =
    Y
  • PARes status =
    R
This status indicates that the account is enrolled in payer authentication but frictionless authentication was rejected by the issuing bank without requiring a challenge. Merchants cannot submit this transaction for authorization. Instead, ask for another form of payment.
When
an AUTHENTICATION_FAILED
 status occurs, the merchant should display a message from the card issuer to the cardholder using the
consumerAuthenticationInformation.cardholderMessage
 field. The text of the message is provided by the ACS/issuer during a frictionless or decoupled transaction to convey information to the cardholder. An message example might be, “Additional authentication is needed for this transaction, contact (issuer name) at xxx-xxx-xxxx.” An example of the entry that would appear in the log for such an occurrence is: "cardholderInfo":"You cannot complete this purchase right now. For help, call CommBank at (111) 555-2222"

Important Response Fields

When you receive a
PENDING_AUTHENTICATION
 response, you also receive these fields:
These fields contain values that are used in the Step-Up service, which runs when a customer is challenged to authenticate.