CFX_NOVA_JAVA™ - A ColdFusion® tag that supports direct, secure submission of credit card transactions to Elavon - Installation & User Guide

collectivemodernSoftware and s/w Development

Jun 30, 2012 (4 years and 11 months ago)

1,584 views


© 2005 CFXWorks, Inc. All Rights Reserved 1

CFX_NOVA_JAVA



A ColdFusion
®
tag that supports direct, secure submission of
credit card transactions to Elavon*



(* formerly Nova Information Systems)



Installation & User Guide

Software Information Installation and User Guide Information
Software Version: 11
Published: 02/22/2006
Updated: 03/24/2006
Updated: 09/01/2007
Updated: 10/05/2008

Document: CFXNovaJava.pdf
Published: 02/22/2006
Updated: 03/24/2006
Updated: 09/01/2007
Updated: 10/05/2008
Updated: 10/15/2008
Updated: 10/28/2008



CFXWorks, Inc.
5365 Chelsen Wood Drive, Duluth, Georgia 30097


Email: sales@cfxworks.com
http://www.CFXWorks-Coldfusion.com


Printed in the United States of America.

© 2005 CFXWorks, Inc. All Rights Reserved 2


1. INTRODUCTION.....................................................................................................4
1.1. T
HANK
Y
OU
.........................................................................................................4
1.2. U
PDATE
................................................................................................................4
1.3. C
ERTIFICATION
....................................................................................................4
1.4. W
HAT IS
CFX_NOVA_JAVA?...........................................................................4
1.5. A

M
ERCHANT

S
R
ELATIONSHIP
W
ITH
E
LAVON
...................................................4
1.6. M
ERCHANT
F
EES
..................................................................................................6
1.7. CFX_NOVA_JAVA

S
OFTWARE
F
EES
................................................................7
1.8. CFX_NOVA_JAVA

P
RODUCT
R
EQUIREMENTS
..................................................7
1.9. S
ECURITY
C
ONCERNS
.........................................................................................10
1.10. W
HO
S
HOULD
U
SE
CFX_NOVA_JAVA?.....................................................11
1.11. W
HO
S
HOULD
N
OT
U
SE
CFX_NOVA_JAVA?.............................................12
2. HOW CREDIT CARD PROCESSING WORKS VIA THE INTERNET.........13
2.1. I
NTERNET
B
ASED
P
ROCESSING
...........................................................................13
2.2. W
HAT
M
AKES
CFX_NOVA_JAVA

D
IFFERENT
...............................................14
2.3. W
HAT
I
NFORMATION
M
UST THE
M
ERCHANT
P
ROVIDE
......................................14
2.4. M
ODES OF
O
PERATION
.......................................................................................16
2.5. T
YPES OF
T
RANSACTIONS
S
UPPORTED
...............................................................17
2.6. MD5

M
ESSAGE
D
IGESTS
....................................................................................19
2.7. AES

E
NCRYPTION
..............................................................................................20
2.8. AVS...................................................................................................................20
2.9. C
ARD
V
ERIFICATION
V
ALUE
2

(CVV2).............................................................21
2.10. AVS
AND
CVV2

C
OMMENTS
.........................................................................21
2.11. V
ISA
3D

S
ECURE
&

M
ASTER
C
ARD
S
ECURE
C
ODE
..........................................21
2.12. R
EOCCURRING
P
AYMENT
F
EATURE
................................................................22
3. CFX_NOVA_JAVA PRODUCT DESCRIPTION...............................................22
3.1. I
NSTALLATION ON
C
OLD
F
USION
........................................................................22
3.2. I
NSTALLATION ON
B
LUE
D
RAGON
.......................................................................25
3.3. P
ERFORMANCE
I
SSUES
.......................................................................................28
3.4. M
INIMUM
S
YSTEM
R
EQUIREMENTS
....................................................................28
3.5. S
OFTWARE
L
ICENSE
...........................................................................................28
3.6. E
XPORT
L
IMITATIONS
........................................................................................28
3.7. F
UTURE
P
OSSIBLE
E
XTENSIONS
.........................................................................29
3.8. S
UPPORT
.............................................................................................................29
3.9. W
ARRANTY
........................................................................................................29
4. HOST BASED PROCESSING USING THE ELAVON TAG............................30
4.1. O
VERVIEW
.........................................................................................................30
4.2. T
AG
P
ARAMETERS
..............................................................................................30
4.3. E
LAVON
T
EST
S
ERVER
&

S
AMPLE
P
ROGRAMS
...................................................31
4.4. CFX_NOVA_JAVA

D
EMO
V
ERSION
L
IMITATIONS
..........................................32
4.5. E
LAVON
R
ECORD
N
UMBERS
...............................................................................32

© 2005 CFXWorks, Inc. All Rights Reserved 3

4.6. T
EST CREDIT CARD
N
UMBERS
.............................................................................33
4.7. C
REDIT
C
ARD
S
ALE
............................................................................................33
4.8. C
REDIT
C
ARD
A
DDRESS
V
ERIFICATION
..............................................................34
4.9. C
REDIT
C
ARD
P
RE
-A
UTHORIZATION
..................................................................35
4.10. C
REDIT
C
ARD
F
ORCE
......................................................................................36
4.11. C
REDIT
C
ARD
C
REDIT
....................................................................................36
4.12. V
OID
...............................................................................................................37
4.13. P
URCHASE
C
ARD
S
ALE
...................................................................................38
4.14. P
URCHASE
C
ARD
C
REDIT
...............................................................................38
4.15. M
AGNETIC
S
TRIPE
D
ATA
................................................................................39
4.16. D
EBIT
C
ARD
S
ALE
..........................................................................................39
4.17. D
EBIT
C
ARD
C
REDIT
......................................................................................40
4.18. P
IN
D
ATA
.......................................................................................................41
4.19. O
VERVIEW OF
B
ATCH
T
RANSACTIONS
...........................................................42
4.20. C
URRENT
B
ATCH
I
NQUIRY
.............................................................................42
4.21. P
REVIOUS
B
ATCH
I
NQUIRY
.............................................................................43
4.22. P
URGE
............................................................................................................43
4.23. S
ETTLEMENT
..................................................................................................43
4.24. MD5

M
ESSAGE
D
IGEST
..................................................................................44
4.25. AES

E
NCRYPTION
/D
ECRYPTION
.....................................................................45
5. QUESTIONS &ANSWERS....................................................................................47
5.1. H
OW DOES
CFX_NOVA_JAVA
SECURE CREDIT CARD TRANSACTIONS
?..........47
5.2. W
HY IS THE USE OF
SSL
IMPORTANT TO THE MERCHANT
?.................................47
5.3. W
HAT IS THE DIFFERENCE BETWEEN
40-
BIT AND
128-
BIT
SSL
CONNECTIONS
?..47
5.4. W
ILL
CFX_NOVA_JAVA
USE
40-
BIT OR
128-
BIT ENCRYPTION
?.....................48
5.5. W
HAT
I
S
CISP?..................................................................................................48
5.6. I
S THE
T
AG
CISP

C
ERTIFIED
?.............................................................................48
APPENDIX A. DATA SENT TO ELAVON.................................................................50
APPENDIX B. DATA RETURNED FROM ELAVON...............................................56
APPENDIX C. TRANSACTION LOG.........................................................................62
APPENDIX D. CREDIT CARD VALIDATION USING THE LUHN FORMULA 65
APPENDIX E. RESPONSES FROM TEST SERVER................................................66
APPENDIX F. CREDIT CARD PROCESSING – A STEP-BY-STEP OUTLINE...71
APPENDIX G. CHANGES FROM PREVIOUS VERSIONS OF TAG....................77


© 2005 CFXWorks, Inc. All Rights Reserved 4

1. I
NTRODUCTION


1.1. Thank You
Thank you for purchasing the CFX_NOVA_JAVA tag. As author of this
tag, it is my intent to develop an offering that adds value to your
ColdFusion efforts by providing you the ability to develop secure credit
card solutions. If you feel a need to contact me directly, please send an
email to anickles@cfxworks.com.


1.2. Update
This solution is an updated version of several Elavon gateway solutions
that CFXWorks developed and have been distributing for several years.
This version of the tag is written in Java and includes several minor
changes and a number of enhancements over the previous tag. It is being
tested on Windows, Linux, Solaris and the MAC (MAC OS X Version
10.3.7 Client and Server). Changes to the previous tag are summarized in
Appendix G – Changes From Previous Versions of Tag.

1.3. Certification
Elavon requires all “Elavon gateway” offerings to successfully execute a
Elavon defined certification test suite. This offering has successfully
completed the Elavon certification process for market segment I (e-
Commerce) and market segment G (Retail).

1.4. What is CFX_NOVA_JAVA?
CFX_NOVA_JAVA is a ColdFusion CFX tag that is intended to assist
ColdFusion programmers develop applications that communicate directly
with Elavon’s merchant services to perform direct, secure, credit card
transactions over the Internet.

CFX_NOVA_JAVA is quite fast. Response time is generally sub second
unless Elavon’s servers are overwhelmed with requests.

1.5. A Merchant’s Relationship With Elavon
Merchants can acquire credit card services directly from providers or
indirectly from 3
rd
party providers. A merchant should be careful when
choosing a provider or 3
rd
party provider and in choosing the
software used. These factors will have a significant impact on costs,
reliability and performance.

