ICVERIFY for Windows Version 4.2 Software Developer s Kit Guide

Transcription

1 ICVERIFY for Windows Version 4.2 Software Developer s Kit Guide 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 South Quebec Street Suite 350 Greenwood Village, CO USA For Sales and Product Information, call: (800) For Technical Support, call: (800)

2 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 CARD VERIFICATION VALUES (CVV2 / CVC2 / CID) CVV Indicator CHAPTER 4 INDUSTRY TRANSACTIONS OVERVIEW RETAIL TRANSACTIONS Sale Void Credit / Refund / Return Credit Void / Cancel Return / Refund Void Auth Only / Pre-Authorization Force / Post-Authorization Cash Advance HANDLING RETAIL TRANSACTIONS SAMPLE TRANSACTIONS Sale Example Void Example Credit / Refund / Return Example Credit Void / Cancel Return / Refund Void Example Auth Only / Pre-Authorization Example Force / Post-Authorization Example Balance Inquiry Example Cash Advance Example CARD-SWIPED TRANSACTIONS Swiped Transaction Support in Request-String Mode Extracting printed card number from track data for FDMS Gift cards Swiped Transaction Support in XML Mode Sale Transaction with Track 1 Data Only Sale Transaction with Track 2 Data Only Sale Transaction with Both Track 1 and Track 2 Data... 29

3 ICVERIFY 4.0 SDK Guide MOTO (MAIL ORDER / TELEPHONE ORDER) TRANSACTIONS Book Ship Processing Book and Ship Transactions EMV TRANSACTIONS HOTEL TRANSACTIONS Check-In Add Charges Extend Stay Check-Out No Show LEVEL III PURCHASING CARDS Level III Record Formats Request-String Mode Level III Record Formats XML Mode DEBIT CARD TRANSACTIONS Processing Debit Card Transactions Debit Transaction Types Debit Transaction Request Format Debit Transaction Support by Processor PROCESSING TRANSACTIONS FOR MULTIPLE MERCHANTS CHAPTER 5 REQUESTS AND RESPONSES OVERVIEW Request Files TRANSACTION RESPONSES Transaction Responses in Request-String Mode Transaction Responses in XML Mode XML Response Fields PROCESSING OFFLINE GROUP INPUT OR REQUEST FILES INTERPRETING RESULTS TOKENIZATION AND ENCRYPTION CAPABILITY ON FDMS CARDNET CHAPTER 6 REPORTS OVERVIEW DETAIL REPORTS Detail Report Format Detail Report Fields Additional Fields Credit Card Summary Information Visa & MasterCard Section American Express Section Not Captured or Authorized Transactions Authorized Transaction Section POST-SETTLEMENT REPORTS Credit Card Section Authorized Only Transaction Section CHAPTER 7 TUTORIALS OVERVIEW WINDOWS VISUAL BASIC INTEGRATION TUTORIAL Using the Direct DLL Interface Using the Request-Answer Interface SAMPLE CODE PROGRAM FLOW Code Program Flow Procedures APPENDIX A RESPONSE CODES... 94

4 ICVERIFY 4.0 SDK Guide OVERVIEW Address Verification Result Codes Card Verification Result Codes Response Code Values APPENDIX B FIELD DEFINITIONS APPENDIX C REPORT TRANSACTION TYPES APPENDIX D GLOSSARY GLOSSARY OF TERMS

5 Introduction to ICVERIFY for Windows 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. Page 1 of 119

6 Introduction to ICVERIFY for Windows Getting Help The following is a list of the available Help features provided to assist you: 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) for Customer Service assistance, or send to the following address: [email protected] Page 2 of 119

7 Overview 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. Page 3 of 119

8 Overview 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 Page 4 of 119

9 Overview 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 positionsensitive, 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. Page 5 of 119

10 The Bankcard Industry 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 ISSUING BANK CARD PROCESSING NETWORK ACQUIRING BANK // ISO ISO VISA MasterCard 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 6 of 119

11 The Bankcard Industry 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 7 of 119

12 The Bankcard Industry Host-based vs. Terminalbased 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 8 of 119

13 The Bankcard Industry 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 9 of 119

14 The Bankcard Industry Understanding 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 signaturebased 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 10 of 119

15 The Bankcard Industry 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 11 of 119

16 The Bankcard Industry 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 Page 12 of 119

17 Chapter 4 Industry Transactions 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 autosettle), 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 13 of 119

18 Industry Transactions 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 14 of 119

19 Industry Transactions 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 15 of 119

20 Industry Transactions Table 1 Retail Transaction Fields Field Leading Field / Transaction Type Description 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 16 of 119

21 Field Description Industry Transactions 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. Account Number 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. 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 17 of 119

22 Industry Transactions Field Expiration Date Description 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 18 of 119

23 Industry Transactions Field Transaction Amount Description 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 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 19 of 119

24 Industry Transactions Sample Transactions Sale Example XML Mode Void Example 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. "C1","Clerk","Comment"," ","0612", "1.00","12345","123 MAIN ST" <Request> <CreditCardCharge> <ClerkID>Clerk</ClerkID> <Comment>Comment</Comment> <AccountInfo> <AccountNumber> </AccountNumber> </AccountInfo> <ExpirationInfo> <ExpirationMonth>12</ExpirationMonth> <ExpirationYear>06</ExpirationYear> </ExpirationInfo> <TransactionAmount>1.00</TransactionAmount> <BillingPostalCode>12345</BillingPostalCode> <BillingAddress>123 MAIN ST</BillingAddress> </CreditCardCharge> </Request> "C2","Clerk","Comment"," ","0612", "1.00","","" XML Mode <Request> <CreditCardVoid> <ClerkID>Clerk</ClerkID> <Comment>Comment</Comment> <AccountInfo> <AccountNumber> </AccountNumber> </AccountInfo> <ExpirationInfo> <ExpirationMonth>12</ExpirationMonth> <ExpirationYear>06</ExpirationYear> </ExpirationInfo> <TransactionAmount>1.00</TransactionAmount> </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 20 of 119

25 Industry Transactions Credit / Refund / Return Example "C3","Clerk","Comment"," ","0612", "1.00","","" XML Mode Credit Void / Cancel Return / Refund Void Example <Request> <CreditCardCredit> <ClerkID>Clerk</ClerkID> <Comment>Comment</Comment> <AccountInfo> <AccountNumber> </AccountNumber> </AccountInfo> <ExpirationInfo> <ExpirationMonth>12</ExpirationMonth> <ExpirationYear>06</ExpirationYear> </ExpirationInfo> <TransactionAmount>1.00</TransactionAmount> </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. "CR","Clerk","Comment"," ","0612", "1.00","","" XML Mode <Request> <CreditCardVoidCredit> <ClerkID>Clerk</ClerkID> <Comment>Comment</Comment> <AccountInfo> <AccountNumber> </AccountNumber> </AccountInfo> <ExpirationInfo> <ExpirationMonth>12</ExpirationMonth> <ExpirationYear>06</ExpirationYear> </ExpirationInfo> <TransactionAmount>1.00</TransactionAmount> </CreditCardVoidCredit> </Request> The example above is a Credit Void/Cancel Return/Refund Void transaction. This transaction is used to void Credit transactions. Page 21 of 119

