ICVERIFY for Windows - First Data - Global Selector 2 – Overview ... In addition to transaction processing, ... Store up to nine years of transaction information for financial tracking,

ICVERIFY

® for Windows

®

Version 4.2 Software Developer’s Kit Guide

Copyright © 2011, ICVERIFY, Inc., a First Data company. All Rights Reserved. All trademarks,

service marks and trade names referenced in this material are the property of their respective

owners.

This version of this document supersedes any and all previous versions of the ICVERIFY® for

Windows® SDK Guide.

Revision Date: 12 September 2011

ICVERIFY, Inc. 6200 South Quebec Street

Suite 350

Greenwood Village, CO 80111

USA

For Sales and Product Information, call:

(800) 538-0651

For Technical Support, call:

(800) 900-6133

Table of Contents

CHAPTER 1 – INTRODUCTION TO ICVERIFY®

FOR WINDOWS®.......................................................... 1

OVERVIEW .......................................................................................................................................................... 1 Style Conventions ........................................................................................................................................... 1

PREREQUISITES ................................................................................................................................................... 1 GETTING HELP .................................................................................................................................................... 2

CHAPTER 2 – OVERVIEW ................................................................................................................................ 3

OVERVIEW .......................................................................................................................................................... 3 FEATURES OVERVIEW ......................................................................................................................................... 4

Integration Modes .......................................................................................................................................... 5 Encryption...................................................................................................................................................... 5

CHAPTER 3 – THE BANKCARD INDUSTRY ................................................................................................ 6

OVERVIEW OF PROCESSING NETWORKS .............................................................................................................. 6 Bank Card Authorization Flow ...................................................................................................................... 6 Host-based vs. Terminal-based Settlement .................................................................................................... 8

ABOUT INTERCHANGE NETWORKS ...................................................................................................................... 8 Interchange Fees ........................................................................................................................................... 9 Merchant Discount Rates ............................................................................................................................... 9

UNDERSTANDING INTERCHANGE FEES AND MERCHANT DISCOUNT RATES ...................................................... 10 CARD VERIFICATION VALUES (CVV2 / CVC2 / CID) ....................................................................................... 11

CVV Indicator .............................................................................................................................................. 12

CHAPTER 4 – INDUSTRY TRANSACTIONS ............................................................................................... 13

OVERVIEW ........................................................................................................................................................ 13 RETAIL TRANSACTIONS ..................................................................................................................................... 13

Sale .............................................................................................................................................................. 13 Void .............................................................................................................................................................. 14 Credit / Refund / Return ............................................................................................................................... 14 Credit Void / Cancel Return / Refund Void .................................................................................................. 14 Auth Only / Pre-Authorization ..................................................................................................................... 14 Force / Post-Authorization .......................................................................................................................... 14 Cash Advance .............................................................................................................................................. 15

HANDLING RETAIL TRANSACTIONS................................................................................................................... 15 SAMPLE TRANSACTIONS ................................................................................................................................... 20

Sale Example ............................................................................................................................................... 20 Void Example ............................................................................................................................................... 20 Credit / Refund / Return Example ................................................................................................................ 21 Credit Void / Cancel Return / Refund Void Example ................................................................................... 21 Auth Only / Pre-Authorization Example ...................................................................................................... 22 Force / Post-Authorization Example ........................................................................................................... 22 Balance Inquiry Example ............................................................................................................................. 23 Cash Advance Example ............................................................................................................................... 23

CARD-SWIPED TRANSACTIONS.......................................................................................................................... 24 Swiped Transaction Support in Request-String Mode ................................................................................. 24 Extracting printed card number from track data for FDMS Gift cards ....................................................... 26 Swiped Transaction Support in XML Mode ................................................................................................. 28 Sale Transaction with Track 1 Data Only ................................................................................................... 28 Sale Transaction with Track 2 Data Only ................................................................................................... 28 Sale Transaction with Both Track 1 and Track 2 Data................................................................................ 29

ICVERIFY® 4.0 SDK Guide

Copyright © 2011, ICVERIFY, Inc., a First Data company.

All trademarks are the property of their respective holders.

MOTO (MAIL ORDER / TELEPHONE ORDER) TRANSACTIONS ........................................................................... 30 Book ............................................................................................................................................................. 33 Ship .............................................................................................................................................................. 33 Processing Book and Ship Transactions ...................................................................................................... 33

EMV TRANSACTIONS ........................................................................................................................................ 34 HOTEL TRANSACTIONS ..................................................................................................................................... 38

Check-In ....................................................................................................................................................... 38 Add Charges ................................................................................................................................................ 40 Extend Stay .................................................................................................................................................. 41 Check-Out .................................................................................................................................................... 42 No Show ....................................................................................................................................................... 43

LEVEL III PURCHASING CARDS ......................................................................................................................... 44 Level III Record Formats – Request-String Mode ....................................................................................... 45 Level III Record Formats – XML Mode ....................................................................................................... 45

DEBIT CARD TRANSACTIONS ............................................................................................................................ 47 Processing Debit Card Transactions ........................................................................................................... 47 Debit Transaction Types .............................................................................................................................. 47 Debit Transaction Request Format .............................................................................................................. 48 Debit Transaction Support by Processor ..................................................................................................... 49

PROCESSING TRANSACTIONS FOR MULTIPLE MERCHANTS ............................................................................... 49

CHAPTER 5 – REQUESTS AND RESPONSES ............................................................................................. 50

OVERVIEW ........................................................................................................................................................ 50 Request Files ................................................................................................................................................ 50

TRANSACTION RESPONSES ................................................................................................................................ 53 Transaction Responses in Request-String Mode .......................................................................................... 53 Transaction Responses in XML Mode ......................................................................................................... 60 XML Response Fields .................................................................................................................................. 62

PROCESSING OFFLINE GROUP INPUT OR REQUEST FILES – INTERPRETING RESULTS ......................................... 66

TOKENIZATION AND ENCRYPTION CAPABILITY ON FDMS CARDNET ......................................... 666

CHAPTER 6 – REPORTS .................................................................................................................................. 70

OVERVIEW ........................................................................................................................................................ 70 DETAIL REPORTS ............................................................................................................................................... 70

Detail Report Format................................................................................................................................... 71 Detail Report Fields..................................................................................................................................... 75 Additional Fields ......................................................................................................................................... 77 Credit Card Summary Information .............................................................................................................. 77 Visa

® & MasterCard

® Section ..................................................................................................................... 78

American Express®

Section.......................................................................................................................... 80 Not Captured or Authorized Transactions ................................................................................................... 81 Authorized Transaction Section ................................................................................................................... 82

POST-SETTLEMENT REPORTS ............................................................................................................................ 83 Credit Card Section ..................................................................................................................................... 84 Authorized Only Transaction Section .......................................................................................................... 85

CHAPTER 7 – TUTORIALS ............................................................................................................................. 87

OVERVIEW ........................................................................................................................................................ 87 WINDOWS

® VISUAL BASIC INTEGRATION TUTORIAL ........................................................................................ 87

Using the Direct DLL Interface ................................................................................................................... 87 Using the Request-Answer Interface ............................................................................................................ 87

SAMPLE CODE PROGRAM FLOW ........................................................................................................................ 89 Code Program Flow Procedures ................................................................................................................. 90

APPENDIX A – RESPONSE CODES ............................................................................................................... 94

ICVERIFY® 4.0 SDK Guide



OVERVIEW ........................................................................................................................................................ 94 Address Verification Result Codes ............................................................................................................... 94 Card Verification Result Codes ................................................................................................................... 94 Response Code Values ................................................................................................................................. 94

APPENDIX B – FIELD DEFINITIONS ........................................................................................................... 96

APPENDIX C – REPORT TRANSACTION TYPES .................................................................................... 107

APPENDIX D – GLOSSARY........................................................................................................................... 108

GLOSSARY OF TERMS ...................................................................................................................................... 108

Introduction to ICVERIFY® for Windows®



Page 1 of 119

Chapter 1 – Introduction to ICVERIFY®

For Windows®

Overview This guide describes how to use the ICVERIFY® Software Developer‘s Kit (SDK)

to set up and configure ICVERIFY. It‘s intended for developers using ICVERIFY

on Microsoft® Windows® platforms.

Style

Conventions

The following style conventions are used in this document:

Bold type indicates items such as file names, window names, and

buttons.

Italics type indicates a reference to another document, or terms that

are defined within the text.

NOTE: Indicates suggestions or additional, detailed, information.

! ! ! Indicates actions you must take or avoid for the system to

operate properly.

Prerequisites Prior to operating the ICVERIFY application, you must complete the following

tasks:

Establish a merchant account with a bank that is licensed to provide

merchant payment services (also called an acquiring bank.)

Confirm that your computer system meets the minimum requirements,

including the service pack levels required for your chosen operating

system.

Obtain your Processor setup information from the merchant

representative at your acquiring bank.

Finally, you must install, set up and register the software.

If you are not certain how to perform these tasks, or do not know if your

computer is capable of running the software, please refer to the ICVERIFY

Setup Guide.

Introduction to ICVERIFY® for Windows®



Page 2 of 119

Getting Help The following is a list of the available Help features provided to assist you:

http://www.firstdata.com/paymentsoftware_integrators — provides a

forum for getting your questions answered and accessing archived help

information.

Context-sensitive Help—allows you to point to an area of the interface

that you would like more information about. To use this Help, click the

question mark in the interface and then click the area of the interface in

question.

GUI Help—allows you to access a directory and index of helpful

information. To use this Help, press F1 while you‘re using ICVERIFY.

Setup Help—allows you to access a directory and index of helpful setup

information. To use this Help, press F1 while you‘re using Advanced Setup.

NOTE: You can also call (800) 900-6133 for Customer Service assistance, or

send email to the following address: [email protected]

http://www.firstdata.com/paymentsoftware_integrators

mailto:[email protected]

Overview



Page 3 of 119

Chapter 2 – Overview

Overview The ICVERIFY® Software Developer‘s Kit (SDK) assumes that you are familiar

with the programming language that you intend to use. There are, however,

tutorials included in the SDK that explain how to use the available sample

code. You‘ll also find sample transactions that you can copy and paste right

from this kit.

Chapter 3 describes the Bank Card Industry. It‘s highly recommended that

you familiarize yourself with this information.

Each section of the SDK gives you a detailed look at what you need for the

industry you are integrating. After completing this document, you will have

the knowledge to integrate the industries of your choice.

ICVERIFY uses a ―request and response‖ integration method. This is available

in one of two implementations:

You can place an ASCII text file in a specific directory. The file is

referred to as a request file. ICVERIFY retrieves the information within

this file and sends it to the Processing Network in the appropriate

format. Then, when the transaction has been processed, ICVERIFY

returns a different file, called the response, or answer. For more

information regarding request and answer files, see Chapter 6.

You can also use the same formats in a direct programming

interface to the ICVERIFY processing Dynamic Link Library (DLL). For

more information on this interface, please refer to the on-line help

materials available in your SDK installation package.

! ! ! IMPORTANT NOTE: Merchants are under certain obligations from the

card associations, merchant banks, and service providers, to demonstrate

compliance with their security programs regarding the storage and

transmission of payment card data. Failure to comply with these security

programs may expose you to liabilities and fines.

ICVERIFY, Inc. has developed documentation to assist you in operating your

software safely and securely. Please review the PA-DSS Implementation

Guide located on your software installation CD-ROM for important

information in this regard.

Overview



Page 4 of 119

ICVERIFY is one of the leading electronic transaction processing software

packages on the market. It provides credit card authorization/draft capture,

check, and debit/ATM card authorization functions. ICVERIFY operates on

open-platform, point-of-sale/business systems worldwide.

In addition to transaction processing, ICVERIFY provides transaction storage,

tracking and retrieval, reporting and integration capabilities. ICVERIFY can

be configured for single-user, multi-user, and/or multi-merchant operation

(additional licensing may be required).

ICVERIFY solutions are used in both traditional retail environments such as

general retail, restaurant, and hotel; and in non-traditional retail environments

such as kiosk, catalog, and mail/phone order, cellular digital packet data,

and wireless communications. ICVERIFY supports transaction processing

through virtually all of the major Processing Networks.

Features

Overview

ICVERIFY® places many powerful features at your fingertips, enabling you to do

the following:

Process VISA®, MasterCard®, American Express®, Discover®, Diners/

Discover®, JCB/Discover®, JCB International and private label credit

cards

Process ATM, debit, and check transactions

Process stored value / gift card transactions

Integrate with existing merchant software systems

Produce comprehensive transaction reports that can be printed or

viewed on screen

Import and/or export data into other applications such as order entry

programs, point of-sale systems, databases, Internet shopping carts,

and spreadsheets

Store up to nine years of transaction information for financial tracking,

reconciliation, and marketing demographics

Use two-track Magnetic Stripe Readers for credit cards, three-track

Magnetic Stripe readers for credit cards and magnetic stripe driver's

licenses, EMV chip readers for EMV smart cards, MICR readers for

checks, and Magnetic Stripe Readers with PINpads for debit/ATM

cards, including DUKPT encryption

Support Visa Paywave (VCPS 2.x) technology for Visa contactless

transactions

Support TDES encryption for Debit Transactions

Overview



Page 5 of 119

Integration

Modes

ICVERIFY® versions 4.0 and above offer two messaging formats and three

primary integration interfaces. You can use whatever combination of formats

and interfaces is needed to enable your payments integration.

The messaging formats supported are as follows:

Request string mode (also known as ―request-answer‖ mode) involves

creating a string of data where each individual data element is

encapsulated in quotation marks and delimited by commas. This

mode is very easy to use; however the request strings are position-

sensitive, meaning you must not omit a field from a request string

even if the field is blank. Instead, you must pass a null value (that is,

two quotation marks with nothing in between them.)

XML mode involves creating an XML document where you only need

to populate the nodes that actually contain data. This mode is very

flexible; however it may be more cumbersome to implement if you

are not familiar with XML programming.

The integration interfaces available are as follows:

A shared directory interface is available where you can place

request files created either in request string or XML format. You can

then configure the ICVERIFY software to poll this directory, pick up the

request files, and generate response files for parsing. The response

files will be formatted in the same manner as the request files.

A direct DLL interface is available for developers comfortable with

DLL programming. There are code samples on the ICVERIFY

installation CD-ROM for this interface.

Last, an ActiveX control is available for developers who want to

avoid a file-based interface but find DLL programming unsuitable or

impractical.

Encryption ICVERIFY versions 4.1 and above offer new encryption features both

within the application itself as well as for external software developers‘

use. By using the encryption and decryption functionalities offered by

the ICVTnsServer, you can introduce cutting edge 256-bit AES

encryption to your transaction processing in a simple integration to

the ICVERIFY software. Refer to the online help in the SDK package for

details on how to invoke and use the ICVTnsServer.

The Bankcard Industry



Page 6 of 119

Chapter 3 – The Bankcard Industry

Overview of

Processing

Networks

Merchants are set up by their financial institution to process transactions

through a Processing Network.

Your ICVERIFY® software uses your computer‘s modem or the Internet to

contact this Processing Network directly. The processor acts as an

intermediary between you and your bank.

In addition to processing credit cards, many Processing Networks also handle

debit card, check verification / guarantee, stored value and private label

transactions.

Figure 1 Bank Card Authorization Flow

BANK CARD AUTHORIZATION FLOW

CARD

PROCESSING

NETWORK

VISA

MasterCard

VISA

MasterCard

ISSUING

BANK

ISSUING

BANKACQUIRING

BANK / ISO

ACQUIRING

BANK / ISO

Bank Card

Authorization

Flow

Credit card processing always involves at least the following two steps (the

second step may or may not be apparent to the merchant):

Authorization

Settlement




Page 7 of 119

Bank Card

Authorization

Flow

(continued)

Step one is generally referred to as authorization. When a credit card

transaction for a sale is processed, ICVERIFY® connects with a credit card

Processing Network and submits the transaction request. The Processing

Network takes the request and matches it with a database maintained by

the bank that issued the credit card. If there is enough credit available, the

transaction is approved and the necessary funds are held in reserve. This

reduces the card‘s ―open to buy‖ (available credit) by the transaction

amount. No money changes hands at this point.

Approved transactions are written to a settlement or open batch file in

ICVERIFY, and these transactions remain in the file until settlement is

performed.

The next step is the settlement (or ―close batch‖) procedure. You must settle

before the funds from approved transactions are deposited in your bank

account.

During settlement, ICVERIFY must send transactions to the processor so funds

can be transferred to your account. The authorization process is uniform, but

the settlement procedure is not. For settlement, processors can be divided

into two categories: Terminal-based and Host-based (Figure 2).

Figure 2 Host- vs. Terminal-based settlement




Page 8 of 119

Host-based

vs. Terminal-

based

Settlement

Terminal-based processors require that the merchant connect to the network

and submit the open batch (which contains all of the transactions that were

previously approved) for settlement before the funds from the approved

transactions are deposited into your account.

This is accomplished with one phone call. ICVERIFY® submits the open batch

for settlement, gets an approval for the batch, logs off, and transfers the

settled transactions from the open batch to history files. The money (minus

any interchange fees) is then transferred to your account. Settlement can be

done at any time with terminal-based processors.

A host-based processor maintains the open batch. As ICVERIFY is authorizing

transactions, the host-based processor keeps track of unsettled transactions

for which you have received approval. Some host-based processors will

auto-settle your batch. This means that at a certain point each day, the

processor will automatically close out the batch. ICVERIFY uses the

computer‘s internal clock to automatically transfer the open batch into the

history file without contacting the processor. Some host-based processors

require that a settlement be performed; however, only batch totals are sent

unless an out-of-balance condition is encountered.

Most merchants that need to settle go through a settlement procedure at

the end of each day. ICVERIFY automatically processes all credit cards

authorized since the last settled batch. Once settlement has been

completed (either by the merchant or the processor) the funds are deposited

to your account at a time determined by your agreement with the bank or

card company.

About

Interchange

Networks

In the context of electronic payment authorization, the exchange of financial

transaction information is termed clearing; while the exchange of actual

funds for the transaction and the fees associated with them is termed

settlement. Clearing and settlement occur behind the scenes across a single

network system, and the term used to refer to this system, globally, is

interchange. Interchange enables issuers and acquirers to exchange

information, transactions and money on a standardized and consistent basis,

when going through the bankcard system — MasterCard®, Visa®, Discover®,

and so on.




Page 9 of 119

Interchange

Fees

During the interchange process, the acquirer pays fees to the issuer. An

acquirer is a bank that represents merchants in accepting transactions (also

referred to as the merchant bank). An issuer is a bank that issues a

credit/debit/purchase card to a consumer.

The issuer deducts these fees from the transaction amount and the issuer

pays the net amount to the acquirer. These are termed interchange fees.

This fee is compensation to reimburse the issuer for the expenses of processing

the transaction and risks associated with providing loans. You can reduce

the interchange fee by employing certain fraud detection schemes such as

AVS and CVV2, or by submitting additional information about the

transaction.

Merchant

Discount

Rates

The acquirer is reimbursed for its costs, including interchange fees paid, by

charging you a merchant discount. This can be a percentage of the

transaction value or a set fee after cost.

The discount is usually calculated and charged once a month. It covers

interchange fees, as well as authorization costs and cost of sales draft

processing. This merchant discount is also known as the Merchant Discount

Rate, and is negotiated at the time the acquirer-merchant agreement is

drawn up.

Once a month, the acquirer calculates the Merchant Discount Rate and