© 2005 CFXWorks, Inc. All Rights Reserved 5


Providers

A provider is an organization who provides credit card processing services
directly to a merchant and provides access to the banking institutions.
Examples of providers include Elavon, American Express, EDS Aurora,
FDMS Nashville, FDMS South, Norwest, Paymentech, TeleCheck, and
Vital.

The following figure illustrates how transactions flow from a merchant to
the provider and then to the banking institutions:


Figure 1 – Transactions Flow Direct To Elavon

Note that a transaction submitted from a merchant is sent directly to the
processor.

3
rd
Party Providers

A 3
rd
party provider is basically a reseller of a provider’s credit card
processing services. Examples of 3
rd
party providers include VeriSign,
ClearCommerce and Authorize.Net. There are thousands of 3
rd
party
providers. Most 3
rd
party providers are simply marketing organizations
who provide little value added from a technical, support or services
perspective. The following figure illustrates how transactions flow from
the merchant to a 3
rd
party provider, to the processor, and finally to the
banking institution:


Figure 2 – Transactions Flow First To 3
rd
Party Provider


© 2005 CFXWorks, Inc. All Rights Reserved 6

3
rd
party providers are sometimes called middlemen or Payment Services
Providers. They position their server between the merchant’s e-commerce
site and the actual “processor” of the credit card so they can charge you
fees on a per transaction basis? They may also provide additional services
including fraud protection schemes, tax calculation capabilities, electronic
storefronts and administration services, for which they charge you
additional fees. Therefore it is important to make sure you need the added
services provided by the 3
rd
party provider before contracting for their
services.

1.6. Merchant Fees
Merchants who process credit cards pay fees for these services either
directly to their provider or to their 3
rd
party provider. Typically these
“fees” include a discount rate, transaction fees, monthly fees and
sometimes quarterly and annual fees. The fees vary from provider to
provider, from 3
rd
party provider to 3
rd
party provider and from merchant
to merchant. There are no standard pricing models for the credit card
industry. Here are some things you should know:

Discount Rate

The “discount rate” is the percent of the total transaction amount that is
charged to the merchant, and deducted, prior to transferring funds to the
merchant’s bank account. Typically this is from 2.3% - 5%, depending on
the type of business and other factors. If the processor or 3
rd
party
processor really wants your business, these rates are negotiable.

Transaction Fees

The “transaction fee” is a flat amount that the merchant pays for each
transaction. Typical transaction fees range from 10 - 50 cents per
transaction. For the bank’s purposes, a transaction is usually defined as
any communication between the merchant and the processing network.
For example, a “Credit” transaction is treated the same as a “Sale”
transaction. Settling a batch is usually considered a transaction as well,
since it involves communications with the processing network.

If you use software provided by the processor or 3
rd
party processor,
there generally is an add-on transaction processing fee.

Monthly Fees

The “monthly fees” are charges for other account-related services, such
as customer service, monthly statements, network access fees, gateway
software fees and a minimum monthly fee. Collectively, all these fees can
amount to $25-$75 per month.


© 2005 CFXWorks, Inc. All Rights Reserved 7

If you use software provided by the processor or 3
rd
party processor,
there generally is an additional monthly fee associated with the use of
their software.

Quarterly and/or Annual Fees

Some providers charge other “hidden” fees such as quarterly or annual
charges ranging from $75-$150 per quarter and/or per year.

Frankly, you have to personally talk to the provider, or 3
rd
party provider,
to fully understand their fee structure. Just make sure you understand
exactly what you are paying up front and on a monthly, quarterly and
annual basis. If you compare the total cost of their services using their
gateway software verses using the our gateway software, you will be
amazed at the difference in costs!

1.7. CFX_NOVA_JAVA Software Fees

We charge a one time license fee for CFX_NOVA_JAVA based on a per
terminal ID. Support is optional. There is a separate charge for support.
Please, contact us at sales@cfxworks.com
for detailed pricing
information.

1.8. CFX_NOVA_JAVA Product Requirements

CFX_NOVA_JAVA is available only to merchants that
acquire their merchant account through Elavon and register
their merchant account under VenderID MA130017.

For new merchants applying for an Elavon merchant account
the process is similar in nature to applying for an actual
credit card. During the application process, Elavon
determines your transaction rate which varies depending on
many different factors.

If you happen to be a merchant with an existing Elavon
merchant account, in order to use CFX_NOVA_JAVA you
will still need to register your merchant account under
VenderID MA130017.


Since CFXWorks has no control over the period of time it
takes Elavon to register a new Merchant account or
transfer an existing account, we highly recommend that the
Merchant register (or transfer) their Elavon Merchant
Account prior to making the purchase of this tag.

© 2005 CFXWorks, Inc. All Rights Reserved 8




Registering or transferring an account can take anywhere
from several days to a couple of weeks. The duration of the
Elavon registration and transfer process is important to
note because CFXWorks will not build or ship the
production version of this tag until the merchant completes
the Elavon registration and CFXWorks verifies that the
Merchant Account has properly been registered and the
account information is correct.



It is the Merchants responsibility to be persistent with Elavon
to ensure that their Merchant Account has properly been
registered or transferred to CFXWorks' VenderID. Once
again, CFXWorks' VenderID is MA130017.


In order to help merchants establish a new merchant account,
Elavon has provided an Internet Account Check-Off Form
which should be helpful when going through the initial setup
process.


Internet Account Check-Off Form



Please download the Elavon Setup Form, which you will
need to submit to Lewis Pergament at the Fax number
provided below. Prior to faxing this document we suggest
you contact him via phone to establish the initial
relationship.


Elavon Setup Form



To register a new account or transfer an existing account,
please contact:



Lewis N. Pergament
Elavon
Relationship Manager
3200 Waterbury Drive
Wantagh, NY 11793
Office: (516) 679-5919
Fax: (516) 826-4559
Lewis.Pergament@Elavon.com




© 2005 CFXWorks, Inc. All Rights Reserved 9


After you have been approved by Elavon and have received
your terminalID, you must contact CFXWorks and supply
them with the name of the merchant
and the new
terminalID
. The TerminalID will be encrypted and
embedded in the production version of the product.



You can contact CFXWorks via email at
support@cfxworks.com or by phone at 770-441-0952.



CFXWorks keeps copies of all product builds (demo and
production) for 30 days. After thirty days we remove all
builds from our web servers. However, if you need to
download your production tag after 30 days please contact us
at support@cfxworks.com. To further assist you, we will
need the following information:

Date of purchase

Name of product purchased

Your company name

Name of person that originally purchased product.

Your contact information (email and phone number)
Once you provide us with the above information we will
gladly review our records and place a copy of your tag back
on our web server for an additional 30 days. After the
additional 30 days, we will once again remove the product
from our web servers.



Once CFXWorks has received your terminalID value and
verifies the Merchant Account has properly been registered
and the account information is correct, the production tag
will be moved out to our web server where you can
download it by:

Return to http://www.cfxworks-coldfusion.com
and
enter your username and password for the website.

Once, you are logged in navigate to [Review my
Downloads]. This should be at the bottom of the first

© 2005 CFXWorks, Inc. All Rights Reserved 10

page you are directed to after logging in successfully.
However, you can always find this link by going to
the "Support" tab at the top of the page, then clicking
on "My Downloads".

Once the search screen appears, select or enter search
criteria for the order that you are seeking. For,
example you could leave all search criteria blank and
get a complete listing of all your downloaded tags.

Click on the "Show History" button.

This should bring up all of your tags.

If you look closely, you will see for each order placed
there is a row. At the end of this row you will see a
reference to the download. Clicking on this will begin
the download process for the associated tag that is to
the left.

It is probably worth noting that the password that you
used to login to the CFXWorks-Coldfusion
website is
the same password that you will use to unzip the
downloaded tag.


1.9. Security Concerns
CFX_NOVA_JAVA uses a communications protocol called
Secure Sockets, SSL, to encrypt and transmit data between our
software and Elavon’s server as illustrated in the following
illustration:

Figure 3 – Secure Sockets Communication


© 2005 CFXWorks, Inc. All Rights Reserved 11

SSL, Secure Sockets, is a security protocol that provides communications
privacy over the Internet. This protocol allows client/server applications to
communicate in a way that is designed to prevent eavesdropping,
tampering, or message forgery. The encryption level used by the
CFX_NOVA_JAVA server is 128-bit. The connection is managed by the
server and requires no SSL programming skills, or special efforts, by the
merchant.

1.10. Who Should Use CFX_NOVA_JAVA?
If you have ColdFusion programming skills and need to implement credit
card processing for a web site, you should seriously consider use of the
CFX_NOVA_JAVA tag.

Save Money - If transaction and administration fees are cutting into your
profit margins, you should consider using the CFX_NOVA_JAVA tag.
The CFX_NOVA_JAVA tag allows you to deal directly with the
“Processors” of the credit-card transactions, i.e., Elavon, rather than
having to deal with a third-party payment services gateway provider. This
cuts out the middleman and their fees. Examples of middleman providers
include VeriSign, ClearCommerce and Authorize.Net. Since this is a very
profitable business, there are many middleman providers. Users of the
CFX_NOVA_JAVA tag typically can save from 1-4% by eliminating the
middleman and connecting directly to Elavon using the
CFX_NOVA_JAVA tag.

