The Internet Encyclopedia (Volume 3)

P1: JDV

Merkow WL040/Bidgolio-Vol I WL040-Sample.cls June 20, 2003 12:46 Char Count= 0

LESSONSLEARNED ANDNEWDIRECTIONS INSECUREONLINEPAYMENTS 257

card authentication passes or fails. The card authentica-

tion results in information that is formatted into the re-

sponse message.

After the password and/or smart Visa card is verified,

the issuer access control server determines whether the

cardholder authentication has passed or failed and for-

mats an authentication response. The issuer server also

sends a copy of the authentication response message to

the authentication history server. All attempted authenti-

cation transaction responses (passed, failed, and not avail-

able) are transmitted and stored in the authentication his-

tory database.

Step 4. The Merchant Processes the Authorization

Upon receiving the authentication response, the merchant

plug-in verifies that the authorization response message

is from a valid participating issuer. If it is verified and the

issuer’s authentication response contains a “passed” re-

sult, the cardholder is deemed “authenticated.” The mer-

chant plug-in returns the authentication response mes-

sage to the merchant storefront software. If the merchant

receives a “failed” authentication response from the is-

suer server, the merchant should request another form of

payment from the shopper. Merchants are not permitted

to submit failed authenticated purchases for authoriza-

tion.

Step 5. The Merchant Acquirer Processes the Autho-

rizationThe acquirer receives the authorization request

from the merchant. The Verified by Visa data fields are

mapped into existing VisaNet fields.

Step 6. VisaNet Verifies the Authentication and Pro-

cesses the AuthorizationThe VisaNet integrated pay-

ments (V.I.P.) system receives the authorization request

containing the authentication data from the acquirer.

These transactions are processed as standard service elec-

tronic commerce transactions.

Step 7. The Issuer Authorizes Internet PurchaseThe

issuer’s authorization center receives the request with au-

thentication data and processes the transaction.

By mid-2002, Verified by Visa was implemented at a

number of major online merchants and offered to the

cardholders of Bank of America, First USA, and Bank One.

Secure Payment Application (SPA)

VbV is not without its critics. Mastercard claims that the

VbV service adds processing times to transactions, takes

customers off the merchant Web site, and adds complex-

ity to integration woes, and have initially pledged not to

support it. Instead, the SPA solution is Mastercard’s an-

swer to the card-not-present transaction problem. SPA

relies on Mastercard’s universal cardholder authenti-

cation field (UCAF) infrastructure to improve online

security of payment transactions and reduce charge-

backs for fraudulent transactions. SPA consists of these

elements:

Issuer-provided SPA-enabled e-wallet,

SPA/UCAF value generation,

Cardholder authentication,

Merchant collection, presentation, and processing of SPA/

UCAF data,

Acquirer acceptance and processing of SPA/UCAF data,

Banknet support to carry SPA/UCAF data, and

Authorization support of SPA/UCAF.

Universal Cardholder Authentication Field (UCAF)

UCAF is a 32-byte field with a variable data structure that

is useful to support any number of authentication ap-

proaches to cardholder identities, including these:

SPA,

Biometrics,

Digital certificates,

Smartcards, and

Mobile and pervasive devices.

The flow for SPA processing follows:

Phase 0:Cardholders visit their credit card issuer Web

sites, register their cards with SPA, establish passwords

or PINs, and download and install SPA-enabled e-wallets.

Transaction Flow:Upon checkout, all traditional data are

still collected (name, shipping address, billing address,

etc.) whether they are filled in by the cardholder, entered

via a wallet, or already stored by the merchant. The data

are then posted to a Web page that the SPA-enabled wallet

can access.

Once the SPA-wallet retrieves the data, it generates a

payment authentication request and sends it to the issuer’s

wallet server.

Upon receipt of the data from the SPA-wallet, the is-

suer’s wallet server challenges the identity of the card-

holder using any method selected by the issuer (entry of

password or PIN, insertion of smart card, etc.). If the chal-

lenge is met with a successful response from the card-

holder, the wallet server generates a transaction-specific

authentication token and sends it back to the SPA-wallet.

This token is referred to as the SPA/UCAF.

The cardholder’s wallet then populates the merchant’s

payment page with payment card details, optionally with

the Mastercard card validation check value (CVC2), and

with the SPA/UCAF token within a hidden field. The page

is then posted back to the merchant Web server.

Once the merchant server receives the data, it formats

an authorization request to the acquirer and sends along

the SPA/UCAF token as a new attribute in the request.

The authorization request is then placed on Banknet

and routed to the issuer bank for a response.

When the authorization request is received, the issuer

bank validates that the SPA/UCAF is authentic and has

not been previously used with a different transaction; it

then issues an approval or declines the request based on

the state of the underlying payment card. The response is

then returned through the networks back to the merchant

server for further processing of the sale.

SPA is intended to offer the digital equivalent of a phys-

ical cardholder signature on a record of charge, and bring