subtracts it from the amount credited to you. Merchant Discount Rates are

calculated using a cost-based interchange methodology, based upon the

economic characteristics of the products you sell, the industry segment to

which you belong, and the processing characteristics of that industry

segment.

Merchant Discount Rates are also calculated using incentive-based

methodologies. These fees are generally lower than calculated rates, and

are reflective of member investments to facilitate interchange, involving

technology adoption, data enhancement, and other strategic objectives of

the bankcard system.




Page 10 of 119

Under-

standing

Interchange

Fees and

Merchant

Discount

Rates

Bankcard systems and issuers use tiered Interchange Fee/Merchant Discount

Rate schedules. This provides an incentive to use the system/issuer, increase

volume through that system/issuer, and interface with the system in a manner

advantageous to the system/issuer.

Generally, technologies/interfaces that are less error prone or otherwise incur

reduced overhead on behalf of the system/issuer are charged lower

Merchant Discount Rates than those that incur greater overhead.

For example, for point-of-sale (POS) debit card transactions, interchange fees

set by the card associations for ―offline‖ transactions (such as signature-

based debit) are much higher than the fees charged for ―online‖

transactions (such as PIN-based debit,) which are set by the regional and

national ATM. The differences in fees are to offset the higher fraud and credit

risks of offline. However, these differences are diminishing rapidly due to

enhancements in the offline networks and may not justify the current fee

gap.

Merchant Discount Rates are used as incentives for merchants to use, and

processors to market ICVERIFY®. What ICVERIFY provides is POS or processing

capabilities that enable merchants, through their processor(s), to exploit

interfaces to the system/issuer, resulting in lower interchange rates on

transactions.

For example, because ICVERIFY runs directly on the POS system (PC-based

cash register or computer), the POS system's keyboard provides the full

alphanumeric capability required for address verification (AVS) on

transactions (which is not true with a bank terminal).

Address verification allows you to include the street number, street name,

and ZIP code with the credit card authorization. When ICVERIFY returns the

authorization, it includes a code which tells whether the information matched

on 1, 2, or 3 of the address fields.

This feature can dramatically reduce the incidence of fraud and

chargebacks, since it‘s comparatively easy to come up with a legitimate

card number, but much more difficult to get the corresponding address. As

such, utilization of this feature often allows you to receive a lower

interchange rate on transactions (resulting in more money in your pocket).

To recap:

When processing transactions, you connect to a Processing

Network. This is an entity that acts as an intermediary between you

and the credit card company.

After authorizing transactions, authorizations must be settled before

the funds from the approved transactions are transferred to your

account. (Most processors require that you dial into their network to

perform a settlement. Some host-based processors (not all) will settle

transactions for you automatically.)




Page 11 of 119

Card

Verification

Values

(CVV2 /

CVC2 / CID)

CVV2/CVC2/CID are security features on the back of Visa® and

MasterCard®, JCB/Discover and Diners/Discover and on the front of

American Express® and Discover® credit cards. They were put in place to

help merchants avoid fraud and increase profits.

The new three-digit or four-digit value is an important security feature for

card-not-present transactions. It provides a cryptographic check of the

information embossed on the card.

The CVV2/CVC2/CID value helps to validate that a customer has a valid

card in his/her possession, and that the card account is legitimate. It helps

minimize the risk of unknowingly accepting a counterfeit card or fraudulent

transaction.

CVV2 and CVC2 are printed only on the back of Visa® and MasterCard®,

JCB/Discover and Diners/Discover cards, while CID is on the front of American

Express® and Discover cards. It‘s not contained in the magnetic stripe

information, and does not appear on sales receipts. It must be included in the

authorization request, along with the following information:

Transaction Type

Account Number

Expiration date

Transaction dollar amount

If you are participating in CVV2/CVC2/CID, you can generally expect to

receive a ―match‖ or ―no match‖ response. However, it is possible your

transaction may still be approved. In that case you must decide what to do

according to your own business rules.

Consult the document AVS & CVV Response Codes located on your

installation CD-ROM for further details.




Page 12 of 119

CVV Indicator

The CVV Indicator is a one-digit value which indicates the presence of

CVV2/CVC2/CID for manually entered transactions for Visa®, MasterCard®,

American Express®, Discover, JCB/Discover and Diners/Discover cards.

The CVV Indicator combo box contains the list of indicator values like

―Present‖, ―NotPresent‖, ―Bypass‖ and ―Illegible‖. The indicator strings are

converted to respective integer values for the authorization and settlement

message formats.

Depending on the CVV Indicator value chosen, the CVV field (stands for

CVV2/CVC2/CID) gets enabled or disabled. The CVV field only becomes

enabled if CVV Indicator is chosen as ―Present‖. Otherwise, it remains

disabled.

When entered in request answer mode the value of this field can be "0", "1",

"2" or "9" where "0" = Bypass, "1" = Present, "2" = Illegible and "9" = Not Present.‖

Figure 4 Sample CVV2

Industry Transactions



Page 13 of 119

Chapter 4 – Industry Transactions

Overview This chapter describes the various types of transactions you can perform

using ICVERIFY®, and provides sample code strings to help you implement a

transaction handling process that best fits your business needs.

For testing purposes, you can copy and paste any of the sample transactions

included in this section into a request file.

NOTE: This guide discusses the file-based integration methods available

within the ICVERIFY product exhaustively and only makes passing reference

to the direct DLL interface. This is because if you are familiar with DLL

programming, you need only understand the message formats discussed in

this document. However, if you are unfamiliar even with file management

programming, you will likely need more information before you feel

comfortable integrating to your ICVERIFY software.

Retail

Transactions

Retail is one of the easiest industry types to integrate. This is done by creating

a flat ASCII text file that ICVERIFY picks up and processes. Once the

transaction has been processed, ICVERIFY returns a flat ASCII text file that

contains the response. The file may be plain-text or encrypted, depending

on your use of the built-in encryption settings.

This integration method is referred to as request (.req) and response/answer

(.ans). The same transaction types used in retail are used in other industries as

well.

Sale A sale is the most commonly used transaction in a retail format. It‘s used to

charge a purchase to a customer‘s credit account. It places a ―hold‖ on the

customer‘s open-to-buy (or available credit) by the amount of the sale.

Once a sale has been approved, the hold on the customer's credit remains

valid for a limited time (three to thirty days, depending on the cardholder's

bank) before expiring and releasing the hold on the funds in the customer's

credit account.

Funds from an approved sale transaction are not deposited into your

account until they have been settled. This occurs automatically if you are

using a host-based processor that auto-settles transactions. If you are using a

terminal-based processor (or a host-based processor that does not auto-

settle), you must perform a settlement / end-of-day procedure in order for the

funds from authorized sales transactions to be transferred to your account.




Page 14 of 119

Void This transaction is used to remove a sale from the open batch before it has

been settled. It does not cause any funds to be transferred. If a sale has not

been settled, it can be voided. If a sale has been settled, a

credit/refund/return transaction must be performed. Transactions that have

been voided continue to hold funds from a customer's open to buy until they

have expired.

Credit /

Refund /

Return

A credit transfers money from your account back to the customer. It‘s used

to return funds to the customer‘s account after a transaction has been

settled.

A void does not work in this type of situation since voids are designed to nullify

an unsettled transaction (that is, a transaction that is still in the open batch

waiting for settlement).

For terminal-based processors, ICVERIFY® does not dial out when a credit‘s

submitted. Instead, the credit‘s stored in the open batch and transmitted at

settlement. For most host-based Processing Networks, the software will dial

out when a credit‘s submitted.

Credit Void /

Cancel

Return /

Refund Void

Similar to a void transaction, a credit void is designed to remove an unsettled

credit transaction from the open batch. A credit void cannot be performed

if the credit has already been settled.

Auth Only /

Pre-

Authorization

An Authorize Only transaction is used to verify funds and return an approval

code. This transaction type places a ―marker‖ for funds on the cardholder‘s

credit line, but does not cause funds to move. Therefore, Auth Only

transactions cannot be settled.

A force transaction must be performed to settle a transaction initiated with

an Auth Only (see Force/Post-Authorization). Auth Only transactions are

cleared out of the batch each time a settlement is performed.

Force / Post-

Authorization

A Force transaction is primarily used to enter a voice approval into the open

batch. For example, you submit a card for approval, get a ―voice

authorization‖ message and call your merchant help desk for a voice

authorization. Your merchant help desk gives you an approval code for the

transaction over the phone.

You can then enter the transaction into the open batch using a Force

transaction and the approval code provided by your help desk. A Force can

also be used to complete an Auth Only transaction (see Auth Only / Pre-

Authorization).




Page 15 of 119

Cash

Advance

A Cash Advance transaction is used by certain merchants who offer cash to

credit card holders in return for a service fee. The amount of the cash

received plus the fee is deducted from the cardholder‘s credit limit.

Currently, this transaction type is only supported for merchant accounts using

First Data‘s CARDnet platform.

Handling

Retail

Transactions

For ICVERIFY® to send a transaction to the Processing Network you will need

at least a credit card number, expiration date, and amount. This information

is placed in a quote, comma delimited format that looks like this:

"C1","Clerk","Comment","Account Number","Expiration Date",

"Amount","Zip","Address"

If you are using XML mode instead of the legacy request string mode, the

logical transaction structure would look like this:

<Request>

<CreditCardCharge>

<ClerkID></ClerkID>

<Comment></Comment>

<AccountInfo>

<AccountNumber></AccountNumber>

</AccountInfo>

<ExpirationInfo>

<ExpirationMonth></ExpirationMonth>

<ExpirationYear></ExpirationYear>

</ExpirationInfo>

<TransactionAmount></TransactionAmount>

<BillingPostalCode></BillingPostalCode>

<BillingAddress></BillingAddress>

</CreditCardCharge>

</Request>

The examples above represent Sale transactions. Table 1 describes the fields

used in retail transactions.




Page 16 of 119

Table 1 Retail Transaction Fields

Field Description

Leading Field /

Transaction Type

Contains the transaction identifier and is case

sensitive. Valid values include the following:

Sale: Request string mode C1, XML mode

CreditCardCharge

Void: Request string mode C2, XML mode

CreditCardVoid

Credit / Refund / Return: Request string

mode C3, XML mode CreditCardCredit

Credit Void / Cancel Return / Refund Void:

Request string mode CR, XML mode

CreditCardVoidCredit

Auth Only / Pre-Authorization: Request string

mode C6, XML mode CreditCardAuthorize

Force / Post-Authorization: Request string

mode C5, XML mode CredtiCardCapture

Balance Inquiry: Request string mode Ci,

XML mode CreditCardBalanceInquiry

NOTE: This field is required. You either have to use

the transaction identifier code in request string mode,

or the node type in XML mode. Remember, Balance

Inquiry transactions are only available for certain

processing networks and cards at this time. Consult

the Transaction Builder tool in your SDK package for

specific information.

Clerk Contains the clerk information, and can contain up

to 32 alphanumeric characters.

NOTE: This field is optional, but if you choose not to

add it in request string mode, you must add a blank

field (represented by two double quotes ―‖) in its

place.




Page 17 of 119

Field Description

Comment Contains comment information about the

transaction, and can contain up to 32 alphanumeric

characters. This field is often used for order numbers

or other internal identifying data meaningful to the

merchant.

NOTE: This field is optional, but if you choose not to

add it in request string mode, you must add a blank

field (represented by two double quotes ―‖) in its

place.

Account Number Contains the credit card number used in the

transaction, and cannot contain spaces or dashes.

NOTE: In request-string mode, this field is required. In

XML mode, the AccountInfo node is required,

however it can contain either the AccountNumber

element, one of the track elements (discussed later),

or any combination thereof.




Page 18 of 119

Field Description

Expiration Date Contains the expiration date on the credit card used

in the transaction. In request-string mode, the date

format is YYMM (year, year, month, month.) In XML

mode, the ExpirationInfo node contains two

elements: ExpirationMonth and ExpirationYear. Use

format MM for ExpirationMonth and YY for

ExpirationYear.

NOTE: The expiration date is required. However,

some payment instruments do not carry an expiration

date, for example certain private label and stored

value cards. Use the following rules to determine

how to populate this field.

If you are using request-string mode:

If the card is a private label card that does

not carry an expiration date, use the default

value 4912

If the card is a FDMS Stored Value card, use

the default value 4912

For all other cards, use the expiration date

actually present on the physical card.

If you are using XML mode:

If you are passing track data in the

AccountInfo node, you do not need to

include the ExpirationInfo node, as the

magnetic tracks contain the expiration

date.

If you are only using the AccountNumber

element of the AccountInfo node (that is,

you are not supplying track data), you must

include the ExpirationInfo node. In this case,

use the default value of 12 and 2049 if the

card does not carry an expiration date.




Page 19 of 119

Field Description

Transaction Amount Contains the amount of the sale. Decimal points are

not required, but recommended.

NOTE: This field is required. However, some

transaction types do not require a transaction

amount, for example a Cashout transaction for FDMS

Stored Value. Use the following rules to determine

how to populate this field:

If you are performing a Cashout transaction

for First Data Gift Card, use the default value

1.23.

If you are performing a Balance Inquiry

transaction, you can use any amount,

including 0.00, which is usually not allowed.

However, we suggest you use the value 1.23

as a consistent default value for other

transaction types.

For all other transaction types, use the

actual amount of the transaction.

Billing Postal Code /

ZIP Code

Contains the ZIP code of the customer‘s billing

address. This field can contain the five or nine-digit

ZIP code without spaces or dashes.

NOTE: This field is optional, but required in cases

where card swipes don‘t work.

Billing Address Contains the customer‘s billing street address. This

field can contain up to 32 alphanumeric characters

and allows for spaces and dashes.

NOTE: This field is optional, but required in cases

where card swipes don‘t work.




Page 20 of 119

Sample

Transactions

Here are a few simple sample transactions. For testing purposes, you can copy

and paste any of the following transaction samples into a request file. Be sure to

remove any line breaks from these samples in your request file.

Sale Example "C1","Clerk","Comment","4111111111111111","0612",

"1.00","12345","123 MAIN ST"

XML Mode <Request>

<CreditCardCharge>

<ClerkID>Clerk</ClerkID>

<Comment>Comment</Comment>

<AccountInfo>

<AccountNumber>4111111111111111</AccountNumber>

</AccountInfo>

<ExpirationInfo>

<ExpirationMonth>12</ExpirationMonth>

<ExpirationYear>06</ExpirationYear>

</ExpirationInfo>

<TransactionAmount>1.00</TransactionAmount>

<BillingPostalCode>12345</BillingPostalCode>

<BillingAddress>123 MAIN ST</BillingAddress>

</CreditCardCharge>

</Request>

Void

Example

"C2","Clerk","Comment","4111111111111111","0612",

"1.00","",""

XML Mode <Request>

<CreditCardVoid>



<AccountInfo>


</AccountInfo>

<ExpirationInfo>



</ExpirationInfo>


</CreditCardVoid>

</Request>

Notice that the format of the Void is very similar to the Sale transaction. In

request-string mode, the only differences are that a Void uses a C2 transaction

identifier and the two trailing fields for address and zip code are blank. In XML

mode, you‘ll notice the CreditCardVoid tag appears in place of

CreditCardCharge, and no address information exists. This is because in XML

mode, you don‘t have to add nodes you aren‘t using.




Page 21 of 119

Credit /

Refund /

Return

Example

"C3","Clerk","Comment","4111111111111111","0612",

"1.00","",""

XML Mode <Request>

<CreditCardCredit>



<AccountInfo>


</AccountInfo>

<ExpirationInfo>



</ExpirationInfo>


</CreditCardCredit>

</Request>

The examples above depict a Credit transaction. Remember that if your

processing network performs Terminal-Based settlement, the ICVERIFY software

will not send out a real-time request for Credit transactions. In this case, Credit

transactions are only sent out during settlement.

Credit Void /

Cancel

Return /

Refund Void

Example

"CR","Clerk","Comment","4111111111111111","0612",

"1.00","",""

XML Mode <Request>

<CreditCardVoidCredit>



<AccountInfo>


</AccountInfo>

<ExpirationInfo>



</ExpirationInfo>


</CreditCardVoidCredit>

</Request>

The example above is a Credit Void/Cancel Return/Refund Void transaction.

This transaction is used to void Credit transactions.




Page 22 of 119

Auth Only /

Pre-

Authorization

Example

"C6","Clerk","Comment","4111111111111111","0612",

"1.00","12345","123 MAIN ST"

XML Mode <Request>

<CreditCardAuthorize>



<AccountInfo>


</AccountInfo>

<ExpirationInfo>



</ExpirationInfo>




</CreditCardAuthorize>

</Request>

The examples above represent Auth Only / Pre-Authorization transactions. This

transaction is used when you want to verify funds on a cardholder account

but not yet submit the transaction for settlement.

Force / Post-

Authorization

Example

"C5","CLK","CMM","4111111111111111","0612","1.00",

"APV","12345","123 MAIN ST"

XML Mode <Request>

<CreditCardCapture>



<AccountInfo>


</AccountInfo>

<ExpirationInfo>



</ExpirationInfo>


<ApprovalNumber>APV</ApprovalNumber>



</CreditCardCapture>

</Request>




Page 23 of 119

The examples above represent a Force / Post-Authorization transaction.

Notice there is an extra field between the amount and ZIP fields. This field is

for the approval code, and is required for this transaction type. In the real

world, you would submit a two to six digit approval code in place of the APV

placeholder in the sample.

Force/Post-Authorization transactions are used when you get a voice

approval, or in conjunction with Auth Only / Pre-Authorization transactions.

Balance

Inquiry

Example

"Ci","CLK","CMM","4111111111111111","0612","1.23",

"",""

XML Mode <Request>

<CreditCardBalanceInquiry>



<AccountInfo>


</AccountInfo>

<ExpirationInfo>



</ExpirationInfo>


</CreditCardBalanceInquiry>

</Request>

The examples above depict a sample Balance Inquiry transaction. Notice

there are comparatively few fields required – essentially the card number,

expiration date and a dummy amount value.

Cash

Advance

Example

"C8","CLK","CMM","4111111111111111","0612","1.23",

"",""




Page 24 of 119

XML Mode <Request>

<CreditCardCashAdvance>



<AccountInfo>


</AccountInfo>

<ExpirationInfo>



</ExpirationInfo>


</CreditCardCashAdvance>

</Request>

The examples above depict a sample Cash Advance transaction. Notice

again there are comparatively few fields required – essentially the card

number, expiration date and a dummy amount value.

Card-

Swiped

Transactions

Card information can be entered manually or can be entered into a card

reader. Transactions based on information obtained from a card reader are

referred to as swiped transactions.

Better discount rates are generally offered for swiped transactions. An

application can prepare these swiped transactions and pass them to

ICVERIFY® for authorization.

To send a swiped transaction, use the same transaction record format and

append the swiped data, minus the start character or sentinel (%), to the

expiration date. A sample of both swiped and keyed (or manual-entered)

transaction types follow.

NOTE: Swiped transactions are only valid for industries where the cardholder

and card are generally present at the point of sale, such as Retail, Restaurant

and Lodging. They are not valid for ―card not present‖ industries such as Mail

or Telephone Order, or e-Commerce.

Swiped

Transaction

Support in

Request-

String Mode

A sample Sale transaction (C1) that does not contain any card-swiped data

is shown below. The expiration date field is in bold print:

"C1","CLERK1","COMMENT2","4003010123426780",

"0512","1.00"

Following is a sample card swiped that could be used by an integrated