Save Time & Resources - Use of the tag may save you considerable
programming effort since most of the work has been already done for you.
Samples provide with the tag provide programmers a fast-path to
implementation.

Secure Your Data - The CFX_NOVA_JAVA provides programmers with
a very serious encryption/decryption solution that can be used to encrypt
sensitive data, for example credit card numbers, before writing this
information to a database.

Secure Your Transactions - The CFX_NOVA_JAVA automatically
handles within the tag all encryption/decryption requirements relative to
communicating with Elavon. The tag secures communication with Elavon
using the SSL protocol.

Improve Your Reliability – By eliminating the 3
rd
party processor and
sending your transactions directly to Elavon, you have eliminated a
significant point of failure.


© 2005 CFXWorks, Inc. All Rights Reserved 12

Improve Your performance - By eliminating the 3
rd
party processor and
sending your transactions directly to Elavon, you also eliminate the
transaction processing delays caused by the 3
rd
party processing and the
need for them to relay transactions to Elavon.

1.11. Who Should Not Use CFX_NOVA_JAVA?
Users who are not using ColdFusion or do not have ColdFusion
programming skills should not attempt to use the CFX_NOVA_JAVA tag.
Also, users who must integrate proprietary, third party provided, fraud
protection, tax calculation, and/or storefront solutions may find that
another solution is more suited to their needs.

© 2005 CFXWorks, Inc. All Rights Reserved 13

2. H
OW
C
REDIT
C
ARD
P
ROCESSING
W
ORKS
V
IA THE
I
NTERNET


2.1. Internet Based Processing
The following figure illustrates a typical web enabled credit card
processing solution.



Figure 1 – Typical Environment

The process starts with your customer, who makes a purchase using a
payment instrument, such as a credit or debit card. This order is
transmitted across the Internet and arrives at the merchant’s web server.
Since the order information includes credit card information, this message
is generally encrypted by the browser and decrypted by the Web server.

For the purpose of this illustration, we will assume that the web server is
running the ColdFusion application server. The merchant’s web server
passes the credit card information to ColdFusion, and the ColdFusion
programmer forwards this data to a payment gateway operated by a third-
party provider. These middlemen are sometimes called Payment Services
Providers. Their purpose in life is to provide an interface between the
merchant’s e-commerce site and the actual “processor” of the credit card.
They may provide additional services including fraud protection schemes,
tax calculation capabilities, electronic storefronts and administration
services, all for which they charge you a fee.

The Payment Services Provider forwards the credit card information to a
Processor. Examples of processors include Elavon, American Express,
EDS Aurora, FDMS Nashville, FDMS South, Norwest, Paymentech,
TeleCheck, and Vital. The Processor’s purpose in life is to process the
transaction, approve or reject it, and return a response to the customer.


© 2005 CFXWorks, Inc. All Rights Reserved 14

The Processor also transfers funds from the customer’s bank account to
the merchant’s bank account.

2.2. What Makes CFX_NOVA_JAVA Different
The following figure illustrates the environment for users of the
CFX_NOVA_JAVA tag.



Figure 2 – CFX_NOVA_JAVA Environment

The process looks very different to that shown in Figure 1 – Typical
Environment. Most significant is the absence of the middlemen, the
Payment Services Provider, from the equation. Merchants, who require
the services provided by the middlemen, can’t use the
CFX_NOVA_JAVA tag unless they code these services them self. But,
for those merchants who do not require these services,
CFX_NOVA_JAVA is a very cost effective solution.

2.3. What Information Must the Merchant Provide
Prior to using the CFX_NOVA_JAVA tag, the merchant must establish a
merchant account. A merchant account is a special account that is opened
with a bank that is a member of the Visa and MasterCard associations.
These banks have been certified by Visa and MasterCard and can provide
merchants the services related to merchant accounts. The merchant must
also contract with Elavon to become his provider.

To establish an account with Elavon, at a minimum you will need the
following:

Merchants’ Federal ID Number typically 8-16
characters
Merchant’s Bank Account Number typically a 10 digit

© 2005 CFXWorks, Inc. All Rights Reserved 15

number
Merchant’s Bank Routing Number typically a 9 digit
number

The following includes the information that Elavon will provide the
merchant:

A Merchant Account Number typically a 8-16 digit
number
A Terminal ID Number typically a 8-16 digit
number

A merchant can also apply to accept credit cards from American Express
and Discover.

Merchant American Express Account Number typically a 10-16 digit
number
Merchant’s Discover Outlet Number typically a 10-16 digit
number

The relationship between the Merchant Account Number and the Terminal
Number is shown as follows:

Figure 3 – Merchant Account Number/Terminal Number

3 47500000073541 99
Merchant Account Number
Terminal Number
Terminal
Identifier
(1)
(2)
(3)
(1) 1 - 15 digits
(2) 1 - 16 digits
(3) 2 digits

© 2005 CFXWorks, Inc. All Rights Reserved 16

2.4. Modes of Operation
Elavon supports two modes of operation. One is called “Host Based
Processing”. The other is called “Terminal Based Processing”.

Host Based Processing
(Used for real-time transaction approval)

With Host Based Processing transactions are forwarded to Elavon, and
Elavon replies in real-time. This enables the merchant to immediately
respond to the customer based on whether on not the transaction was
verified. This is the most common method for processing live Internet
transactions.

Elavon provides two methods of settlement for Host Based Processing.
Most merchants choose “Autoclose”. With Autoclose Settlement is
automatically run each evening at approximately 2:30 AM. In other
words, Elavon automatically settles the entire batch of transactions
submitted during the previous 24 hours at 2:30 AM. This takes the burden
off the merchant to remember to close the batch every day. Five
transaction types provide support for this method of settlement: SALE,
PRE-AUTHORIZATION, FORCE, CREDIT and VOID. If the merchant
chooses “Autoclose”, they can also use the “Settlement” transaction to
force the batch to close at any time.

Elavon also provides a “Manual” settlement option for Host Based
Processing. With manual settlement the merchant must close his own
batch and force settlement. The SETTLEMENT transaction can be used to
manually close a batch.

For administrative purposes, Elavon supports three transaction types
including SETTLEMENT, CURRENT and PREVIOUS. Each of these
transaction types is described in the following documentation.

When merchants register with Elavon, a choice must be made between
Hosed Based Processing and Terminal Based Processing. We strongly
recommend that the merchant choose the Autoclose method of settlement.

CFX_NOVA_JAVA is certified for two market segments. The market
segment chosen by the merchant determines what types of transactions
they can transmit across the Internet.

e-Commerce Market Segment

The e-Commence market segment is sometimes referred to as
market segment “I”. Market segment I is for card-not-present
transactions. This means that the credit card data is key entered.
The transaction types supported include:

© 2005 CFXWorks, Inc. All Rights Reserved 17


• SALE
• PRE-AUTHORIZATION
• FORCE
• CREDIT
• VOID
• PSALE – purchase card
• PCREDIT – purchase card
• DSALE – debit card used as a credit card
• DCREDIT – debit card used as a credit card
• CURRENT
• PREVIOUS
• PURGE
• SETTLEMENT

Retail Market Segment

The Retail market segment is sometimes referred to as market
segment “G”. Market segment G is for both card-present and card-
not-present transactions. This means that the credit card data can
be swiped or key entered. The transaction types supported include
all of the above transaction types plus:

• DSALE – debit card used as a debit card
• DCREDIT – debit card used as a debit card

Terminal Based Processing


Terminal based processing is not currently supported by this tag.

2.5. Types of Transactions Supported
The CFX_NOVA_JAVA tag, provides merchants the ability to process
the following types of
Credit Card
transactions.

SALE – A transaction is sent for approval. The transaction is
rejected or approved, the merchant is notified of the approval, and
the transaction settles at the end of the business day. If the
merchant uses Elavon’s Autoclose feature, all transactions
submitted during the business day are settled at approximately
2:30 AM the following morning. If the merchant chooses to
manually close, a transaction must be sent to Elavon at the end of
each business day to force settlement.

PRE-AUTHORIZATION – A transaction is sent for authorization
only. Authorization is requested to reserve a certain amount on a

© 2005 CFXWorks, Inc. All Rights Reserved 18

customer’s credit card without actually charging the card. Pre-
Authorizations are useful to merchants who want to verify the
validity of a customer’s credit card before shipping products,
accepting orders or providing services. For example, most hotels
require you to present a credit card when making a reservation or
prior to checking in. When you check in they process a Pre-
Authorization to verify that the credit card is valid, to verify that
credit is available to cover the charge and to reserve the funds for
future payment. When you check out they process a Force
transaction, using the Pre_Authorization number retrived in the
previous transaction, to capture the funds.

FORCE – A Force transaction is used to capture funds reserved by
a Pre-Authorization transaction.

CREDIT – A credit is used for example, when a customer returns a
product for credit to his credit card account.

VOID – Void cancels a transaction that has been submitted for
processing, before the batch has been settled. Voiding a transaction
prevents a charge to the credit card from occurring. A VOID
cannot be used on a transaction unless it is in the current batch.

The CFX_NOVA_JAVA tag, provides merchants the ability to process
the following types of
Debit Card
transactions.

DSALE – A transaction is sent for approval. The transaction is
rejected or approved, the merchant is notified of the approval, and
the transaction settles at the end of the business day. If the
merchant uses Elavon’s Autoclose feature, all transactions
submitted during the business day are settled at approximately
2:30 AM the following morning. If the merchant chooses to
manually close, a transaction must be sent to Elavon at the end of
each business day to force settlement.