26 Industry Transactions Auth Only / Pre- Authorization Example "C6","Clerk","Comment"," ","0612", "1.00","12345","123 MAIN ST" XML Mode <Request> <CreditCardAuthorize> <ClerkID>Clerk</ClerkID> <Comment>Comment</Comment> <AccountInfo> <AccountNumber> </AccountNumber> </AccountInfo> <ExpirationInfo> <ExpirationMonth>12</ExpirationMonth> <ExpirationYear>06</ExpirationYear> </ExpirationInfo> <TransactionAmount>1.00</TransactionAmount> <BillingPostalCode>12345</BillingPostalCode> <BillingAddress>123 MAIN ST</BillingAddress> </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"," ","0612","1.00", "APV","12345","123 MAIN ST" XML Mode <Request> <CreditCardCapture> <ClerkID>Clerk</ClerkID> <Comment>Comment</Comment> <AccountInfo> <AccountNumber> </AccountNumber> </AccountInfo> <ExpirationInfo> <ExpirationMonth>12</ExpirationMonth> <ExpirationYear>06</ExpirationYear> </ExpirationInfo> <TransactionAmount>1.00</TransactionAmount> <ApprovalNumber>APV</ApprovalNumber> <BillingPostalCode>12345</BillingPostalCode> <BillingAddress>123 MAIN ST</BillingAddress> </CreditCardCapture> </Request> Page 22 of 119

27 Industry Transactions 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"," ","0612","1.23", "","" XML Mode <Request> <CreditCardBalanceInquiry> <ClerkID>Clerk</ClerkID> <Comment>Comment</Comment> <AccountInfo> <AccountNumber> </AccountNumber> </AccountInfo> <ExpirationInfo> <ExpirationMonth>12</ExpirationMonth> <ExpirationYear>06</ExpirationYear> </ExpirationInfo> <TransactionAmount>1.23</TransactionAmount> </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"," ","0612","1.23", "","" Page 23 of 119

28 Industry Transactions XML Mode <Request> <CreditCardCashAdvance> <ClerkID>Clerk</ClerkID> <Comment>Comment</Comment> <AccountInfo> <AccountNumber> </AccountNumber> </AccountInfo> <ExpirationInfo> <ExpirationMonth>12</ExpirationMonth> <ExpirationYear>06</ExpirationYear> </ExpirationInfo> <TransactionAmount>1.23</TransactionAmount> </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"," ", "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 24 of 119

29 Industry Transactions 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: "0412B ^JANEDOE^ ?; = ?" 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: "0412B ^JANE DOE^ ?" 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: " = ?" 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 25 of 119

30 Industry Transactions 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: ; = ? Bin Number: Partial Account Number (B): 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 26 of 119

31 Industry Transactions 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 ; = ? Page 27 of 119

32 Swiped Transaction Support in XML Mode Industry Transactions The implementation of swiped transaction support is somewhat cleaner in XML mode. AccountInfo node contains three subelements: AccountNumber Track1 Track2 The 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"," ","0512B ^JANE DOE^ ?","1.00" XML Mode <Request> <CreditCardCharge> <ClerkID>CLERK1</ClerkID> <Comment>COMMENT2</Comment> <AccountInfo> <Track1>B ^JANE DOE^ ?</Track1> </AccountInfo> <TransactionAmount>1.00</TransactionAmount> </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"," "," = ?""1.00" Page 28 of 119

33 Industry Transactions XML Mode <Request> <CreditCardCharge> <ClerkID>CLERK1</ClerkID> <Comment>COMMENT2</Comment> <AccountInfo> <Track2> = ?</Track2> </AccountInfo> <TransactionAmount>1.00</TransactionAmount> </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"," ","0412B ^JANEDOE^ ?; = ?"," 1.00" XML Mode <Request> <CreditCardCharge> <ClerkID>CLERK1</ClerkID> <Comment>COMMENT2</Comment> <AccountInfo> <Track1>B ^JANE DOE^ ?</Track1> <Track2> = ?</Track2> </AccountInfo> <TransactionAmount>1.00</TransactionAmount> </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 29 of 119

34 Industry Transactions 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 Leading Field / Transaction Type Description 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 30 of 119

35 Industry Transactions Field CVV2 / CVC2 / CID number Description 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). NOTE: This field is optional. 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 31 of 119

36 Industry Transactions Field Expiration Date Description 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. Amount Billing Postal Code / ZIP Code 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. Contains the amount of the sale. Decimal points are not required, but recommended. This field is required. 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 32 of 119

37 Industry Transactions Field Billing Address Description 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"," ","0912","1.00","ZIP", "Address" Page 33 of 119

38 Industry Transactions Book Sample XML Mode Ship Sample XML Mode <Request> <CreditCardBook> <ClerkID>Clerk</ClerkID> <Comment>Comment</Comment> <AccountInfo> <AccountNumber> </AccountNumber> </AccountInfo> <ExpirationInfo> <ExpirationMonth>12</ExpirationMonth> <ExpirationYear>09</ExpirationYear> </ExpirationInfo> <TransactionAmount>1.00</TransactionAmount> <BillingPostalCode>12345</BillingPostalCode> <BillingAddress>123 MAIN ST</BillingAddress> <CardVerificationValue>123</CardVerificationValue> </CreditCardBook> </Request> <Request> <CreditCardShip> <ClerkID>Clerk</ClerkID> <Comment>Comment</Comment> <AccountInfo> <AccountNumber> </AccountNumber> </AccountInfo> <ExpirationInfo> <ExpirationMonth>12</ExpirationMonth> <ExpirationYear>09</ExpirationYear> </ExpirationInfo> <TransactionAmount>1.00</TransactionAmount> <BillingPostalCode>12345</BillingPostalCode> <BillingAddress>123 MAIN ST</BillingAddress> </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 34 of 119

39 Industry Transactions Chip Transaction Structure Request-String Mode "C1","Clerk","Comment"," "," = ?","1.00","12345","Address","","","","","","","9F <GS>9F2608E6E8EDBE9F3EB5FE<GS> < GS>9F C<GS>5F340100<GS>9F <GS>9F <GS>9F270180<GS>8407A <GS>9F A5000F FF<GS>9F <GS>9F3303E0B0C8<GS>9F1A <GS>9F1E <GS>9A <GS>9F350122<GS> <GS>5F2A020840<GS>9F <GS>9C0100<GS>9F37040 C99FDE0<GS>5A <GS>Y","A ","Master Card","0" Page 35 of 119

40 Industry Transactions Chip Transaction Structure XML Mode <Request> <CreditCardCharge>Clerk</ClerkID><Comment>Comment</Comm ent><accountinfo><accountnumber> </accountn umber><accountinfo><accountnumber></accountnumber><track1 ></Track1><Track2> = ?</Track2 ></AccountInfo><ExpirationInfo><ExpirationYear>09</ExpirationYear> <ExpirationMonth>12</ExpirationMonth></ExpirationInfo><Transaction Amount>1.00</TransactionAmount><CardVerificationFlag></CardVer ificationflag><cardverificationvalue></cardverificationvalue><emv TagInfo>9F <GS>9F2608E6E8EDBE9F3EB5FE<GS> <GS>9F C<GS>5F340100<GS>9F <GS>9F <GS>9F270180<GS>8407A <GS>9F A5000F FF<GS>9F <GS>9F3303E0B0 C8<GS>9F1A020999<GS>9F1E <GS>9A < GS>9F350122<GS> <GS>5F2A020840<GS>9F <GS>9C0100<GS>9F37040C99FDE0<GS>5A <G S>Y</EMVTagInfo><ApplicationID>A </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 36 of 119