application to create a request file containing swiped data. This swiped data

contains Track 1 and Track 2 data, which is separated by start and end

sentinels. The start and end sentinels for Track 1 and Track 2 are shown in bold

print.




Page 25 of 119

The Track 1 data in this example uses a ―%‖ (percent) character as the start

sentinel, and the Track 2 data uses a ―;‖ (semicolon) as the start sentinel.

Note that both Track 1 and Track 2 data use a ―?‖ (question mark) as the end

sentinel.

NOTE: It‘s often possible to configure different card readers to use different

ASCII characters as start and end sentinels. ICVERIFY® expects the start and

end sentinels used in the examples provided above.

If a swiped transaction formatted into a request file does not conform to the

format used in these examples, ICVERIFY will not process the transaction

properly.

Formatting a

Request File to

Contain Track 1

and Track 2

Data (Request

String Mode)

Track 1 and 2 data is desired. The entire string shown in the previous section

would be used—with the exception of the start sentinel for the Track 1 data

(the % character). This string would be appended to the expiration date field

of the transaction request in this manner:

"0412B4003010123426780^JANEDOE^041201101002?;4003010123426780=

041201675?"

The expiration date is shown in bold print. The percent symbol, which signifies

the start of the Track 1 data, is removed from the card swiped information

and the resulting string is appended to the expiration date field of the

transaction request. Note that the end sentinel for the Track 1 data, as well

as the start and end sentinels for the Track 2 data, are still present (in bold

print).

Formatting a

Request File to

Contain Only

Track 1 Data

(Request String

Mode)

If only Track 1 data was desired, then the following information would be

appended to the card expiration date in the expiration date field:

"0412B4003010123426780^JANE DOE^041201101002?"

The expiration date, followed by the Track 1 data, minus the start sentinel is

used.

Formatting a

Request File to

Contain Only

Track 2 Data

(Request String

Mode)

If just Track 2 data were desired, the expiration date field would be formatted

in this manner:

"04124003010123426780=0412016752001002?"

The expiration date and the end sentinel for the Track 2 data have been

shown in bold print. Note that the start sentinel for the Track 2 data (a

semicolon) is not present.




Page 26 of 119

Extracting

printed card

number from

track data for

FDMS Gift

cards

The card number printed in a FDMS gift card is created from the first four bytes of the

discretionary data and the nine bytes that immediately follow the six-byte BIN number in

the account field of the track data.

The account field is formatted as follows:

Size Field name Remarks

6 BIN Number

9 Partial Account Number (B)

1 VISA Check Digit Modulo

The discretionary data is formatted as follows:

Size Field name Remarks

4 Partial serial number (A) The leading part

of the serial

number

4 Checksum (C) The complete

checksum

Track II: ;6010567006473139=00010004000070776619?

Bin Number: 601056

Partial Account Number (B): 700647313

VISA Check Digit: 9

Partial serial number (A): 7077

Checksum (C): 6619

Steps:

i. Take part (A) and concatenate part (B). The resulting string is the account serial

number. Part (C) is the checksum. The length of the serial number is 13 bytes and the

length of the checksum is 4 bytes giving a total length of 17 bytes. This differs from the

printed number of 16 bytes.

ii. To construct the printed number from Track II data, take part (A), dropping the second

digit.

iii. Concatenate parts (B) and (C), resulting in the 16 digit printed card number.

Below is an example of the extraction:




Page 27 of 119

Start

Sentinel

Account Number Sep

arat

or

Expiry

Date

Service

Code

PVKI PVV Discretionary

data

End

Sentinel

BIN

#

Partial

ACCT#

CK

Digit

Leading

Digits

Check

sum

; 60

10

56

7 0064

7313

9 = 0001 000 4 0000 7 0 7

7

6619 ?

7777 00647313 6619




Page 28 of 119

Swiped

Transaction

Support in

XML Mode

The implementation of swiped transaction support is somewhat cleaner in XML mode. The

AccountInfo node contains three subelements:

AccountNumber

Track1

Track2

As you have already seen, if you can only supply the account number, you simply populate the

AccountNumber element of the AccountInfo node. However, if you are able to supply the track

data from the card, you can submit it in either the Track1 or Track2 element, or both, depending

on how much data you actually read from the card. Don‘t concatenate the track data to the

expiration date information the way you would for request-string mode, and drop both the start

and end sentinels.

If you supply one of the track elements, you generally do not have to supply ExpirationMonth or

ExpirationYear in the ExpirationInfo node because this data is embedded in the track.

NOTE: Some card providers do not follow the ISO standards for track data layout. In these cases,

you must parse the track data manually and supply the AccountNumber, ExpirationMonth and

ExpirationYear elements even if you are also supplying either Track1 or Track2.

Sale

Transaction

with Track 1

Data Only

The following is an example of a sale transaction containing only Track 1 data.

"C1","CLERK1","COMMENT2","4003010123426780","0512B4003010123426

780^JANE DOE^051201101002?","1.00"

XML Mode <Request>

<CreditCardCharge>

<ClerkID>CLERK1</ClerkID>

<Comment>COMMENT2</Comment>

<AccountInfo>

<Track1>B4003010123426780^JANE DOE^051201101002?</Track1>

</AccountInfo>


</CreditCardCharge>

</Request>

You‘ll notice that since track data was submitted in XML mode, there was no

need to add the ExpirationInfo node.

Sale

Transaction

with Track 2

Data Only

The following is an example of a sale transaction containing only Track 2

data.

"C1","CLERK1","COMMENT2","4003010123426780","05124003010123426

780=0512016 752001002?""1.00"




Page 29 of 119

XML Mode <Request>

<CreditCardCharge>



<AccountInfo>

<Track2>4003010123426780=0512016 752001002?</Track2>

</AccountInfo>


</CreditCardCharge>

</Request>

Again, since track data was submitted in XML mode, there was no need to

add the ExpirationInfo node.

Sale

Transaction

with Both

Track 1 and

Track 2 Data

The following is an example of a sale transaction containing both Track 1 and

Track 2 data. "C1","CLERK1","COMMENT2","4003010123426780","0412B4003010123426

780^JANEDOE^041201101002?;4003010123426780=0412016752001002?","

1.00"

XML Mode <Request>

<CreditCardCharge>



<AccountInfo>

<Track1>B4003010123426780^JANE DOE^051201101002?</Track1>

<Track2>4003010123426780=0512016 752001002?</Track2>

</AccountInfo>


</CreditCardCharge>

</Request>

NOTE: The magnetic card reader is used to get the best transaction rate from

the Processing Network for the retail industry. The credit card is swiped

through the card reader and includes extra information that is sent to the

Processing Network. It‘s recommended that you include BOTH Track 1 and

Track 2 data with a transaction request.

When Track 1 and Track 2 are sent, the ICVERIFY software sends the

information necessary to get you the best rate with your network.




Page 30 of 119

MOTO (Mail

Order /

Telephone

Order)

Transactions

Integrating the MOTO industry is similar to integrating the retail industry. If you

are not yet familiar with how to integrate for the retail industry, see Handling

Retail Transactions. MOTO uses all the transactions that are contained in the

retail industry with the addition of two others.

MOTO is often called the card-not-present industry since most, if not all, of a

MOTO merchant‘s business is done over the phone or through a catalog.

There are special rules and transactions in place for this environment.

Table 2 describes the fields used in a MOTO transaction.

Table 2 MOTO Transaction Fields

Field Description

Leading Field /

Transaction Type

Again, the first field indicates the type of transaction.

Valid values include all the transaction types from

Retail and the following MOTO-specific types:

Book: Request string mode C4, XML mode

CreditCardBook

Ship: Request string mode CO, XML mode

CreditCardShip

NOTE: This field is required.

CVV Indicator Indicates the presence of CVV2/CVC2/CID for

manually entered Visa®, MasterCard®, American

Express® & Discover® credit card transactions.

The indicator has four values:

Present

Not Present

Bypass

Illegible

Depending on the value selected, you will also need

to submit a CVV2, CVC2 or CID value.




Page 31 of 119

Field Description

CVV2 / CVC2 / CID

number

Contains the three-digit CVV2 or CVC2 or four-digit

CID printed in the signature block on the back of

Visa, MasterCard and Diners Club cards, or at the

front of American Express and Discover cards.

NOTE: This field can be used for Book, Sale,

AuthOnly/Pre-Authorization, and Force/Post-

Authorization transactions.

Not all Processing Networks support CVV2, CVC2 or

CID. If your Processing Network does not support this

feature, leave this field blank. If you are not sure if

your Processing Network supports this feature, you

can send the information. Your ICVERIFY® software

will send it to the Processing Network if it‘s required.

For more information about CVV2/CVC2/CID, see

Card Verification Value 2 / Card Verification Code 2

/ Card Identification.

Clerk Contains the clerk information, and can contain up

to 32 alpha numeric characters.

NOTE: This field is optional.

Comments Contains comment information about the

transaction, and can contain up to 32 alphanumeric

characters.

This field is often used for order numbers (a unique

number or alphanumeric sequence that identifies the

transaction).


Credit Card Number Contains the credit card number used in the

transaction, and cannot contain spaces or dashes.

NOTE: In XML mode, you need to submit the

AccountNumber element within the AccountInfo

node.




Page 32 of 119

Field Description

Expiration Date Contains the expiration date on the credit card used

in the transaction. In request-string mode, the date

format is YYMM (year, year, month, month.) In XML

mode, the ExpirationInfo node contains two

elements: ExpirationMonth and ExpirationYear. Use

format MM for ExpirationMonth and YY for

ExpirationYear.

NOTE: The expiration date is required. However,

some payment instruments do not carry an expiration

date, for example certain private label and stored

value cards. Use the following rules to determine

how to populate this field.

If you are using request-string mode:

If the card is a private label card that does

not carry an expiration date, use the default

value 4912

If the card is a FDMS Stored Value card, use

the default value 4912

For all other cards, use the expiration date

actually present on the physical card.

If you are using XML mode:

If you are passing track data in the

AccountInfo node, you do not need to

include the ExpirationInfo node, as the

magnetic tracks contain the expiration

date.

If you are only using the AccountNumber

element of the AccountInfo node (that is,

you are not supplying track data), you must

include the ExpirationInfo node. In this case,

use the default value of 12 and 2049 if the

card does not carry an expiration date.

Amount Contains the amount of the sale. Decimal points are

not required, but recommended. This field is

required.

Billing Postal Code /

ZIP Code

Contains the ZIP code of the customer‘s billing

address. This field can contain the five- or nine-digit

ZIP code without spaces or dashes.

NOTE: This field is required for MOTO transactions,

and helps prove that the owner of the card is the

person placing the order. Since the card is not

present, this information helps prevent fraud.




Page 33 of 119

Field Description

Billing Address Contains the customer‘s billing street address. This

field can contain up to 32 alphanumeric characters

and allows for spaces and dashes.

Book Booking a transaction authorizes and places a hold on the transaction

amount. A Book transaction is the first part of a two-part transaction; it

cannot be settled until it‘s completed by a Ship transaction. This transaction

is used if the merchandise will not be sent to the customer within 24 hours. If

the merchandise is to be sent to the customer within 24 hours, then a sale

transaction can be performed. You put this information in a quote, comma

delimited format that looks like this:

"C4","Clerk","Comment","Charge Card","0512",

"1.00","ZIP","Address","CVV2"

A card can still be approved if the address information is incorrect. It‘s up to

each merchant to accept or decline failed AVS transactions based on the

information. For more information, see Transaction Responses.

Ship This transaction is used to complete a Book transaction. It voids the Book

transaction and creates a new transaction (Ship).

When settlement is performed, this transaction sends the message that the

merchandise was sent. Funds are not transferred from a Book transaction

until a Ship is performed.

Processing

Book and

Ship

Transactions

For ICVERIFY® to send a transaction to the Processing Network, you must

include at least a credit card number, expiration date, and the amount. This

information in request-string mode looks as follows:

Book: "C4","Clerk","Comment”","Card#","ExpDate","Amount","ZIP",

"Address","CVV2"

Ship: "CO","ClK","CMM","4111111111111111","0912","1.00","ZIP",

"Address"




Page 34 of 119

Book Sample –

XML Mode

<Request>

<CreditCardBook>



<AccountInfo>


</AccountInfo>

<ExpirationInfo>



</ExpirationInfo>




<CardVerificationValue>123</CardVerificationValue>

</CreditCardBook>

</Request>

Ship Sample –

XML Mode

<Request>

<CreditCardShip>



<AccountInfo>


</AccountInfo>

<ExpirationInfo>



</ExpirationInfo>




</CreditCardShip>

</Request>

EMV

Transactions

Chip transactions contain chip data (EMV tags) returned from the chip

reader. For the processing host to process a transaction as an EMV chip

transaction, the request needs to contain the EMV Tags separated by a

separator (<GS> as shown in the below examples). The <GS> should be

replaced by hex ‗1D‘ in the request string to ensure proper parsing while

preparing the message request.

NOTE: Presently, chip transactions are supported only in Retail industry. Chip

transactions are never valid in Card Not Present environment.




Page 35 of 119

Chip

Transaction

Structure –

Request-String

Mode

"C1","Clerk","Comment","5413330089010012","1209541333008901001

2=120910100000043900?","1.00","12345","Address","","","","",""

,"","9F0306000000000000<GS>9F2608E6E8EDBE9F3EB5FE<GS>82021800<

GS>9F3602006C<GS>5F340100<GS>9F3403410302<GS>9F020600000000150

0<GS>9F270180<GS>8407A0000000041010<GS>9F10120212A5000F0400000

00000000000000000FF<GS>9F09020002<GS>9F3303E0B0C8<GS>9F1A02099

9<GS>9F1E083131313132323232<GS>9A03980828<GS>9F350122<GS>95058

040008000<GS>5F2A020840<GS>9F410400000499<GS>9C0100<GS>9F37040

C99FDE0<GS>5A085413330089010012<GS>Y","A0000000041010","Master

Card","0"




Page 36 of 119

Chip

Transaction

Structure – XML

Mode

<Request>

<CreditCardCharge>Clerk</ClerkID><Comment>Comment</Comm

ent><AccountInfo><AccountNumber>5413330089010012</AccountN

umber><AccountInfo><AccountNumber></AccountNumber><Track1

></Track1><Track2>5413330089010012=120910100000043900?</Track2

></AccountInfo><ExpirationInfo><ExpirationYear>09</ExpirationYear>

<ExpirationMonth>12</ExpirationMonth></ExpirationInfo><Transaction

Amount>1.00</TransactionAmount><CardVerificationFlag></CardVer

ificationFlag><CardVerificationValue></CardVerificationValue><EMV

TagInfo>9F0306000000000000<GS>9F2608E6E8EDBE9F3EB5FE<GS>8202

1800<GS>9F3602006C<GS>5F340100<GS>9F3403410302<GS>9F020600

0000001500<GS>9F270180<GS>8407A0000000041010<GS>9F10120212

A5000F040000000000000000000000FF<GS>9F09020002<GS>9F3303E0B0

C8<GS>9F1A020999<GS>9F1E083131313132323232<GS>9A03980828<

GS>9F350122<GS>95058040008000<GS>5F2A020840<GS>9F410400000

499<GS>9C0100<GS>9F37040C99FDE0<GS>5A085413330089010012<G

S>Y</EMVTagInfo><ApplicationID>A0000000041010</ApplicationID><

ApplicationDisplayName>MasterCard</ApplicationDisplayName><E

MVFallBack>0</EMVFallBack></CreditCardCharge>

</Request>

NOTE: ICVERIFY expects hex ‗1D‘ as separator between the EMV tags. If a

chip transaction formatted into a request file does not conform to the said

format, ICVERIFY will not process the transaction properly.

Visa Paywave Transactions

Visa Paywave transactions are transactions done with Visa

contactless cards that follow the Visa Contactless Payment

Specification version 2.x (VCPS 2.x). Visa Paywave transactions require

additional chip data fields retrieved from the contactless cards during

authorization. For the processing host to process a contactless

transaction as a Visa Paywave transaction, in addition to the regular

fields, the request needs to contain the Visa Paywave tags separated

by a separator (<GS> as shown in the below examples) The <GS>

should be replaced by hex ‗1D‘ in the request string to ensure proper

parsing while preparing the message request.

NOTE: Presently, Visa Paywave transactions are only supported for

Retail industry on the FDMS South, FDMS Cardnet, FDMS Nashville and

FDMS Buypass processors. They are not valid in Card Not Present

environment.




Page 37 of 119

Visa Paywave transaction structure – Request-String Mode

"C1","sysadmin","","4005572000000260","1210B4005572000000260^CARD

M/VISA^1210621555550123400000000005560000100333080000?;4005572000000260

=12106215555533300081","35.00","12345","Address","","","","","","Y","","","","","","9F260859

0057F092E57607<GS>9F3602000D<GS>9F7C1B0006495353554552000B50524F50524

94554415259000444415441<GS>9F0206000000000001<GS>9F6E0420700000<GS>9F

100706011103A00000<GS>9F370445692675"

Visa Paywave transaction structure – XML Mode

<Request><CreditCardCharge><ClerkID>swarnendu</ClerkID><Comment></Co

mment><AccountInfo><AccountNumber>4005572000000260</AccountNumber>

<Track1>B4005572000000260^CARD

M/VISA^1210621555550123400000000005560000100333080000?</Track1><Track2>

4005572000000260=12106215555533300081?</Track2></AccountInfo><ExpirationI

nfo><ExpirationYear>10</ExpirationYear><ExpirationMonth>12</ExpirationMonth>

</ExpirationInfo><TransactionAmount>45.00</TransactionAmount><BillingPostalC

ode></BillingPostalCode><BillingAddress></BillingAddress><CardVerificationFlag

></CardVerificationFlag><CardVerificationValue></CardVerificationValue><BillP

aymentIndicator>0</BillPaymentIndicator><ContactLessFlag>Y</ContactLessFla

g><VisaPayWave>9F2608590057F092E57607<GS>9F3602000D<GS>9F7C1B0006495

353554552000B50524F5052494554415259000444415441<GS>9F0206000000000001<

GS>9F6E0420700000<GS>9F100706011103A00000<GS>9F370445692675</VisaPayW

ave></CreditCardCharge></Request>

NOTE: ICVERIFY expects hex ‗ID‘ as separator between the different Visa

Paywave tags. If a Visa Paywave transaction formatted into a request file does

not confirm to the said format, ICVERIFY will not process the transaction properly.




Page 38 of 119

Hotel

Transactions

The Hotel format contains all of the basic retail transaction types discussed in

Handling Retail Transactions, and the Hotel-specific transactions discussed

below. ICVERIFY is certified with many processors for the Hotel market format.

You will note that a new XML node appears called LodgingInfo. Generally,

fields specific to Lodging transactions will appear as elements under this

subnode.

NOTE: These are samples only. Other fields may be required by your specific

processing network. For a complete list of field descriptions, see Standard

Transaction Record Formats and review the information in the Transaction

Builder tool provided with your SDK package.

Check-In This is the initial step in a Hotel billing procedure. This transaction confirms the

validity of a customer‘s credit card and pre-authorizes the amount to be

billed.

Check-In

Transaction

Structure –

Request-String

Mode

"C4","CMc","CMI","ACT","EXP","AMT","CmR","cmR","CMN","CMA",

"CMD","Cmr","CmP","CME","Cme"




Page 39 of 119

Check-In

Transaction

Structure – XML

Mode

<Request>

<CreditCardBook>

<ClerkID></ClerkID>

<AccountInfo>