DCREDIT – This transaction type is used when a customer returns
a product for credit to his debit card account.

The CFX_NOVA_JAVA tag, provides merchants the ability to process
the following types of
Purchase Card
transactions.

PSALE – A transaction is sent for approval. The transaction is
rejected or approved, the merchant is notified of the approval, and
the transaction settles at the end of the business day. If the
merchant uses Elavon’s Autoclose feature, all transactions
submitted during the business day are settled at approximately

© 2005 CFXWorks, Inc. All Rights Reserved 19

2:30 AM the following morning. If the merchant chooses to
manually close, a transaction must be sent to Elavon at the end of
each business day to force settlement.

PCREDIT – This transaction type is used when a customer returns
a product for credit to his debit card account.

The following transaction types apply to
Credit, Debit
and
Purchase

card transactions.

CURRENT BATCH INQUIRY – A current transaction is an
administrative request for statistics relative to the current batch.

PREVIOUS BATCH INQUIRY – A previous transaction is an
administrative request for statistics relative to the previous batch.

PURGE BATCH - A purge batch transaction deletes all
transactions in the current batch.

SETTLEMENT – A settlement transaction is valid only for
merchants who choose to use manual close with Host Based
Processing. A settlement transaction closes the current batch and
opens a new batch.

The tag also supports the ability to create message digests and to encrypt
or decrypt data. The following transaction types are supported:

MD5 - Create a MD5 message digest.

ENCRYPT – Encrypt data using 128-bit AES encryption.

DECRYPT – Decrypt data encrypted using this tag.

2.6. MD5 Message Digests
A message digest (also sometimes referred to as a one-way hash function)
is a fixed length computationally unique identifier corresponding to a set
of data. The result of applying this algorithm is that data digested will map
to a particular block of information called a message digest. The digest is
not random; digesting the same unit of data with the same algorithm will
always produce the same message digest.

MD5 belongs to a family of one-way hash functions called message digest
algorithms. The MD5 system is defined in RFC 1321. MD5 takes a
message of arbitrary length and produces as output a 128-bit message
digest. It is conjectured that it is computationally infeasible to produce two

© 2005 CFXWorks, Inc. All Rights Reserved 20

different messages having the same message digest, or to produce any
message having a given message digest.

RFC 1321 also defines a certification suite to validate correct
implementation of the algorithm. The tag has been validated against this
suite.

The tag produces a result that is always a 32 byte hex representation of the
digest.

2.7. AES Encryption
This tag encrypts and decrypts text using the algorithm specified in the
Federal Information Processing Standard (FIPS) for the Advanced
Encryption Standard, FIPS-197
. This standard specifies Rijndael,
sometimes referred to as AES, as the FIPS-approved symmetric
encryption algorithm that should be used by U.S. Government
organizations, agencies, and others to protect sensitive information.

Rijndael is a block cipher (symmetric key) encryption algorithm that
supports 128-bit, 192-bit and 256-bit key sizes. It was selected
(10/02/2000) by the National Institute of Standards and Technology
(NIST) as the new Federal Information Processing Standard (FIPS) for
encryption. Effective 12/04/2001, Rijndael replaced DES as the FIPs
standard. For a detailed discussion of Rijndael, and the Advanced
Encryption Standard (AES) selection process, please visit web site
http://csrc.nist.gov/encryption/aes/
.

The FIPS standard also defines a certification suite to validate correct
implementation of the algorithm. The tag has been validated against this
suite.

The tag implements the 128-bit key size. The result returned from the
encryption routine is a hex representation of the binary encrypted data.
The result returned from decryption is the original “clear” text.

2.8. AVS
Elavon supports AVS to assist merchants in verifying that the address and
zip code provided by the customer match the actual address registered at
the bank that issued the credit card. The registered address would
normally include the name, address, city, state, and zip code. However, the
AVS system only validates the number part of the address and the zip
code. AVS is intended to assist merchants make an informed decision at
the time of the sale as to whether or not to accept a person’s credit.

© 2005 CFXWorks, Inc. All Rights Reserved 21


Since there are many reasons that an address and zip code may not match,
the merchant is not required to refuse a transaction because of an AVS
mismatch, however, many banks charge an added fee, a non-qualified
transaction surcharge typically in the range of an additional 1%, for these
transactions.

2.9. Card Verification Value 2 (CVV2)
Elavon also supports a feature called CVV2. CVV2 is a three or four digit
value that appears on the credit card used to verify the card’s authenticity
for the purpose of preventing fraud in the mail order, telephone order and
card-not-present environments. On some cards the value is printed on the
face of the card at the end, or above, the printed credit card number. On
other cards it appears on the back of the card following the personal
authentication number.

2.10. AVS and CVV2 Comments
With CREDIT, VOID and FORCE transactions types
(NOVA_TRANSACTION_TYPE), AVS and CVV2 parameters can be
submitted, but they are ignored by Elavon. Therefore, no response will be
received in the NOVA_AVS_RESPONSE and
NOVA_CVV2_RESPONSE fields for these transaction types.

For test transactions that use
NOVA_CARD_ACCOUNT_NBR=50003000020003003, AVS and
CVV2 parameters can be submitted, but they are ignored by Elavon.
Therefore, no response will be received in the NOVA_AVS_RESPONSE
and NOVA_CVV2_RESPONSE fields for these transaction types.

For test transactions that use
NOVA_CARD_ACCOUNT_NBR=374255312721002, the CVV2
parameter can be submitted, but it is ignored by Elavon. Therefore, no
response will be received in the NOVA_CVV2_RESPONSE field for
these transaction types.

Normally AVS and CVV2 are not used if the NOVA_STRIPE parameter
is used. However, the test server will respond to AVS unless one of the
above mentioned exceptions exist. It will not respond to CVV2.


2.11. Visa 3D Secure & MasterCard SecureCode


© 2005 CFXWorks, Inc. All Rights Reserved 22

CFX_NOVA_JAVA also supports a feature called 3DSecure or
SecureCode. It is used to pass the Verified By Visa CAVV Value or the
Mastercard Secure Code Value for cardholder authentication. This feature
applies only to market segment I (e-Commerce) for creidit cards and
purchase cards. It is passed only on sale transactions.

2.12. Reoccurring Payment Feature
Some Payment Services Providers support the ability to store transactions,
and/or batches of transactions on their gateway servers. This is a Payment
Services Provider supported feature, not a capability directly supported by
Elavon. Since CFX_NOVA_JAVA eliminates the Payment Services
Provider, a reoccurring payment capability is not directly supported by the
CFX_NOVA_JAVA tag. Users who require this feature will need to code
it themselves.
3. CFX_NOVA_JAVA

P
RODUCT
D
ESCRIPTION


3.1. Installation on ColdFusion
The CFX_NOVA_JAVA installation process is a five or six step process:

1. CFX_NOVA_JAVA is distributed in zip file that contains Java
jar files, some documentation, and several ColdFusion sample
programs. The actual filename of the zip file may vary. The
command you must enter at a command line is as follows:

pkunzip filename

2. Next copy the “CFX_NOVA_JAVA.jar”, “cryptix-jce-api.jar”,
and “cryptix-jce-provider.jar” files to the directory where you
want to execute the tag from. This can be any directory, as long
as you add the directory to the Java Class Path using the
ColdFusion Administrator. You can do this by opening the
ColdFusion Administrator program, click on the “Java &
JVM” menu item, and add the tags to the JVM’s Classpath.
The following illustrates doing this:


© 2005 CFXWorks, Inc. All Rights Reserved 23



Figure 5 - Registering CFX_NOVA_JAVA

The actual text added to the Classpath doesn’t display well in the
above figure. Assuming the directory that contains the jar files is
“d:\eclipse3\workspace\Tags\package, the actual text added to the
class path would be:

Windows

“d:\eclipse3\workspace\Tags\package”

UNIX/Linux/MAC

“/eclipse3/workspace/Tags/package”

You must stop and restart the ColdFusion server for the
changes to take place.

3. On UNIX/Linux and the MAC, the jar files copied in step 2
must be executable. To do this position yourself in the
directory containing these files and enter the following
command: “chmod a+x *.jar”.

4. ColdFusion also requires that you register the tag using the
ColdFusion Administrator. The registration dialog will look
similar to the following:

© 2005 CFXWorks, Inc. All Rights Reserved 24




Figure 6 - Registering CFX_NOVA_JAVA

Name the tag whatever you like. The sample programs use
the name “CFX_NOVA_JAVA. Next, you must tell
ColdFusion the name of the Java class to execute when the
tag is called. Java is very unforgiving if you make an error
entering this value. The value is case sensitive. You must
enter the following “Nova.CFX_NOVA_JAVA”.

5. If you want to use the encryption capabilities provided by this
tag, you must copy the “strong encryption” jar files available
from Sun to the appropriate directory on the host system.
Without these jar files the encryption capabilities provided by
this tag will not work. These files, (local_policy.jar and
US_export_policy.jar) must be installed in the
%JAVA_HOME%/jre/lib/security directory. They replace files
of the same name that are distributed in the standard Java SDK.
The standard distribution files do not allow the use of strong
encryption.

6. If you are using a version of ColdFusion that uses Java Release
1.3, you will also have to copy three additional jar files to the