41 Industry Transactions Visa Paywave transaction structure Request-String Mode "C1","sysadmin",""," ","1210B ^CARD M/VISA^ ?; = ","35.00","12345","Address","","","","","","Y","","","","","","9F F092E57607<GS>9F D<GS>9F7C1B B50524F <GS>9F <GS>9F6E <GS>9F A00000<GS>9F " Visa Paywave transaction structure XML Mode <Request><CreditCardCharge><ClerkID>swarnendu</ClerkID><Comment></Co mment><accountinfo><accountnumber> </accountnumber> <Track1>B ^CARD M/VISA^ ?</Track1><Track2> = ?</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>9f f092e57607<gs>9f d<gs>9f7c1b B50524F <GS>9F < GS>9F6E <GS>9F A00000<GS>9F </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 37 of 119

42 Industry Transactions 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 Check-In Transaction Structure Request-String Mode 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. "C4","CMc","CMI","ACT","EXP","AMT","CmR","cmR","CMN","CMA", "CMD","Cmr","CmP","CME","Cme" Page 38 of 119

43 Industry Transactions Check-In Transaction Structure XML Mode <Request> <CreditCardBook> <ClerkID></ClerkID> <AccountInfo> <AccountNumber></AccountNumber> </AccountInfo> <ExpirationInfo> <ExpirationMonth></ExpirationMonth> <ExpirationYear></ExpirationYear> </ExpirationInfo> <BillingAddress></BillingAddress> <BillingPostalCode></BillingPostalCode> <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 39 of 119

44 Industry Transactions Add Charges Add Charges Transaction Structure Request-String Mode 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. "CG","CMc","CMI","ACT","EXP","AMT","CmR","cmR","CMN","CMA", "CMD","Cmr","CmP","CME","Cme" Add Charges Transaction Structure XML Mode <Request> <CreditCardAddCharges> <ClerkID></ClerkID> <AccountInfo> <AccountNumber></AccountNumber> </AccountInfo> <ExpirationInfo> <ExpirationMonth></ExpirationMonth> <ExpirationYear></ExpirationYear> </ExpirationInfo> <TransactionAmount></TransactionAmount> <SalesTaxAmount></SalesTaxAmount> <BillingPostalCode></BillingPostalCode> <BillingAddress></BillingAddress> <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> </CreditCardAddCharges> </Request> Page 40 of 119

45 Industry Transactions 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> <AccountNumber></AccountNumber> </AccountInfo> <ExpirationInfo> <ExpirationMonth></ExpirationMonth> <ExpirationYear></ExpirationYear> </ExpirationInfo> <TransactionAmount></TransactionAmount> <SalesTaxAmount></SalesTaxAmount> <LodgingInfo> <InvoiceNumber></InvoiceNumber> <RoomNumber></RoomNumber> <ArrivalDate></ArrivalDate> <OriginalDepartureDate></OriginalDepartureDate> <RoomRate></RoomRate> <PreferredCardholderFlag></PreferredCardholderFlag> <ExtraChargeAmount></ExtraChargeAmount> <ChargeCodes></ChargeCodes> <ArrivalTime></ArrivalTime> <DepartureTime></DepartureTime> <CustomerCode></CustomerCode> </LodgingInfo> <ReferenceNumber></ReferenceNumber> <CustomerName></CustomerName> </CreditCardExtendStay> </Request> Page 41 of 119

46 Industry Transactions Check-Out Check-Out Transaction Structure Request-String Mode 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. "CO","CMc","CMI","ACT","EXP","AMT","CmR","cmR","CMN","CMA", "CMD","Cmr","CmP","CME","Cme" Check-Out Transaction Structure XML Mode <Request> <CreditCardCheckout> <ClerkID></ClerkID> <AccountInfo> <AccountNumber></AccountNumber> </AccountInfo> <ExpirationInfo> <ExpirationMonth></ExpirationMonth> <ExpirationYear></ExpirationYear> </ExpirationInfo> <TransactionAmount></TransactionAmount> <SalesTaxAmount></SalesTaxAmount> <LodgingInfo> <InvoiceNumber></InvoiceNumber> <RoomNumber></RoomNumber> <ArrivalDate></ArrivalDate> <DepartureDate></DepartureDate> <RoomRate></RoomRate> <PreferredCardholderFlag></PreferredCardholderFlag> <ExtraChargeAmount></ExtraChargeAmount> <ChargeCodes></ChargeCodes> <CustomerCode></CustomerCode> <ArrivalTime></ArrivalTime> <DepartureTime></DepartureTime> </LodgingInfo> <ReferenceNumber></ReferenceNumber> <CustomerName></CustomerName> </CreditCardCheckout> </Request> Page 42 of 119

47 Industry Transactions 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", "CMD","Cmr","CmP","CME","Cme" No Show Transaction Structure XML Mode <Request> <CreditCardNoShow> <ClerkID></ClerkID> <AccountInfo> <AccountNumber></AccountNumber> </AccountInfo> <ExpirationInfo> <ExpirationMonth></ExpirationMonth> <ExpirationYear></ExpirationYear> </ExpirationInfo> <TransactionAmount></TransactionAmount> <LodgingInfo> <InvoiceNumber></InvoiceNumber> <RoomNumber></RoomNumber> <ArrivalDate></ArrivalDate> <DepartureDate></DepartureDate> <RoomRate></RoomRate> <PreferredCardholderFlag></PreferredCardholderFlag> <ExtraChargeAmount></ExtraChargeAmount> <ChargeCodes></ChargeCodes> <CustomerCode></CustomerCode> <ArrivalTime></ArrivalTime> <DepartureTime></DepartureTime> </LodgingInfo> <ReferenceNumber></ReferenceNumber> <CustomerName> </CustomerName> </CreditCardNoShow> </Request> Page 43 of 119

48 Industry Transactions 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"," "," ","0909", "40.00","12345","LIIIWithLID"," ","0.00","0.00","0.00", "0.00"," ","31432"," ","45435","3" "P0","0004","Pens","Green","555EEE000","1.0000","Gross", " ","00.00","0.00","0.00" "P0","0003","Pens","Red","444DDD000","1.0000", Gross", " ","00.00","0.00","0.00" "P0","0003","Pens","Red","444DDD000","1.0000","Gross", " ","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 44 of 119

49 Industry Transactions 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: 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 45 of 119

50 Industry Transactions Level III Transaction Sample XML Mode <Request> <CreditCardCharge> <AccountInfo> <AccountNumber> </AccountNumber> </AccountInfo> <ExpirationInfo> <ExpirationMonth>12</ExpirationMonth> <ExpirationYear>09</ExpirationYear> </ExpirationInfo> <SalesTaxAmount>1.00</SalesTaxAmount> <TransactionAmount>7.00</TransactionAmount> <ClerkID>ICV1</ClerkID> <BillingPostalCode>30329</BillingPostalCode> <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 46 of 119