</AccountInfo>

<ExpirationInfo>



</ExpirationInfo>



<CardVerificationValue></CardVerificationValue>

<CardVerificationFlag></CardVerificationFlag>

<SalesTaxAmount></SalesTaxAmount>

<LodgingInfo>

<InvoiceNumber></InvoiceNumber>

<RoomNumber></RoomNumber>

<ArrivalDate></ArrivalDate>

<DepartureDate></DepartureDate>

<RoomRate></RoomRate>

<PreferredCardholderFlag></PreferredCardholderFlag>

<ExtraChargeAmount></ExtraChargeAmount>

<ChargeCodes></ChargeCodes>

<ArrivalTime></ArrivalTime>

<DepartureTime></DepartureTime>

<CustomerCode></CustomerCode>

</LodgingInfo>

<ReferenceNumber></ReferenceNumber>

<CustomerName></CustomerName>

</CreditCardBook>

</Request>




Page 40 of 119

Add Charges This is an incremental transaction type that allows a merchant to decrease a

customer‘s open to buy for services such as meals, telephone calls, or gift

shop purchases before checkout.

Add Charges

Transaction

Structure –

Request-String

Mode

"CG","CMc","CMI","ACT","EXP","AMT","CmR","cmR","CMN","CMA",


Add Charges

Transaction

Structure – XML

Mode

<Request>

<CreditCardAddCharges>

<ClerkID></ClerkID>

<AccountInfo>


</AccountInfo>

<ExpirationInfo>



</ExpirationInfo>





<LodgingInfo>












</LodgingInfo>



</CreditCardAddCharges>

</Request>




Page 41 of 119

Extend Stay This transaction type extends the customer‘s checkout date.

Extend Stay

Transaction

Structure –

Request-String

Mode

"CI","CMc","CMI","ACT","EXP","Amt","CmR","cmR","CMN","cMA",

"cMa","Cmr","CmP","CME","Cme"

Extend Stay

Transaction

Structure – XML

Mode

<Request>

<CreditCardExtendStay>

<ClerkID></ClerkID>

<AccountInfo>


</AccountInfo>

<ExpirationInfo>



</ExpirationInfo>



<LodgingInfo>




<OriginalDepartureDate></OriginalDepartureDate>








</LodgingInfo>



</CreditCardExtendStay>

</Request>




Page 42 of 119

Check-Out This transaction is used when the customer is checking out of a hotel.

Charges to a customer‘s card are not settled until a checkout is performed.

Check-Out

Transaction

Structure –

Request-String

Mode

"CO","CMc","CMI","ACT","EXP","AMT","CmR","cmR","CMN","CMA",


Check-Out

Transaction

Structure – XML

Mode

<Request>

<CreditCardCheckout>

<ClerkID></ClerkID>

<AccountInfo>


</AccountInfo>

<ExpirationInfo>



</ExpirationInfo>



<LodgingInfo>












</LodgingInfo>



</CreditCardCheckout>

</Request>




Page 43 of 119

No Show This transaction is used when a customer doesn‘t arrive when expected.

No Show

Transaction

Structure –

Request-String

Mode

"CN","CMc","CMI","ACT","EXP","AMT","CmR","cmR","CMN","CMA",


No Show

Transaction

Structure – XML

Mode

<Request>

<CreditCardNoShow>

<ClerkID></ClerkID>

<AccountInfo>


</AccountInfo>

<ExpirationInfo>



</ExpirationInfo>


<LodgingInfo>












</LodgingInfo>


<CustomerName> </CustomerName>

</CreditCardNoShow>

</Request>




Page 44 of 119

Level III

Purchasing

Cards

Level III purchasing cards are business-to-business (B2B) credit cards. They

require much more detail than regular credit cards. This section explains

what is required. A brief example of the transaction record format for a Level

III purchasing transaction is shown below. Refer to the ICVERIFY Purchasing

Card Supplement for a detailed discussion of purchasing card processing.

NOTE: The first three lines are actually one line containing the transaction

record for the actual transaction. The following lines are records for line item

details for the transaction (the line item details in the example are shown in

bold to make them more visible).

Purchasing

Card Sample –

Request-String

Mode

"C1","clerk","12433254365436","4275330000005810","0909",

"40.00","12345","LIIIWithLID","2354325","0.00","0.00","0.00",

"0.00","07-30-2003","31432","4254325","45435","3"

"P0","0004","Pens","Green","555EEE000","1.0000","Gross",

"35.9900","00.00","0.00","0.00"

"P0","0003","Pens","Red","444DDD000","1.0000",”Gross",

"39.9500","00.00","0.00","0.00"

"P0","0003","Pens","Red","444DDD000","1.0000","Gross",

"39.9500","00.00","0.00","0.00"

Each of the line items for this transaction begins with a P0 field. This indicates

a Visa® purchasing card line item. This transaction is in the format that is

required for First Data‘s CARDnet (North) platform. The formats for line items

vary by the type of card and are described fully in the Purchasing Card

Supplement.

Currently, only a limited number of Processing Networks support Level III

purchasing, which allows the inclusion of line item details for purchase card

transactions (line items are descriptions of each item that constitute a

purchase).

The following section briefly describes how to create transaction records for

First Data Commercial Services. Processing Networks and card companies

use different formats and have different data requirements, so transaction

record formats required for each network are will vary. Be sure to use the

Transaction Builder utility found with the ICVERIFY Software Developer‘s Kit on

your installation CD-ROM to determine your exact processing requirements.




Page 45 of 119

Level III

Record

Formats –

Request-

String Mode

Commas separate the records listed in this document. These should be

converted to quote-comma delimited fields, and populated with data as

indicated by the field definition.

NOTE: Usually, a transaction record consists of a single line that is terminated

by a carriage return, but Level III purchasing transactions occupy more than

one line because of associated line items.

Many records end with a CMz field. This field is mandatory, contains two

numeric characters, and is right justified. It‘s used to indicate the number of

line items that are associated with the transaction.

For example, if the CMz field is 1, it means that one line item is associated with

the transaction.

The value of 0 indicates that no line items are associated with the transaction.

A value of 99 would indicate that 99 line items are associated with the

transaction (this is the maximum possible value). If this field is populated with

a single digit, the position to the left of the field should be null.

For example, 1 and 01 are both correct.

If the transaction record does not provide a CMz field, no line items may be

associated with the record.

For example, line items are not required for a void transaction because the

transaction record for this transaction type does not include a CMz field.

When including line items, be aware that each the line item detail formats for

each general type of purchase card (Visa®, MasterCard®, and American

Express®) are different. The application writing the transaction must use the

correct record type when appending line items to the transaction record

when creating the file.

Some records contain a cMo field type. The way this field is formatted

depends on the type of purchasing card the transaction record represents.

If the transaction record is for a Visa® purchasing card, the field is populated

with the order date in the following format: 07-22-2003. If the transaction

record is for a MasterCard® purchasing card, this field should be left blank.

Level III

Record

Formats – XML

Mode

Creating a Level III transaction using XML mode is relatively straightforward.

The purchase order fields are generally confined to a new subnode in the

transaction request called PurchaseInfo. You only need to add the

PurchaseInfo node and its associated elements to your transaction request to

submit your order and line item data. The following sample transaction shows

a Sale transaction with both summary and line item details.

NOTE: You do not have to end each element with a newline character.

Each element is represented on a separate line here to improve legibility.




Page 46 of 119

Level III

Transaction

Sample – XML

Mode

<Request>

<CreditCardCharge>

<AccountInfo>


</AccountInfo>

<ExpirationInfo>



</ExpirationInfo>

<SalesTaxAmount>1.00</SalesTaxAmount>


<ClerkID>ICV1</ClerkID>


<BillingAddress>4 Corporate Square</BillingAddress>

<PurchaseInfo>

<PurchaseItemCount>2</PurchaseItemCount>

<PurchaseItems>

<LineItem>

<ItemCode>1111</ItemCode>

<ItemDescription>Description123</ItemDescription>

<ItemQuantity>5</ItemQuantity>

<ItemUnitOfMeasure>Kg</ItemUnitOfMeasure>

<ItemUnitCost>3.00</ItemUnitCost>

<ItemDiscountAmount>1.00</ItemDiscountAmount>

<ItemAmount>3.00</ItemAmount>

<ItemDCFlag>C</ItemDCFlag>

</LineItem>

<LineItem>

<ItemCode>2222</ItemCode>

<ItemDescription>Description123</ItemDescription>

<ItemQuantity>5</ItemQuantity>

<ItemUnitOfMeasure>Kg</ItemUnitOfMeasure>

<ItemUnitCost>3.00</ItemUnitCost>

<ItemDiscountAmount>1.00</ItemDiscountAmount>

<ItemAmount>3.00</ItemAmount>

<ItemDCFlag>C</ItemDCFlag>

</LineItem>

</PurchaseItems>

</PurchaseInfo>

</CreditCardCharge>

</Request>




Page 47 of 119

Debit Card

Transactions

Hardware issues must be considered when adding debit card processing to

an application. In order for a processor to accept a debit transaction,

swiped card data is required as well as an encrypted PIN (Personal

Identification Number) datagram.

Since manually entered card numbers are not accepted by debit processors,

a card reader and a PIN Pad are required. You must provide support for

these devices in your application if you are not using the ICVERIFY® product

for user input.

! ! ! If you are programming your own PIN-based debit transaction interface,

it is your responsibility to interact with the PIN pad. You cannot use the

ICVERIFY software application to drive the PIN pad device; you must drive it

yourself and submit the transaction data to ICVERIFY after you have retrieved

it from the device.

Processing

Debit Card

Transactions

Processing a debit card transaction requires a card reader and an encrypted

PIN-pad. A bank must program ATM PIN-pads before they can be used by

ICVERIFY. Your PIN-pad must be a serial input PIN-pad, and must be VeriFone

1000- or 2000-compatible.

PIN-pads are designed to support either Master Session or DUKPT (Derived

Unique Key Per Transaction) encryption of PIN data. In either case, the PIN

entered by the cardholder is encrypted and not known to the merchant or

the processing network; it is only decrypted by the card issuing bank.

DUKPT PIN-pads have already been properly encrypted by your processor or

merchant bank with the appropriate configuration and encryption key

injection.

Debit

Transaction

Types

Like credit cards, authorized debit card transactions must be settled before

the funds are transferred to your account. The following transaction types are

generally available:

Sale – Transfers funds from an ATM/debit account to your account

(used for all ATM/debit purchases.)

Void – Removes an unsettled sale transaction from the open batch

(used to remove a debit transaction prior to settlement.)

Credit/Return/Refund – Transfers funds from your account to an

ATM/debit account (used to reverse a sale transaction that has

settled.)

Reversal – Reverses an unsettled Sale transaction from an open

batch. This transaction is only supported for the FDMS Buypass and

FDMS Cardnet processors. It is used to reverse a previous Sale

transaction which has received full/partial approval.




Page 48 of 119

Debit

Transaction

Request

Format

The format of a standard debit request within the ICVERIFY® application is as

follows.

Debit

Transaction

Structure –

Request-String

Mode

"D1","CMc","CMN","AMT","amn","AMt","ACT","BLK",

"TDT","PIN"

The field definitions are as follows:

D1 indicates a debit sale transaction,

CMc is the clerk,

CMN is the customer name,

AMT is the amount of purchase,

amn is the additional (cash back) amount,

AMt is the total amount including the cash back amount,

ACT is the account number,

BLK is a empty field, required to process debit transactions properly,

TDT is the track data,

PIN is the cryptogram returned by the user entering his or her PIN on

the input device.

Debit

Transaction

Structure – XML

Mode

<Request>

<DebitCardCharge>

<ClerkID></ClerkID>


<CashBackAmount></CashBackAmount>


<AccountInfo>


<Track1></Track1>

<Track2></Track2>

</AccountInfo>

<PINData></PINData>

</DebitCardCharge>

</Request>




Page 49 of 119

Debit

Transaction

Support by

Processor

Currently ICVERIFY supports PIN-based debit transactions on the following

processor networks:

FDMS® Cardnet® – CES

FDMS Omaha (FDR)

First Data Atlanta (Concord BUYPASS)

TSYS Acquiring Solutions

Global Payment Systems – East

Global Payment Systems – Central

ELAVON Information Systems

WorldPay Systems

Chase Paymentech

Heartland Payment Systems

Processing

Transactions

for Multiple

Merchants

To process a transaction for a specific merchant, you need to use the

merchant code. The merchant code is the four characters that you used in

the naming of the SET file. See the discussion on multiple merchant setups in

the ICVERIFY Setup Guide.

For example, if the set file name is ICVE0001.SET, the merchant code is 0001.

The following is an example of how request-string transactions should look:

"C1","~0001~","comment","5419840000000003","0912", "15.00"

"C1","~0002~","comment","4005550000000027","0912", "10.00"

"C2","~0001~","comment","5419840000000003","0912", "15.00"

In this example, the first request is a $15.00 sale for merchant #1; the second

line is a $10.00 sale for merchant #2; the third line voids the first sale for

merchant #1. ICVERIFY® sees the ―~0002~‖ and switches to the merchant

number stored in ICVE0002.SET.

As shown by the example below, a merchant ID need not be numeric.

"C1","~MER3~","comment","4005550000000027","0412","10.00"

This would use the setup file ICVEMER3.SET.

To do transactions for multiple merchants in XML mode, simply overload the

ClerkID node with the merchant number in the following way:

<ClerkID>0001</ClerkID>

<ClerkID>0002</ClerkID>

Requests and Responses



Page 50 of 119

Chapter 5 – Requests and Responses

Overview This chapter discusses the interaction between your application logic and the

ICVERIFY product from the context of the request you make and the response

that you receive. For ease of discussion, the file-based method will be used

extensively in the chapter.

A request file is a file containing one or more transactions that need to be

processed. This file is generated by your application. After ICVERIFY®

processes a request file, a response is given for that request.

NOTE: Remember that you can also use the Direct DLL programming

interface to interact with the ICVERIFY application. You also have the ability

to use the built-in encryption library within the product to increase the security

of your transaction processing. ICVERIFY, Inc. strongly recommends you

consider both these options.

Request Files Follow the steps below to create a simple request file in the request-string

model.

Step Action

1. Create a new directory in your ICVERIFY directory, and name it

―REQDIR‖.

2. Run the ICVERIFY Multi-User Request file Processor.

NOTE: You need to have entered your merchant information in

the setup or be using one of the ICVERIFY demo setups for this

example. If you have not yet configured a merchant, even a

dummy merchant for testing, consult the ICVERIFY Setup Guide for

information on how to do so.

3. Click Browse next to the request directory field. Search for and

select the new directory called reqdir.

4. Click Initialize, and minimize the Multi-User Request file Processor.




Page 51 of 119

Step Action

5. Open a text editor, and type the following line:

"C1","Clerkfield","Commentfield","5000300020003003",

"0912","1.00"

This line is a basic sale transaction. There are six fields in this

transaction. A set of quotes and a comma separate each field

within this transaction. The first field is for the transaction type. The

transaction type is a two-character code that tells ICVERIFY® what

kind of transaction this is. This field is case sensitive. In the above

example, the transaction type is C1. C1 is the ICVERIFY code for

Sale. For a list of field types, see Standard Transaction Record

Formats.

The next two fields are the clerk and comment fields. These two

fields can contain alpha and numeric characters only. You don‘t

have to enter information in the clerk and comment fields, but you

must include the empty fields if you decide not to fill them in. Some

merchants use the clerk and comment fields for order numbers or

customer names.

NOTE: The Clerk field in the SDK is used by the ICVERIFY software to

trigger certain rules for certain transaction types. Generally, the

format that you should follow is:

"ClerkName<CMN>CustomerName"

For example, if the Clerk name is Bob and the customer name is

John, the field should read: "Bob<CMN>John".

If you don‘t want to provide either the clerk or the customer name

fields, the field should read: "<CMN>". This is because if you omit

the <CMN> in the field, the transaction will be interpreted as an

Installment transaction and will be billed accordingly.

Therefore, be sure you include valid data in the ―Clerk‖ field, even if

all you add is ―<CMN>‖, unless you are performing an Installment

transaction. Installment transactions require the <CMN> value to

appear in the Comment field rather than the Clerk field as follows:

"CommentField<CMN>CustomerName"




Page 52 of 119

Step Action

6. The fourth field is for the credit card number. This field cannot

contain any dashes or spaces. The fifth field is for the expiration

date. The expiration date must be in the year, year, month, month

format. For example, 0611 would be November of the year 2006.

The sixth field is for the amount. A decimal is not needed in this

field, but it‘s recommended that it be entered. This transaction

contains everything you need to get an authorization from your

processing network.

7. Save the text file to your desktop as icver001.REQ.

8. Encrypt the request file

9. Open the request directory and copy the icver001.REQ file to your

request directory. If the file icver001.ans exists, it will be deleted.

Almost immediately, ICVERIFY® automatically renames

icver001.REQ to icver001.HLD. ICVERIFY reads the transaction

information from the HLD file and sends it to the processing network

for approval.

9. ICVERIFY® then creates the file icver001.ZZZ. ICVERIFY writes the

response from the Processing Network to the icver001.ZZZ file.

When all transactions are sent to the processor, ICVERIFY deletes

the icver001.HLD file, and renames the icver001.ZZZ file to

icver001.ANS. The process of creating and deleting the HLD and

ZZZ files happens so quickly that you might not see it occur.

Icver001.ANS is the file that the client application will read. The

client application should decrypt the answer file before using the

actual response internally. It contains the response or responses

from the Processing Network. This file will remain until the next

icver001.REQ file is found by the Multi-User Request file Processor, or

until it‘s deleted by an outside source. It‘s highly recommended

that the file be read and removed by the client application.

The name for the request file is unique for each register or user. If

you have two cash registers, register one will use ICVER001.REQ and

register two will use ICVER002.REQ. The number after the ICVER

represents the register number. You can use up to the number you

are licensed for. You may not use the same request file name for

multiple registers.




Page 53 of 119

Transaction

Responses

! ! ! The information that you receive back from ICVERIFY® is very important, so make

sure you read this section carefully. You can set up the type of response that you

want from ICVERIFY. For more information, see Options Tab.

Transaction

Responses in

Request-String

Mode

This section assumes that ICVERIFY is set up to return evaluated responses. It‘s

recommended that you use the evaluated response option because it‘s easy to

understand and you don‘t have to write extra code to obtain more information.

The evaluated response gives back a letter code followed by a six-digit approval

code. Depending on the Processing Network, there may be an eight-digit reference

number following the approval code. If address information was included in the

transaction, a response is also included.

As an example, imagine the following transaction was sent for authorization:

"C1","Billy","5000300020003003","0612","25.00","65421","2 Happy

Lucky St."

The transaction is sent to a terminal based Processing Network and is approved. The

response would look like the following:

"Y123456Y"

The first letter is the answer for the transaction (Y=Approved). However, Y is not the

only response code you can get for approved transactions.

Card Subtypes You can also receive the response codes below, depending on the Processing

Network.

Y - Approved

N - Declined

P - Approved not captured

Q - Approved for VISA/MC Purchase Card

B - Approved for VISA/MC Business Card

C - Approved for VISA/MC Corporate Card

The last three responses, Q, B and C, indicate that the card used to perform the

transaction was issued under a purchasing, business or corporate card program.

These cards operate under different interchange programs. To qualify for the most

favorable rates, you should submit order and tax information for the transaction

before it is settled by the processing network.




Page 54 of 119

Partial

Authorization