© 2005 CFXWorks, Inc. All Rights Reserved 25

directory used in step 2. These jar files are jsse.jar, jnet.jar and
jcert.jar. You can download these jar files from Sun or use the
copies shipped with the tag. Note that if you don’t know what
version of Java you are using I have included another tag in the
distribution. It is called CFX_Classpath. Install it and run the
ColdFusion example Java_Classpath.cfm and it will display the
level of java being used by ColdFusion.

That’s it! The entire installation process should take only a few minutes to
complete.

3.2. Installation on BlueDragon
The tag has also been test on BlueDragon Release 6.1. The
CFX_NOVA_JAVA installation process is a four or five step process:

1. CFX_NOVA_JAVA is distributed in zip file that contains Java
jar files, some documentation, and several ColdFusion sample
programs. The actual filename of the zip file will vary. The
command you must enter at a command line is as follows:

pkunzip filename –s[password]

2. Next copy the “CFX_NOVA_JAVA.jar”, “cryptix-jce-api.jar”,
and “cryptix-jce-provider.jar” files to the directory where you
want to execute the tag from. This can be any directory, as long
as you add the directory to the Java Class Path using the
BlueDragon Administrator. You can do this by opening the
BlueDragon Administrator program, click on the “java vm
settings” menu item, and add the tags to the JVM’s Classpath.
The following illustrates doing this:


© 2005 CFXWorks, Inc. All Rights Reserved 26



Figure 7 - Registering CFX_NOVA_JAVA

The actual text added to the Classpath doesn’t display well in the
above figure. Assuming the directory that contains the jar files is
“d:\eclipse3\workspace\Tags\package, the actual text added to the
class path would be:

Windows

“d:/eclipse3/workspace/Tags/package/cryptix-jce-
api.jar;d:/eclipse3/workspace/Tags/package/cryptix-jce-
provider.jar;d:/eclipse3/workspace/Tags/package/CFX_NOVA
_JAVA.jar”

UNIX/Linux/MAC

“/eclipse3/workspace/Tags/package/cryptix-jce-
api.jar:/eclipse3/workspace/Tags/package/cryptix-jce-
provider.jar:/eclipse3/workspace/Tags/package/CFX_NOVA_J
AVA.jar”

You must stop and restart the BlueDragon server for the
changes to take place.


© 2005 CFXWorks, Inc. All Rights Reserved 27

3. On UNIX/Linux and the MAC, the jar files copied in step 2
must be executable. To do this position yourself in the
directory containing these files and enter the following
command: “chmod a+x *.jar”.

4. ColdFusion also requires that you register the tag using the
ColdFusion Administrator. The registration dialog will look
similar to the following:



Figure 8 - Registering CFX_NOVA_JAVA

Name the tag whatever you like. The sample programs use
the name “CFX_NOVA_JAVA. Next, you must tell
ColdFusion the name of the Java class to execute when the
tag is called. Java is very unforgiving if you make an error
entering this value. The value is case sensitive. You must
enter the following “Nova.CFX_NOVA_JAVA”.

5. If you want to use the encryption capabilities provided by this
tag, you must copy the “strong encryption” jar files available
from Sun to the appropriate directory on the host system.
Without these jar files the encryption capabilities provided by
this tag will not work. These files, (local_policy.jar and

© 2005 CFXWorks, Inc. All Rights Reserved 28

US_export_policy.jar) must be installed in the
%JAVA_HOME%/jre/lib/security directory. They replace files
of the same name that are distributed in the standard Java SDK.
The standard distribution files do not allow the use of strong
encryption.

Note: If you are installing on a MAC, the install directory for
these policy files will be similar to the following:

“/System/Library/Frameworks/JavaVM.framework/Versions/1.
4.2/Home/lib/security”

That’s it! The entire installation process should take only a few minutes to
complete.

3.3. Performance Issues
It appears from our testing that the CFX_NOVA_JAVA tag can feed
transactions Elavon faster than Elavon can process them. Therefore, the
major performance issue is likely to be the performance of Elavon’s
gateway processor.

3.4. Minimum System Requirements
This tag has been tested on Windows, Linux, Solaris and MAC platforms.
It should function properly on any system executing ColdFusion Release
5.0 of later. Our reference to the MAC is specifically for MAC OS X
Version 10.3.7 Server and Client.

3.5. Software License
The tag is licensed on a per terminal ID basis. The license agreement is
contained in the product distribution zip file. Please read this pdf file for
detailed license information.

3.6. Export Limitations
This tag software contains encryption technology that is subject to the
U.S. Export Administration Regulations and other U.S. law, and may not
be exported or re-exported to certain countries (currently Afghanistan
(Taliban-controlled areas), Cuba, Iran, Iraq, Libya, North Korea, Serbia
(except Kosovo), Sudan and Syria) or to persons or entities prohibited
from receiving U.S. exports (including Denied Parties, entities on the
Bureau of Export Administration Entity List, and Specially Designated
Nationals). For more information on the U.S. Export Administration

© 2005 CFXWorks, Inc. All Rights Reserved 29

Regulations http://www.bxa.doc.gov/Encryption/regs.htm
, 15 C.F.R. Parts
730-774, and the Bureau of Export Administration U. S. Department of
Commerce. Please see the home page www.bxa.doc.gov


3.7. Future Possible Extensions
Please send us your suggestions.

3.8. Support
Support is provided for this offering via email. Please contact us at
support@cfxworks.com
.

3.9. Warranty
Please read the license file in distribution zip file.

© 2005 CFXWorks, Inc. All Rights Reserved 30

4.

H
OST BASED
P
ROCESSING
U
SING
T
HE
E
LAVON
T
AG


4.1. Overview
Elavon provides two methods of settlement for Host Based Processing.
Most merchants choose “Autoclose”. With Autoclose Settlement is
automatically run each evening at approximately 2:30 AM. In other
words, Elavon automatically settles the entire batch of transactions
submitted during that day at 2:30 AM. This takes the burden off the
merchant to remember to close the batch every day.

4.2. Tag Parameters
For a detailed discussion of the parameters supported by the
CFX_NOVA_JAVA tag, please refer to Appendix A – Data Sent To
Elavon. For a detailed discussion of the responses parameters returned
from Elavon please see Appendix .

Not all parameters documented in Appendix A are supported for every
card type (credit card, debit card and purchase card). If an invalid
parameter is sent to Elavon, they reject the transaction. Therefore, we
screen out invalid parameters and eliminate them from the transaction
before it is sent to Elavon. The following table summarizes the parameters
that are may be screened and those that are supported for each card type.
An “S” indicates that the parameter is supported and will be sent to
Elavon. An “I” indicates that this is an invalid parameter for this card
type. Specifically we screen out all “I” parameters and do not send them to
Elavon as part of the transaction.


Parameter: Credit
Card:
(1)
Debit
Card:
(2)
Purchase
Card:
NOVA_TRANSACTION_CODE S S S
NOVA_MERCHANT S S S
NOVA_BANK_NBR S S S
NOVA_CARD_ACCOUNT_NBR S I S
NOVA_AMOUNT S S S
NOVA_CARD_EXP_DATE S I S
NOVA_STREET S I I
NOVA_ZIP S I I
NOVA_CVV2_DATA S I I

© 2005 CFXWorks, Inc. All Rights Reserved 31

NOVA_3D_SECURE S I S
NOVA_FORCE_APPROVAL S I I
NOVA_VOID_RECORD_NBR S I I
NOVA_PURCHASE_NBR I I S
NOVA_INVOICE_NBR I I S
NOVA_TAX I I S
NOVA_STRIPE S S S
NOVA_PIN_BLOCK I S I
NOVA_SURCHARGE_AMOUNT I S I
NOVA_KEY_PTR I S I
NOVA_TRANS_DATE NA NA NA
NOVA_TRANS_TIME NA NA NA
NOVA_USER_KEY (3) S S S
NOVA_CRYPTO_IN (4) NA NA NA
NOVA_CRYPTO_KEY (4) NA NA NA
NOVA_CRYPTO_IV (4) NA NA NA
NOVA_USERNAME (5) S S S
NOVA_PASSWORD (5) S S S

(1) Credit card and debit card used as a credit card.
(2) Debit card used as a debit card.
(3) Supported for all transaction types.
(4) Supported only for message digest and encryption transactions.
(5) Used to restrict access to CFX_NOVA_JAVA’s Elavon service

The above table means that AVS and CVV2 are supported only for credit
cards. Purchase order numbers, invoice numbers and tax are supported
only for purchase cards. Debit cards require the use of stripe data, pin
block, surcharge amount and key pointer.

4.3. Elavon Test Server & Sample Programs
We have provided several ColdFusion sample programs that exercise the
transactions described in the following sections of this manual. Elavon has
provided access to their test server using the following test Terminal IDs.
You can specify which test Terminal ID to use by coding the following
parameter:

NOVA_MERCHANT="value"

This parameter causes the tag to use the following values for test
purposes:

NOVA_MERCHANT NOVA_TERMINAL_ID NOVA_BANK_NBR MARKET
SEGMENT

© 2005 CFXWorks, Inc. All Rights Reserved 32

test0 999888216 401205 eCommerce
test1 999888217 401205 Retail
test2 999888218 401205 eCommerce
test3 999888219 401205 Retail

For example if the user codes NOVA_MERCHANT="test0", the tag sends
the transaction to the test server using the following values:

