Running Payer Authentication with SDK

The payer authentication process in SDK requires checking whether a customer is participating in a card authentication program. If the customer is enrolled in payer authentication, you validate their current status in the program and authorize the transaction. The following procedures describe how to ensure the correct data values are passed during the payer authentication process.

Requesting the Check Enrollment Service (SDK)

After the SDK completes the device collection from your mobile application, and after the customer clicks the Buy button, you must make a back-end, server-to-server call to request the Enrollment Check service.

The Check Enrollment service verifies that the card is enrolled in a card authentication program. The merchant ID is included as part of the header, but these fields are required in the request:

clientReferenceInformation.code

consumerAuthenticationInformation.referenceId

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

orderInformation.billTo.postalCode

paymentInformation.card.expirationMonth

paymentInformation.card.expirationYear

paymentInformation.card.number

paymentInformation.card.type

IMPORTANT

To reduce your issuer step-up authentication rates, you can send additional request data in order. It is best to send all available fields.

Use the enrollment check and card authorization services in the same request or in separate requests:

Same request:

Cybersource

attempts to authorize the card if your customer is not enrolled in a payer authentication program. In this case, the field values that are required to prove that you attempted to check enrollment are passed automatically to the authorization service. If authentication is required, processing automatically stops.

Separate requests: Manually include the enrollment check result values (Enrollment Check response fields) in the authorization service request (Card Authorization request fields).

Be sure to include the following card-specific information in your authorization request:

For Visa, American Express, JCB, Diners Club, Discover, China UnionPay, and Elo, include the CAVV.

For Mastercard only, include the collection indicator and the AAV (also known as UCAF).

These fields are listed in this table.

Enrollment Check and Response Fields
Identifier	Enrollment Check Response Field	Card Authorization Request Field
E-commerce indicator	consumerAuthenticationInfo rmation.ecommerceIndicator	processingInformation.commerceIndicator
Collection indicator	consumerAuthenticationInfo rmation.ucafCollectionIndicator	consumerAuthenticationInfo rmation.ucafCollectionIndicator
CAVV	consumerAuthenticationInfo rmation.cavv	consumerAuthenticationInfo rmation.cavv
AAV	consumerAuthenticationInfo rmation.ucafAuthentication Data	consumerAuthenticationInfo rmation.ucafAuthentication Data
XID	consumerAuthenticationInfo rmation.xid and	consumerAuthenticationInfo rmation.xid
Result of the enrollment check for Asia, Middle East, and Africa Gateway	consumerAuthenticationInfo rmation.veresEnrolled	consumerAuthenticationInfo rmation.veresEnrolled
3-D Secure version	consumerAuthenticationInfo rmation.specificationVersion	consumerAuthenticationInfo rmation.paSpecificationVersion
Directory server transaction ID	consumerAuthenticationInfo rmation.directoryServerTran sactionId	consumerAuthenticationInfo rmation.directoryServerTransactionId

Interpreting the Response

In EMV 3-D Secure, there are two possible responses:

Frictionless: No challenge or stepup to the cardholder. While frictionless authentication can indicate a successfully authenticated outcome because the customer's card is enrolled in a payer authentication program, it can also result from the bank failing or rejecting authentication without challenging the cardholder. In the frictionless authentication flow, you receive a PAResStatus of either

, or

with an associated ECI value. With successful frictionless authentication, the PAResStatus =

and you receive a CAVV. You may also receive a PAResStatus =

indicating successful authentication but it might not include a CAVV.

Challenge: The response contains PAResStatus =

. A challenge response has a payload and contains an ACS URL and a StepUpUrl. Challenge the cardholder to provide additional authentication information and display an authentication challenge window to the cardholder so the cardholder can respond to a validation request and receive a validation response.

Authenticating Enrolled Cards

In the response from the enrollment check service, confirm that you receive these fields and values:

3-D Secure version = 2.x

VERes enrolled = Y

PARes status = C

These values identify whether it is a EMV 3-D Secure 2.x transaction and that a challenge is required.

Once you validate these fields, you call
Cardinal.cca_continue
(Android SDK) or
Cardinal session continue
(iOS SDK) for the SDK to perform the challenge between the customer and the issuing bank.

Requesting the Validation Service

For enrolled cards, the next step is to make a back-end, server-to-server call to request the validation service.

When you make the validation request, you must:

Send the

consumerAuthenticationInformation.authenticationTransactionId

request field.

Send the credit card information including the PAN, currency, and expiration date (month and year).

The response that you receive contains the validation result.

It is recommended that you request the payer authentication and card authorization services at the same time. Doing this automatically sends the correct information to your payment processor and converts the values of these fields to the proper format required by your payment processor:

consumerAuthenticationInformation.ecommerceIndicator

consumerAuthenticationInformation.cavv

consumerAuthenticationInformation.ucafAuthenticationData

consumerAuthenticationInformation.xid

and

consumerAuthenticationInformation.xid

If you request the services separately, manually include the validation result values (Validation Check response fields) in the authorization service request (Card Authorization request fields). To receive liability shift protection, you must ensure that you pass all pertinent data for the card type and processor in your request. Failure to do so might invalidate your liability shift for that transaction. Include the electronic commerce indicator (ECI), the transaction ID (XID), the 3-D Secure version, the directory server transaction ID, and this card-specific information in your authorization request.

For Visa, American Express, JCB, Diners Club, Discover, China UnionPay, and Elo, include the CAVV.

For Mastercard only, include the collection indicator and the AAV (also known as UCAF).

Validation Check and Response Fields
Identifier	Validation Check Response Field	Card Authorization Request Field
E-commerce indicator	consumerAuthenticationInformation.indicator	processingInformation.commerceIndicator
Collection indicator	consumerAuthenticationInforma tion.ucafCollectionIndicator	consumerAuthenticationInfo rmation.ucafCollectionIndicator
CAVV	consumerAuthenticationInformation.cavv	consumerAuthenticationInformation.cavv
AAV	consumerAuthenticationInforma tion.ucafAuthenticationData	consumerAuthenticationInfo rmation.ucafAuthenticationData
XID	consumerAuthenticationInformation.xid	consumerAuthenticationInformation.xid
3-D Secure version	consumerAuthenticationInforma tion.specificationVersion	consumerAuthenticationInfo rmation.paSpecificationVersion
Directory server transaction ID	consumerAuthenticationInforma tion.directoryServerTransactionId	consumerAuthenticationInfo rmation.directoryServerTransactionId