The next six digits represent the approval code. The last letter is the response for

address verification (for a list of address verification result codes, see Address

Verification Result Codes).

If your Processing Network is host-based, the response would look like this:

"Y12345687654321Y"

You have eight extra digits following the approval code. These eight digits represent

the reference number that was returned by your Processing Network.

ICVERIFY 4.1 and above supports partial authorization on Credit and Debit card

products for Visa, MasterCard, American Express and Discover. For a partially

approved transaction, the host returns approval on a part of the total transaction

amount and the card holder has to pay the balance amount by other means.

The response received for a partially approved transaction would look like the

following:

―Y123456Y<APP>35.00‖

The amount value specified after the <APP> tag is the approved amount which is in

this case $35.00. The original amount submitted in the request for this transaction

was something greater than $35.00.

If the host returns full approval on the original amount submitted in the request, the

<APP> tag is not present in the response.

NOTE: Presently partial authorization is supported only for FDMS Buypass (Credit and

Debit cards), FDMS South (Credit Only), FDMS Cardnet (Credit and Debit cards),

FDMS Nashville (Credit only) and the TSYS Acquiring Solutions (Credit only) platforms.

Balance Reception with Authorization and Balance Inquiry transaction

ICVERIFY 4.1 and above supports balance reception on Credit card products for

Visa, MasterCard, American Express and Discover. In case of Balance Reception,

the host processor may return the available balance on the card along with the

regular authorization response. For a standalone balance inquiry transaction, the

host returns the prepaid card balance.

The response received for a transaction with card balance (if returned by host)

would look like the following:

―Y123456Y<BAL>10.00‖

The amount after <BAL> tag is the card balance returned from host processor. The

response for a standalone balance inquiry transaction is also similar to the format

mentioned above.




Page 55 of 119

Note: Presently balance reception with authorization is supported only for FDMS

Buypass, FDMS South and FDMS Nashville processors on Credit cards. Standalone

balance inquiry is supported on the FDMS South, FDMS Cardnet and FDMS Nashville

processors only.

FDMS South Processor

FDMS

South

Industry Transaction Type Card Type

VIS

A

MC Amex Discover

Retail Partial Authorization Y Y Y Y

Full Reversal Y Y Y Y

Balance Inquiry[1] Y Y Y N

Balance Receptive with

an Authorization Request

Y Y N N

Concurrent Partial

Authorization and

Balance Reception

Y Y N N

Moto Partial Authorization Y Y Y Y


Balance Inquiry Y N Y N

Balance Receptive with

an Authorization Request

Y N N N

Concurrent Partial

Authorization and

Balance Reception

Y N N N

For South processor, MasterCard will support Balance Inquiry only for Retail industry.




Page 56 of 119

FDMS Atlanta

FDMS

Atlanta


VISA MC Amex Discover

Retail

Partial Authorization[1] Y Y Y Y

Full Reversal (online

void)[2]

Y Y Y Y

Balance Inquiry[3] N N N N

Balance Receptive

with an Authorization

Request

Y Y Y Y

Concurrent Partial

Authorization and

Balance Reception

Y Y Y Y

Restaurant Partial Authorization Y Y Y Y


Balance Inquiry N N N N

Balance Receptive

with an Authorization

Request

Y Y Y Y

Concurrent Partial

Authorization and

Balance Reception

Y Y Y Y

1) In case of Atlanta a full reversal is an online void.

2) Balance inquiry is not supported for credit cards in FDMS Atlanta.




Page 57 of 119

FDMS Nashville

FDMS

Nashville



Retail Partial Authorization Y Y Y Y

Full Reversal[1] Y Y Y Y

Balance Inquiry Y Y Y Y

Balance Receptive with an

Authorization Request[2]

Y Y Y Y

Concurrent Partial Authorization

and Balance Reception[3]

N N N N



Balance Inquiry Y Y Y Y


Authorization Request

Y Y Y Y


and Balance Reception

N N N N

FDMS Cardnet

FDMS

Cardnet



Retail Partial Authorization[4] Y Y Y Y


Balance Inquiry[1][2] Y Y Y N


Authorization Request[2][3]

Y Y Y Y



Y Y Y Y



Balance Inquiry Y N Y N



Y Y Y Y



Y Y Y Y

Restaurant Partial Authorization Y Y Y Y


Balance Inquiry Y Y Y N



Y Y Y Y



Y Y Y Y




Page 58 of 119

1. FDMS Cardnet does not support above mentioned features for Hotel industry.

TSYS

TSYS



Retail

Partial Authorization Y Y Y Y

Full Reversal Y Y N N

Balance Inquiry Y Y N N



Y Y Y Y



Y Y Y Y

Restaurant

Partial Authorization Y Y Y Y





Y Y Y Y



Y Y Y Y

Lodging Partial Authorization Y Y Y Y





Y Y Y Y



Y Y Y Y

MOTO Partial Authorization Y Y Y Y





Y Y Y Y



Y Y Y Y




Page 59 of 119

Decline Response Following is an example of how the response for a declined transaction would be

formatted:

"NPICK UP CARD"

The N at the beginning of the field indicates that the transaction was declined. The

text of the response from the processor follows. Declined transactions always start

with a N.

GE Promotional

Data Elements

For Private Label

Transactions

In the GE platform, the following Promotional Data Elements will be returned

in the transaction response for private label transactions

1. During Promo APR

2. Promo APR (v) Flag

3. After Promo APR

4. After Promo (v) Flag

5. Promo Type

6. Promo Duration

The above promotional data elements received from host will be present at

the end of transaction response in the following format:

<PROMOTYPE>Promo Type<PROMODUR>Promo Duration<DURPROMOAPR>

During Promo APR <PROMOAPRFLAG> Promo APR Flag <AFTERPROMOAPR>

After Promo APR<AFTERPROMOFLAG> After Promo Flag

The values of the promotional data elements are present in the transaction

response as they are received from host. These promotional data values are

not formatted or space-trimmed in any way by ICVERIFY. Please use your

own formatting on these values if you need to.

The values of During Promo APR and After Promo APR are returned in the

transaction response as 6 digits as present in host response. To obtain the

Percentage APR value you should insert a decimal point after the first two

digits and truncate any trailing zeros (if present).

Example: If the APR value returned in the transaction response is 299900, the

percentage APR value should be 29.99%.

Following is an example for the response received for a private label

transaction for GE with promotional data elements:




Page 60 of 119

"Y019275000010<PROMOTYPE>WITH PAYMENT DEFERRED INTEREST

<PROMODUR>12 MONTHS

<DURPROMOAPR>299900<PROMOAPRFLAG>00<AFTERPROMOAPR>299900<

AFTERPROMOFLAG>00"

Transaction

Responses in

XML Mode

Response messages in XML mode always follow the same logical structure.

Let‘s assume that you performed the same Sale transaction that appeared

on the previous page in request-string format. The XML request would look

like this:

<Request>

<CreditCardCharge>

<ClerkID>Billy</ClerkID>


<AccountInfo>


</AccountInfo>

<ExpirationInfo>



</ExpirationInfo>



<BillingAddress>2 Happy Lucky St.</BillingAddress>

</CreditCardCharge>

</Request>

When you submit this request to the ICVERIFY application and receive a

response, you will receive a response similar to the following example.

NOTE: The fields in the response have been placed on separate lines to

improve legibility. The actual response string will not have newline characters

between the XML elements. Also, not all the fields in the response example

may be present. Field presence depends on whether the transaction was

successfully processed and what the response actually was.




Page 61 of 119

XML Response

Sample

<Reply>

<TransactionReply>

<ResponseCode>0</ResponseCode>

<ResultCode>00</ResultCode>

<ResultMessage></ResultMessage>

<BatchSequenceNumber>1</BatchSequenceNumber>

<AVSResponseCode>X</AVSResponseCode>

<CVVResponseCode>U</CVVResponseCode>

<ApprovalNumber>OK1234</ApprovalNumber>

<TransactionDate>09152005</TransactionDate>

<TransactionTime>140415</TransactionTime>

<CardSubType>Q</CardSubType>

<AccountNumber>xxxxxxxxxxxx3003</AccountNumber>


<RawResponse>OTU1MDBBQU9LMDAwNg==</RawResponse>

</TransactionReply>

</Reply>

XML Response containing Partial Authorization and Balance Reception

Responses.

The XML response for a partially approved transaction would contain the

partially authorized amount within the <ApprovedAmount/> XML element.

The transaction response containing the prepaid card balance (if returned

by host) is contained within the <BalanceAmount/> XML element. XML

response for a standalone Balance Inquiry transaction also contains the

returned card balance with the <BalanceAmount/> XML element

NOTE: Presently partial authorization is supported only for FDMS Buypass

(prepaid Credit and Debit cards), FDMS South (prepaid Credit cards), FDMS

Cardnet (prepaid Credit and Debit cards), FDMS Nashville (prepaid Credit

cards) and TSYS Acquiring Solutions (prepaid Credit cards) processors.

Balance reception with authorization is supported only for FDMS Buypass,

FDMS South and FDMS Nashville processors on prepaid Credit cards.

Standalone balance inquiry transactions are supported in FDMS South, FDMS

Cardnet and FDMS Nashville processors only.

The sample XML response containing partial approval and card balance

fields is shown below.




Page 62 of 119

<Reply>

<TransactionReply>





<AVSResponseCode>X</AVSResponseCode>

<CVVResponseCode>U</CVVResponseCode>

<ApprovalNumber>OK1234</ApprovalNumber>



<CardSubType>Q</CardSubType>



<ApprovedAmount>7.00</ApprovedAmount>

<BalanceAmount></BalanceAmount>

<RawResponse>OTU1MDBBQU9LMDAwNg==</RawResponse>

</TransactionReply>

</Reply>

XML

Response

Fields

While some of the XML response fields are obvious, others may be a little

more difficult to understand. The following table provides a brief description

of fields and their meanings.

Table 3 XML Response Fields

Field Description

ResponseCode This is the ―master‖ response code and indicates the

type of response at a high level. You should check

the value in this field before any others. A value of 0

(zero) means the transaction was approved or

successfully processed. Other responses indicate

various other states. Refer to Appendix A for a list of

codes and their definitions.

ResultCode This code is returned directly from the Processing

Network and is generated by the processing platform.




Page 63 of 119

Field Description

It is proprietary to each network. You may be required

to display this value on a screen or print it on receipts.

The ICVERIFY application maps the various ResultCode

values from all the processors to a common set of

ResponseCode values.

ResultMessage If the processing network has supplied a text message,

it will appear in this XML field. You may need to

display this value on a screen or print it on receipts.

Examples of this field include PLEASE REENTER or PICK

UP CARD.

BatchSequence

Number

This is a numeric value showing the current batch

number in the ICVERIFY application.

AVSResponseCode The address verification response code returned from

the Processing Network. For a list of AVS response

codes, see the reference document AVS & CVV

Response Codes.

CVVResponseCode The card verification response code returned from the

Processing Network, if your transaction request

included CVV2, CVC2 or CID information. For a list of

CVV response codes, see the reference document

AVS & CVV Response Codes.

ApprovalNumber A six-position alphanumeric field showing the approval

code for an authorization-type transaction (such as a

Sale, Book or Auth-Only.)

TransactionDate

TransactionTime

The date and time the transaction response was

created. The format of TransactionDate is MMDDYYYY

while the format of TransactionTime is HHMMSS (24-

hour notation.)

CardSubType This field indicates whether the card used in the

transaction is a consumer, corporate, purchasing or

commercial card. See the earlier section discussing

card subtypes for potential values.

AccountNumber The account number used for this transaction, with the

leading positions masked by x characters.

TransactionAmount The transaction amount submitted for the transaction.

RawResponse The actual response message returned from the

Processing Network, encoded in Base64 format to

guard against special characters. If your application




Page 64 of 119

Field Description

logic requires you to parse the actual processor

message, you can Base64-decode this field and

perform whatever operations you require.

PROMOTYPE Promo Type.

This field is present only for GE private label transaction

responses

PROMODUR Promo Duration.


responses

DURPROMOAPR During Promo APR.


responses.

The APR value returned is of six digits. To obtain the

Percentage APR value, you should insert a decimal

point after the first two digits and truncate any trailing

zeros (if present).

Example: If the APR value returned in the transaction

response is 299900, the percentage APR value should

be 29.99%

PROMOAPRFLAG Promo APR Flag.


responses.

AFTERPROMOAPR After Promo APR.


responses.

The APR value returned is of six digits. To obtain the

Percentage APR value you should insert a decimal

point after the first two digits and truncate any trailing

zeros (if present).

Example: If the APR value returned in the transaction

response is 299900, the percentage APR value should

be 29.99%

AFTERPROMOFLAG After Promo Flag.


responses.

ApprovedAmount The amount approved for a partially approved

transaction.

BalanceAmount The balance amount on the card if returned by host.

Token The token id corresponding to the original account




Page 65 of 119

Field Description

number returned by the host.




Page 66 of 119

Processing

Offline

Group Input

or Request

Files –

Interpreting

Results

In file-based integration mode, ICVERIFY® writes the results of the offline group

or request session to the offline group output or .ans file. ICVERIFY can return

the results from the transmitted offline group in two different ways. The

following is an example of a response from an approved MasterCard

purchasing card transaction taken directly from the offline group output file.

NOTE: The first three lines should be regarded as one continuous line. The

response from the Processing Network is repeated for each transaction or line

item associated with the transaction. The field containing the Processing

Network‘s actual response is shown in bold print.

"C4","clerk","22222","5405010100000016","0912","10.00","11111"

,”NorthStreet","44444","0.00","0.00","0.00","0.00","","55555",

"33333","66666","1","","","","""07-22-

2003","13:48:44","Y813484","A1000","","000001"

"P0","","Feathers","111AAA000","1.0000","Ton","100.0000","","0

.00","","","","","","","","","","","","","""07-22-

2003","13:48:44","Y813484","","","000001"

The Y at the beginning of the response field indicates that the transaction

was approved. This is followed by the approval code for the transaction (the

approval code is usually six digits, but the standard length of the approval

code can vary depending on the Processing Network that the merchant is

using) and an optional reference number. If the software has been

configured for address verification, the one-letter AVS response will be

included at the end of the approval code:

"Y123456Y12345678"

For a complete list of AVS response codes, see the document AVS & CVV

Response Codes on your installation CD-ROM. If an additional number

follows the AVS response, it‘s a reference number for the transaction

provided by the Processing Network.

Processing

Offline Group

Input or

Request Files –

Interpreting

Results: Method

2

It‘s possible to use the Export Transactions feature to export the results of an

offline group transmission, but line item details will not be included.

The export feature exports the header record for purchasing transactions, but

not the line item details. For example, an input file including a single Visa®

purchasing card transaction would appear as follows (extra spaces included

for legibility):




Page 67 of 119

"C1","clerk","12433254365436","4275330000005810",

"0912","40.00","12345","LIIIWithLID","2354325","0.00","0.00",

"0.00","0.00","07-30-2003","31432","4254325","45435"," 3"

"P0","0004","Pens,Green","555EEE000","1.0000","Gross",

"35.9900","00.00","0.00","0.00"

"P0","0003","Pens,Red","444DDD000","1.0000","Gross",

"39.9500","00.00","0.00","0.00"

"P0","0003","Pens,Red","444DDD000","1.0000","Gross",

"39.9500","00.00","0.00","0.00"

If the export feature is used, only the information that is bold is available for

export (along with the response from the Processing Network). The line items

for the transaction (the remaining three entries) are ignored by the export

feature as transactions are exported.

Tokenization

and

Encryption

Capability on

FDMS Cardnet

From ICVERIFY version 4.2 and above secure transaction processing via

tokenization and encryption technologies are supported on the FDMS

Cardnet platform. If this support is enabled then the cardholder PAN / track

data information being sent to the host from a POS are encrypted. Additional

security is provided using tokenization where the real account number is

replaced by a token at the POS.

If secure transaction processing support is enabled then ICVERIFY sends

encrypted track data / account number during authorization. For all

subsequent transactions with this account number ICVERIFY uses a token

which is returned from the host. For each account number one unique

token is returned from the host after authorization. The token length and

last four digits will be same as that of the original account number. For any

dependent transactions e.g. Void/Force/Credit Refund, token will be used

in place of the account number.

NOTE: The support for secure transaction processing using data encryption

and tokenization is at present supported for FDMS Cardnet platform only.

All users doing transaction in Request-Answer (request string or XML) mode

will need a token to perform the dependent transactions. This token will be

returned in answer file within <Token> tag for the corresponding

authorization transaction. For all dependent transactions the merchant has

to give the token value in the account number field.

A new field CDT has been introduced to hold the card type information.

Since, after transaction ICVERIFY will not store the PAN anywhere so it stores

the card type information in the CDT field to perform subsequent

dependent transactions by the corresponding token.




Page 68 of 119

Merchants need not populate the CDT field during preparing request files

for dependent transactions. This will be populated automatically by

ICVERIFY.

Transaction Request Format

In the response the token from the host is returned under the <Token> tag. If

we need to do a dependant transaction corresponding to the above

authorization then we need to use the specified token in place of the

account number. Shown below is a Void transaction corresponding to the

above auth.

The response received from an authorized sale transaction in the comma

delimited mode will be as follows,

―Y123456<Token>0280600158580026‖

Following is a sample response in XML mode,

<Reply>

<TransactionReply>



<AVSResponseCode>Y</AVSResponseCode>

<CVVResponseCode></CVVResponseCode>

<ApprovalNumber>OK521C</ApprovalNumber>

<AuthorizationNumber></AuthorizationNumber>



<BalanceAmount></BalanceAmount>


<CardSubType>Y</CardSubType>

<TransactionID>0000001</TransactionID>



<Token>0280600158580026</Token>

<HostTransactionID>011224231005904</HostTransactionID>


<RawResponse>MRxBUE9LNTIxQxwwODEyHFkcQTAxNEswMTEyMjQyMzEwMDU

5MDRHNzU4ICAwMDAwMDAwMDAwMDAw

MDAwMDAwMDAwMDAcHBwcHBwbQTBWSTAwNENSQyBBMFNQMDM1WFow

MDFPMDcwMTYwMjgwNjAwMTU4

NTgwMDI2MTAwMDMwMDIb</RawResponse>

<CardType></CardType>

<CardName></CardName>

</TransactionReply>

</Reply>

The request format for a void transaction will be,

"C2","CMS","CMT","ACT","EXP","AMT","TIP","ZYX","ZYX","DFG","FAM","CCD","EXR","CRT","CRD"

,"CLI","REV","CDT"




Page 69 of 119

A sample request with the example token is shown below,

"C2","sysadmin<CMN>","","0280600158580026","1212","1.00","","","","","","","","","0.00","USD","0

.00","","","","Y",""

A sample XML request with the example token is given below,

<Request>

<CreditCardVoid>

<ClerkID>Clerk Name</ClerkID>

<Comment></Comment>

<AccountInfo>


<Track1></Track1>

<Track2></Track2>

</AccountInfo>

<ExpirationInfo>



</ExpirationInfo>


<TransactionReversalFlag>Y</TransactionReversalFlag>

</CreditCardVoid>

</Request>

Reports



Page 70 of 119

Chapter 6 – Reports

Overview The chapter describes the individual sections of reports generated by the

ICVERIFY® application.

To see a sample report in its entirety, see Detailed Report Sample.

Detail

Reports

The Detail Report is used to view transactions before they are settled. This

report is also known as the Pre-Settlement Report.