NOVA_TERMINAL_ID=
999888216
NOVA_BANK_NBR=
401205
MARKET SEGMENT - eCommerce


Licensed copies of the tag have additional entries in the above table for
each production Terminal ID and bank number.

The test server is extremely useful to someone building and testing
programs that use the CFX_NOVA_JAVA tag. However, the test server
does not always response consistent with what you might expect to
receive from Elavon’s production server. This is because the test
server simulates validating some transaction parameters rather than
actually validating them. In particular, the responses provided in the
fields NOVA_AUTH_RESPONSE, NOVA_AVS_RESPONSE and
NOVA_CVV2_RESPONSE are simulated on the test server. Please
see E. Responses From Test Server for the rules Elavon uses to create the
simulated responses.

4.4. CFX_NOVA_JAVA Demo Version Limitations
The demonstration copy of CFX_NOVA_JAVA supports sending
transactions only to Elavon’s test server.

If you have purchased a copy of the CFX_NOVA_JAVA tag please
contact us at support@cfxworks.com
, or by phone, so we can build and
ship you a production copy of the tag. You will need to supply your
terminal ID to us so we can complete the build. If you also supply your
bank number, we will add that to the tag also. Typically the terminal ID is
15 or 16 digits long and ends in either 98 or 99. Your Elavon terminal ID
will be provided to you by Elavon when you establish your merchant
account.

4.5.
Elavon
Record Numbers
Elavon numbers transactions within a batch and returns the number for
each transaction in the parameter NOVA_RECORD_NBR. For tracking
purposes, you should save the value returned in the

© 2005 CFXWorks, Inc. All Rights Reserved 33

NOVA_RECORD_NBR field from each transaction. You will need this
number if you want to void a transaction. The tag will also return the
value for NOVA_BATCH_NBR from each transaction.

4.6. Test credit card Numbers
Elavon has supplied the following test credit card numbers.

4123456789012349 (Visa) 4715000000000008 (Visa Purchase Card)
5121212121212124 (MC) 4121212121212127 (Visa)
36999999999999 (Dinners) 374255312721002 (Amex)
5000300020003003 MC) 6011111111111117 (Amex)

Elavon’s policy is that if you send a transaction to their production
server using one of these test credit card numbers, they cancel the
entire batch and its contents. To prevent this from happening, the tag
simply returns a 93 return code in the “NOVA_RC” parameter for
these transactions and does not submit the transaction to Elavon for
processing.

4.7. Credit Card Sale
Description

The purpose of a Sale transaction is to record a Sale and to receive a
response from Elavon that the transaction has been either accepted or
rejected.

Sample ColdFusion Programs

The following are samples of SALE transactions:

Test Program Function Tested
Java_Nova_Sale_AVS.Full.cfm Credit card sale with full AVS
(address and zip)
Java_Nova_Sale_AVS.Zip.cfm Credit card sale with partial AVS
(zip)
Java_Nova_Sale_CVV2.cfm Credit card sale with CVV2.

When you run these samples the tag will populate the return parameters
with whatever values are returned from Elavon. The tag will return the
values in ColdFusion variables that can be processed and used as you
would expect to use any ColdFusion parameter.

Parameters Supported


Parameter: Credit

© 2005 CFXWorks, Inc. All Rights Reserved 34

Card:
(1)
NOVA_TRANSACTION_CODE S
NOVA_MERCHANT S
NOVA_BANK_NBR S
NOVA_CARD_ACCOUNT_NBR S
NOVA_AMOUNT S
NOVA_CARD_EXP_DATE S
NOVA_STREET S
NOVA_ZIP S
NOVA_CVV2_DATA S
NOVA_3D_SECURE S
NOVA_STRIPE S

(1) Credit card and debit card used as a credit card

4.8. Credit Card Address Verification
Description

A SALE transaction can be used only for the purpose of verifying the
address information. Processors call this an “Address Verification Only”
transaction. Address verification is performed exactly as a Sale transaction
except the NAVA_AMOUNT parameter is set to zero.

Sample ColdFusion Programs

The following are samples of Address Verification Only transactions:

Test Program Function Tested
Java_Nova_AddressVer_AVS_Full.cfm Address verification with full
AVS (address and zip)
Java_Nova_AddressVer_AVS.Zip.cfm Address verification with
partial AVS (zip)

If you look at these examples the NOVA_AMOUNT fields have been set
to zero. When they executed, a response of “NOVA_AUTH_RESPONSE
= APPROVAL” indicates that the address was verified.

Parameters Supported


Parameter: Credit
Card:
(1)
NOVA_TRANSACTION_CODE S
NOVA_MERCHANT S
NOVA_BANK_NBR S

© 2005 CFXWorks, Inc. All Rights Reserved 35

NOVA_CARD_ACCOUNT_NBR S
NOVA_AMOUNT Must be
0
NOVA_CARD_EXP_DATE S
NOVA_STREET S
NOVA_ZIP S
NOVA_STRIPE S

(1) Credit card and debit card used as a credit card.

4.9. Credit Card Pre-Authorization
Description

The purpose of a Pre-Authorization is to reserve a certain amount on a
customer’s credit card without actually charging the card. Pre-
Authorizations are used to verify the validity of a customer’s credit card
before shipping products, accepting orders or providing services.

Transaction Parameters

The following are samples of Pre Authorization transactions:

Test Program Function Tested
Java_Nova_PreAuth_AVS.Full.cfm Pre-Authorization with full AVS
(address and zip)
Java_Nova_
PreAuth_AVS.Zip.cfm
Pre-Authorization with partial
AVS (zip)
Java_Nova_ PreAuth _CVV2.cfm Pre-Authorization with CVV2.

Parameters Supported


Parameter: Credit
Card:
(1)
NOVA_TRANSACTION_CODE S
NOVA_MERCHANT S
NOVA_BANK_NBR S
NOVA_CARD_ACCOUNT_NBR S
NOVA_AMOUNT S
NOVA_CARD_EXP_DATE S
NOVA_STREET S
NOVA_ZIP S
NOVA_CVV2_DATA S
NOVA_STRIPE S

(1) Credit card and debit card used as a credit card.

© 2005 CFXWorks, Inc. All Rights Reserved 36


4.10. Credit Card Force
Description

A Force transaction is used when a Pre-Authorization is obtained through
any means other than the Internet. For example, merchants can call Elavon
and receive a Pre-Authorization number. Merchants then use the Pre-
Authorization number for the value NOVA_FORCE_APPROVAL, to
process the transaction after the product or service has been provided.

As an alternative to calling Elavon for the Pre-Authorization number, the
merchant could execute a PREAUTH transaction. The value returned in
the variable NOVA_APPROVAL_CODE can then be used as the value
NOVA_FORCE_APPROVAL when the FORCE transaction is executed.

Samples

The following is a sample of a Force transaction:

Test Program Function Tested
Java_Nova_Force_AVS.Full.cfm Force with full AVS (address and
zip)

Parameters Supported


Parameter: Credit
Card:
(1)
NOVA_TRANSACTION_CODE S
NOVA_MERCHANT S
NOVA_BANK_NBR S
NOVA_CARD_ACCOUNT_NBR S
NOVA_AMOUNT S
NOVA_CARD_EXP_DATE S
NOVA_FORCE_APPROVAL S
NOVA_STRIPE S

(1) Credit card and debit card used as a credit card.

4.11. Credit Card Credit
Description

A Credit transaction is used when a customer returns a product for credit
to his account.

Samples


© 2005 CFXWorks, Inc. All Rights Reserved 37

The following are samples of Credit transactions:

Test Program Function Tested
Java_Nova_Credit.cfm Credit without AVS or CVV2
Java_Nova_ Credit_AVS.Full.cfm Credit with full AVS (address
and zip)

Parameters Supported


Parameter: Credit
Card:
(1)
NOVA_TRANSACTION_CODE S
NOVA_MERCHANT S
NOVA_BANK_NBR S
NOVA_CARD_ACCOUNT_NBR S
NOVA_AMOUNT S
NOVA_CARD_EXP_DATE S
NOVA_STRIPE S

(1) Credit card and debit card used as a credit card.

4.12. Void
Description

Void cancels a transaction that has been submitted for processing. Void
can only be used on a transaction within a batch before the batch has been
settled. Voiding a transaction prevents a charge to the credit card from
occurring.

Samples

The following is a sample of a Void transaction:

Test Program Function Tested
Java_Nova_Void.cfm Void transaction

Parameters Supported


Parameter: Credit
Card:
(1)
NOVA_TRANSACTION_CODE S
NOVA_MERCHANT S
NOVA_BANK_NBR S
NOVA_CARD_ACCOUNT_NBR S

© 2005 CFXWorks, Inc. All Rights Reserved 38

NOVA_AMOUNT S
NOVA_CARD_EXP_DATE S
NOVA_VOID_RECORD_NBR S
NOVA_STRIPE S

(1) Credit card and debit card used as a credit card.

4.13. Purchase Card Sale
Description

A Sale performed using a purchase card should be handled as shown in the
following sample program:

Test Program Function Tested
Java_Nova_PurchaseCardSale.cfm Sale using a purchase card

Parameters Supported


