Overview

The Real-time Data Exchange (RDX) API integrates with Visa Consumer Authentication Service (VCAS) to help with transaction authentication decisions. RDX allows the issuer to decide how much they would like to be involved in the transaction process by sharing data between VCAS and the issuer or issuer’s processor.

RDX 2.2.3 supports EMV 3DS version 2.2.0 and specific issuer EMV 3DS implementations. Each EMV 3DS protocol may require specific data elements to complete authentication. Check with your VCAS team for more details.

RDX supports four API calls:

• Risk-Based Analysis or Risk Call
• Stepup Call
• Initiate Action Call
• Validate Call

Using RDX, an issuer can tell VCAS why a cardholder responded the way they did by using the Reason Code and Reason Description fields. For example, an issuer can tell VCAS that they responded with SUCCESS for the Stepup response after the cardholder successfully authenticates the transaction.

Note: RDX uses PascalCase for object and field names.

Note: Do not add strict validation on any field marked as optional in this specification.

Risk-Based Analysis or Risk Call

Risk is the first step in the RDX process and correlates transaction, merchant, consumer, and device information to determine the level of risk in a given transaction. The responses for the risk call include:

SUCCESS: Ends the transaction with a successful authentication status to the merchant
STEPUP: Continues with the challenge flow
FAILURE: Ends the transaction with a failed authentication status to the merchant
FAILWITHFEEDBACK: Presents a screen to the cardholder with instructions to get help and will send back a failed authentication status to the merchant
ERROR: Returns an unavailable authentication status to the merchant
BLOCKED: Blocks the card and returns a failed authentication status to the merchant, future authentication attempts are failed until unblocked
REJECTED: This status ends the transaction with a rejected authentication status to the merchant and indicates to them they should not proceed with authorization

As mentioned above, with RDX the issuer can decide their involvement in the decision process. As an example, the issuer can implement the risk call which will allow the issuer to utilize their own risk/rules engine to determine the risk. The issuer also has the option to utilize VCAS for the risk assessment.

Stepup Call

If the Risk assessment results in a status of Stepup, this will determine how the issuer can challenge the cardholder. The result of this step consists mainly of a list of ways that the cardholder can be challenged, also known as “Credentials”.

The issuer may choose not to share the cardholder data or credentials with VCAS and can implement the Stepup call to tell VCAS how to challenge the cardholder. In this scenario, VCAS would pass along the PAN to the issuer during the Stepup call so the issuer could look up the cardholder and in the Stepup response send one or many options as to how to challenge the cardholder. The other option is for the issuer to provide the cardholder data to VCAS as “credentials” for use when challenging the cardholder.

Initiate Action Call

The Initiate Action call takes place once the method of Stepup authentication is identified. In the case of “One-Time Passcode” or OTP, the OTP will be sent to the cardholder’s chosen method of contact. The outcome of the Initiate Action call is the cardholder seeing the “Validate” screen. This screen will give the cardholder instructions on how to complete their authentication, whether by entering an OTP or interacting with a 3rd party application. This section needs to be updated to add that it is just not for OTP, but also for other challenge flows to confirm that we can move forward.

• Option 1: VCAS to generate, deliver, and validate the OTP. For this, the issuer would not implement the Initiate Action call.
• Option 2: Issuer to generate, deliver, and validate the OTP. For this, the issuer would implement Initiate Action and Validate calls.
• Option 3: VCAS to generate, issuer to deliver, and VCAS to validate the OTP. For this, the issuer would implement the Initiate Action call.

Note: While the Initiate Action is commonly used for OTP challenges, it can be used for other RDX challenge flows. For the Embedded Out-of-Band (OOB) flow, the Initiate Action call is not applicable.

Validate Call

In the case of the OTP authentication method, the Validate call is used to send the OTP which the cardholder entered into the VCAS Validate screen. After validation, a status is sent back. The possible statuses are:

• SUCCESS: Ends the transaction with a successful authentication status to the merchant.
• RETRY: Allows the cardholder to re-attempt authentication and validation logic can be built to limit the number of authentication attempts. Note: This status is only applicable when VCAS is not validating the issuer’s OTP or Token value.
• STEPUP: Allows the cardholder to be challenged again and will start the RDX process over again with a new RDX Stepup Request.
• PENDING: Will initiate a Validate Request from VCAS to the issuer after 2 seconds and will only be used when StepUpResponse ➤Type is OUTOFBANDOTHER or BIOMETRIC.
• FAILURE: Ends the transaction with a failed authentication status to the merchant.
• FAILWITHFEEDBACK: Presents a screen to the cardholder with instructions to get help and will send back a failed authentication status to the merchant.
• ERROR: Returns an unavailable authentication status to the merchant.
• BLOCKED: Blocks the card and returns a failed authentication status to the merchant, future authentication attempts are failed until unblocked.
• REJECTED: Only supported for 2.x.x transactions. This status ends the transaction with a rejected authentication status to the merchant and indicates they should not proceed with authorization.

If a cardholder enters the OTP correctly, the transaction is successful and is returned to the merchant page. If the cardholder enters an invalid code, a failure or block may occur, thus completing the transaction with the corresponding 3DS status.

If the cardholder enters an invalid code, the issuer can decide how many attempts are allowed before the transaction is either a failure or blocked. The issuer can also choose to re-challenge the cardholder, which may result in a resend of an OTP or choose a different delivery method.

For example, if a cardholder enters the OTP via SMS too many times without success, the issuer can resend the OTP or have them choose a different delivery method. The cardholder may also ask for a resend if the original OTP is not working properly. An example is if the cardholder requests an OTP via SMS but hasn’t received any SMS and would like to try email delivery instead.

The status “PENDING” is used for out of band authentication methods (e.g. Biometrics); if the cardholder has not authenticated yet the issuer would return a status of “PENDING”. The client is responsible for managing and keeping track of the validation, so having this called out here will help them think on how to track internally.

Risk Indicator Values

The Risk Indicator value is set during risk or challenge flows to indicate the risk level or challenge type. The value is then used in the construction of certain Authentication Values (AV). For example, CAVV Usage 3 Version 0 & CAVV Usage 3 Version 7 allows for this value to be passed within the AV value that is sent to the networks Directory Server (DS).

Review Risk Indicator Values or contact your VCAS representative or consult the “VCAS Enhanced AV” documentation for more details.

Backwards Compatibility

RDX features backwards compatibility to gracefully handle new EMV 3DS versions as they are introduced. This feature allows VCAS clients to upgrade their RDX version independent of when new EMV 3DS versions become available. When VCAS enables a new EMV 3DS version, any existing EMV 3DS field that gets a new value will be re-mapped to a previous EMV 3DS version value (for example Merchant Challenge Indicator & 3RI Indicator). For any net new field and values, those will be dropped for any previous RDX version, which will allow issuers to upgrade to the latest RDX version based on their own development timelines.