A merchant views the Detail Report to verify that the correct transactions are

going to be settled. At the head of the Detail Report is a common

introduction to a report. The rest of the report is broken into the following

sections:

Credit Card

Visa® & MasterCard®

Visa®

MasterCard®

American Express®

Discover®

Diners/Discover®

JCB/Discover®

Other

Captured

Not Captured or Auth Only

Sequence Number

Authorized Transactions

Reports



Page 71 of 119

Detail Report

Format

A detail report can be generated through the same request file process as

regular transactions.

Use the following format in request-string mode: "RC","HRD","SDT","EDT","RPS","SUM","TAG","CMc","CMM","ACT",

"EXP","AMT","CMN"

In XML mode, the request would follow this structure: <Request>

<ChargeCardReport>

<ClerkID></ClerkID>

<Comment></Comment>

<PrintFlag></PrintFlag>

<ReportStartDate></ReportStartDate>

<ReportEndDate></ReportEndDate>

<ReportOptions></ReportOptions>

<ReportSummaryIndicator></ReportSummaryIndicator>

<ReportPrintReceiptOptions></ReportPrintReceiptOptions>

<ReportType></ReportType>

<AccountInfo>


</AccountInfo>

<ExpirationInfo>



</ExpirationInfo>

</ChargeCardReport>

</Request>

You can customize your report by changing the values in the parameters or

by changing the type of report you run. Refer to the Transaction Builder tool

for additional information about report subtypes. Table 4 describes the

standard fields used to generate a detail report.

Reports



Page 72 of 119

If you are using the Dynamic Currency Conversion (DCC) feature within the

software, the request-string format includes a new field at the end: "RC","HRD","SDT","EDT","RPS","SUM","TAG","CMc","CMM","ACT",

"EXP","AMT","CMN","CCD"

In XML mode, the equivalent node is <DccInfo><DccCurrencyCode>.

If you support DCC and a batch contains transactions in multiple currencies,

then multiple detail sections in different currencies will be shown in the Detail

Report. The Report will be grouped by the currency code. An additional

summary section in U.S. Dollars will be present along with the foreign currency

for converted transactions. The Grand Total will be printed in U.S. Dollars.

NOTE: Depending on the service pack level of your software, the DCC

feature may not be available.

Table 4 Detail Report Field Definitions

Field Description

RC Describes the type of transaction to report.

HRD A yes/no flag specifying whether you wish this

report to be spooled to the printer. The print

device used will be the one you configured as

your report printer in the ICVERIFY Setup

Application Printer tab.

SDT Use the current date to produce a Settlement

Preview report (this is the ―processed date range‖

of the transaction requested). Use a date range

that spans over a period to produce a Credit

Card report. Use the format xx-xx-xxxx.

EDT Use the current date to produce a Settlement

Preview report (this is the ―processed date range‖

of the transaction requested). Use a date range

that spans over a period to produce a Credit

Card report. Use the format xx-xx-xxxx.

CMN Contains the customer‘s name.

Reports



Page 73 of 119

Field Description

RPS Allows you to set report options you want to use

for each report. Valid values are the following:

Y — Captured

N — Not captured

V — Visa®

M — MasterCard®

A — American Express®

D — Discover®


SUM Enables summary information. Valid values are

the following:

Y — Totals only

N — Include details with totals

S — Settlement sub-totals

D — Settlement sub-totals with details

TAG Enables or disables receipt printing. Choose Y to

print, choose N to disable.

CMc Contains the clerk information, and can contain

up to 32 alphanumeric characters.

CMM Contains comment information about the

transaction, and can contain up to 32

alphanumeric characters. This field is often used

for order numbers (a unique number or

alphanumeric sequence that identifies the

transaction).

ACT If you wish to report on a single transaction, you

can use this field as a filter on a specific card

number. Otherwise, do not enter a value.

In request-string mode, you must supply this field

even if you leave it blank. In XML mode, you may

omit the AccountInfo node if you do not wish to

use it.

AMT Use this field along with the ACT field to filter on a

specific transaction.

In request-string mode, you must supply this field

even if you leave it blank. In XML mode, you may

omit the TransactionAmount element if you do

not wish to use it.

Reports



Page 74 of 119

Field Description

EXP If you include an account number in the ACT

field, you will need to specify its expiration date.

The format in request-string mode is YYMM. In

XML mode, you may omit the ExpirationInfo node

if you do not wish to use it.

CCD This is a currency code indicator for Dynamic

Currency Conversion reports. You do not need to

include this field unless you are using the DCC

feature on First Data‘s CARDnet platform.

Report information is located at the beginning of the Detail Report. The

introduction includes the report type, dates and time, the company name,

and page number, as shown in Figure 7.

Figure 7 Detail Report – Introduction

Reports



Page 75 of 119

The first section of the report is called Credit Card. This section details what

cards are going to settle and includes all card types. If you are performing

standard processing, the report will look similar to that shown in Figure 8a. If

you‘re doing Dynamic Currency Conversion (DCC), the report will look similar

to Figure 8b.

Figure 8a Detail Report, Credit Card Section – Standard Processing

Figure 8b Detail Report, Credit Card Section – DCC Processing

Detail Report

Fields

There are several fields in this section of the Detail report that are also found

in other sections of the report. The fields under CARD/COMMENT are

described in Table 5.

Reports



Page 76 of 119

Table 5 Card/Comments Fields in the Detail Report

Field Description

T The type of transaction.

NOTE: This field is industry specific. For instance, in

the MOTO industry, the most commonly used

transaction types are Book (B) and Ship (S). In the

food industry the most commonly used transaction

are Authorization (A) and Add Tip (T). If your industry

is retail then the most commonly used transaction is

Sale (S).

Type The type of credit card used for the transaction.

Number The credit card number used for the transaction.

EXP The expiration date on the credit card used for the

transaction.

Amount The amount of the transaction.

Date The date the transaction was executed.

Time The time of day the transaction was executed.

SEQ# A sequence number supplied by the Processing

Network.

Response The approval code for the transaction.

NOTE: The word OK before the approval means that

the card is good.

Customer Name The customer‘s name as it appears on the credit

card used for the transaction.

NOTE: This field is completed only if the credit card

was swiped.

Clerk The name of the clerk who took the order.

Comment Any additional comments regarding the transaction.

This field is often used for order numbers (a unique

number or alphanumeric sequence that identifies the

transaction).

Reports



Page 77 of 119

Additional

Fields

Right below the credit card number, there are three more fields. The first of

the three fields does not have an identifier.

This unidentified field is for the customer‘s name that appears on the card

used for that particular transaction (swiped cards only).

The next two areas are the clerk and comment identifiers. To the right of the

clerk and comment identifiers are the fields that contain the information for

the identifiers. Some merchants use the comments field for a customer order

number.

Credit Card

Summary

Information

A summary of all credit card activity appears at the bottom of the report in

the Credit Card section. The rest of the Detail Report is broken into sections

similar to the Credit Card section.

If you‘re performing standard processing, your summary will be similar to that

shown in Figure 9a. If you‘re performing DCC processing, the summary will be

similar to Figure 9b.

Figure 9a Detail Report, Credit Card Summary – Standard Processing

Reports



Page 78 of 119

Figure 9b Detail Report, Credit Card Summary – DCC Processing

Visa® &

MasterCard®

Section

This section shows Visa® and MasterCard® transactions for each card type

(Figure 10). It contains the same fields as the Credit Card section, plus a few

more.

Figure 10 Detail Report (Visa® and MasterCard® Section)

Detail Report

(Visa® and

MasterCard®

Totals)

This section contains the total of Visa® and MasterCard® transactions.

(Figure 11).

Reports



Page 79 of 119

Figure 11 Detail Report (Visa® and MasterCard® Totals)

Detail Report

(Defining Visa®

or MasterCard®

Transactions)

This section of the report breaks down the total dollar amount and defines

whether they are Visa® or MasterCard® transactions (Figure 12).

Figure 12 Detail Report (Defining Visa® or MasterCard® Transactions)

Reports



Page 80 of 119

American

Express®

Section

This section of the report is devoted entirely to American Express® transactions

(Figure 13).

Figure 13 Detail Report (Defining American Express® Transactions)

Detail Report

(American

Express®

Transaction

Totals)

You will find the number and total dollar amount of American Express®

transactions here (Figure 14).

Figure 14 Detail Report (American Express® Transaction Totals)

Reports



Page 81 of 119

Not Captured

or Authorized

Transactions

The transactions that were not captured or are authorized only and did not

settle are displayed in Figure 15.

Figure 15 Detail Report (Not Captured or Authorized Transactions)

Reports



Page 82 of 119

Authorized

Transaction

Section

The next section of the report shows authorized transactions. This section of

the report also includes transactions that were authorized but not captured.

For example, a Sale transaction is authorized and captured, but Book

transaction is authorized but not captured. Both transaction types are shown

in this section.

NOTE: This section of the report does not include transactions that were

declined.

Figure 16 Detail Report (Authorized Transaction Section)

Reports



Page 83 of 119

Post-

Settlement

Reports

The Post-Settlement report is used after settlement is complete, and describes

the transactions sent to the Processing Network for deposit to your account.

This report can be generated from a request file. Use the following format in

request-string mode: "SP","RPS","HRD","RPT"

In XML mode, the request would follow this structure: <Request>

<CreateSettlementReport>

<PrintFlag></PrintFlag>

<ReportOptions></ReportOptions>

<ReportType></ReportType>

</CreateSettlementReport>

</Request>

Table 6 describes the fields used to generate a Post-Settlement report.

Table 6 Post-Settlement Report Fields

Field Description

SP Describes the type of transaction to report

(Settlement report).

RPS Allows you to set report options you want to use for

each report. Valid values are the following:

Y — Captured

N — Not captured

V — Visa®

M — MasterCard®

A — American Express®

D — Discover®

HRD Specifies the printer you want to use to print the

report. This field should contain the URL or path to

the printer in Windows notation.

Reports



Page 84 of 119

Figure 17 Post-Settlement Report (Introduction)

Credit Card

Section

The first section of the report indicates the transactions that settled and the

total dollar amount of these transactions. They are broken out by credit card

type.

Post-Settlement

Report (Credit

Card Section)

The information shown in Figure 18 is the segment that summarizes the credit

card section.

Figure 18 Post-Settlement Report (Credit Card Section)

Reports



Page 85 of 119

Authorized

Only

Transaction

Section

The next section of the report identifies those transactions that did not settle—

these transactions were authorized only. It also breaks down these

transactions by credit card type. Credit card type Total dollar amount of

settled transactions

Post-Settlement

Reports

(Authorized

Only

Transactions)

Figure 19 displays a summary of Authorized Only transactions that did not

settle.

Figure 19 Post-Settlement Reports (Authorized Only Transactions)

Reports



Page 86 of 119

Post-Settlement

Report

(Unsettled

Transactions)

Figure 20 displays a summary of transactions that did not settle.

Figure 20 Post-Settlement Report (Unsettled Transactions)

Tutorials



Page 87 of 119

Chapter 7 – Tutorials

Overview This chapter discusses how to perform simple integrations to your ICVERIFY

software.

Windows®

Visual Basic

Integration

Tutorial

This Visual Basic Integration Tutorial guides you through all the steps necessary

to integrate your Visual Basic application with the ICVERIFY® interface. This is a

typical Multiple User Request and Answer File integration solution.

This tutorial uses the sample code supplied with the SDK as an example. The

sample application builds a request file and waits until it has been processed

by the ICVERIFY application to produce an answer file.

The sample project is named vb32raf.vbp (VB Version 6.0). The application

reads data from a text file (demo.dat) and allows you to process either a

single or all transactions.

Answers from the processor are displayed in appropriate controls. Note that

the application is run under demo mode. You can use an actual .SET file to

do live testing. The online documentation describes steps necessary to build

a live .SET file using the Setup program.

Using the

Direct DLL

Interface

Refer to the online help system in your SDK package for information on how

to submit transactions directly to the ICVERIFY DLL interface.

Using the

Request-

Answer

Interface

To use the Request-Answer file interface, the ICVERIFY application must be set

up with a request directory that is used to process transactions. If you are

unsure how to do this, refer to the ICVERIFY Setup Guide.

The ICVERIFY software polls this directory for request files (.REQ) and writes

responses into answer files (.ANS) in a first-in, first-out (FIFO) model. Table 6

illustrates the file naming conventions used when processing transactions

using this interface.

Tutorials



Page 88 of 119

Table 6 File Naming Conventions

File Extension Description

.TMP A temporary file that stores transactions used to store

transactions that need to be processed (one

transaction per line). The extension of this file is

arbitrary so long as the file extension is NOT .REQ,

.HLD, .ZZZ, or .ANS.

.REQ Rename the temporary file to ICVERxxx.REQ where

xxx is the station number. In a single user

environment, this is always 001.

.HLD Created by ICVERIFY® for processing.

.ZZZ Created by ICVERIFY® for processing.

.ANS The answer for the transaction(s) processed.

Tutorials



Page 89 of 119

Sample

Code

Program

Flow

To integrate successfully, the client application must follow some basic

guidelines. The table below describes the process flow.

Step

1. Identify global constants

2. Prepare temporary request file or message. For Request-Answer

file method, encrypt the transaction records using ICVTnsClient

and prepare a temporary request file

3. Rename request file to active file type, or submit the message to

the ICVERIFY request directory or ICVERIFY DLL interface for

processing.

4. Wait for answer file or response to DLL interface call

5. Process answer file or response

Tutorials



Page 90 of 119

Code

Program Flow

Procedures

Follow the steps in the table below to set up a directory to process

transactions.

Step Action

1. Identify Global Constants. The code module vb32raf.bas defines all

constants and variables used by the sample application. The ones

of interest for integration are mentioned below.

‗ request directory to drop request files

Public Const REQUEST_DIR = ―C:\REQUEST‖

‗ station number for this client

Public Const STATION_NUM = ―001‖

‗ prefix used to name request file

Public Const REQ_FILE_PREFIX = ―ICVER‖

Refer to vb32raf.frm for the remaining steps.

Tutorials



Page 91 of 119

Step Action

2. Encrypt the transaction records using ICVTnsClient and prepare a

temporary request file

Public Sub Prepare_File(bSingleTran As Boolean)

Dim sTempFile As String

Dim iIndex As Integer

'Create TnsClient object

Dim objSslTcpClient As New SslTcpClient

Dim stext As String

'build temporary file name

sTempFile = App.Path + "\" + REQ_FILE_PREFIX + STATION_NUM +

".TMP"

'write transaction record(s) into temporary file

Open sTempFile For Output As #1

If (bSingleTran) Then 'Process Single transaction

'write the encrypted string in the file

Print #1, objSslTcpClient.Encrypt ( cmbTransaction.Text)

Else 'Process Batch transaction

'write the encrypted string in the file

For iIndex = 0 To cmbTransaction.ListCount - 1

Print #1, objSslTcpClient.Encrypt (

cmbTransaction.List(iIndex))

Next

End If

Close #1

On Error GoTo 0

Exit Sub

End Sub

The sample above builds a temporary file name ICVER001.TMP

(with path). The file is then opened, TnsClient is invoked to encrypt

the transaction records and the encrypted transaction record(s) is

written to it. Use the Transaction Builder tool to look up transaction

record formats.

Tutorials



Page 92 of 119

Step Action

3. Rename request file

Function Rename_File() As Boolean

Dim sTempFile As String

Dim sRequestFile As String

'build temporary and request file names

sTempFile = App.Path + "\" + REQ_FILE_PREFIX + STATION_NUM +

".TMP"

sRequestFile = REQUEST_DIR + "\" + REQ_FILE_PREFIX +

STATION_NUM + ".REQ"

On Error GoTo ErrFileRename

'rename temporary file into REQ file

Name sTempFile As sRequestFile

The code above renames the temporary request file name

(ICVER001.TMP) to a valid request file name (ICVER001.REQ).

4. Wait for answer file

The request file is picked up by the ICVERIFY application and

processed into an answer file.

Depending on the transaction, the ICVERIFY application may dial

the processor (e.g. credit card), request a PIN from the PIN Pad

(debit card), return inquiry information such as merchant name,

etc.

Public Function WaitFor_AnswerFile() As Boolean

Dim sAnswerFile As String

bCancelWait = False

sAnswerFile = REQUEST_DIR + "\" + REQ_FILE_PREFIX + STATION_NUM

+ ".ANS"

'loop until an answer file is available in the request directory or

'the user clicks the Cancel Wait button

Do While (Dir(sAnswerFile) = "") And (Not bCancelWait)

DoEvents

Sleep (WAIT_SECONDS)

Loop

The code sample above waits in a while loop for the answer file.

Tutorials



Page 93 of 119

Step Action

5. Decrypt the contents using ICVTnsClient and process answer file

Once the transaction is processed by the ICVERIFY application, the

answer file can be examined for the response and processed as

necessary. Before processing however the answer file needs to be

decrypted.

The sample application calls the Show_AnswerFile() function

decrypts the answer file and displays the contents of the answer file

in an edit box.

Public Sub Show_AnswerFile()

Dim sAnswerFile As String

Dim sAnswerLine As String

Dim objSslTcpClient As New SslTcpClient

'build answer file name path

sAnswerFile = REQUEST_DIR + "\" + REQ_FILE_PREFIX + STATION_NUM

+ ".ANS"

On Error GoTo ErrFileOpen

'open answer file and display contents in the text box

Open sAnswerFile For Input As #1

Do While Not EOF(1)

Line Input #1, sAnswerLine

sAnswerLine = objSslTcpClient.Decrypt (sAnswerLine)

txtAnswer = txtAnswer + sAnswerLine + Chr$(13) + Chr$(10)

Loop

Close #1

On Error GoTo 0

Exit Sub

End Sub

Repeat Steps 2-5 to process transactions.

Perform necessary approval/decline processing for the answer file.

Response Codes



Page 94 of 119

Appendix A – Response Codes

Overview This appendix discusses the various result and response codes you may

receive from the ICVERIFY application.

Address

Verification

Result Codes

You will receive address verification response codes in both the request-string

and XML modes. In request-string mode, the response code is within the .ANS

response file or the DLL response string. In XML mode, the response code

resides within the AVSResponseCode element. Refer to the document AVS &

CVV Response Codes for the current codes you might receive from your

processing network.

Card

Verification

Result Codes

You will receive CVV2 / CVC2 / CID verification response codes available in

both the request-string and XML modes. In request-string mode, the response

code is within the .ANS response file or the DLL response string. In XML mode,

the response code resides within the CVVResponseCode element.

Response

Code Values

Table 9 lists the values within the ResponseCode XML element. You can query

the ResponseCode value along with the processor-specific ResultCode value

(if needed) to determine how to proceed with your transaction processing.

Table 9 ResponseCode Values

Value Description

0 (zero) Transaction was approved or accepted. Query other fields

such as ApprovalNumber for important transaction

information.

2 Transaction received only partial approval for the request

amount.

256 Transaction was declined. Do not proceed with the

transaction.

257 Transaction was declined due to insufficient funds.

258 Invalid card number or routing number (if a check

transaction.)

259 Expired card or other payment instrument.

260 Call the issuer before proceeding with the transaction.

Response Codes



Page 95 of 119

Value Description

1023 Error at processing network. Attempt the transaction again

or call your financial institution‘s voice authorization center.

1024 General error including potential syntax problems, inability to

validate PIN for debit transactions, or inability to fulfill a batch

settlement request. Check the validity of your transaction

request and the data you are submitting, and try again. Also

check the ResultCode and ResultMessage field for additional