Parameter: Purchase
Card:
NOVA_TRANSACTION_CODE S
NOVA_MERCHANT S
NOVA_BANK_NBR S
NOVA_CARD_ACCOUNT_NBR S
NOVA_AMOUNT S
NOVA_CARD_EXP_DATE S
NOVA_PURCHASE_NBR S
NOVA_INVOICE_NBR S
NOVA_TAX S
NOVA_3D_SECURE S
NOVA_STRIPE S

4.14. Purchase Card Credit
Description

A Credit performed using a purchase card should be handled as shown in
the following sample program:

Test Program Function Tested
Java_Nova_PurchaseCardCredit.cfm Credit using a purchase card

Parameters Supported


Parameter: Purchase
Card:

© 2005 CFXWorks, Inc. All Rights Reserved 39

NOVA_TRANSACTION_CODE S
NOVA_MERCHANT S
NOVA_BANK_NBR S
NOVA_CARD_ACCOUNT_NBR S
NOVA_AMOUNT S
NOVA_CARD_EXP_DATE S
NOVA_PURCHASE_NBR S
NOVA_INVOICE_NBR S
NOVA_TAX S
NOVA_STRIPE S

4.15. Magnetic Stripe Data
Description

CFX_NOVA_JAVA will support Stripe transactions, for example,
sending data read from Track 1 of a credit card to Elavon. Since Stripe
transactions are considered more secure than transactions verified using
AVS or CVV2 data, Elavon honors lower transaction fees for stripe
transactions.

If stripe data is provided, it must be passed to the tag using the parameter
NOVA_STRIPE=”data”. The Stripe data must be presented to the tag in
exactly the format read from the card, i.e. in raw data format. The tag will
parse the data required by Elavon from the stripe data. Since stripe data
contains the necessary credit card information data, it is not necessary for
the programmer to pass the following parameters to the tag:

NOVA_CARD_ACCOUNT_NBR
NOVA_CARD_EXP_DATE

In addition to the return data documented in the preceding sections of this
manual, the tag will return the above values to the calling ColdFusion
program after parsing this information from the stripe data.
CFX_NOVA_JAVA will also return the name on the credit card in the
ColdFusion variable called NOVA_CC_NAME.

4.16. Debit Card Sale
Description

The purpose of of this transaction type is to record a sale from a customer
that used a “Debit Card” as a “Debit Card”.

Sample

The following examples are provided to demonstrate the use of stripe data:


© 2005 CFXWorks, Inc. All Rights Reserved 40

Test Program Function Tested
Java_Nova_DebitCardSale.cfm Sale using a debit card

When you run these samples, CFX_NOVA_JAVA will format and send
the request to Elavon. When Elavon responds, CFX_NOVA_JAVA
extracts the return values from the response and places these values in a
instance of the CFXNovaJasWrapper class. You can see in the Nova_Test
code exactly how to retrieve the response information from this class.

Parameters Supported


Parameter: Debit
Card:
(1)
NOVA_TRANSACTION_CODE S
NOVA_MERCHANT S
NOVA_BANK_NBR S
NOVA_AMOUNT S
NOVA_STRIPE S
NOVA_PIN_BLOCK S
NOVA_SURCHARGE_AMOUNT S
NOVA_KEY_PTR S

(1) Debit card used as a debit card.

4.17. Debit Card Credit
Description

The purpose of of this transaction type is to record a a return or refund for
a customer that used a “Debit Card” as a “Debit Card”.

Sample

The following examples are provided to demonstrate the use of stripe data:

Test Program Function Tested
Java_Nova_DebitCardCredit.cfm Credit using a debit card

Parameters Supported


Parameter: Debit
Card:
(1)
NOVA_TRANSACTION_CODE S
NOVA_MERCHANT S
NOVA_BANK_NBR S

© 2005 CFXWorks, Inc. All Rights Reserved 41

NOVA_AMOUNT S
NOVA_STRIPE S
NOVA_PIN_BLOCK S
NOVA_SURCHARGE_AMOUNT S
NOVA_KEY_PTR S
NOVA_TRANS_TIME S
NOVA_TRANS_DATE S

(1) Debit card used as a debit card.

4.18. Pin Data
CFX_NOVA_JAVA will support Debit Card Sale (Purchase) and
Credit (Return) transactions. Debit card transactions require that the
merchant use a Elavon certified magnetic card reader that has swipe
and PIN number capability.

We use a terminal from Mag-Tek, Inc. The product name is Intellipin
(Model Series - 300151XX). You can contact Mag-Tek at 1-800-462-
4835. We worked with Liza MacKinnon at extension #253. This terminal
is attached to a PC using a serial port. Mag-Tek supplies an ActiveX
control to assist developers read swipe and PIN number data from the
terminal. Mag-Tek also provides a keyboard-attached version of this
terminal. This allows the user to process stripe data and PIN numbers
using Active Script code from within a browser.

Two values must be read from the terminal to process debit cards. First,
the stripe data is read from the terminal. This data must be passed to
CFX_NOVA_JAVA in the parameter NOVA_STRIPE. Once the stripe
data is read, the PIN data must be read and passed to CFX_NOVA_JAVA
in the NOVA_PIN_BLOCK parameter.

Elavon requires two additional parameters for a debit card PURCHASE
that are not read from the terminal device. NOVA_REQ_KEY_PTR is
used to indicate what encryption key was used on the swipe terminal. This
value rotates from 0 to 9 and then must repeat the 0 to 9 sequences.
Elavon also requires the NOVA_SURCHARGE_AMOUNT parameter be
passed.

Two additional parameters are required for a debit card RETURN
transaction. NOVA_TRANS_DATE passes the date of the original sale
transaction. NOVA_TRANS_TIME passes the time of the original sale.

In addition to the normal response parameters, Elavon returns several
parameters that are unique to Debit card transactions:

© 2005 CFXWorks, Inc. All Rights Reserved 42


NOVA_NEXT_KEY_PTR - The value returned in this parameter
will be a value equal to 0-9. This value must be passed to Elavon
in the parameter NOVA_REQ_KEY_PTR, in the next PIN based
transaction. This value is unique to a specific point of sale
terminal. Therefore, if the merchant has multiple point-of-sale
devices, you must keep track of this value on a per terminal basis.

NOVA_SURCHARGE_INDICATOR – Surcharge indicator.
“0000” is successful. “xxxx” Surcharge request denied. The
amount shown will be the original
NOVA_SURCHARGE_AMOUNT from the request transaction.

NOVA_ACCOUNT_TYPE – Either CHECKING or SAVINGS.

NOVA_REFERENCE_NBR – A transaction reference number.

4.19. Overview of Batch Transactions
Elavon provides a “Manual” settlement option for Host Based Processing.
With manual settlement the merchant must close his own batch and force
settlement. The CURRENT and PREVIOUS transaction types described
in this section of the manual are useful to users selecting either
“Autoclose” or “manual” close. The SETTLEMENT transaction type
described in this section can be used to force Elavon to close and settle a
batch and open a new batch. A merchant can choose Autoclose or manual
close, but not both. The PURGE transaction type is useful for clearing all
transactions within the current batch.

4.20. Current Batch Inquiry
Description

A current transaction is an administrative request to retrieve statistics from
Elavon relative to the current batch.

Samples

The following example is provided to demonstrate use of the Current
transaction:

Test Program Function Tested
Java_Nova_Current.cfm A Current transaction

Parameters Supported


Parameter:

© 2005 CFXWorks, Inc. All Rights Reserved 43

NOVA_TRANSACTION_CODE S
NOVA_MERCHANT S
NOVA_BANK_NBR S

4.21. Previous Batch Inquiry
Description

A previous transaction is an administrative request to retrieve statistics
from Elavon relative to the previous batch.

Samples

The following example is provided to demonstrate use of the Previous
transaction:

Test Program Function Tested
Java_Nova_Previous.cfm A Previous transaction

Parameters Supported


Parameter:
NOVA_TRANSACTION_CODE S
NOVA_MERCHANT S
NOVA_BANK_NBR S

4.22. Purge
Description

A purge transaction clears all transactions within the current batch.

Samples

The following example is provided to demonstrate use of the Previous
transaction:

Test Program Function Tested
Java_Nova_Purge.cfm A Purge transaction

Parameters Supported


Parameter:
NOVA_TRANSACTION_CODE S
NOVA_MERCHANT S
NOVA_BANK_NBR S

4.23. Settlement

© 2005 CFXWorks, Inc. All Rights Reserved 44

Description

A settlement transaction closes the current batch and opens a new batch.

Samples

The following example is provided to demonstrate use of the Settlement
transaction:

Test Program Function Tested
Java_Nova_Settlement.cfm A Settlement transaction

Parameters Supported


Parameter:
NOVA_TRANSACTION_CODE S
NOVA_MERCHANT S
NOVA_BANK_NBR S

4.24. MD5 Message Digest
Description

Message digests are used to protect data integrity, not to achieve data
confidentiality. You might use MD5 as follows. If you are concerned that
a hacker might penetrate your security and modify the content of fields
within your database, you might create a message digest for each field, or
a digest for some combination of fields, and store the result in the
database. When you retrieve the record you would recalculate the digest
and compare it to the original value. If they compare, no change has been
made to the data. If the digest has changed, the data has been changed.
Normally one would use message digests in combination with
encryption/decryption.

The MD5 transaction type is used to calculate a message digest for a text
value passed to the tag. A message digest is not an encryption/decryption
technique because it is a one-way hash function. In other words given the
result of the hash function, you cannot calculate the original input. It is
said that the difficulty of coming up with two messages having the same
message digest is in the order of 2^64. The difficulty in defining a
message with a specific message digest is in the order of 2^128.

