Enrollment Check

Request the Check Enrollment service only after you receive the device data collection response. If you check enrollment before receiving the device data collection response, data collection stops. Data collection can take up to 10 seconds. 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 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 assessment that results in one of these outcomes:

Frictionless success (low risk)
Challenge required (moderate risk)
Frictionless failure or decline (high risk)

Best Practices

Follow these practices for this step to achieve optimal performance:

Do not start checking enrollment until the device data collection is complete.
Notify cardholders to contact their bank for instructions if a problem occurs. Display information about additional action required of the cardholder on the checkout page. Providing instructions to the customer avoids multiple attempts to resubmit the same card.

Endpoint

POST /risk/v1/authentications

Request Fields

The consumerAuthenticationInformation.referenceId field is mapped from the consumerAuthenticationInformation.referenceId field as discussed in Authentication Setup.

The consumerAuthenticationInformation.returnUrl value is set to the URL to which the issuing bank redirects the customer as discussed in Step-Up Authentication.

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.type
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-Up Authentication 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-Up Authentication determines the actual size.

Field values must use the ISO 3166-2 format.

Interpreting the Check Enrollment Response

Check the status values in the response. These possible statuses are the same for all card types:

Status	VERes Enrolled	PARes Status	Description
`PENDING_AUTHENTICATION`	`Y`	`C`	The account number is enrolled in payer authentication and the cardholder must complete a challenge. Authenticate the cardholder before authorizing the transaction.
`AUTHENTICATION_SUCCESSFUL`	`Y`	`Y`	Frictionless authentication was successful — step-up authentication is not required. 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	`Y`	`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	`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	`Y`	`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	`Y`	`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.
`AUTHENTICATION_FAILED`: Rejected Frictionless Authentication	`Y`	`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, display a message from the card issuer to the cardholder using the consumerAuthenticationInformation.cardholderMessage field. The ACS/issuer provides the message text during a frictionless or decoupled transaction. A message example might be, "Additional authentication is needed for this transaction, contact (issuer name) at xxx-xxx-xxxx."

Important Response Fields

When you receive a PENDING_AUTHENTICATION response, you also receive these fields:

consumerAuthenticationInformation.stepUpUrl — discussed in Step-Up Authentication.
consumerAuthenticationInformation.accessToken — discussed in Step-Up Authentication.

These fields contain values used in the Step-Up service, which runs when a customer is challenged to authenticate.

Was this page helpful?

Last published: September 29, 2026