information.

1026 Transaction timed out or processing network requested a

resubmission for another reason. Attempt the transaction

again. If you consistently receive this error, check the validity

of your transaction request or call your financial institution‘s

voice authorization center.

1027 Processing network is not available due to a

communications failure. This error generally means you will

need to revert to manual processing for a period of time until

your processing network is back on line.

1028 Transaction wasn‘t performed because a duplicate of it was

already present at the processing network.

1029 The transaction was rejected because the merchant ID used

to submit it is not valid.

1030 The transaction was rejected because the request type is not

valid.

1034 The transaction was rejected because the merchant ID used

to submit it is not authorized to perform this type of

transaction, or one of the transaction elements failed a

syntax check at the processing network.

1035 The transaction was rejected because the transaction type is

not permitted by the processing network or the transaction

could not be fulfilled as requested (for example, a daily

cashback limit was exceeded on a debit card)

8191 Unknown or unexpected error.

Field Definitions



Page 96 of 119

Appendix B – Field Definitions

Table 10 Table 10 describes the field definitions for use within the ICVERIFY SDK,

including the XML element(s) corresponding to the application field where

applicable. You will notice that in many cases, several fields have been

combined into one XML element for ease of use. Be sure you use the

Transaction Builder tool to determine how your specific field usage will affect

your transaction construction.

Field XML Element Name Description Data Type

ABA RoutingNumber Check routing (ABA) number Number

ACI AccountType Account Type Text

act PriorAccountNumber Prior Account Number,

generally used if value is being

transferred from one stored

value card to another

Number

ACT AccountInfo.

AccountNumber or

Track1 or

Track2

Account Number Number

AD2 ApplicationInfo.

Applicant.

Address2

Primary Applicant Address Line

2 (GE Application Processing)

Text

ADA AdditionalAmount Additional (Surcharge)

Amount

$Amount

ADD BillingAddress Billing Address Text

ADG ApplicationInfo.

Applicant.

Address1

Primary Applicant Address Line

1 (GE Application Processing)

Text

ADN ApplicationDisplayName Application Display Name Text

ADS LineItem.

AmountSign

Amount Sign, + for debit and –

for credit, from the

cardholder‘s perspective

Text

ADT LineItem.

AmountType

Amount Type, used to report a

breakdown of charges by

type (for example, tips, fees,

and so on)

Text

Amn

CashBackAmount Additional Cash $Amount

AMN

CashBackAmount Additional Cash (Cash Back

Amount)

$Amount

Field Definitions



Page 97 of 119


AMP

PurchaseInfo.

PurchaseItems.

LineItem.

ItemAmount

Purchase Amount

$Amount

Amt TransactionAmount Additional Amount $Amount

AMt TransactionAmount Total Amount $Amount

AMT TransactionAmount Amount $Amount

ANI CustomerPhoneNumber Customer Phone Number Text

APV ApprovalNumber Approval Code Text

ATM LodgingInfo.

ArrivalTime

Arrival Time Number

AID ApplicationID Application ID Text

BDC BypassDupCheckFlag Duplicate Check Text

BIN BalanceInformation Balance Information Y/N

BIP BillPaymentIndicator Bill Payment Indicator Y/N

BLK n/a Blank field Text

CCD DccInfo.

CurrencyCode

Foreign Currency Code Text

CGE ApplicationInfo.

Applicant.

City

City Text

Ch2 AccountInfo.

AccountNumber

Account Number Text

CH2 AccountInfo.

AccountNumber


CH3 AccountInfo.

AccountNumber

Account Number Text

CHK AccountInfo.

AccountNumber


CID CardVerificationFlag Card Verification Indicator Text

CKN CheckNumber Check Number Number

CKR RoutingNumber Check routing (ABA) number Number

CLK ClerkID Clerk Number Number

cMa LodgingInfo.

DepartureDate

New Departure Date Date

cMA LodgingInfo.

OriginalDepartureDate

Original Departure Date Date

CMA LodgingInfo.

ArrivalDate

Arrival Date Date

CMc ClerkID Clerk Text

CMD LodgingInfo.

DepartureDate

Departure Date Date

Cme LodgingInfo.

ChargeCodes

Charge Codes Number

CME LodgingInfo.

ExtraChargeAmount

Additional Charges $Amount

CMF Descriptor Charge Description Text

Field Definitions



Page 98 of 119


Cmi InvoiceNumber Invoice Number Number

CMI LodgingInfo.

InvoiceNumber

Invoice/folio Number Number

Cmm PurchaseInfo.

DiscountAmount

Discount Amount $Amount

CMM Comment Comment Text

CMN CustomerName Customer name Text

cmO CustomerOrderID Reference Number Text

cMo PurchaseInfo.

OrderDate

Order Date Date

Cmo CustomerOrderID Customer Order Number Text

CmO CustomerOrderID Customer Order Number Text

CMO CustomerOrderID Customer Order Number Text

CMo OperatorID Operator ID Text

cmp PurchaseInfo.

ShippingPostalCode

Destination zip code Text

cmP PurchaseInfo.

SendingPostalCode

Original zip code Text

CmP LodgingInfo.

PreferredCardholderFlag

Preferred cardholder?(y/n) Text

CMP DescriptorCode Descriptor codes Number

cmR ReferenceNumber Reference number Text

Cmr LodgingInfo.

RoomRate

Room rate $Amount

CmR LodgingInfo.

RoomNumber

Room number Text

CMR PaymentTermCode Ticket terms Number

CMS ClerkID Server ID Text

Cmt PurchaseInfo.

PurchaseOrderID

Merchant Order Number Text

CMt PurchaseInfo.

PurchaseOrderID

Merch Order #/Purchase ID Text

Cmw PurchaseInfo.

CustomerCode

Customer Code Text

CMw PurchaseInfo.

AlternateOrderID

Alternate purchase order

number

Text

CMW PurchaseInfo.

CustomerCode

Customer Code/Reference ID Text

cMX SalesTaxAmount Sales Tax $Amount

CMx SalesTaxAmount Tax Amount $Amount

CMX SalesTaxAmount Tax Amount $Amount

CMY PurchaseInfo.

DutyAmount

Duty Amount $Amount

CMz PurchaseInfo.

PurchaseItemCount

Total Addenda Number

CMZ PurchaseInfo.

FreightAmount

Freight Amount $Amount

Field Definitions



Page 99 of 119


CNB Client Order ID Client Order ID (Citi Private

Label)

Text

COD CustomerANICode Customer ANI Code Text

COI CashOutFlag Cash out Y/N

CPI CardPresentFlag Card Present Indicator Y/N

CRD DccInfo.

ConversionDate

Currency Conversion Date Date

CRT DccInfo.

ConversionTime

Currency Conversion Time Text

CT3 PurchaseInfo.

PurchaseItems.

LineItem.

ItemCode

Commodity Code Text

CSI ApplicationInfo.

CrossSellFlag

Cross-Sell Indicator Y/N

CT4 PurchaseInfo.

SummaryCommodityCode

Summary Commodity Code Text

CVv CardVerificationValue CVV2/CVC2/CID Text

CVV CardVerificationValue CVV2/CVC2/CID Text

DCC DestCountryCode Destination Country Code Text

DCI ApplicationInfo.

DualCreditFlag

Dual Credit Indicator Y/N

DEF DeferredBillingFlag Deferred Billing Flag Text

DEM PurchaseInfo.

PurchaseItems.

LineItem.

ItemDescription

Description Text

DEV PurchaseInfo.

PurchaseItems.

LineItem.

ItemDescription

Description Text

DFG DccInfo.

DccStatusIndicator

DCC Status Text

DL1 ApplicationInfo.

Applicant.

IdentificationNumber

Drivers License Number Text

DLE IdentificationNumber Drivers License Number Text

DLI IdentificationNumber Customer ID Text

DLN IdentificationNumber Drivers License Number Text

DLS ApplicationInfo.

Applicant.

IdentificationState

Drivers License State Text

DNP DeferredNumberOfPayme

nts

Deferred Number of Payments Number

DOB BirthDate Date of Birth Date

DPC ShippingState Destination State Code Text

dpc DepartmentCode Department Code Text

Field Definitions



Page 100 of 119


DPM DebtPaymentFlag Debt payment Text

DPP DeferredPaymentPlan Deferred Payment Plan Number

DSC PurchaseItems.

LineItem.

ItemDiscountAmount

Discount amount $Amount

dsc Descriptor Description of purchase for GE

private label transactions

Text

DTM LodgingInfo.

DepartureTime

Departure Time Number

DTP DeferredTimePeriod Deferred Time Period Number

DXP ApplicationInfo.

Applicant.

IdentificationExpiration

Date

Drivers License Expiration Date

E01 PurchaseInfo.

NationalTaxAmount

National Tax Amount $Amount

E03 PurchaseInfo.

CustomerVatRegistration

Number

Customer VAT Registration

Number

Text

E09 PurchaseInfo.

PurchaseItems.

LineItem.

ItemUnitOfMeasure

Unit of measure Text

E16 PurchaseInfo.

PurchaseItems.

LineItem.

ItemUnitCost

Unit cost Number

E18 PurchaseInfo.

PurchaseItems.

LineItem.

ItemTaxAmount

VAT / Tax Amount $Amount

E19 PurchaseInfo.

PurchaseItems.

LineItem.

ItemQuantity

Quantity Number

E20 PurchaseInfo.

UniqueVatInvoice

ReferenceNumber

Unique VAT Invoice Reference

Number

Text

EDT ReportEndDate Ending date Date

EMV EMVTagInfo EMV Tag Info Text

EST EscheatableFlag Escheatable Indicator Y/N/X

EXP ExpirationInfo.

ExpirationMonth &

ExpirationYear

Expiration Date Date

EXR DccInfo.

ExchangeRate

Foreign Currency Exchange

Rate

Amount

FAM DccInfo. Foreign Amount Amount

Field Definitions



Page 101 of 119


ForeignAmount

FBC PurchaseItems.

LineItem.

ItemDCFlag

Debit/credit flag Text

FBK EMVFallBack EMV FallBack Text

HRD PrintFlag Printer?(y/n) Y/N

IAT LineItem.

ItemAmount

Unit cost of line item Amount

INC InvoiceNumber Invoice Number Text

ins InstallmentCount Number of Installments Number

IQT LineItem.

ItemQuantity

Item quantity Number

ISW SwipeData Data for check transaction

processing; may be manually

entered or retrieved from a

MICR reader

Text

LNI ApplicationInfo.

LanguageIndicator

Language Indicator Text

MON MerchantOrderNumber Merchant Order Number Text

NRI NetworkReferenceID Network Reference Identifier Number

NSF NoNSFFlag No NSF Y/N/X

OAM OriginalTransactionAmount Original Transaction Amount $Amount

OPR OriginalTransactionID Original Purchase Reference Text

OTD OriginalTransactionDate Original Transaction Date MM/DD/YYYY

OTT OriginalTransactionTime Original Transaction Time hhmmss

pc1 ProductCode1 Product Code 1 (Citi Private

Label)

Text


Label)

Text


Label)

Text


Label)

Text


Label)

Text

pCI ApplicationInfo.

CreditInsuranceFlag

Credit Insurance Y/N

PCN ApplicationInfo.

Applicant.

MobilePhoneNumber

Primary Cell Phone Number

PDB ApplicationInfo.

Applicant.

BirthDate

Date of Birth Date

pHI ApplicationInfo.

Applicant.

HousingFlag

Housing Information Text

pHN ApplicationInfo. Home Phone Number

Field Definitions



Page 102 of 119


Applicant.

HomePhoneNumber

PIF ApplicationInfo.

Applicant.

IncomeFrequency

Income Frequency Text

pIM ApplicationInfo.

RequestedAmount

Initial Requested Amount Number

pIN ApplicationInfo.

Applicant.

Income

Monthly Income Number

PIN PINData Pin data Text

pJI

ApplicationInfo.

JointApplicationFlag Joint Indicator Y/N

pPC

ApplicationInfo.

ProductCode Product Code Text

Pmn ApplicationInfo.

Applicant.

FirstName

First Name Text

pMn ApplicationInfo.

Applicant.

MiddleName

Middle Name Text

pmN ApplicationInfo.

Applicant.

LastName

Last Name Text

PR6 SKUData SKU Data Text

PR8 DeferredBillingFlag Deferred Payment Indicator Number

PRD PurchaseInfo.

ProductCode

Summary Product Code for

Visa purchasing card

transactions

Text

PRI PartialRedemptionFlag Partial Redemption Indicator Y/N

pRN ApplicationInfo.

Applicant.

RelativePhoneNumber

Relative Phone Number Number

pSN ApplicationInfo.

Applicant.

SSN

SSN Number

PSU SKUData Product SKU Text

PTA ApplicationInfo.

Applicant.

TimeAtResidence

Time at Residence Text

PTC PromotionalCode Promotional Code Number

PTJ ApplicationInfo.

Applicant.

TimeAtJob

Time at Job Text

pWN ApplicationInfo.

Applicant.

WorkPhoneNumber

Application Work Phone

Number

Number

Field Definitions



Page 103 of 119


PYN PurchaseCardFlag Purchase Card Indicator for

American Express transactions

Y/N

PYT PaymentType Payment Type indicator for

Paymentech Stored Value

transactions; used for reporting

purposes only

Text

QUa PurchaseInfo.

PurchaseItems.

LineItem.

ItemQuantity

Quantity Text

REF TransactionID Reference Number Number

RER RecurringFlag Recurring Flag Text

REV TransactionReversalFlag Reversal Flag Y/N

RPD ReportOptions Report options (or enter) Rpt. Options

RPS ReportOptions Report options (or enter) Rpt. Options

RTM RetailTermsCode Retail Terms Text

SA2 ApplicationInfo.

CoApplicant.

Address2

Secondary Applicant Address

2nd Line

Text

SAD ApplicationInfo.

CoApplicant.

Address1

Secondary Applicant Address Text

SCN ApplicationInfo.

CoApplicant.

MobilePhoneNUmber

Secondary Applicant Cell

Phone

Number

SCY ApplicationInfo.

CoApplicant.

City

Secondary Applicant City Text

sDB ApplicationInfo.

CoApplicant.

BirthDate

Secondary Applicant Date of

Birth

Number

SDL ApplicationInfo.

CoApplicant.

IdentificationNumber

Secondary Applicant Drivers

License

Text

SDS ApplicationInfo.

CoApplicant.

IdentificationState

Secondary Applicant DL State Text

SDX ApplicationInfo.

CoApplicant.

IdentificationExpiration

Date

Secondary Applicant DL

Expiration

Text

SDT ReportStartDate Starting date Date

SIf ApplicationInfo.

CoApplicant.

IncomeFrequency

Secondary Applicant Income

Frequency

Text

SIM ShippingMethod Shipping Method Text

sIN ApplicationInfo. Secondary Applicant Income Number

Field Definitions



Page 104 of 119


CoApplicant.

Income

Smn ApplicationInfo.

CoApplicant.

FirstName

Secondary Applicant First

Name

Text

sMn ApplicationInfo.

CoApplicant.

MiddleName

Secondary Applicant Middle

Name

Text

smN ApplicationInfo.

CoApplicant.

LastName

Secondary Applicant Last

Name

Text

SMT SurchargeAmount Surcharge Amount Number

sPH ApplicationInfo.

CoApplicant.

WorkPhoneNUmber

Secondary Applicant Work

Phone Number

Number

SPN ApplicationInfo.

CoApplicant.

HomePhoneNUmber

Secondary Phone Number Number

SRS ApplicationInfo.

CoApplicant.

HousingFlag

Secondary Housing Info Text

sSN ApplicationInfo.

CoApplicant.

SSN

Secondary SSN Number

SST ApplicationInfo.

CoApplicant.

State

Secondary Applicant State of

Residence

Text

StE IdentificationState State code Text

STA ApplicationInfo.

CoApplicant.

TimeAtResidence

Secondary Applicant Time at

Address

Text

STC ShippingCountry Ship-To Country Code Text

STE IdentificationState State Code Text

STG ApplicationInfo.

Applicant.

State

State Code Text

STJ ApplicationInfo.

CoApplicant.

TimeAtJob

Secondary Applicant Time at

Job

Text

SUM ReportSummaryIndicator Summary only? (y/n/s/d) Text

SVI StoredValueIndicator Stored Value Card Indicator Text

SZP ApplicationInfo.

CoApplicant.

PostalCode

Secondary Applicant ZIP Code Text

TDT AccountInfo.

Track1 or

Track2

Track data Text

Field Definitions



Page 105 of 119


TDY TenderType Tender Type Text

TIP RestaurantInfo.

TipAmount

Tip Amount $Amount

TOI TypeOfIndustry Type of Industry Text

TOP ProcessingTypeIndicator Type of Processing for GE

private label transactions: E =

Easy LID, M = Manufacturer

Text

TTI PurchaseInfo.

PurchaseItems.

LineItem.

TaxTypeIdentifier

Tax Type Identifier Text

TXD HostTransactionID Transaction ID Text

TXI TaxAmountIndicator Tax Amount Indicator (0 = tax

not provided, 1 = tax included,

2 = tax exempt)

Text

UOM PurchaseInfo.

PurchaseItems.

LineItem.

ItemUnitOfMeasure

Unit of Measure Text

UPR PurchaseInfo.

PurchaseItems.

LineItem.

ItemUnitCost

Unit Price $Amount

UR1 UserField1 User Field 1 for First Data Gift

Card transactions

Text

UR2 UserField2 User 2 for First Data Gift Card

transactions

Text

Vat PurchaseInfo.

VatTaxAmount

VAT / Tax Amount $Amount

VPW VisaPaywave Visa Paywave taginfo Text

VtR PurchaseInfo.

VatTaxRate

Summary VAT / Tax Rate for a

purchasing card transaction

Number

VT2 PurchaseInfo.

PurchaseItems.

LineItem.

ItemTaxRate

VAT / Tax Rate for an

individual line item within a

purchasing card transaction.

Number

VT5 PurchaseInfo.

PurchaseItems.

LineItem.

TaxRate

VAT / Tax Rate for an

individual line item within a

purchasing card transaction.

Number

Zip PurchaseInfo.

ShippingPostalCode

Destination ZIP Code Text

ZIP BillingPostalCode ZIP Code Text

ZP2 ApplicationInfo.

Applicant.

PostalCode

ZIP Code Number

Field Definitions



Page 106 of 119


NOTE: Refer to the Transaction Builder utility in your SDK software for your

processor-specific field requirements and for maximum and minimum lengths.

Report Transaction Types



Page 107 of 119

Appendix C – Report Transaction Types

Table 11 Table 11 describes the different types of report transactions available within

the ICVERIFY® application.

Mail Order

Charge Card

Types

Retail Charge

Card Types

Food Charge

Card Types

Hotel / Lodging

Charge Card

Types

Book B Sale S Authorization A Check-in I

Ship S Void Sale V Add Tips T

(force)

Check-out O

Sale S Credit/Return C

or R

Sale S Extended Stay E

Void Sale V Credit Void V Void Sale V No-show N

Credit/Return C or

R

Pre-Auth/

AuthOnly P

Credit/ Return C

or R

Sale S

Credit Void V Force Sale F Credit Void V Void Sale V

Pre-Auth/

AuthOnly P Pre-Auth/

AuthOnly P

Credit/Return C or

R

Force Sale F Force Sale F Credit Void V

Pre-Auth/ AuthOnly

P

Force Sale F

Glossary



Page 108 of 119

Appendix D – Glossary

