How It Works

The steps of a Verified by Visa transaction are outlined and described below.

Step 1. Merchant Plug-in (MPI) software activated

The cardholder shops at a participating Internet Merchant. When the cardholder selects the “Buy” button, the Verified by Visa Merchant server software is activated.

Step 2. Merchant authentication process

The merchant server software identifies the account number and queries the Visa Directory Server. The Visa Directory Server sends a query to the Issuer’s Access Control Server (ACS). If the card participates in Verified by Visa, the Web site address of the Issuer ACS is returned to the merchant server software. If the card does not participate in Verified by Visa, the Merchant server software receives an attempted authentication response message and returns the transaction to the Merchant’s commerce server to proceed with a standard authorization request.

After the correct information is submitted by the cardholder and verified, the Issuer ACS determines whether the cardholder authentication was approved or failed, and formats an appropriate authentication response message. A cryptographic value called the Cardholder Authentication Verification Value (CAVV) is calculated and sent to the Merchant to be used later during transaction authorization. As a final step before sending the authentication response message back to the Merchant server software, the Issuer ACS digitally signs the response message.

Step 3. Issuer Access Control Server functionality

For participating account numbers, the merchant server software sends an authentication request to the Issuer’s ACS via the cardholder’s browser using the Internet address provided by the Issuer’s Server in the previous step. The Issuer ACS displays the Verified by Visa authentication window to the cardholder. The window displays information about the particular purchase to be authenticated and prompts the cardholder to enter their identity information or password. The cardholder enters the information and the Issuer ACS verifies it.

The Issuer ACS then sends a copy of the authentication response message to the Visa Authentication History Server (AHS). All authentication transaction responses (approved, attempted, failed, and not available) are transmitted and stored on the Authentication History Server. The server provides transaction reporting to Issuers and Acquirers, serving as the database of record for dispute resolution.

Step 4. Cardholder data

If the cardholder is unable to correctly enter the information requested, the cardholder is notified that he/she cannot be authenticated. Merchants can choose to request another form of payment, or to decline the transaction.

Upon receiving the authentication response, the MPI software verifies that the digital signature is from a valid participating Issuer. If the digital signature is verified and the Issuer’s authentication response contains an “Approved” or “Attempt” result, the MPI software returns the authentication response message to the Merchant commerce server. The Merchant commerce server sends an authorization request, including the Electronic Commerce Indicator (ECI) and other authentication data for authorization.

If the Merchant receives a “Failed” authentication response from the Issuer ACS, the Merchant should request another form of payment from the shopper. Merchants are not permitted to submit failed authentication transactions for authorization.

If the Merchant receives an “Authentication Unavailable” response, the Merchant continues with the standard authorization process.

Step 5. Acquirer processes authorization

The Acquirer receives the authorization request from the Merchant and sends a VisaNet authorization request.

Step 6. VisaNet passes the authorization request

VisaNet receives the authorization request and transmits the request to the Issuer.

Step 7. Issuer authorizes Internet purchase

The Issuer receives the authorization request containing additional Verified by Visa authentication information and processes the transaction. An authorization response is returned to the Acquirer and the Merchant.

The Issuer may choose to decline the authorization request for reasons unrelated to the Verified by Visa authentication (e.g., insufficient open to buy).