51 Industry Transactions 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 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 47 of 119

52 Industry Transactions Debit Transaction Request Format Debit Transaction Structure Request-String Mode The format of a standard debit request within the ICVERIFY application is as follows. "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> <CustomerName></CustomerName> <CashBackAmount></CashBackAmount> <TransactionAmount></TransactionAmount> <AccountInfo> <AccountNumber></AccountNumber> <Track1></Track1> <Track2></Track2> </AccountInfo> <PINData></PINData> </DebitCardCharge> </Request> Page 48 of 119

53 Industry Transactions 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 The following is an example of how request-string transactions should look: "C1","~0001~","comment"," ","0912", "15.00" "C1","~0002~","comment"," ","0912", "10.00" "C2","~0001~","comment"," ","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"," ","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> Page 49 of 119

54 Requests and Responses 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 50 of 119

55 Requests and Responses Step Action 5. Open a text editor, and type the following line: "C1","Clerkfield","Commentfield"," ", "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 51 of 119

56 Requests and Responses 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 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 52 of 119

57 Requests and Responses 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"," ","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). only response code you can get for approved transactions. However, Y is not the 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 53 of 119

58 Requests and Responses 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: "Y Y" You have eight extra digits following the approval code. These eight digits represent the reference number that was returned by your Processing Network. Partial Authorization 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 $ The original amount submitted in the request for this transaction was something greater than $ 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 54 of 119

59 Requests and Responses 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 MC Amex Discover A 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 Y Y N N Authorization and Balance Reception Moto Partial Authorization Y Y Y Y Full Reversal Y Y Y Y Balance Inquiry Y N Y N Balance Receptive with an Authorization Request Concurrent Partial Authorization and Balance Reception Y N N N Y N N N For South processor, MasterCard will support Balance Inquiry only for Retail industry. Page 55 of 119

60 Requests and Responses FDMS Atlanta FDMS Atlanta Industry Transaction Type Card Type VISA MC Amex Discover Retail Partial Authorization[1] Y Y Y Y Full Reversal (online Y Y Y Y void)[2] Balance Inquiry[3] N N N N Balance Receptive Y Y Y Y with an Authorization Request Concurrent Partial Y Y Y Y Authorization and Balance Reception Restaurant Partial Authorization Y Y Y Y Full Reversal Y Y Y Y Balance Inquiry N N N N Balance Receptive with an Authorization Request Concurrent Partial Authorization and Balance Reception Y Y Y Y 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 56 of 119

61 Requests and Responses FDMS Nashville FDMS Nashville Industry Transaction Type Card Type VISA MC Amex Discover 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 N N N N and Balance Reception[3] Moto Partial Authorization Y Y Y Y Full Reversal Y Y Y Y Balance Inquiry Y Y Y Y Balance Receptive with an Authorization Request Concurrent Partial Authorization and Balance Reception Y Y Y Y N N N N FDMS Cardnet FDMS Cardnet Industry Transaction Type Card Type VISA MC Amex Discover Retail Partial Authorization[4] Y Y Y Y Full Reversal Y Y Y Y Balance Inquiry[1][2] Y Y Y N Balance Receptive with an Authorization Request[2][3] Y Y Y Y Concurrent Partial Authorization Y Y Y Y and Balance Reception Moto Partial Authorization Y Y Y Y Full Reversal Y Y Y Y Balance Inquiry Y N Y N Balance Receptive with an Y Y Y Y Authorization Request Concurrent Partial Authorization Y Y Y Y and Balance Reception Restaurant Partial Authorization Y Y Y Y Full Reversal Y Y Y Y Balance Inquiry Y Y Y N Balance Receptive with an Authorization Request Concurrent Partial Authorization and Balance Reception Y Y Y Y Y Y Y Y Page 57 of 119

62 Requests and Responses 1. FDMS Cardnet does not support above mentioned features for Hotel industry. TSYS TSYS Industry Transaction Type Card Type VISA MC Amex Discover Retail Partial Authorization Y Y Y Y Restaurant Full Reversal Y Y N N Balance Inquiry Y Y N N Balance Receptive with an Authorization Request Y Y Y Y Concurrent Partial Authorization Y Y Y Y and Balance Reception Partial Authorization Y Y Y Y Full Reversal Y Y N N Balance Inquiry Y Y N N Balance Receptive with an Y Y Y Y Authorization Request Concurrent Partial Authorization Y Y Y Y and Balance Reception Lodging Partial Authorization Y Y Y Y Full Reversal Y Y N N Balance Inquiry Y Y N N Balance Receptive with an Authorization Request Concurrent Partial Authorization and Balance Reception Y Y Y Y Y Y Y Y MOTO Partial Authorization Y Y Y Y Full Reversal Y Y N N Balance Inquiry Y Y N N Balance Receptive with an Authorization Request Concurrent Partial Authorization and Balance Reception Y Y Y Y Y Y Y Y Page 58 of 119

63 Requests and Responses 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 , 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 59 of 119

64 Requests and Responses "Y <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> <Comment>Comment</Comment> <AccountInfo> <AccountNumber> </AccountNumber> </AccountInfo> <ExpirationInfo> <ExpirationMonth>12</ExpirationMonth> <ExpirationYear>09</ExpirationYear> </ExpirationInfo> <TransactionAmount>25.00</TransactionAmount> <BillingPostalCode>65421</BillingPostalCode> <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 60 of 119

65 Requests and Responses 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> </TransactionDate> <TransactionTime>140415</TransactionTime> <CardSubType>Q</CardSubType> <AccountNumber>xxxxxxxxxxxx3003</AccountNumber> <TransactionAmount>25.00</TransactionAmount> <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 61 of 119

66 Requests and Responses <Reply> <TransactionReply> <ResponseCode>0</ResponseCode> <ResultCode>00</ResultCode> <ResultMessage></ResultMessage> <BatchSequenceNumber>1</BatchSequenceNumber> <AVSResponseCode>X</AVSResponseCode> <CVVResponseCode>U</CVVResponseCode> <ApprovalNumber>OK1234</ApprovalNumber> <TransactionDate> </TransactionDate> <TransactionTime>140415</TransactionTime> <CardSubType>Q</CardSubType> <AccountNumber>xxxxxxxxxxxx3003</AccountNumber> <TransactionAmount>8.27</TransactionAmount> <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 ResponseCode ResultCode Description 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. This code is returned directly from the Processing Network and is generated by the processing platform. Page 62 of 119

67 Requests and Responses Field ResultMessage BatchSequence Number AVSResponseCode CVVResponseCode ApprovalNumber TransactionDate TransactionTime CardSubType AccountNumber TransactionAmount RawResponse 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. 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. This is a numeric value showing the current batch number in the ICVERIFY application. 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. 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. A six-position alphanumeric field showing the approval code for an authorization-type transaction (such as a Sale, Book or Auth-Only.) 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.) 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. The account number used for this transaction, with the leading positions masked by x characters. The transaction amount submitted for the transaction. The actual response message returned from the Processing Network, encoded in Base64 format to guard against special characters. If your application Page 63 of 119