MD5 is probably the most popular message digest algorithm in use today
because as compared to other message digest algorithms, it offers a better
balance between performance and security. You can learn more about
MD5 at http://www.nic.mil/ftp/rfc/rfc1321.txt
.

Sample


© 2005 CFXWorks, Inc. All Rights Reserved 45

The following example is provided to demonstrate the use of the MD5
transaction:

Test Program Function Tested
Java_Nova_Digest.cfm A example of calculating an MD5
message digest

Parameters Supported


Parameter:
NOVA_TRANSACTION_CODE S
NOVA_CRYPTO_IN S
NOVA_BANK_NBR S

4.25. AES Encryption/Decryption
Description

The tag encrypts and decrypts data using the AES encryption algorithm
described in Section 2.7 of this document. Encryption is used to protect
data confidentiality.

Sample

The following example is provided to demonstrate the use of an
encryption/decryption transaction:

Test Program Function Tested
Java_Nova_Crypto.cfm A example of encrypting and
decrypting a text field

Parameters Supported


Parameter:
NOVA_TRANSACTION_CODE S
NOVA_CRYPTO_IN S
NOVA_CRYPTO_KEY S
NOVA_CRYPTO_IV S

How Strong Is AES 128-bit Encryption?

To put this issue in perspective, here are some statistics presented by the
National Institute of Standards and Technology (NIST) relative to the
possibility that someone could crack a 128-bit Rijndael encryption key.

http://www.nist.gov/public_affairs/releases/aesq&a.htm



© 2005 CFXWorks, Inc. All Rights Reserved 46

"In the late 1990s, specialized "DES Cracker" machines were built that
could recover a DES key after a few hours. In other words, by trying
possible key values, the hardware could determine which key was used to
encrypt a message. Assuming that one could build a machine that could
recover a DES key in a second (i.e., try 255 keys per second), then it
would take that machine approximately 149 thousand billion (149 trillion)
years to crack a 128-bit AES key. To put that into perspective, the
universe is believed to be less than 20 billion years old."

Alert

AES (Rijndael) is a very serious encryption algorithm. Hackers are
not likely in our lifetime, to be able to compromise this algorithm
unless of course, they guess your encryption key. There are no known
back doors to this algorithm. The bad news is that if you forget your
encryption key, there is absolutely no way that our organization, or
any other organization known to exist, can bail you out! If you forget
you encryption key, you should assume that your data is lost forever!


© 2005 CFXWorks, Inc. All Rights Reserved 47

5. Q
UESTIONS
&A
NSWERS


5.1. How does CFX_NOVA_JAVA secure credit
card transactions?
CFX_NOVA_JAVA uses SSL to encrypt data flowing between the
ColdFusion server and Elavon’s server. This encryption level is 128 bit
strong, regardless of the user’s browser. The SSL protocol, Secure Sockets
Layer protocol, is a security protocol that provides communications
privacy over the Internet. This protocol allows client/server applications to
communicate in a way that is designed to prevent eavesdropping,
tampering, or message forgery.

5.2. Why is the use of SSL important to the
merchant?
When customers use a web page that is secured, their browser will display
a 'closed lock' or other symbol to inform them that SSL has been enabled.
This symbol communicates to them that the information that flows
between their browser and the merchant’s web server is secured via SSL.
However, what happens to this information as it flows between the
merchant’s web server and the processor of the credit card transaction? By
using CFX_NOVA_JAVA’s SSL connection, the merchant is able to
assure their customer that data integrity and data confidentiality is
protected all the way through to Elavon’s servers. Some vendors refer to
this capability as end-to-end encryption.

Also, many service providers in the future will be subject to audits as per
outlined in the SAS-70 Auditing Guidelines. Merchants not using SSL
encryption technology will find that failure to do so will subject them to
harsh criticism from the auditors.

5.3. What is the difference between 40-bit
and 128-bit SSL connections?
Many financial institutions require 128-bit encryption for online banking
because 40-bit encryption is considered to be relatively weak. 128-bits is
about 309 septillion times (309,485,000,000,000,000,000,000,000 ) larger
than 40-bits.

Equated to the real world, sending information without encryption is like
sending a postcard through the mail - the contents are visible to practically
anyone who wants to see it. Using this analogy, 40-bit encryption is like

© 2005 CFXWorks, Inc. All Rights Reserved 48

sending the information in a plain white envelope. 56-bits could then be
equated to using a security envelope that is printed to prevent it from
being seen through.

Relative to these strengths, 128-bit encryption could be compared to
encasing your data in a lead-lined, 12-inch thick titanium safe that is being
transported by an armored tank with a convoy of a hundred armed guards.
In other words, 128-bits is considerably more secure than 40.

Another way to think of the strength of 128-bit encryption is to compare
the length of time it would take for a supercomputer to break the
encrypted data into clean, clear, readable text. In this analogy, it would
take longer than the assumed age of the universe (14 billion years), to
break 128-bit encrypted data, using today’s computing technology.

5.4. Will CFX_NOVA_JAVA use 40-bit or 128-bit
encryption?
The strength of encryption supported by CFX_NOVA_JAVA is controlled
by the strength the encryption technology used by the Elavon server that it
connects to. Since Elavon’s servers in the United States support full
strength 128-bit encryption, CFX_NOVA_JAVA will use 128-bit
encryption for this connection.

5.5. What Is CISP?
CISP is acronym for the Visa U.S.A. Cardholder Information Security
Program. It directly impacts all merchants accepting Visa credit cards for
payment of goods and/or services. In particular, it has a profound impact
on all merchants using the Internet to process credit card orders for goods
or services. CISP defines a standard of due care and enforcement for
protecting sensitive user and credit card information. The program ensures
the annual validation of merchants and all service providers on both the
issuing and acquiring side of the business.

As a merchant who intends to implement credit card capability using
the Internet, you should become very familiar with this program. The
best source of information on the CISP program is www.visa.com\cisp
.

5.6. Is the Tag CISP Certified?

The scope of the CISP certification program includes security
requirements relative to the merchants systems, networks, software, skill
sets, policies and procedures as well as vendor provided software. Since

© 2005 CFXWorks, Inc. All Rights Reserved 49

we provide only one of these components, it would be impossible for us
to CISP certify our product. However, our product does meet the
following CISP requirements:

• CFX_NOVA_JAVA is capable of being deployed by the merchant
in a CISP-compliant manner as defined by the Visa’s CISP
Payment Application Best Practices documentation.
• CFX_NOVA_JAVA does not store magnetic stripe, credit card
numbers, credit card expiration dates or CVV2 data. Please see the
comments in Appendix C relative to the requirement that the
merchant turn off logging capabilities when processing live data.
• CFX_NOVA_JAVA by default stores no credit card data. Please
see the comments in Appendix C relative to the requirement that
the merchant turn off logging capabilities when processing live
data.
• A merchant can force CFX_NOVA_JAVA to log selected
transaction data for debugging purposes. By default all logs are
disabled. Sensitive credit card data is masked from appearing in
the logs. Please see the comments in Appendix C relative to the
requirement that the merchant turn off logging capabilities when
processing live data.
• We believe that CFX_NOVA_JAVA has been developed using
secure coding guidelines that are considered best-practices within
the programming community.
• CFX_NOVA_JAVA does not support wireless communication.
• We have thoroughly tested this offering and closely monitors
newly discovered security vulnerabilities with the intent of
correcting any security vulnerabilities found in our solution.
• CFX_NOVA_JAVA has been tested on networks that deploy
network address translation (NAT), port address translation (PAT),
traffic filtering network devices, anti-virus protection, and use of
encryption.
• CFX_NOVA_JAVA does not enable remote software updates.
• CFX_NOVA_JAVA does not enable remote access.
• CFX_NOVA_JAVA encrypts all network traffic between our
server and Elavon using strong encryption. It is the responsibility
of the merchant to enable SSL between his system and our server.
• CFX_NOVA_JAVA does not provide administrative capability for
web based management.


© 2005 CFXWorks, Inc. All Rights Reserved 50

A
PPENDIX
A.

D
ATA
S
ENT
T
O
E
LAVON


The following information is based on the contents of several Elavon documents with
updates on what we have learned by experience using the CFX_NOVA_JAVA tag. We
have made a serious attempt to make sure the following information is correct, however,
we do not warrant or guarantee that it is accurate. The information is subject to change
and ownership of the standards and rules is entirely controlled by Elavon.

Parsing Rules:
A – Strip all blanks and special characters. Result must be all Alpha. Length
cannot exceed the maximum length allowed.
AN – Strip all blanks and special characters. Result must be all Alpha or Numeric
(0-9). Length cannot exceed the maximum length allowed.
N – Strip all blanks and special characters. Result must be all Numeric (0-9).
Length cannot exceed the maximum length allowed.
ASCII – Must be a valid ASCII character from decimal 32-126. Length is
truncated at the maximum length allowed.
Special – Some data fields have special editing requirements. See field definition
for these special requirements.

Parameter Name

Log Name

Field Description
Max
CFX
Parsing
Rules

NOVA_USER_KEY
MFUKEY
A user defined field that can be used for
any purpose. This field is displayed in the
transaction log to help identify individual
transactions.
15 ASCII
NOVA_USERNAME
This value is used by the