P1: JDV
Merkow WL040/Bidgolio-Vol I WL040-Sample.cls June 20, 2003 12:46 Char Count= 0
CREDITCARDPROCESSING ANDCORRESPONDINGSET PHASES 2491997, SET Version 0.2 was released to the public, con-
taining requests for enhancements that satisfied the
additional needs of non-Visa/MasterCard issuers, such
as American Express, Japan Credit Bank (JCB), and
Novus/Discover.
On May 31, 1997, SET Version 1.0 was released to the
public.Complying with the SET Standard
Because SET is an open and neutral protocol, in theory it
is possible to purchase any implementation from anyone
who offers it without concern for proprietary ingredients.
To turn this theory into a reality, independent testing is
required to ensure compliance as defined by the specifi-
cation.
SET Version 1.0 was the baseline standard that devel-
opers used to build their systems, knowing that later ver-
sions will most certainly supersede it. As SET versions
evolved, software needed to be tested and retested for
compliance with the new standards.
Developer interpretation of the specification was at the
root of the problem. For SET to ever succeed, it needed
a single, unambiguous understanding among developers
that eliminated the possibility of proprietary implemen-
tations of SET. That is one of the major tasks of Secure
Electronic Transaction, LLP, or SETCo.Compliance Testing and Certification
SETCo operates under the sponsorship of the card asso-
ciations, but is independent of them. They assume the
responsibility for SET’s development, maintenance, evo-
lution, and market acceptance, and they regulate the use
of the SETmark for products that successfully pass a rig-
orous compliance testing program. SETCo also maintains
a dispute resolution board that decides how to best han-
dle disputes or questions regarding an implementation.
The SET Compliance Administrator (SCA) serves the ad-
ministrative functions for SETCo, evaluating test results
submitted by software developers and maintaining SET
testing tool suites.
Upon signing SETCo’s Master License Agreement and
paying the fees, developers are given testing tools and
scripts. These testing tools run through various permuta-
tions of SET messages, monitor, and log the results, and
assist in identifying noncompliance (if it occurs). Once
a developer is satisfied that its product is compliant, it
sends the test results back to SETCo for verification. After
SETCo is satisfied, it permits the developer to use the SET-
mark on its software. Each compliant software compo-
nent of SET will bear its own SETmark, attesting that
the component itself passed the battery of tests. The SET-
mark, however, does not ensure that the component will
work properly with other counterpart SET components
build by other developers. SETCo does not offer end-to-
end testing services, nor does SETCo offer interoperability
testing services.Baseline vs. Derivative Systems
SETCo established rules separating the products that
must be tested and certified from the ones that need
not be. Each unrelated operating system implementation
is considered a baseline product and must undergo fulltesting with submission of test results to SETCo. Deriva-
tive products are adaptations of baseline products in-
tended for use on similar operating systems. An example
of a derivative is a port from Solaris to AIX. The deriva-
tive must be documented for SETCo’s purposes, and test-
ing is strongly encouraged, but test results need not be
submitted and no additional fees are charged. Developers
decide which products they consider the baselines and
which ones the derivatives.
In addition to the initial testing of the baseline version,
SETCo requires developers to retest their products every
6 months. In the re-evaluation process, retesting is per-
formed using the latest testing scripts, with the results
resubmitted to SETCo for evaluation. If recertification is
not performed, the developer risks losing the use of the
SETmark. Periodically, SETCo may decide to audit com-
pleted software compliance tests. Reasons for these audits
include random selection to assure conformance and re-
ports from the field indicating suspected failures or com-
promises of security. To remain in the compliance-testing
program, developers must pay an annual fee to continue
licensing SETCo’s services.
Whereas SETCo oversees the testing that ensures direct
compliance of distinct components, the interoperability
testing between components and between products from
different companies remains the domain of SET develop-
ers, who take on the work themselves.Vendor Interoperability Testing
Recognizing that interoperability is a critical hurdle,
most SET developers agreed that their products must be
tested for interoperability before they were introduced
into the marketplace. Therefore, IBM and VeriFone pro-
duced the “Interoperability Reference Guide for SET Ver-
sion 1.0,” based on IBM and VeriFone’s experiences culled
from the testing they performed. The document describes
test scenarios, assumptions in use, configurations for
environments, and other related information. RSA Data
Security Inc. also developed interoperability documenta-
tion to assist developers. The SET 1.0 Interoperability Test
Plan defines a certificate infrastructure, data, and busi-
ness scenarios that vendors may use to test their applica-
tions among themselves.CREDIT CARD PROCESSING AND
CORRESPONDING SET PHASES
To the uninitiated, credit card processing may appear
straightforward and simple, but the complexity involved is
hidden under the covers. To help understand SET within
the context of its intended use, the following is a quick
explanation of who is involved and what happens when a
credit card charge is made and the goods are delivered.Roles in Card Processing
A cardholder is the user of a credit card that was applied
for and received from an Issuer Bank.
A merchant is an accepting destination for a credit card
charge
An acquiring bank manages merchant relationships and
accepts charge receipts from merchants as deposits
into Merchant Accounts.