68 Requests and Responses Field PROMOTYPE PROMODUR DURPROMOAPR Description logic requires you to parse the actual processor message, you can Base64-decode this field and perform whatever operations you require. Promo Type. This field is present only for GE private label transaction responses Promo Duration. This field is present only for GE private label transaction responses During Promo APR. This field is present only for GE private label transaction responses. PROMOAPRFLAG AFTERPROMOAPR 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 , the percentage APR value should be 29.99% Promo APR Flag. This field is present only for GE private label transaction responses. After Promo APR. This field is present only for GE private label transaction responses. AFTERPROMOFLAG ApprovedAmount BalanceAmount Token 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 , the percentage APR value should be 29.99% After Promo Flag. This field is present only for GE private label transaction responses. The amount approved for a partially approved transaction. The balance amount on the card if returned by host. The token id corresponding to the original account Page 64 of 119

69 Requests and Responses Field Description number returned by the host. Page 65 of 119

70 Requests and Responses 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"," ","0912","10.00","11111", NorthStreet","44444","0.00","0.00","0.00","0.00","","55555", "33333","66666","1","","","",""" ","13:48:44","Y813484","A1000","","000001" "P0","","Feathers","111AAA000","1.0000","Ton"," ","","0.00","","","","","","","","","","","","",""" ","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: "Y123456Y " 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 66 of 119

71 Requests and Responses "C1","clerk"," "," ", "0912","40.00","12345","LIIIWithLID"," ","0.00","0.00", "0.00","0.00"," ","31432"," ","45435"," 3" "P0","0004","Pens,Green","555EEE000","1.0000","Gross", " ","00.00","0.00","0.00" "P0","0003","Pens,Red","444DDD000","1.0000","Gross", " ","00.00","0.00","0.00" "P0","0003","Pens,Red","444DDD000","1.0000","Gross", " ","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 67 of 119

72 Requests and Responses 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> Following is a sample response in XML mode, <Reply> <TransactionReply> <ResultCode>1</ResultCode> <ResultMessage></ResultMessage> <AVSResponseCode>Y</AVSResponseCode> <CVVResponseCode></CVVResponseCode> <ApprovalNumber>OK521C</ApprovalNumber> <AuthorizationNumber></AuthorizationNumber> <TransactionDate>0812</TransactionDate> <TransactionTime>152501</TransactionTime> <BalanceAmount></BalanceAmount> <AccountNumber>xxxxxxxxxxxx0026</AccountNumber> <CardSubType>Y</CardSubType> <TransactionID> </TransactionID> <TransactionAmount>1.00</TransactionAmount> <BatchSequenceNumber>1</BatchSequenceNumber> <Token> </Token> <HostTransactionID> </HostTransactionID> <ResponseCode>0</ResponseCode> <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 68 of 119

73 Requests and Responses A sample request with the example token is shown below, "C2","sysadmin<CMN>",""," ","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> <AccountNumber> </AccountNumber> <Track1></Track1> <Track2></Track2> </AccountInfo> <ExpirationInfo> <ExpirationYear>12</ExpirationYear> <ExpirationMonth>12</ExpirationMonth> </ExpirationInfo> <TransactionAmount>1.00</TransactionAmount> <TransactionReversalFlag>Y</TransactionReversalFlag> </CreditCardVoid> </Request> Page 69 of 119

74 Reports 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 Page 70 of 119

75 Reports 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> <AccountNumber></AccountNumber> </AccountInfo> <ExpirationInfo> <ExpirationMonth></ExpirationMonth> <ExpirationYear></ExpirationYear> </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. Page 71 of 119

76 Reports 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 RC HRD SDT EDT CMN Field Description Describes the type of transaction to report. 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. 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. 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. Contains the customer s name. Page 72 of 119

77 Reports RPS SUM TAG CMc Field Description 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 NOTE: This field is optional. 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 Enables or disables receipt printing. Choose Y to print, choose N to disable. 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. Page 73 of 119

78 Reports EXP CCD Field Description 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. 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 Page 74 of 119

79 Reports 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. Page 75 of 119

80 Reports Table 5 Card/Comments Fields in the Detail Report T Type Number EXP Amount Date Time SEQ# Field The type of transaction. Description 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). The type of credit card used for the transaction. The credit card number used for the transaction. The expiration date on the credit card used for the transaction. The amount of the transaction. The date the transaction was executed. The time of day the transaction was executed. 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 Comment The name of the clerk who took the order. Any additional comments regarding the transaction. This field is often used for order numbers (a unique number or alphanumeric sequence that identifies the transaction). Page 76 of 119

81 Reports 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 Figure 9a 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. Detail Report, Credit Card Summary Standard Processing Page 77 of 119

82 Reports 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). Page 78 of 119

83 Reports Figure 11 Detail Report (Visa and MasterCard Totals) Detail Report (Defining Visa or MasterCard Transactions) Figure 12 This section of the report breaks down the total dollar amount and defines whether they are Visa or MasterCard transactions (Figure 12). Detail Report (Defining Visa or MasterCard Transactions) Page 79 of 119

84 Reports 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) Page 80 of 119

85 Reports 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) Page 81 of 119

86 Reports 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) Page 82 of 119

87 Reports 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. Page 83 of 119

88 Reports 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) Figure 18 The information shown in Figure 18 is the segment that summarizes the credit card section. Post-Settlement Report (Credit Card Section) Page 84 of 119

89 Reports 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 Figure 19 displays a summary of Authorized Only transactions that did not settle. Post-Settlement Reports (Authorized Only Transactions) Page 85 of 119

90 Reports Post-Settlement Report (Unsettled Transactions) Figure 20 Figure 20 displays a summary of transactions that did not settle. Post-Settlement Report (Unsettled Transactions) Page 86 of 119

91 Tutorials 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. Page 87 of 119

92 Tutorials Table 6 File Naming Conventions File Extension.TMP.REQ.HLD.ZZZ.ANS Description 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. Rename the temporary file to ICVERxxx.REQ where xxx is the station number. In a single user environment, this is always 001. Created by ICVERIFY for processing. Created by ICVERIFY for processing. The answer for the transaction(s) processed. Page 88 of 119

93 Tutorials 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 Page 89 of 119

94 Tutorials 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. Page 90 of 119

95 Tutorials 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. Page 91 of 119

96 Tutorials Step 3. Rename request file Action 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. Page 92 of 119

97 Tutorials Step 5. Action 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. Page 93 of 119

98 Response Codes 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. Page 94 of 119

99 Response Codes Value Description 1023 Error at processing network. Attempt the transaction again or call your financial institution s voice authorization center 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 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 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 Transaction wasn t performed because a duplicate of it was already present at the processing network The transaction was rejected because the merchant ID used to submit it is not valid The transaction was rejected because the request type is not valid 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 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. Page 95 of 119

100 Field Definitions 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, Number generally used if value is being transferred from one stored value card to another ACT AccountInfo. Account Number Number AccountNumber or Track1 or Track2 AD2 ApplicationInfo. Primary Applicant Address Line Text Applicant. Address2 2 (GE Application Processing) ADA AdditionalAmount Additional (Surcharge) $Amount Amount ADD BillingAddress Billing Address Text ADG ApplicationInfo. Applicant. Address1 Primary Applicant Address Line 1 (GE Application Processing) ADN ApplicationDisplayName Application Display Name Text ADS LineItem. Amount Sign, + for debit and Text AmountSign for credit, from the cardholder s perspective ADT LineItem. AmountType Amount Type, used to report a breakdown of charges by type (for example, tips, fees, and so on) Amn CashBackAmount Additional Cash $Amount Text Text AMN CashBackAmount Additional Cash (Cash Back Amount) $Amount Page 96 of 119