Glossary of

Terms

It takes time to learn to use a new technology. This glossary will help you

understand unfamiliar terms used in this manual, and make your learning

process easier.

Term Description

ABA (American

Bankers

Association)

Routing Number

Unique bank identifying number that directs electronic ACH deposits to

the proper bank—this number precedes the account number printed at

the bottom of a check. This number is usually printed with magnetic ink.

Account number A unique sequence of numbers assigned to a cardholder account,

which identifies the issuer and type of financial transaction card.

ACH A method of transferring funds between banks via the Federal Reserve

System. ACH is used by most, but not all, financial institutions.

Acquirer See acquiring financial institution.

Acquiring financial

institution

A financial institution enables the merchant to accept credit card

transactions. Merchants must maintain accounts with an acquiring

financial institution to be able to process credit card transactions.

The acquiring financial institution deposits the daily credit card sales into

the merchant‘s account, minus applicable fees.

Address

Verification

Service (AVS)

See AVS.

Agent bank A bank that participates in another bank's card program, usually by

turning over its applicants for bankcards to the bank administering the

bankcard program and by acting as a depository for merchants.

Approval An acceptance of payment—a code is issued by a card-issuing bank

allowing a sale to be charged against a cardholder‘s account.

The amount is within the cardholder‘s remaining credit limit and that the

card has not been reported lost or stolen. Approvals are requested via

an authorization.

American Express® An organization that issues cards and acquires transactions (unlike Visa®

and MasterCard®, which are bank associations).

Glossary



Page 109 of 119

Term Description

Arbitration The procedure used to determine the responsibility for a Chargeback-

related dispute between two member banks. See Chargeback.

Asynchronous A method of transmitting data in which the data elements are identified

with special start and stop characters. An asynchronous modem cannot

communicate with a synchronous modem. Contrast synchronous.

Auth file See transaction file.

Auth only See Terminal Capture.

Automated

Clearing House

See ACH.

Authorization A process by which a financial institution approves a cardholder

transaction and provides an authorization code. When an authorization

is successful, a marker is placed against a portion of the card account‘s

credit limit to cover the cost of the potential purchase.

The code is used as proof of authorization. See authorization code.

Authorization

code

An alphanumeric value returned from the processor for successful

transactions. If a transaction fails authorization, an authorization code is

not returned from the processor.

Average ticket The average dollar amount of merchant credit transactions.

AVS (Address

Verification

Service)

AVS matches the first five digits of the street address and the ZIP code

information from the cardholder‘s collected billing address to the

corresponding bill information on record with the card issuers. A code

representing the level of match is returned.

AVS codes cannot be obtained independent of an authorization, and

it‘s up to the merchant to decide whether to fulfill an order.

If the AVS code fails, the authorization will not fail. For Terminal Capture

merchants, the authorization will be returned successfully.

For Host Capture (AuthCapture and Auth/PostAuth) merchants, the

authorization will be downgraded to an auth. The downgraded

authorization must then be manually settled.

Bank Identification

Number

The digits of a credit card that identify the issuing bank. The first six digits

of a card number are often referred to as a BIN.

Basis Point One one-hundredth of a percent. Discount rates are expressed as basis

points.

Glossary



Page 110 of 119

Term Description

Batch A collection of transactions. Usually a merchant has one batch per day

or per shift.

Batch processing A type of data processing where related transactions are transmitted as

a group for processing.

BIN See Bank Identification Number.

Bundled rate

A discount rate that includes communications costs as well as

transaction fees. Also referred to as flat rate.

Cancellation

number

A number provided by a resort, hotel or motel to verify a cardholder's

notification to cancel a guaranteed reservation or advance deposit.

Capture A process in which a credit card sale or return transaction is submitted for

financial settlement. Authorized credit card sales must be captured and

settled for a merchant to receive the funds. See settlement.

Card issuer See issuing financial institution.

Chargeback

The act of taking back funds (for a disputed or improper credit card

transaction) that have been paid to a merchant.

This procedure is initiated by the issuer after the acquirer has begun the

clearing process.

Chargeback

period

The number of calendar days in which an issuer may charge sales back

to the merchant, beginning the day after the date the record is first

received by the merchant or bank, and continuing until the end of the

day on which it‘s dispatched as a Chargeback item.

Chargeback

reason code

A two-digit code identifying the specific reason for the Chargeback.

Check guarantee

A service which guarantees check payment (up to the limit defined for

the account) provided that the merchant follows correct procedures in

accepting the check. The service determines whether the check writer

has previously written delinquent checks.

Clearing The process of exchanging financial details between an acquirer and an

issuer to facilitate posting of a cardholder's account and reconciliation of

a customer's settlement position.

Close batch The process by which transactions with authorization codes are sent to

the processor for payment to the merchant.

Glossary



Page 111 of 119

Term Description

Confirmation letter A letter sent by a processor to a merchant at a specified interval to verify

batch deposits.

Copy request See retrieval request.

Credit A return of funds to a cardholder's account (crediting entry) for a sale

that has already been authorized and settled.

Custom Payment

Services (CPS)

CPS regulations require additional customer information to be sent from

the merchant to the credit card processor, increasing security of the

transaction.

CPS compliant transactions receive the best possible transaction rates.

CID Card Identification. Only for American Express®, Discover®, JCB/Discover

and Diners/Discover cards

CVC2 Card Verification Code 2. Only for MasterCard®.

CVV Indicator Indicates the presence of CVV2/CVC2/CID for the manually entered

transactions for Visa®, Master Card®, American Express®,

Diners/Discover, JCB/Discover & Discover® credit cards. The indicator

has four values:

Present

Not Present

Bypass

Illegible

Depending on the value selected, the CVV field gets enabled or

disabled.

CVV2 Credit Card Verification Value Version 2. Only for Visa® cards.

DDA (Demand

Deposit Account)

A bank account, such as a checking account, that allows the holder to

withdraw funds or use funds for payment upon demand.

Debit card An ATM bankcard used to purchase goods and services and to obtain

cash, which debits the cardholder's personal deposit account.

Requires a Personal Identification Number (PIN) for use.

Decline A response to a transaction request meaning that the issuing bank will

not authorize the transaction. A decline message is accompanied by

the error code from the Processing Network. Each Processing Network

has its own set of error codes, so the format of the error response will vary

according to the Processing Network that the merchant has been

Glossary



Page 112 of 119

Term Description

configured to use.

If transactions are declined with a Call Center or Voice Auth message,

this usually indicates that the merchant needs to call the Processing

Network to obtain an approval code for the transaction.

This approval code can then be used by the merchant to complete the

transaction using a Force/Ticket Only/Post Authorization transaction.

Deferred Billing Deferred Billing refers to payments that can be made on a later date.

This is a Promotional venture that merchants offer to their customers.

Deferred Time

Period

Deferred Time Period refers to the time period (in months) for which the

payment will be deferred.

Deferred Number

of Payments

Deferred Number of Payments refers to the number of months in which

the entire sum will be divided and paid with or without interest charged

to the card-holder. This payment may also be made after the Deferred

Time Period has lapsed.

Deferred Payment

Plan

Deferred Payment Plan (supported by FDMS South PROSA Platform) refers

to the different deferred payment modes for which a transaction can be

configured. Currently three such plans will be supported:

Deposit The aggregate of sales records and refunds submitted to a bank

processor for processing.

Deposit bank The bank into which merchant deposits funds from credit card

transactions.

Discount rate The percentage of credit card sales amounts the acquiring financial

institution charges the merchant for the settlement of the transaction.

Draft capture Refers to settlement.

DUKPT PINpad A Derived Unique Key Per Transaction (DUKPT) PINpad is used if you want

to process debit card transactions. DUKPT PINpads have already been

properly encrypted by your Processor or Merchant bank with the

Processor‘s configuration and key injection.

ECI Electronic Commerce Indicators.

Electronic Cash

Register (ECR)

The combination of a cash register and a point-of-sale (POS) terminal,

often PC-based.

Electronic Draft

Capture (EDC)

A system in which each transaction is routed to the host computer for

processing and storage. The stored transactions are used to create

settlement files and transaction reports.

Electronic Funds

Transfer (EFT)

A method of incrementing or decrementing an account through

electronic means, eliminating the need for paper checks or withdrawal

Glossary



Page 113 of 119

Term Description

slips.

Encrypt To scramble a message so that a key, held only by authorized recipients

is needed to unscramble and read the message. When the encrypted

data is routed through a gateway, it‘s decrypted and processed.

All processed information (approved/declined transactions) is then re-

encrypted and sent securely back to the merchant's web site. Once at

the web server, it‘s decrypted and displayed to the consumer. See

decrypt.

External Sales

Agent (ESA)

A term used by American Express® for Independent Sales Organizations

(ISOs) and MSPs.

Floor limit Rarely used now, this was a preset limit established by an issuer that

allowed merchants to accept credit card sales without authorization

provided the merchant check to see that the card number was not listed

on a Warning Bulletin for lost or stolen cards.

Force A transaction type used primarily to enter a voice approved sale

transaction into an open batch. For example, a merchant submits a

card for approval gets a ―voice authorization‖ message and calls the

merchant help desk for a voice authorization.

The merchant help desk gives the merchant an approval code for the

transaction over the phone. The merchant can then enter the

transaction into the open batch using a force transaction and the

approval code provided by the merchant help desk. A force can also

be used to complete a Terminal Capture transaction.

Host Capture A processing model by which payment information is stored at the

processor rather than the software. This processing model consists of two

methods for authorizing and capturing transactions: AuthCapture and

Auth/PostAuth. See AuthCapture and Auth/PostAuth.

Host computer Refers to the computer at the processor that is dialed for authorization

and settlement.

Imprint A form of proof that the credit card was present for the transaction. It

can be electronic (by swiping a card through a card reader) or manual

(by obtaining a physical imprint using an imprinter), but one of the two

ways is always required for card-present transactions.

Independent Sales

Organization (ISO)

See ISO.

Interchange The flow of information between issuers and acquirers (for example,

transactions, retrieval requests, and chargebacks).

Glossary



Page 114 of 119

Term Description

Interchange fee The fee that the merchant‘s bank pays the consumer‘s bank for each

credit card transaction that is settled.

ISO A Visa® term for a company that is sponsored by an acquiring bank to

solicit, and sometimes support, merchants.

Issuing Providing a bankcard to a cardholder and authorizing that person to use

it to complete financial transactions.

Issuing financial

institution

The financial institution that extends credit to a consumer through credit

card accounts. The financial institution issues a credit card and bills the

consumer for purchases against the credit card account. Also referred

to as the cardholder‘s financial institution or issuer.

Keyed entry See manual entry.

Local review The ability for a merchant to review, from his or her terminal, the contents

of a batch before or after settlement.

Magnetic Ink

Check Reader

(MICR)

A device that reads characters (i.e. account information) printed on a

check with ink containing particles of a magnetic material.

MAG stripe See magnetic stripe.

Magnetic stripe A stripe on the back of a bankcard that contains magnetically encoded

cardholder account information. The name of the cardholder is stored

on Track I, the account number and expiration date are stored on Track

II. Also referred to as MAG stripe.

Manual entry Credit card information that is entered via terminal keypad or keyboard

instead of swiping the card through a card reader.

MasterCard An association of banks that governs the issuing and acquiring of

MasterCard credit card transactions and Maestro debit transactions.

Member A financial institution that is a member of Visa® USA and/or MasterCard®

International. A member is licensed to issue cards to holders and/or

accept merchant drafts.

Member Service

Provider

MasterCard® term for a company that is sponsored by an acquiring bank

to solicit and sometimes support merchants.

Merchant A retailer, or any other entity (pursuant to a merchant agreement), that

agrees to accept credit cards, debit cards, or both, when properly

presented.

Glossary



Page 115 of 119

Term Description

Merchant

agreement

A written agreement between a merchant and a bank (or possibly a

merchant, a bank, and ISO) containing their respective rights, duties, and

warranties with respect to acceptance of the bankcard and matters

related to bankcard activity.

Merchant bank A bank that has entered into an agreement with a merchant to process

bank card transactions. Also referred to as acquirer or acquiring bank.

Merchant

category code

See SIC code.

Merchant

Identification

Number (MID)

A unique number that identifies a merchant.

Merit The qualification levels for a MasterCard transaction. Merit III is the

highest discount, followed by Merit II, Merit I, and then Standard.

MID See Merchant Identification Number.

MICR See Magnetic Ink Check Reader.

Modem MOdulator / DEModulator. An electronic telecommunications hardware

device that is used by the terminal or PC POS to dialup the processor.

MOTO Mail Order/Telephone Order.

MSP See Member Service Provider.

Multi-trans mode A host computer that allows multiple transactions with the same

telephone call.

Net settlement

bank

The bank that maintains the settlement account and that executes funds

transfers with member clearing banks.

Network The setup of hardware and software that allows multiple computers to

connect and communicate with each other electronically or through

the use of fiber optics.

Network

Reference

Identifier (NRID)

A unique 15 digit numeric value assigned by the Discover Network and

returned in Authorization Response for each Discover transaction

authorized through FDMS South Platform

Node One of the many points connected together to form a network. The

terminal dials the closest node and becomes connected to a

nationwide telecommunications network.

Non-qualified A broad term that describes a transaction that did not interchange at

the best rate because it was entered manually or it was not settled in a

timely manner.

Glossary



Page 116 of 119

Term Description

Offline An operating mode in which the software or service is not connected to

the processor in real time. This mode is often used when a merchant is

batch-processing transactions.

Online inquiry Some processors offer PC inquiry to the host system to view transactions,

Chargebacks, and so on.

Open to buy The amount of credit available at a given time on a cardholder's

account.

Original draft The original copy of the forms and signature used in the transaction. Also

referred to as hard copy.

Packet-switched

network

A nationwide network of circuits that allow a computer to dial a local

number and communicate with another computer also on the network,

such as the Internet.

Partial

Authorization

A Partial Authorization is one where the host returns approval on a part of

the total transaction amount and the card holder has to pay the

balance amount by other means.

PC POS

application

A computer program that integrates two or more of the following

functions: cash register, inventory, accounting, and credit card

authorization and settlement.

Personal

Identification

Number (PIN)

See PIN.

PIN A personal identification number, typically a short alphanumeric

character string, used as a password to gain access to bank or credit

accounts. A PIN is usually required when performing financial

transactions using a debit or credit card.

Point of Sale (POS) The place and time at which a transaction occurs. This term also refers to

the devices or software used to capture transactions.

POS See Point of Sale.

Post-Authorization A transaction that has been submitted for completion and has

completed a payment.

Posting The process of recording debits and credits to individual cardholder

account balances.

Pre-Authorization See Auth only.

Glossary



Page 117 of 119

Term Description

Prestigious

properties

A $500, $1000 or $1500 floor limit at designated hotels/resorts. Floor limit‘s

returned as part of authorization response.

Prior authorized

sale

A transaction for which authorization was obtained at an earlier time (for

example, a merchant had to call for authorization or a merchant

authorized the card before services were rendered). See Terminal

Capture.

Private label card A bankcard that can be used only in a specific merchant's store.

Typically not a bankcard.

Processor A transaction processor; a large computer center that processes data

from credit card transactions and settles funds to merchants.

PSIRF The highest qualification that a Visa® transaction can obtain. Card must

be swiped and transaction deposited within 24 hours.

Qualification A level at which a transaction interchanges. The level of qualification is

dependent on how credit card number is entered, how quickly a

transaction is settled, type of industry, specific information, and so on.

Receipt A hard copy description of the transaction that occurred at the point of

sale. Minimum information contained on a receipt is: date, merchant

name and location, account number, type of account used (for

example, Visa®, MasterCard®, American Express®, and so on), amount,

reference number and/or authorization number, and action code.

Recurring

transaction

A transaction that is periodically charged to the cardholder‘s account,

such as a subscription fee. The merchant must get permission from the

cardholder to do this.

Reference

number

A code given to a transaction by Host Capture processors.

Release The merchant instructs the software to close a batch. This applies only to

the Host Capture processing model.

Cardholders are not charged (or merchant accounts credited) until a

batch is released. Compare deposit.

Retrieval request A request to a merchant for documentation concerning a transaction,

usually a Cardholder dispute or suspicious sale/return. A retrieval request

can lead to a Chargeback.

Settle See settlement.

Settlement A process in which a credit card transaction is settled financially

Glossary



Page 118 of 119

Term Description

between the merchant‘s acquiring financial institution and the

consumer‘s credit card issuing financial institution.

The merchant‘s processor credits his or her account for the credit card

sale and the sale is posted to the consumer‘s credit card account. See

capture.

SIC (Standard

Industry

Classification)

code

A four-digit code assigned to a merchant to identify that merchant‘s

principal line of business.

SKU Data A pair of elements identifying a particular inventory item. SKU Data

contain 2 entries:

SKU code/value

Corresponding dollar amount for this SKU

A maximum of 7 SKU data can be entered per transaction.

Slid entry See swiped card. Compare manual entry.

Standard The lowest qualification level at which a Visa® or MasterCard® transaction

may interchange. Caused when a transaction is deposited several days

after the original authorization and not swiped.

Stripe read See swiped card.

Surcharges Any additional charges to a merchant's standard processing fees. They

are a result of non-qualified transactions of different communications

methods.

Suspense A state in which a batch of transactions is not released to interchange

because of problem noticed by the host computer.

This state requires human intervention to fix the problem and settle the

batch.

Swiped card Credit card information that is read into ICVERIFY® directly as a result of

swiping (or sliding) the credit card through a card reader.

The information magnetically encoded in the magnetic stripe is

transmitted. This information includes secret data that helps validate the

card. Compare manual entry.

Synchronous A method of transmitting data in which the data elements are sent at a

specific rate so that start and stop characters are not needed. This is

used by older modems. Contrast asynchronous.

Glossary



Page 119 of 119

Term Description

Travel and

Entertainment

(T&E) Card

Credit cards that typically require payment in full each month (for

example, American Express®, Diner‘s Club®, and Carte Blanche®).

Terminal Capture A processing model by which payments are authorized immediately and

stored in a batch file. Batch files are sent by the merchant to the

processor for settlement. Also referred to as Auth Only.

Third-party

processor

A non-member agent employed by an acquiring bank, which provides

authorization, settlement and merchant services to a merchant.

Ticket only A sale transaction for which you have received a voice authorization.

Transaction A financial interaction that changes the financial position of the parties

involved. The Cash Register recognizes several types of transactions:

invoiced, authorized, and post-authorized transactions; returns, voids,

and voided returns; payment transactions and refund transactions.

See authorized transaction, refund, return, void, and voided return.

Transaction fee A ―per transaction‖ charge incurred by merchants who are on scale

pricing. This is in addition to the percentage discount fees.

Transaction file A file created by processors that contain all of the transactions for the

previous day. Some processors create two files, one of authorizations

and one of settled transactions.

Vendor file See transaction file.

Visa® An association of banks that governs the issuing and acquiring of Visa®

credit card transactions.

Voice

authorization

A transaction authorization that is provided by an operator, usually when

an issuer sends a ―Please Call‖ message to the merchant instead of an

authorization number.

Void A correction transaction used by a merchant. There is only a small

period of time in which a purchase can be canceled. Voids are typically

handled by issuing credit to the consumer‘s account. A void is

transaction specific, and must be entered in the same batch as the

original purchase.

Documents

ICVERIFY for Windows - First Data - Global Selector 2 – Overview ... In addition to transaction processing, ... Store up to nine years of transaction information for financial tracking,