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 data device 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.
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 and to minimize potential operating issues.
  • 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
payerAuthEnrollService_referenceID
 field is mapped from the
payerAuthSetupReply_referenceID
 field as discussed in Step 1: Setup Service.
The
payerAuthEnrollService_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:
  • card_accountNumber
  • encryptedPayment_data
  • encryptedPayment_descriptor
  • recurringSubscriptionInfo_subscriptionID
  • tokenSource_transientToken
These fields are required (merchant ID is in the header):
  • billTo_country
  • billTo_email
  • billTo_firstName
  • billTo_lastName
  • billTo_postalCode
  • billTo_state
  • billTo_street1
  • card_cardType
  • card_expirationMonth
  • card_expirationYear
  • merchantID
  • payerAuthEnrollService_referenceID
  • payerAuthEnrollService_returnURL
  • purchaseTotals_currency
  • purchaseTotals_grandTotalAmount
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
payerAuthEnrollService_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.
For further details on individual API fields, refer to the . The field values should use the ISO 3166-2 format.
Step 3: Payer Authentication Check Enrollment Service

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.

Reason Code 475

  • 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.

Reason Code 100

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.

Attempts 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.

Reason Code 476

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
a 476
 status occurs, the merchant should display a message from the card issuer to the cardholder using the
payerAuthEnrollReply_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 example message 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"
Step 3: Payer Authentication Check Enrollment Service

Important Response Fields

When you receive a
reason code 475
 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.
Step 3: Payer Authentication Check Enrollment Service