101 Field Definitions Field XML Element Name Description Data Type AMP PurchaseInfo. PurchaseItems. LineItem. Purchase Amount $Amount ItemAmount 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. Arrival Time Number ArrivalTime 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. Foreign Currency Code Text CurrencyCode CGE ApplicationInfo. City Text Applicant. City Ch2 AccountInfo. Account Number Text AccountNumber CH2 AccountInfo. Account Number Number AccountNumber CH3 AccountInfo. Account Number Text AccountNumber CHK AccountInfo. Account Number Number 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. New Departure Date Date DepartureDate cma LodgingInfo. Original Departure Date Date OriginalDepartureDate CMA LodgingInfo. Arrival Date Date ArrivalDate CMc ClerkID Clerk Text CMD LodgingInfo. Departure Date Date DepartureDate Cme LodgingInfo. Charge Codes Number ChargeCodes CME LodgingInfo. Additional Charges $Amount ExtraChargeAmount CMF Descriptor Charge Description Text Page 97 of 119

102 Field Definitions Field XML Element Name Description Data Type Cmi InvoiceNumber Invoice Number Number CMI LodgingInfo. Invoice/folio Number Number InvoiceNumber Cmm PurchaseInfo. Discount Amount $Amount DiscountAmount CMM Comment Comment Text CMN CustomerName Customer name Text cmo CustomerOrderID Reference Number Text cmo PurchaseInfo. Order Date Date OrderDate 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. Destination zip code Text ShippingPostalCode cmp PurchaseInfo. Original zip code Text SendingPostalCode CmP LodgingInfo. Preferred cardholder?(y/n) Text PreferredCardholderFlag CMP DescriptorCode Descriptor codes Number cmr ReferenceNumber Reference number Text Cmr LodgingInfo. Room rate $Amount RoomRate CmR LodgingInfo. Room number Text RoomNumber CMR PaymentTermCode Ticket terms Number CMS ClerkID Server ID Text Cmt PurchaseInfo. Merchant Order Number Text PurchaseOrderID CMt PurchaseInfo. Merch Order #/Purchase ID Text PurchaseOrderID Cmw PurchaseInfo. Customer Code Text CustomerCode CMw PurchaseInfo. Alternate purchase order Text AlternateOrderID number CMW PurchaseInfo. Customer Code/Reference ID Text CustomerCode cmx SalesTaxAmount Sales Tax $Amount CMx SalesTaxAmount Tax Amount $Amount CMX SalesTaxAmount Tax Amount $Amount CMY PurchaseInfo. Duty Amount $Amount DutyAmount CMz PurchaseInfo. Total Addenda Number PurchaseItemCount CMZ PurchaseInfo. FreightAmount Freight Amount $Amount Page 98 of 119

103 Field Definitions Field XML Element Name Description Data Type CNB Client Order ID Client Order ID (Citi Private Text Label) COD CustomerANICode Customer ANI Code Text COI CashOutFlag Cash out Y/N CPI CardPresentFlag Card Present Indicator Y/N CRD DccInfo. Currency Conversion Date Date ConversionDate CRT DccInfo. Currency Conversion Time Text ConversionTime CT3 PurchaseInfo. Commodity Code Text PurchaseItems. LineItem. ItemCode CSI ApplicationInfo. Cross-Sell Indicator Y/N CrossSellFlag CT4 PurchaseInfo. Summary Commodity Code Text SummaryCommodityCode CVv CardVerificationValue CVV2/CVC2/CID Text CVV CardVerificationValue CVV2/CVC2/CID Text DCC DestCountryCode Destination Country Code Text DCI ApplicationInfo. Dual Credit Indicator Y/N DualCreditFlag DEF DeferredBillingFlag Deferred Billing Flag Text DEM PurchaseInfo. Description Text PurchaseItems. LineItem. ItemDescription DEV PurchaseInfo. Description Text PurchaseItems. LineItem. ItemDescription DFG DccInfo. DCC Status Text DccStatusIndicator DL1 ApplicationInfo. Drivers License Number Text Applicant. IdentificationNumber DLE IdentificationNumber Drivers License Number Text DLI IdentificationNumber Customer ID Text DLN IdentificationNumber Drivers License Number Text DLS ApplicationInfo. Drivers License State Text Applicant. IdentificationState DNP DeferredNumberOfPayme Deferred Number of Payments Number nts DOB BirthDate Date of Birth Date DPC ShippingState Destination State Code Text dpc DepartmentCode Department Code Text Page 99 of 119

104 Field Definitions Field XML Element Name Description Data Type DPM DebtPaymentFlag Debt payment Text DPP DeferredPaymentPlan Deferred Payment Plan Number DSC PurchaseItems. Discount amount $Amount LineItem. ItemDiscountAmount dsc Descriptor Description of purchase for GE Text private label transactions DTM LodgingInfo. Departure Time Number DepartureTime DTP DeferredTimePeriod Deferred Time Period Number DXP ApplicationInfo. Drivers License Expiration Date Applicant. IdentificationExpiration Date E01 PurchaseInfo. National Tax Amount $Amount NationalTaxAmount E03 PurchaseInfo. Customer VAT Registration Text CustomerVatRegistration Number Number E09 PurchaseInfo. Unit of measure Text PurchaseItems. LineItem. ItemUnitOfMeasure E16 PurchaseInfo. Unit cost Number PurchaseItems. LineItem. ItemUnitCost E18 PurchaseInfo. VAT / Tax Amount $Amount PurchaseItems. LineItem. ItemTaxAmount E19 PurchaseInfo. PurchaseItems. LineItem. ItemQuantity Quantity Number E20 PurchaseInfo. UniqueVatInvoice ReferenceNumber Unique VAT Invoice Reference Number EDT ReportEndDate Ending date Date EMV EMVTagInfo EMV Tag Info Text EST EscheatableFlag Escheatable Indicator Y/N/X EXP ExpirationInfo. Expiration Date Date ExpirationMonth & ExpirationYear EXR DccInfo. Foreign Currency Exchange Amount ExchangeRate Rate FAM DccInfo. Foreign Amount Amount Page 100 of 119 Text

105 Field Definitions Field XML Element Name Description Data Type ForeignAmount FBC PurchaseItems. Debit/credit flag Text LineItem. ItemDCFlag FBK EMVFallBack EMV FallBack Text HRD PrintFlag Printer?(y/n) Y/N IAT LineItem. Unit cost of line item Amount ItemAmount INC InvoiceNumber Invoice Number Text ins InstallmentCount Number of Installments Number IQT LineItem. Item quantity Number ItemQuantity ISW SwipeData Data for check transaction Text processing; may be manually entered or retrieved from a MICR reader LNI ApplicationInfo. Language Indicator Text LanguageIndicator 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 Text Label) pc2 ProductCode2 Product Code 2 (Citi Private Text Label) pc3 ProductCode3 Product Code 3 (Citi Private Text Label) pc4 ProductCode4 Product Code 4 (Citi Private Text Label) pc5 ProductCode5 Product Code 5 (Citi Private Text Label) pci ApplicationInfo. Credit Insurance Y/N CreditInsuranceFlag PCN ApplicationInfo. Primary Cell Phone Number Applicant. MobilePhoneNumber PDB ApplicationInfo. Date of Birth Date Applicant. BirthDate phi ApplicationInfo. Housing Information Text Applicant. HousingFlag phn ApplicationInfo. Home Phone Number Page 101 of 119

106 Field Definitions Field XML Element Name Description Data Type Applicant. HomePhoneNumber PIF ApplicationInfo. Income Frequency Text Applicant. IncomeFrequency pim ApplicationInfo. Initial Requested Amount Number RequestedAmount pin ApplicationInfo. Monthly Income Number Applicant. Income PIN PINData Pin data Text pji ApplicationInfo. JointApplicationFlag Joint Indicator Y/N ppc ApplicationInfo. ProductCode Product Code Text Pmn ApplicationInfo. First Name Text Applicant. FirstName pmn ApplicationInfo. Middle Name Text Applicant. MiddleName pmn ApplicationInfo. Last Name Text Applicant. LastName PR6 SKUData SKU Data Text PR8 DeferredBillingFlag Deferred Payment Indicator Number PRD PurchaseInfo. Summary Product Code for Text ProductCode Visa purchasing card transactions PRI PartialRedemptionFlag Partial Redemption Indicator Y/N prn ApplicationInfo. Relative Phone Number Number Applicant. RelativePhoneNumber psn ApplicationInfo. SSN Number Applicant. SSN PSU SKUData Product SKU Text PTA ApplicationInfo. Time at Residence Text Applicant. TimeAtResidence PTC PromotionalCode Promotional Code Number PTJ ApplicationInfo. Applicant. TimeAtJob Time at Job Text pwn ApplicationInfo. Applicant. WorkPhoneNumber Application Work Phone Number Page 102 of 119 Number

107 Field Definitions Field XML Element Name Description Data Type PYN PurchaseCardFlag Purchase Card Indicator for Y/N American Express transactions PYT PaymentType Payment Type indicator for Text Paymentech Stored Value transactions; used for reporting purposes only QUa PurchaseInfo. Quantity Text PurchaseItems. LineItem. ItemQuantity 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. Secondary Applicant Address Text CoApplicant. Address2 2 nd Line SAD ApplicationInfo. CoApplicant. Address1 Secondary Applicant Address Text SCN SCY sdb SDL SDS SDX ApplicationInfo. CoApplicant. MobilePhoneNUmber ApplicationInfo. CoApplicant. City ApplicationInfo. CoApplicant. BirthDate ApplicationInfo. CoApplicant. IdentificationNumber ApplicationInfo. CoApplicant. IdentificationState ApplicationInfo. CoApplicant. IdentificationExpiration Date Secondary Applicant Cell Phone Secondary Applicant City Secondary Applicant Date of Birth Secondary Applicant Drivers License Secondary Applicant DL State Secondary Applicant DL Expiration Page 103 of 119 Number Text Number SDT ReportStartDate Starting date Date SIf ApplicationInfo. Secondary Applicant Income Text CoApplicant. IncomeFrequency Frequency SIM ShippingMethod Shipping Method Text sin ApplicationInfo. Secondary Applicant Income Number Text Text Text

108 Field Definitions Field XML Element Name Description Data Type CoApplicant. Income Smn ApplicationInfo. Secondary Applicant First Text CoApplicant. FirstName Name smn ApplicationInfo. Secondary Applicant Middle Text CoApplicant. MiddleName Name smn ApplicationInfo. Secondary Applicant Last Text CoApplicant. LastName Name SMT SurchargeAmount Surcharge Amount Number sph ApplicationInfo. Secondary Applicant Work Number CoApplicant. WorkPhoneNUmber Phone Number SPN ApplicationInfo. Secondary Phone Number Number CoApplicant. HomePhoneNUmber SRS ApplicationInfo. Secondary Housing Info Text CoApplicant. HousingFlag ssn ApplicationInfo. CoApplicant. SSN Secondary SSN Number SST ApplicationInfo. CoApplicant. State Secondary Applicant State of Residence StE IdentificationState State code Text STA ApplicationInfo. Secondary Applicant Time at Text CoApplicant. TimeAtResidence Address 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 SUM ReportSummaryIndicator Summary only? (y/n/s/d) Text SVI StoredValueIndicator Stored Value Card Indicator Text SZP ApplicationInfo. Secondary Applicant ZIP Code Text CoApplicant. PostalCode TDT AccountInfo. Track1 or Track2 Track data Text Page 104 of 119 Text Text

109 Field Definitions Field XML Element Name Description Data Type TDY TenderType Tender Type Text TIP RestaurantInfo. Tip Amount $Amount TipAmount TOI TypeOfIndustry Type of Industry Text TOP ProcessingTypeIndicator Type of Processing for GE Text private label transactions: E = Easy LID, M = Manufacturer TTI PurchaseInfo. Tax Type Identifier Text PurchaseItems. LineItem. TaxTypeIdentifier TXD HostTransactionID Transaction ID Text TXI TaxAmountIndicator Tax Amount Indicator (0 = tax Text not provided, 1 = tax included, 2 = tax exempt) UOM PurchaseInfo. Unit of Measure Text PurchaseItems. LineItem. ItemUnitOfMeasure UPR PurchaseInfo. Unit Price $Amount PurchaseItems. LineItem. ItemUnitCost UR1 UserField1 User Field 1 for First Data Gift Text Card transactions UR2 UserField2 User 2 for First Data Gift Card Text transactions Vat PurchaseInfo. VAT / Tax Amount $Amount VatTaxAmount VPW VisaPaywave Visa Paywave taginfo Text VtR PurchaseInfo. Summary VAT / Tax Rate for a Number VatTaxRate purchasing card transaction VT2 PurchaseInfo. VAT / Tax Rate for an Number PurchaseItems. LineItem. individual line item within a purchasing card transaction. ItemTaxRate VT5 Zip PurchaseInfo. PurchaseItems. LineItem. TaxRate PurchaseInfo. ShippingPostalCode VAT / Tax Rate for an individual line item within a purchasing card transaction. Destination ZIP Code Number ZIP BillingPostalCode ZIP Code Text ZP2 ApplicationInfo. Applicant. PostalCode ZIP Code Number Text Page 105 of 119

110 Field Definitions Field XML Element Name Description Data Type NOTE: Refer to the Transaction Builder utility in your SDK software for your processor-specific field requirements and for maximum and minimum lengths. Page 106 of 119

111 Report Transaction Types 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 Check-out O (force) Sale S Credit/Return C Sale S Extended Stay E or R Void Sale V Credit Void V Void Sale V No-show N Credit/Return C or Pre-Auth/ Credit/ Return C Sale S R AuthOnly P or R 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 Page 107 of 119

112 Glossary 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 ABA (American Bankers Association) Routing Number Account number ACH Acquirer Acquiring financial institution Description 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. A unique sequence of numbers assigned to a cardholder account, which identifies the issuer and type of financial transaction card. A method of transferring funds between banks via the Federal Reserve System. ACH is used by most, but not all, financial institutions. See 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) Agent bank Approval See AVS. 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. 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). Page 108 of 119

113 Glossary Term Description Arbitration Asynchronous Auth file Auth only Automated Clearing House Authorization The procedure used to determine the responsibility for a Chargebackrelated dispute between two member banks. See Chargeback. 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. See transaction file. See Terminal Capture. See ACH. 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 Average ticket AVS (Address Verification Service) An alphanumeric value returned from the processor for successful transactions. If a transaction fails authorization, an authorization code is not returned from the processor. The average dollar amount of merchant credit transactions. 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 Basis Point 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. One one-hundredth of a percent. Discount rates are expressed as basis points. Page 109 of 119

114 Glossary Term Description Batch Batch processing BIN Bundled rate Cancellation number Capture Card issuer Chargeback A collection of transactions. Usually a merchant has one batch per day or per shift. A type of data processing where related transactions are transmitted as a group for processing. See Bank Identification Number. A discount rate that includes communications costs as well as transaction fees. Also referred to as flat rate. A number provided by a resort, hotel or motel to verify a cardholder's notification to cancel a guaranteed reservation or advance deposit. 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. See issuing financial institution. 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 Chargeback reason code Check guarantee Clearing Close batch 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. A two-digit code identifying the specific reason for the Chargeback. 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. 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. The process by which transactions with authorization codes are sent to the processor for payment to the merchant. Page 110 of 119

115 Glossary Term Confirmation letter Copy request Credit Custom Payment Services (CPS) Description A letter sent by a processor to a merchant at a specified interval to verify batch deposits. See retrieval request. A return of funds to a cardholder's account (crediting entry) for a sale that has already been authorized and settled. 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 DDA (Demand Deposit Account) Debit card Credit Card Verification Value Version 2. Only for Visa cards. A bank account, such as a checking account, that allows the holder to withdraw funds or use funds for payment upon demand. 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 Page 111 of 119

116 Glossary Term configured to use. Description 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 Time Period Deferred Number of Payments Deferred Payment Plan Deposit 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 refers to the time period (in months) for which the payment will be deferred. 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 (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: The aggregate of sales records and refunds submitted to a bank processor for processing. Deposit bank Discount rate Draft capture DUKPT PINpad ECI Electronic Cash Register (ECR) Electronic Draft Capture (EDC) Electronic Funds Transfer (EFT) The bank into which merchant deposits funds from credit card transactions. The percentage of credit card sales amounts the acquiring financial institution charges the merchant for the settlement of the transaction. Refers to settlement. 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. Electronic Commerce Indicators. The combination of a cash register and a point-of-sale (POS) terminal, often PC-based. 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. A method of incrementing or decrementing an account through electronic means, eliminating the need for paper checks or withdrawal Page 112 of 119

117 Glossary Term slips. Description 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. External Agent (ESA) Floor limit Force Host Capture Sales All processed information (approved/declined transactions) is then reencrypted 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. A term used by American Express for Independent Sales Organizations (ISOs) and MSPs. 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. 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. 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 Imprint Independent Sales Organization (ISO) Interchange Refers to the computer at the processor that is dialed for authorization and settlement. 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. See ISO. The flow of information between issuers and acquirers (for example, transactions, retrieval requests, and chargebacks). Page 113 of 119

118 Glossary Term Description Interchange fee ISO Issuing The fee that the merchant s bank pays the consumer s bank for each credit card transaction that is settled. A Visa term for a company that is sponsored by an acquiring bank to solicit, and sometimes support, merchants. Providing a bankcard to a cardholder and authorizing that person to use it to complete financial transactions. Issuing institution financial 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 Local review Magnetic Ink Check Reader (MICR) MAG stripe Magnetic stripe Manual entry MasterCard See manual entry. The ability for a merchant to review, from his or her terminal, the contents of a batch before or after settlement. A device that reads characters (i.e. account information) printed on a check with ink containing particles of a magnetic material. See 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. Credit card information that is entered via terminal keypad or keyboard instead of swiping the card through a card reader. 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 Provider Merchant Service MasterCard term for a company that is sponsored by an acquiring bank to solicit and sometimes support merchants. A retailer, or any other entity (pursuant to a merchant agreement), that agrees to accept credit cards, debit cards, or both, when properly presented. Page 114 of 119

119 Glossary Term Merchant agreement Merchant bank Merchant category code Merchant Identification Number (MID) Merit MID MICR Modem MOTO MSP Multi-trans mode Description 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. A bank that has entered into an agreement with a merchant to process bank card transactions. Also referred to as acquirer or acquiring bank. See SIC code. A unique number that identifies a merchant. The qualification levels for a MasterCard transaction. Merit III is the highest discount, followed by Merit II, Merit I, and then Standard. See Merchant Identification Number. See Magnetic Ink Check Reader. MOdulator / DEModulator. An electronic telecommunications hardware device that is used by the terminal or PC POS to dialup the processor. Mail Order/Telephone Order. See Member Service Provider. A host computer that allows multiple transactions with the same telephone call. Net bank Network settlement The bank that maintains the settlement account and that executes funds transfers with member clearing banks. 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) Node Non-qualified 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 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. 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. Page 115 of 119

120 Glossary Term Description Offline Online inquiry Open to buy Original draft Packet-switched network 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. Some processors offer PC inquiry to the host system to view transactions, Chargebacks, and so on. The amount of credit available at a given time on a cardholder's account. The original copy of the forms and signature used in the transaction. Also referred to as hard copy. 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 PC application POS 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. 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) PIN See 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) POS Post-Authorization Posting Pre-Authorization The place and time at which a transaction occurs. This term also refers to the devices or software used to capture transactions. See Point of Sale. A transaction that has been submitted for completion and has completed a payment. The process of recording debits and credits to individual cardholder account balances. See Auth only. Page 116 of 119

121 Glossary Term Prestigious properties Description A $500, $1000 or $1500 floor limit at designated hotels/resorts. Floor limit s returned as part of authorization response. Prior sale authorized 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 Processor PSIRF Qualification Receipt Recurring transaction A bankcard that can be used only in a specific merchant's store. Typically not a bankcard. A transaction processor; a large computer center that processes data from credit card transactions and settles funds to merchants. The highest qualification that a Visa transaction can obtain. Card must be swiped and transaction deposited within 24 hours. 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. 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. 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 Release A code given to a transaction by Host Capture processors. 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 Settle Settlement 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. See settlement. A process in which a credit card transaction is settled financially Page 117 of 119

122 Glossary 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 Standard Stripe read Surcharges Suspense Swiped card See swiped card. Compare manual entry. 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. See swiped card. Any additional charges to a merchant's standard processing fees. They are a result of non-qualified transactions of different communications methods. 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. 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. Page 118 of 119

123 Glossary Term Travel and Entertainment (T&E) Card Terminal Capture Third-party processor Description Credit cards that typically require payment in full each month (for example, American Express, Diner s Club, and Carte Blanche ). 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. A non-member agent employed by an acquiring bank, which provides authorization, settlement and merchant services to a merchant. Ticket only Transaction A sale transaction for which you have received a voice authorization. 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 Transaction file Vendor file A per transaction charge incurred by merchants who are on scale pricing. This is in addition to the percentage discount fees. 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. 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. Page 119 of 119