ICVERIFY SDK Guide

®

ICVERIFY for Windows

®

Version 4.2 Software Developer’s Kit Guide Copyright © 2011, ICVERIFY, Inc., a First Data company. All Rights Reserved. All trademarks, service marks and trade names referenced in this material are the property of their respective owners. This version of this document supersedes any and all previous versions of the ICVERIFY® for Windows® SDK Guide. Revision Date: 12 September 2011

ICVERIFY, Inc. 6200 South Quebec Street Suite 350 Greenwood Village, CO 80111 USA For Sales and Product Information, call: (800) 538-0651 For Technical Support, call: (800) 900-6133

Table of Contents CHAPTER 1 – INTRODUCTION TO ICVERIFY® FOR WINDOWS®.......................................................... 1 OVERVIEW .......................................................................................................................................................... 1 Style Conventions........................................................................................................................................... 1 PREREQUISITES ................................................................................................................................................... 1 GETTING HELP .................................................................................................................................................... 2 CHAPTER 2 – OVERVIEW ................................................................................................................................ 3 OVERVIEW .......................................................................................................................................................... 3 FEATURES OVERVIEW ......................................................................................................................................... 4 Integration Modes .......................................................................................................................................... 5 Encryption...................................................................................................................................................... 5 CHAPTER 3 – THE BANKCARD INDUSTRY ................................................................................................ 6 OVERVIEW OF PROCESSING NETWORKS .............................................................................................................. 6 Bank Card Authorization Flow ...................................................................................................................... 6 Host-based vs. Terminal-based Settlement .................................................................................................... 8 ABOUT INTERCHANGE NETWORKS ...................................................................................................................... 8 Interchange Fees ........................................................................................................................................... 9 Merchant Discount Rates............................................................................................................................... 9 UNDERSTANDING INTERCHANGE FEES AND MERCHANT DISCOUNT RATES ...................................................... 10 CARD VERIFICATION VALUES (CVV2 / CVC2 / CID) ....................................................................................... 11 CVV Indicator .............................................................................................................................................. 12 CHAPTER 4 – INDUSTRY TRANSACTIONS ............................................................................................... 13 OVERVIEW ........................................................................................................................................................ 13 RETAIL TRANSACTIONS ..................................................................................................................................... 13 Sale .............................................................................................................................................................. 13 Void .............................................................................................................................................................. 14 Credit / Refund / Return ............................................................................................................................... 14 Credit Void / Cancel Return / Refund Void.................................................................................................. 14 Auth Only / Pre-Authorization ..................................................................................................................... 14 Force / Post-Authorization .......................................................................................................................... 14 Cash Advance .............................................................................................................................................. 15 HANDLING RETAIL TRANSACTIONS................................................................................................................... 15 SAMPLE TRANSACTIONS ................................................................................................................................... 20 Sale Example ............................................................................................................................................... 20 Void Example ............................................................................................................................................... 20 Credit / Refund / Return Example ................................................................................................................ 21 Credit Void / Cancel Return / Refund Void Example ................................................................................... 21 Auth Only / Pre-Authorization Example ...................................................................................................... 22 Force / Post-Authorization Example ........................................................................................................... 22 Balance Inquiry Example............................................................................................................................. 23 Cash Advance Example ............................................................................................................................... 23 CARD-SWIPED TRANSACTIONS.......................................................................................................................... 24 Swiped Transaction Support in Request-String Mode ................................................................................. 24 Extracting printed card number from track data for FDMS Gift cards ....................................................... 26 Swiped Transaction Support in XML Mode ................................................................................................. 28 Sale Transaction with Track 1 Data Only ................................................................................................... 28 Sale Transaction with Track 2 Data Only ................................................................................................... 28 Sale Transaction with Both Track 1 and Track 2 Data................................................................................ 29

ICVERIFY® 4.0 SDK Guide MOTO (MAIL ORDER / TELEPHONE ORDER) TRANSACTIONS ........................................................................... 30 Book ............................................................................................................................................................. 33 Ship .............................................................................................................................................................. 33 Processing Book and Ship Transactions ...................................................................................................... 33 EMV TRANSACTIONS ........................................................................................................................................ 34 HOTEL TRANSACTIONS ..................................................................................................................................... 38 Check-In....................................................................................................................................................... 38 Add Charges ................................................................................................................................................ 40 Extend Stay .................................................................................................................................................. 41 Check-Out .................................................................................................................................................... 42 No Show ....................................................................................................................................................... 43 LEVEL III PURCHASING CARDS ......................................................................................................................... 44 Level III Record Formats – Request-String Mode ....................................................................................... 45 Level III Record Formats – XML Mode ....................................................................................................... 45 DEBIT CARD TRANSACTIONS ............................................................................................................................ 47 Processing Debit Card Transactions ........................................................................................................... 47 Debit Transaction Types .............................................................................................................................. 47 Debit Transaction Request Format .............................................................................................................. 48 Debit Transaction Support by Processor ..................................................................................................... 49 PROCESSING TRANSACTIONS FOR MULTIPLE MERCHANTS ............................................................................... 49 CHAPTER 5 – REQUESTS AND RESPONSES ............................................................................................. 50 OVERVIEW ........................................................................................................................................................ 50 Request Files ................................................................................................................................................ 50 TRANSACTION RESPONSES ................................................................................................................................ 53 Transaction Responses in Request-String Mode .......................................................................................... 53 Transaction Responses in XML Mode ......................................................................................................... 60 XML Response Fields .................................................................................................................................. 62 PROCESSING OFFLINE GROUP INPUT OR REQUEST FILES – INTERPRETING RESULTS ......................................... 66 TOKENIZATION AND ENCRYPTION CAPABILITY ON FDMS CARDNET ......................................... 666 CHAPTER 6 – REPORTS.................................................................................................................................. 70 OVERVIEW ........................................................................................................................................................ 70 DETAIL REPORTS ............................................................................................................................................... 70 Detail Report Format................................................................................................................................... 71 Detail Report Fields..................................................................................................................................... 75 Additional Fields ......................................................................................................................................... 77 Credit Card Summary Information .............................................................................................................. 77 Visa® & MasterCard® Section ..................................................................................................................... 78 American Express® Section.......................................................................................................................... 80 Not Captured or Authorized Transactions ................................................................................................... 81 Authorized Transaction Section ................................................................................................................... 82 POST-SETTLEMENT REPORTS ............................................................................................................................ 83 Credit Card Section ..................................................................................................................................... 84 Authorized Only Transaction Section .......................................................................................................... 85 CHAPTER 7 – TUTORIALS ............................................................................................................................. 87 OVERVIEW ........................................................................................................................................................ 87 WINDOWS® VISUAL BASIC INTEGRATION TUTORIAL ........................................................................................ 87 Using the Direct DLL Interface ................................................................................................................... 87 Using the Request-Answer Interface ............................................................................................................ 87 SAMPLE CODE PROGRAM FLOW ........................................................................................................................ 89 Code Program Flow Procedures ................................................................................................................. 90 APPENDIX A – RESPONSE CODES ............................................................................................................... 94 Copyright © 2011, ICVERIFY, Inc., a First Data company. All trademarks are the property of their respective holders.

ICVERIFY® 4.0 SDK Guide OVERVIEW ........................................................................................................................................................ 94 Address Verification Result Codes............................................................................................................... 94 Card Verification Result Codes ................................................................................................................... 94 Response Code Values ................................................................................................................................. 94 APPENDIX B – FIELD DEFINITIONS ........................................................................................................... 96 APPENDIX C – REPORT TRANSACTION TYPES .................................................................................... 107 APPENDIX D – GLOSSARY........................................................................................................................... 108 GLOSSARY OF TERMS ...................................................................................................................................... 108

Copyright © 2011, ICVERIFY, Inc., a First Data company. All trademarks are the property of their respective holders.

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 representative at your acquiring bank.

from

the

merchant

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.

Copyright © 2011, ICVERIFY, Inc., a First Data company. All trademarks are the property of their respective holders. Page 1 of 119

Introduction to ICVERIFY® for Windows® Getting Help

The following is a list of the available Help features provided to assist you: http://www.firstdata.com/paymentsoftware_integrators — provides a forum for getting your questions answered and accessing archived help information. Context-sensitive Help—allows you to point to an area of the interface that you would like more information about. To use this Help, click the question mark in the interface and then click the area of the interface in question. GUI Help—allows you to access a directory and index of helpful information. To use this Help, press F1 while you‘re using ICVERIFY. Setup Help—allows you to access a directory and index of helpful setup information. To use this Help, press F1 while you‘re using Advanced Setup.

NOTE: You can also call (800) 900-6133 for Customer Service assistance, or send email to the following address: [email protected]


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.


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


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.


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

CARD PROCESSING NETWORK

ISSUING ISSUING BANK BANK

ACQUIRING ACQUIRING BANK BANK//ISO ISO

VISA VISA MasterCard 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



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



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.


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.


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.) Copyright © 2011, ICVERIFY, Inc., a First Data company. All trademarks are the property of their respective holders. Page 10 of 119


Card Verification Values (CVV2 / CVC2 / CID)

CVV2/CVC2/CID are security features on the back of Visa® and MasterCard®, JCB/Discover and Diners/Discover and on the front of American Express® and Discover® credit cards. They were put in place to help merchants avoid fraud and increase profits. The new three-digit or four-digit value is an important security feature for card-not-present transactions. It provides a cryptographic check of the information embossed on the card. The CVV2/CVC2/CID value helps to validate that a customer has a valid card in his/her possession, and that the card account is legitimate. It helps minimize the risk of unknowingly accepting a counterfeit card or fraudulent transaction. CVV2 and CVC2 are printed only on the back of Visa® and MasterCard®, JCB/Discover and Diners/Discover cards, while CID is on the front of American Express® and Discover cards. It‘s not contained in the magnetic stripe information, and does not appear on sales receipts. It must be included in the authorization request, along with the following information: Transaction Type Account Number Expiration date Transaction dollar amount If you are participating in CVV2/CVC2/CID, you can generally expect to receive a ―match‖ or ―no match‖ response. However, it is possible your transaction may still be approved. In that case you must decide what to do according to your own business rules. Consult the document AVS & CVV Response Codes located on your installation CD-ROM for further details.


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


Industry Transactions

Chapter 4 – Industry Transactions Overview

This chapter describes the various types of transactions you can perform using ICVERIFY®, and provides sample code strings to help you implement a transaction handling process that best fits your business needs. For testing purposes, you can copy and paste any of the sample transactions included in this section into a request file.

NOTE: This guide discusses the file-based integration methods available within the ICVERIFY product exhaustively and only makes passing reference to the direct DLL interface. This is because if you are familiar with DLL programming, you need only understand the message formats discussed in this document. However, if you are unfamiliar even with file management programming, you will likely need more information before you feel comfortable integrating to your ICVERIFY software.

Retail Transactions

Retail is one of the easiest industry types to integrate. This is done by creating a flat ASCII text file that ICVERIFY picks up and processes. Once the transaction has been processed, ICVERIFY returns a flat ASCII text file that contains the response. The file may be plain-text or encrypted, depending on your use of the built-in encryption settings. This integration method is referred to as request (.req) and response/answer (.ans). The same transaction types used in retail are used in other industries as well.

Sale

A sale is the most commonly used transaction in a retail format. It‘s used to charge a purchase to a customer‘s credit account. It places a ―hold‖ on the customer‘s open-to-buy (or available credit) by the amount of the sale. Once a sale has been approved, the hold on the customer's credit remains valid for a limited time (three to thirty days, depending on the cardholder's bank) before expiring and releasing the hold on the funds in the customer's credit account. Funds from an approved sale transaction are not deposited into your account until they have been settled. This occurs automatically if you are using a host-based processor that auto-settles transactions. If you are using a terminal-based processor (or a host-based processor that does not 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.


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 / PreAuthorization

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 / PostAuthorization

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 / PreAuthorization).


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: The examples above represent Sale transactions. Table 1 describes the fields used in retail 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.


Industry Transactions Field Comment

Description Contains comment information about the transaction, and can contain up to 32 alphanumeric characters. This field is often used for order numbers or other internal identifying data meaningful to the merchant.

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

Account Number

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.


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.


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 1.23. If you are performing a Balance Inquiry transaction, you can use any amount, including 0.00, which is usually not allowed. However, we suggest you use the value 1.23 as a consistent default value for other transaction types. For all other transaction types, use the actual amount of the transaction. Billing Postal Code / ZIP Code

Contains the ZIP code of the customer‘s billing address. This field can contain the five or nine-digit ZIP code without spaces or dashes.

NOTE: This field is optional, but required in cases where card swipes don‘t work. Billing Address

Contains the customer‘s billing street address. This field can contain up to 32 alphanumeric characters and allows for spaces and dashes.

NOTE: This field is optional, but required in cases where card swipes don‘t work.



Sample Transactions

Here are a few simple sample transactions. For testing purposes, you can copy and paste any of the following transaction samples into a request file. Be sure to remove any line breaks from these samples in your request file.

Sale Example

"C1","Clerk","Comment","4111111111111111","0612", "1.00","12345","123 MAIN ST"

XML Mode

Clerk Comment 4111111111111111 12 06 1.00 12345 123 MAIN ST

Void Example

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

XML Mode

Clerk Comment 4111111111111111 12 06 1.00 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.


Industry Transactions Credit / Refund / Return Example

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

XML Mode

Clerk Comment 4111111111111111 12 06 1.00 The examples above depict a Credit transaction. Remember that if your processing network performs Terminal-Based settlement, the ICVERIFY software will not send out a real-time request for Credit transactions. In this case, Credit transactions are only sent out during settlement.

Credit Void / Cancel Return / Refund Void Example

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

XML Mode

Clerk Comment 4111111111111111 12 06 1.00 The example above is a Credit Void/Cancel Return/Refund Void transaction. This transaction is used to void Credit transactions.


Industry Transactions Auth Only / PreAuthorization Example

"C6","Clerk","Comment","4111111111111111","0612", "1.00","12345","123 MAIN ST"

XML Mode

Clerk Comment 4111111111111111 12 06 1.00 12345 123 MAIN ST 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 / PostAuthorization Example

"C5","CLK","CMM","4111111111111111","0612","1.00", "APV","12345","123 MAIN ST"

XML Mode

Clerk Comment 4111111111111111 12 06 1.00 APV 12345 123 MAIN ST


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","4111111111111111","0612","1.23", "",""

XML Mode

Clerk Comment 4111111111111111 12 06 1.23 The examples above depict a sample Balance Inquiry transaction. Notice there are comparatively few fields required – essentially the card number, expiration date and a dummy amount value.

Cash Advance Example

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


Industry Transactions XML Mode

Clerk Comment 4111111111111111 12 06 1.23 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.

CardSwiped 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 RequestString Mode

A sample Sale transaction (C1) that does not contain any card-swiped data is shown below. The expiration date field is in bold print: "C1","CLERK1","COMMENT2","4003010123426780", "0512","1.00" Following is a sample card swiped that could be used by an integrated application to create a request file containing swiped data. This swiped data contains Track 1 and Track 2 data, which is separated by start and end sentinels. The start and end sentinels for Track 1 and Track 2 are shown in bold print.


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: "0412B4003010123426780^JANEDOE^041201101002?;4003010123426780= 041201675?" The expiration date is shown in bold print. The percent symbol, which signifies the start of the Track 1 data, is removed from the card swiped information and the resulting string is appended to the expiration date field of the transaction request. Note that the end sentinel for the Track 1 data, as well as the start and end sentinels for the Track 2 data, are still present (in bold print).

Formatting a Request File to Contain Only Track 1 Data (Request String Mode)

If only Track 1 data was desired, then the following information would be appended to the card expiration date in the expiration date field:

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:

"0412B4003010123426780^JANE DOE^041201101002?" The expiration date, followed by the Track 1 data, minus the start sentinel is used.

"04124003010123426780=0412016752001002?" The expiration date and the end sentinel for the Track 2 data have been shown in bold print. Note that the start sentinel for the Track 2 data (a semicolon) is not present.


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 6 9 1

Field name BIN Number Partial Account Number (B) VISA Check Digit

Remarks

Modulo

The discretionary data is formatted as follows:

Size 4

Field name Partial serial number (A)

4

Checksum (C)

Track II:

Remarks The leading part of the serial number The complete checksum

;6010567006473139=00010004000070776619?

Bin Number: 601056 Partial Account Number (B): 700647313 VISA Check Digit: 9 Partial serial number (A): 7077 Checksum (C): 6619 Steps: i. Take part (A) and concatenate part (B). The resulting string is the account serial number. Part (C) is the checksum. The length of the serial number is 13 bytes and the length of the checksum is 4 bytes giving a total length of 17 bytes. This differs from the printed number of 16 bytes. ii. To construct the printed number from Track II data, take part (A), dropping the second digit. iii. Concatenate parts (B) and (C), resulting in the 16 digit printed card number.

Below is an example of the extraction:



Account Number

Sep arat or

Start Sentinel

;

BIN #

Partial ACCT#

60 10 56

7

0064 7313

Expiry Date

Service Code

PVKI

PVV

CK Digit

9

Discretionary data

Leading Digits

=

7777

0001

000

4

0000

7

00647313 6619


0

End Sentinel

Check sum

7 7

6619

?

Industry Transactions Swiped Transaction Support in XML Mode

The implementation of swiped transaction support is somewhat cleaner in XML mode. AccountInfo node contains three subelements: AccountNumber

The

Track1 Track2 As you have already seen, if you can only supply the account number, you simply populate the AccountNumber element of the AccountInfo node. However, if you are able to supply the track data from the card, you can submit it in either the Track1 or Track2 element, or both, depending on how much data you actually read from the card. Don‘t concatenate the track data to the expiration date information the way you would for request-string mode, and drop both the start and end sentinels. If you supply one of the track elements, you generally do not have to supply ExpirationMonth or ExpirationYear in the ExpirationInfo node because this data is embedded in the track.

NOTE: Some card providers do not follow the ISO standards for track data layout. In these cases, you must parse the track data manually and supply the AccountNumber, ExpirationMonth and ExpirationYear elements even if you are also supplying either Track1 or Track2.

Sale Transaction with Track 1 Data Only

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

XML Mode

CLERK1 COMMENT2 B4003010123426780^JANE DOE^051201101002? 1.00

"C1","CLERK1","COMMENT2","4003010123426780","0512B4003010123426 780^JANE DOE^051201101002?","1.00"

You‘ll notice that since track data was submitted in XML mode, there was no need to add the ExpirationInfo node.

Sale Transaction with Track 2 Data Only

The following is an example of a sale transaction containing only Track 2 data. "C1","CLERK1","COMMENT2","4003010123426780","05124003010123426 780=0512016 752001002?""1.00"


Industry Transactions XML Mode

CLERK1 COMMENT2 4003010123426780=0512016 752001002? 1.00 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.

XML Mode

CLERK1 COMMENT2 B4003010123426780^JANE DOE^051201101002? 4003010123426780=0512016 752001002? 1.00

"C1","CLERK1","COMMENT2","4003010123426780","0412B4003010123426 780^JANEDOE^041201101002?;4003010123426780=0412016752001002?"," 1.00"

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.


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.


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, Authorization transactions.

and

Force/Post-

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.


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. Amount

Contains the amount of the sale. Decimal points are not required, but recommended. This field is required.

Billing Postal Code / ZIP Code

Contains the ZIP code of the customer‘s billing address. This field can contain the five- or nine-digit ZIP code without spaces or dashes.

NOTE: This field is required for MOTO transactions, and helps prove that the owner of the card is the person placing the order. Since the card is not present, this information helps prevent fraud.


Industry Transactions Field Billing Address

Book

Description Contains the customer‘s billing street address. This field can contain up to 32 alphanumeric characters and allows for spaces and dashes.

Booking a transaction authorizes and places a hold on the transaction amount. A Book transaction is the first part of a two-part transaction; it cannot be settled until it‘s completed by a Ship transaction. This transaction is used if the merchandise will not be sent to the customer within 24 hours. If the merchandise is to be sent to the customer within 24 hours, then a sale transaction can be performed. You put this information in a quote, comma delimited format that looks like this: "C4","Clerk","Comment","Charge Card","0512", "1.00","ZIP","Address","CVV2" A card can still be approved if the address information is incorrect. It‘s up to each merchant to accept or decline failed AVS transactions based on the information. For more information, see Transaction Responses.

Ship

This transaction is used to complete a Book transaction. It voids the Book transaction and creates a new transaction (Ship). When settlement is performed, this transaction sends the message that the merchandise was sent. Funds are not transferred from a Book transaction until a Ship is performed.

Processing Book and Ship Transactions

For ICVERIFY® to send a transaction to the Processing Network, you must include at least a credit card number, expiration date, and the amount. This information in request-string mode looks as follows:

Book: "C4","Clerk","Comment”","Card#","ExpDate","Amount","ZIP", "Address","CVV2" Ship: "CO","ClK","CMM","4111111111111111","0912","1.00","ZIP", "Address"


Industry Transactions Book Sample – XML Mode

Clerk Comment 4111111111111111 12 09 1.00 12345 123 MAIN ST 123

Ship Sample – XML Mode

Clerk Comment 4111111111111111 12 09 1.00 12345 123 MAIN ST

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 ( as shown in the below examples). The 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.


Industry Transactions Chip Transaction Structure – Request-String Mode

"C1","Clerk","Comment","5413330089010012","1209541333008901001 2=120910100000043900?","1.00","12345","Address","","","","","" ,"","9F03060000000000009F2608E6E8EDBE9F3EB5FE82021800< GS>9F3602006C5F3401009F34034103029F020600000000150 09F2701808407A00000000410109F10120212A5000F0400000 00000000000000000FF9F090200029F3303E0B0C89F1A02099 99F1E0831313131323232329A039808289F35012295058 0400080005F2A0208409F4104000004999C01009F37040 C99FDE05A085413330089010012Y","A0000000041010","Master Card","0"


Industry Transactions Chip Transaction Structure – XML Mode

ClerkComment54133300890100125413330089010012=120910100000043900?09 121.009F03060000000000009F2608E6E8EDBE9F3EB5FE8202 18009F3602006C5F3401009F34034103029F020600 00000015009F2701808407A00000000410109F10120212 A5000F040000000000000000000000FF9F090200029F3303E0B0 C89F1A0209999F1E0831313131323232329A03980828< GS>9F350122950580400080005F2A0208409F410400000 4999C01009F37040C99FDE05A085413330089010012YA0000000041010< ApplicationDisplayName>MasterCard0 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 ( as shown in the below examples) The 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.


Industry Transactions Visa Paywave transaction structure – Request-String Mode "C1","sysadmin","","4005572000000260","1210B4005572000000260^CARD M/VISA^1210621555550123400000000005560000100333080000?;4005572000000260 =12106215555533300081","35.00","12345","Address","","","","","","Y","","","","","","9F260859 0057F092E576079F3602000D9F7C1B0006495353554552000B50524F50524 945544152590004444154419F02060000000000019F6E04207000009F 100706011103A000009F370445692675" Visa Paywave transaction structure – XML Mode swarnendu4005572000000260 B4005572000000260^CARD M/VISA^1210621555550123400000000005560000100333080000? 4005572000000260=12106215555533300081?1012 45.000Y9F2608590057F092E576079F3602000D9F7C1B0006495 353554552000B50524F50524945544152590004444154419F0206000000000001< GS>9F6E04207000009F100706011103A000009F370445692675 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.



Hotel Transactions

The Hotel format contains all of the basic retail transaction types discussed in Handling Retail Transactions, and the Hotel-specific transactions discussed below. ICVERIFY is certified with many processors for the Hotel market format. You will note that a new XML node appears called LodgingInfo. Generally, fields specific to Lodging transactions will appear as elements under this subnode.

NOTE: These are samples only. Other fields may be required by your specific processing network. For a complete list of field descriptions, see Standard Transaction Record Formats and review the information in the Transaction Builder tool provided with your SDK package.

Check-In

This is the initial step in a Hotel billing procedure. This transaction confirms the validity of a customer‘s credit card and pre-authorizes the amount to be billed.

Check-In Transaction Structure – Request-String Mode

"C4","CMc","CMI","ACT","EXP","AMT","CmR","cmR","CMN","CMA", "CMD","Cmr","CmP","CME","Cme"


Industry Transactions Check-In Transaction Structure – XML Mode



Add Charges

This is an incremental transaction type that allows a merchant to decrease a customer‘s open to buy for services such as meals, telephone calls, or gift shop purchases before checkout.

Add Charges Transaction Structure – Request-String Mode

"CG","CMc","CMI","ACT","EXP","AMT","CmR","cmR","CMN","CMA", "CMD","Cmr","CmP","CME","Cme"

Add Charges Transaction Structure – XML Mode



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



Check-Out

This transaction is used when the customer is checking out of a hotel. Charges to a customer‘s card are not settled until a checkout is performed.

Check-Out Transaction Structure – Request-String Mode

"CO","CMc","CMI","ACT","EXP","AMT","CmR","cmR","CMN","CMA", "CMD","Cmr","CmP","CME","Cme"

Check-Out Transaction Structure – XML Mode



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



Level III Purchasing Cards

Level III purchasing cards are business-to-business (B2B) credit cards. They require much more detail than regular credit cards. This section explains what is required. A brief example of the transaction record format for a Level III purchasing transaction is shown below. Refer to the ICVERIFY Purchasing Card Supplement for a detailed discussion of purchasing card processing.

NOTE: The first three lines are actually one line containing the transaction record for the actual transaction. The following lines are records for line item details for the transaction (the line item details in the example are shown in bold to make them more visible). Purchasing Card Sample – Request-String Mode

"C1","clerk","12433254365436","4275330000005810","0909", "40.00","12345","LIIIWithLID","2354325","0.00","0.00","0.00", "0.00","07-30-2003","31432","4254325","45435","3" "P0","0004","Pens","Green","555EEE000","1.0000","Gross", "35.9900","00.00","0.00","0.00" "P0","0003","Pens","Red","444DDD000","1.0000",”Gross", "39.9500","00.00","0.00","0.00" "P0","0003","Pens","Red","444DDD000","1.0000","Gross", "39.9500","00.00","0.00","0.00" Each of the line items for this transaction begins with a P0 field. This indicates a Visa® purchasing card line item. This transaction is in the format that is required for First Data‘s CARDnet (North) platform. The formats for line items vary by the type of card and are described fully in the Purchasing Card Supplement. Currently, only a limited number of Processing Networks support Level III purchasing, which allows the inclusion of line item details for purchase card transactions (line items are descriptions of each item that constitute a purchase). The following section briefly describes how to create transaction records for First Data Commercial Services. Processing Networks and card companies use different formats and have different data requirements, so transaction record formats required for each network are will vary. Be sure to use the Transaction Builder utility found with the ICVERIFY Software Developer‘s Kit on your installation CD-ROM to determine your exact processing requirements.


Industry Transactions Level III Record Formats – RequestString Mode

Commas separate the records listed in this document. These should be converted to quote-comma delimited fields, and populated with data as indicated by the field definition.

NOTE: Usually, a transaction record consists of a single line that is terminated by a carriage return, but Level III purchasing transactions occupy more than one line because of associated line items. Many records end with a CMz field. This field is mandatory, contains two numeric characters, and is right justified. It‘s used to indicate the number of line items that are associated with the transaction. For example, if the CMz field is 1, it means that one line item is associated with the transaction. The value of 0 indicates that no line items are associated with the transaction. A value of 99 would indicate that 99 line items are associated with the transaction (this is the maximum possible value). If this field is populated with a single digit, the position to the left of the field should be null. For example, 1 and 01 are both correct. If the transaction record does not provide a CMz field, no line items may be associated with the record. For example, line items are not required for a void transaction because the transaction record for this transaction type does not include a CMz field. When including line items, be aware that each the line item detail formats for each general type of purchase card (Visa®, MasterCard®, and American Express®) are different. The application writing the transaction must use the correct record type when appending line items to the transaction record when creating the file. Some records contain a cMo field type. The way this field is formatted depends on the type of purchasing card the transaction record represents. If the transaction record is for a Visa® purchasing card, the field is populated with the order date in the following format: 07-22-2003. If the transaction record is for a MasterCard® purchasing card, this field should be left blank.

Level III Record Formats – XML Mode

Creating a Level III transaction using XML mode is relatively straightforward. The purchase order fields are generally confined to a new subnode in the transaction request called PurchaseInfo. You only need to add the PurchaseInfo node and its associated elements to your transaction request to submit your order and line item data. The following sample transaction shows a Sale transaction with both summary and line item details.

NOTE: You do not have to end each element with a newline character. Each element is represented on a separate line here to improve legibility. Copyright © 2011, ICVERIFY, Inc., a First Data company. All trademarks are the property of their respective holders. Page 45 of 119

Industry Transactions Level III Transaction Sample – XML Mode

4275330000005810 12 09 1.00 7.00 ICV1 30329 4 Corporate Square 2 1111 Description123 5 Kg 3.00 1.00 3.00 C 2222 Description123 5 Kg 3.00 1.00 3.00 C



Debit Card Transactions

Hardware issues must be considered when adding debit card processing to an application. In order for a processor to accept a debit transaction, swiped card data is required as well as an encrypted PIN (Personal Identification Number) datagram. Since manually entered card numbers are not accepted by debit processors, a card reader and a PIN Pad are required. You must provide support for these devices in your application if you are not using the ICVERIFY® product for user input.

! ! ! If you are programming your own PIN-based debit transaction interface, it is your responsibility to interact with the PIN pad. You cannot use the ICVERIFY software application to drive the PIN pad device; you must drive it yourself and submit the transaction data to ICVERIFY after you have retrieved it from the device.

Processing Debit Card Transactions

Processing a debit card transaction requires a card reader and an encrypted PIN-pad. A bank must program ATM PIN-pads before they can be used by ICVERIFY. Your PIN-pad must be a serial input PIN-pad, and must be VeriFone 1000- or 2000-compatible. PIN-pads are designed to support either Master Session or DUKPT (Derived Unique Key Per Transaction) encryption of PIN data. In either case, the PIN entered by the cardholder is encrypted and not known to the merchant or the processing network; it is only decrypted by the card issuing bank. DUKPT PIN-pads have already been properly encrypted by your processor or merchant bank with the appropriate configuration and encryption key injection.

Debit Transaction Types

Like credit cards, authorized debit card transactions must be settled before the funds are transferred to your account. The following transaction types are generally available: Sale – Transfers funds from an ATM/debit account to your account (used for all ATM/debit purchases.) Void – Removes an unsettled sale transaction from the open batch (used to remove a debit transaction prior to settlement.) Credit/Return/Refund – Transfers funds from your account to an ATM/debit account (used to reverse a sale transaction that has settled.) Reversal – Reverses an unsettled Sale transaction from an open batch. This transaction is only supported for the FDMS Buypass and FDMS Cardnet processors. It is used to reverse a previous Sale transaction which has received full/partial approval.



Debit Transaction Request Format

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

Debit Transaction Structure – Request-String Mode

"D1","CMc","CMN","AMT","amn","AMt","ACT","BLK", "TDT","PIN" The field definitions are as follows: D1 indicates a debit sale transaction, CMc is the clerk, CMN is the customer name, AMT is the amount of purchase, amn is the additional (cash back) amount, AMt is the total amount including the cash back amount, ACT is the account number, BLK is a empty field, required to process debit transactions properly, TDT is the track data, PIN is the cryptogram returned by the user entering his or her PIN on the input device.

Debit Transaction Structure – XML Mode


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 0001. The following is an example of how request-string transactions should look: "C1","~0001~","comment","5419840000000003","0912", "15.00" "C1","~0002~","comment","4005550000000027","0912", "10.00" "C2","~0001~","comment","5419840000000003","0912", "15.00" In this example, the first request is a $15.00 sale for merchant #1; the second line is a $10.00 sale for merchant #2; the third line voids the first sale for merchant #1. ICVERIFY® sees the ―~0002~‖ and switches to the merchant number stored in ICVE0002.SET. As shown by the example below, a merchant ID need not be numeric. "C1","~MER3~","comment","4005550000000027","0412","10.00" This would use the setup file ICVEMER3.SET. To do transactions for multiple merchants in XML mode, simply overload the ClerkID node with the merchant number in the following way: 0001 0002


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.


Requests and Responses Step 5.

Action Open a text editor, and type the following line: "C1","Clerkfield","Commentfield","5000300020003003", "0912","1.00" This line is a basic sale transaction. There are six fields in this transaction. A set of quotes and a comma separate each field within this transaction. The first field is for the transaction type. The transaction type is a two-character code that tells ICVERIFY® what kind of transaction this is. This field is case sensitive. In the above example, the transaction type is C1. C1 is the ICVERIFY code for Sale. For a list of field types, see Standard Transaction Record Formats. The next two fields are the clerk and comment fields. These two fields can contain alpha and numeric characters only. You don‘t have to enter information in the clerk and comment fields, but you must include the empty fields if you decide not to fill them in. Some merchants use the clerk and comment fields for order numbers or customer names.

NOTE: The Clerk field in the SDK is used by the ICVERIFY software to trigger certain rules for certain transaction types. Generally, the format that you should follow is: "ClerkNameCustomerName" For example, if the Clerk name is Bob and the customer name is John, the field should read: "BobJohn". If you don‘t want to provide either the clerk or the customer name fields, the field should read: "". This is because if you omit the 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 ―‖, unless you are performing an Installment transaction. Installment transactions require the value to appear in the Comment field rather than the Clerk field as follows: "CommentFieldCustomerName"


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 2006. The sixth field is for the amount. A decimal is not needed in this field, but it‘s recommended that it be entered. This transaction contains everything you need to get an authorization from your processing network.

7.

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

8. 9.

Encrypt the request file 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.


Requests and Responses Transaction Responses

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

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.

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.

The evaluated response gives back a letter code followed by a six-digit approval code. Depending on the Processing Network, there may be an eight-digit reference number following the approval code. If address information was included in the transaction, a response is also included. As an example, imagine the following transaction was sent for authorization: "C1","Billy","5000300020003003","0612","25.00","65421","2 Happy Lucky St." The transaction is sent to a terminal based Processing Network and is approved. The response would look like the following: "Y123456Y" The first letter is the answer for the transaction (Y=Approved). only response code you can get for approved transactions.

Card Subtypes

However, Y is not the

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.


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: "Y12345687654321Y" You have eight extra digits following the approval code. These eight digits represent the reference number that was returned by your Processing Network.

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

Partial products for Visa, MasterCard, American Express and Discover. For a partially Authorization 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: ―Y123456Y35.00‖ The amount value specified after the tag is the approved amount which is in this case $35.00. The original amount submitted in the request for this transaction was something greater than $35.00. If the host returns full approval on the original amount submitted in the request, the 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: ―Y123456Y10.00‖ The amount after 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. Copyright © 2011, ICVERIFY, Inc., a First Data company. All trademarks are the property of their respective holders. Page 54 of 119

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 Industry

Transaction Type

FDMS South Retail

Moto

Card Type VIS A Y

MC

Amex

Discover

Y

Y

Y

Full Reversal

Y

Y

Y

Y

Balance Inquiry[1]

Y

Y

Y

N

Balance Receptive with an Authorization Request

Y

Y

N

N

Concurrent Partial Authorization and Balance Reception Partial Authorization

Y

Y

N

N

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

Partial Authorization

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



FDMS Atlanta Industry FDMS Atlanta

Retail

Restaurant

Transaction Type

Card Type VISA

MC

Amex

Discover

Partial Authorization[1]

Y

Y

Y

Y

Full Reversal (online void)[2] Balance Inquiry[3]

Y

Y

Y

Y

N

N

N

N

Balance Receptive with an Authorization Request Concurrent Partial Authorization and Balance Reception Partial Authorization

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Full Reversal

Y

Y

Y

Y

Balance Inquiry

N

N

N

N


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.


Requests and Responses FDMS Nashville Industry FDMS Nashville

Retail

Moto

Transaction Type

Card Type VISA

MC

Amex

Discover


Y

Y

Y

Y

Full Reversal[1]

Y

Y

Y

Y

Balance Inquiry

Y

Y

Y

Y

Balance Receptive with an Authorization Request[2]

Y

Y

Y

Y

Concurrent Partial Authorization and Balance Reception[3] Partial Authorization

N

N

N

N

Y

Y

Y

Y

Full Reversal

Y

Y

Y

Y

Balance Inquiry

Y

Y

Y

Y


Y

Y

Y

Y

N

N

N

N

FDMS Cardnet Industry FDMS Cardnet

Retail

Moto

Restaurant

Transaction Type

Card Type VISA

MC

Amex

Discover

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


Y

Y

Y

Y

Y

Y

Y

Y

Full Reversal

Y

Y

Y

Y

Balance Inquiry

Y

N

Y

N


Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Partial Authorization[4]

Full Reversal

Y

Y

Y

Y

Balance Inquiry

Y

Y

Y

N


Y

Y

Y

Y

Y

Y

Y

Y



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

TSYS Industry

Transaction Type VISA

MC

Amex

Discover

Retail


Y

Y

Y

Y

Full Reversal

Y

Y

N

N

Balance Inquiry

Y

Y

N

N

Balance Receptive with an Authorization Request

Y

Y

Y

Y


Y

Y

Y

Y

Y

Y

Y

Y

Full Reversal

Y

Y

N

N

Balance Inquiry

Y

Y

N

N


Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Full Reversal

Y

Y

N

N

Balance Inquiry

Y

Y

N

N


Y

Y

Y

Y

Y

Y

Y

Y


Y

Y

Y

Y

Full Reversal

Y

Y

N

N

Balance Inquiry

Y

Y

N

N


Y

Y

Y

Y

Y

Y

Y

Y

TSYS

Restaurant

Lodging

MOTO

Card Type



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. 2. 3. 4. 5. 6.

During Promo APR Promo APR (v) Flag After Promo APR After Promo (v) Flag Promo Type Promo Duration

The above promotional data elements received from host will be present at the end of transaction response in the following format: Promo TypePromo Duration During Promo APR Promo APR Flag After Promo APR After Promo Flag The values of the promotional data elements are present in the transaction response as they are received from host. These promotional data values are not formatted or space-trimmed in any way by ICVERIFY. Please use your own formatting on these values if you need to. The values of During Promo APR and After Promo APR are returned in the transaction response as 6 digits as present in host response. To obtain the Percentage APR value you should insert a decimal point after the first two digits and truncate any trailing zeros (if present). Example: If the APR value returned in the transaction response is 299900, the percentage APR value should be 29.99%.

Following is an example for the response received for a private label transaction for GE with promotional data elements: Copyright © 2011, ICVERIFY, Inc., a First Data company. All trademarks are the property of their respective holders. Page 59 of 119

Requests and Responses "Y019275000010WITH PAYMENT DEFERRED INTEREST 12 MONTHS 29990000299900< 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: Billy Comment 5000300020003003 12 09 25.00 65421 2 Happy Lucky St. 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.


Requests and Responses XML Response Sample

0 00 1 X U OK1234 09152005 140415 Q xxxxxxxxxxxx3003 25.00 OTU1MDBBQU9LMDAwNg==

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 XML element. The transaction response containing the prepaid card balance (if returned by host) is contained within the XML element. XML response for a standalone Balance Inquiry transaction also contains the returned card balance with the 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.



0 00 1 X U OK1234 09152005 140415 Q xxxxxxxxxxxx3003 8.27 7.00 OTU1MDBBQU9LMDAwNg==

XML Response Fields

While some of the XML response fields are obvious, others may be a little more difficult to understand. The following table provides a brief description of fields and their meanings.

Table 3

XML Response Fields

Field

Description

ResponseCode

This is the ―master‖ response code and indicates the type of response at a high level. You should check the value in this field before any others. A value of 0 (zero) means the transaction was approved or successfully processed. Other responses indicate various other states. Refer to Appendix A for a list of codes and their definitions.

ResultCode

This code is returned directly from the Processing Network and is generated by the processing platform.


Requests and Responses Field

Description It is proprietary to each network. You may be required to display this value on a screen or print it on receipts. The ICVERIFY application maps the various ResultCode values from all the processors to a common set of ResponseCode values.

ResultMessage

If the processing network has supplied a text message, it will appear in this XML field. You may need to display this value on a screen or print it on receipts. Examples of this field include PLEASE REENTER or PICK UP CARD.

BatchSequence Number

This is a numeric value showing the current batch number in the ICVERIFY application.

AVSResponseCode

The address verification response code returned from the Processing Network. For a list of AVS response codes, see the reference document AVS & CVV Response Codes.

CVVResponseCode

The card verification response code returned from the Processing Network, if your transaction request included CVV2, CVC2 or CID information. For a list of CVV response codes, see the reference document AVS & CVV Response Codes.

ApprovalNumber

A six-position alphanumeric field showing the approval code for an authorization-type transaction (such as a Sale, Book or Auth-Only.)

TransactionDate

The date and time the transaction response was created. The format of TransactionDate is MMDDYYYY while the format of TransactionTime is HHMMSS (24hour notation.)

TransactionTime

CardSubType

This field indicates whether the card used in the transaction is a consumer, corporate, purchasing or commercial card. See the earlier section discussing card subtypes for potential values.

AccountNumber

The account number used for this transaction, with the leading positions masked by x characters.

TransactionAmount

The transaction amount submitted for the transaction.

RawResponse

The actual response message returned from the Processing Network, encoded in Base64 format to guard against special characters. If your application



Description logic requires you to parse the actual processor message, you can Base64-decode this field and perform whatever operations you require.

PROMOTYPE

Promo Type.

PROMODUR

This field is present only for GE private label transaction responses Promo Duration.

DURPROMOAPR

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

The APR value returned is of six digits. To obtain the Percentage APR value, you should insert a decimal point after the first two digits and truncate any trailing zeros (if present). Example: If the APR value returned in the transaction response is 299900, the percentage APR value should be 29.99% Promo APR Flag.

AFTERPROMOAPR

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

The APR value returned is of six digits. To obtain the Percentage APR value you should insert a decimal point after the first two digits and truncate any trailing zeros (if present). Example: If the APR value returned in the transaction response is 299900, the percentage APR value should be 29.99% After Promo Flag.

BalanceAmount

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.

Token

The token id corresponding to the original account

ApprovedAmount



Description number returned by the host.



Processing Offline Group Input or Request Files – Interpreting Results

In file-based integration mode, ICVERIFY® writes the results of the offline group or request session to the offline group output or .ans file. ICVERIFY can return the results from the transmitted offline group in two different ways. The following is an example of a response from an approved MasterCard purchasing card transaction taken directly from the offline group output file.

NOTE: The first three lines should be regarded as one continuous line. The response from the Processing Network is repeated for each transaction or line item associated with the transaction. The field containing the Processing Network‘s actual response is shown in bold print. "C4","clerk","22222","5405010100000016","0912","10.00","11111" ,”NorthStreet","44444","0.00","0.00","0.00","0.00","","55555", "33333","66666","1","","","","""07-222003","13:48:44","Y813484","A1000","","000001" "P0","","Feathers","111AAA000","1.0000","Ton","100.0000","","0 .00","","","","","","","","","","","","","""07-222003","13:48:44","Y813484","","","000001"

The Y at the beginning of the response field indicates that the transaction was approved. This is followed by the approval code for the transaction (the approval code is usually six digits, but the standard length of the approval code can vary depending on the Processing Network that the merchant is using) and an optional reference number. If the software has been configured for address verification, the one-letter AVS response will be included at the end of the approval code: "Y123456Y12345678" For a complete list of AVS response codes, see the document AVS & CVV Response Codes on your installation CD-ROM. If an additional number follows the AVS response, it‘s a reference number for the transaction provided by the Processing Network.

Processing Offline Group Input or Request Files – Interpreting Results: Method 2

It‘s possible to use the Export Transactions feature to export the results of an offline group transmission, but line item details will not be included. The export feature exports the header record for purchasing transactions, but not the line item details. For example, an input file including a single Visa® purchasing card transaction would appear as follows (extra spaces included for legibility):


Requests and Responses "C1","clerk","12433254365436","4275330000005810", "0912","40.00","12345","LIIIWithLID","2354325","0.00","0.00", "0.00","0.00","07-30-2003","31432","4254325","45435"," 3" "P0","0004","Pens,Green","555EEE000","1.0000","Gross", "35.9900","00.00","0.00","0.00" "P0","0003","Pens,Red","444DDD000","1.0000","Gross", "39.9500","00.00","0.00","0.00" "P0","0003","Pens,Red","444DDD000","1.0000","Gross", "39.9500","00.00","0.00","0.00" If the export feature is used, only the information that is bold is available for export (along with the response from the Processing Network). The line items for the transaction (the remaining three entries) are ignored by the export feature as transactions are exported.

Tokenization and Encryption Capability on FDMS Cardnet

From ICVERIFY version 4.2 and above secure transaction processing via tokenization and encryption technologies are supported on the FDMS Cardnet platform. If this support is enabled then the cardholder PAN / track data information being sent to the host from a POS are encrypted. Additional security is provided using tokenization where the real account number is replaced by a token at the POS. If secure transaction processing support is enabled then ICVERIFY sends encrypted track data / account number during authorization. For all subsequent transactions with this account number ICVERIFY uses a token which is returned from the host. For each account number one unique token is returned from the host after authorization. The token length and last four digits will be same as that of the original account number. For any dependent transactions e.g. Void/Force/Credit Refund, token will be used in place of the account number. NOTE: The support for secure transaction processing using data encryption and tokenization is at present supported for FDMS Cardnet platform only. All users doing transaction in Request-Answer (request string or XML) mode will need a token to perform the dependent transactions. This token will be returned in answer file within 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. Copyright © 2011, ICVERIFY, Inc., a First Data company. All trademarks are the property of their respective holders. Page 67 of 119

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 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, ―Y1234560280600158580026‖ Following is a sample response in XML mode, 1 Y OK521C 0812 152501 xxxxxxxxxxxx0026 Y 0000001 1.00 1 0280600158580026 011224231005904 0 MRxBUE9LNTIxQxwwODEyHFkcQTAxNEswMTEyMjQyMzEwMDU 5MDRHNzU4ICAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAcHBwcHBwbQTBWSTAwNENSQyBBMFNQMDM1WFow MDFPMDcwMTYwMjgwNjAwMTU4 NTgwMDI2MTAwMDMwMDIb 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" Copyright © 2011, ICVERIFY, Inc., a First Data company. All trademarks are the property of their respective holders. Page 68 of 119


A sample request with the example token is shown below, "C2","sysadmin","","0280600158580026","1212","1.00","","","","","","","","","0.00","USD","0 .00","","","","Y","" A sample XML request with the example token is given below, Clerk Name 0280600158580026 12 12 1.00 Y


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


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: You can customize your report by changing the values in the parameters or by changing the type of report you run. Refer to the Transaction Builder tool for additional information about report subtypes. Table 4 describes the standard fields used to generate a detail report.


Reports 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 . If you support DCC and a batch contains transactions in multiple currencies, then multiple detail sections in different currencies will be shown in the Detail Report. The Report will be grouped by the currency code. An additional summary section in U.S. Dollars will be present along with the foreign currency for converted transactions. The Grand Total will be printed in U.S. Dollars.

NOTE: Depending on the service pack level of your software, the DCC feature may not be available.

Table 4

Detail Report Field Definitions

Field

Description

RC

Describes the type of transaction to report.

HRD

A yes/no flag specifying whether you wish this report to be spooled to the printer. The print device used will be the one you configured as your report printer in the ICVERIFY Setup Application Printer tab.

SDT

Use the current date to produce a Settlement Preview report (this is the ―processed date range‖ of the transaction requested). Use a date range that spans over a period to produce a Credit Card report. Use the format xx-xx-xxxx.

EDT

Use the current date to produce a Settlement Preview report (this is the ―processed date range‖ of the transaction requested). Use a date range that spans over a period to produce a Credit Card report. Use the format xx-xx-xxxx.

CMN

Contains the customer‘s name.


Reports Field RPS

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. SUM

Enables summary information. Valid values are the following: Y — Totals only N — Include details with totals S — Settlement sub-totals D — Settlement sub-totals with details

TAG

Enables or disables receipt printing. Choose Y to print, choose N to disable.

CMc

Contains the clerk information, and can contain up to 32 alphanumeric characters.

CMM

Contains comment information about the transaction, and can contain up to 32 alphanumeric characters. This field is often used for order numbers (a unique number or alphanumeric sequence that identifies the transaction).

ACT

If you wish to report on a single transaction, you can use this field as a filter on a specific card number. Otherwise, do not enter a value. In request-string mode, you must supply this field even if you leave it blank. In XML mode, you may omit the AccountInfo node if you do not wish to use it.

AMT

Use this field along with the ACT field to filter on a specific transaction. In request-string mode, you must supply this field even if you leave it blank. In XML mode, you may omit the TransactionAmount element if you do not wish to use it.


Reports Field

Description

EXP

If you include an account number in the ACT field, you will need to specify its expiration date. The format in request-string mode is YYMM. In XML mode, you may omit the ExpirationInfo node if you do not wish to use it.

CCD

This is a currency code indicator for Dynamic Currency Conversion reports. You do not need to include this field unless you are using the DCC feature on First Data‘s CARDnet platform.

Report information is located at the beginning of the Detail Report. The introduction includes the report type, dates and time, the company name, and page number, as shown in Figure 7.

Figure 7

Detail Report – Introduction


Reports

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. Copyright © 2011, ICVERIFY, Inc., a First Data company. All trademarks are the property of their respective holders. Page 75 of 119

Reports

Table 5

Card/Comments Fields in the Detail Report

Field T

Description The type of transaction.

NOTE: This field is industry specific. For instance, in the MOTO industry, the most commonly used transaction types are Book (B) and Ship (S). In the food industry the most commonly used transaction are Authorization (A) and Add Tip (T). If your industry is retail then the most commonly used transaction is Sale (S). Type

The type of credit card used for the transaction.

Number

The credit card number used for the transaction.

EXP

The expiration date on the credit card used for the transaction.

Amount

The amount of the transaction.

Date

The date the transaction was executed.

Time

The time of day the transaction was executed.

SEQ#

A sequence number supplied by the Processing Network.

Response

The approval code for the transaction.

NOTE: The word OK before the approval means that the card is good. Customer Name

The customer‘s name as it appears on the credit card used for the transaction.

NOTE: This field is completed only if the credit card was swiped. Clerk

The name of the clerk who took the order.

Comment

Any additional comments regarding the transaction. This field is often used for order numbers (a unique number or alphanumeric sequence that identifies the transaction).


Reports Additional Fields

Right below the credit card number, there are three more fields. The first of the three fields does not have an identifier. This unidentified field is for the customer‘s name that appears on the card used for that particular transaction (swiped cards only). The next two areas are the clerk and comment identifiers. To the right of the clerk and comment identifiers are the fields that contain the information for the identifiers. Some merchants use the comments field for a customer order number.

Credit Card Summary Information

A summary of all credit card activity appears at the bottom of the report in the Credit Card section. The rest of the Detail Report is broken into sections similar to the Credit Card section. If you‘re performing standard processing, your summary will be similar to that shown in Figure 9a. If you‘re performing DCC processing, the summary will be similar to Figure 9b.

Figure 9a

Detail Report, Credit Card Summary – Standard Processing


Reports

Figure 9b

Detail Report, Credit Card Summary – DCC Processing

Visa® & MasterCard® Section

This section shows Visa® and MasterCard® transactions for each card type (Figure 10). It contains the same fields as the Credit Card section, plus a few more.

Figure 10

Detail Report (Visa® and MasterCard® Section)

Detail Report (Visa® and MasterCard® Totals)

This section contains the total of Visa® and MasterCard® transactions. (Figure 11).


Reports

Figure 11

Detail Report (Visa® and MasterCard® Totals)

Detail Report (Defining Visa® or MasterCard® Transactions)

This section of the report breaks down the total dollar amount and defines whether they are Visa® or MasterCard® transactions (Figure 12).

Figure 12

Detail Report (Defining Visa® or MasterCard® Transactions)


Reports

American Express® Section

This section of the report is devoted entirely to American Express® transactions (Figure 13).

Figure 13

Detail Report (Defining American Express® Transactions)

Detail Report (American Express® Transaction Totals)

You will find the number and total dollar amount of American Express® transactions here (Figure 14).

Figure 14

Detail Report (American Express® Transaction Totals)


Reports

Not Captured or Authorized Transactions

The transactions that were not captured or are authorized only and did not settle are displayed in Figure 15.

Figure 15

Detail Report (Not Captured or Authorized Transactions)


Reports

Authorized Transaction Section

The next section of the report shows authorized transactions. This section of the report also includes transactions that were authorized but not captured. For example, a Sale transaction is authorized and captured, but Book transaction is authorized but not captured. Both transaction types are shown in this section.

NOTE: This section of the report does not include transactions that were declined.

Figure 16

Detail Report (Authorized Transaction Section)


Reports

PostSettlement 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: Table 6 describes the fields used to generate a Post-Settlement report.

Table 6

Post-Settlement Report Fields

Field

Description

SP

Describes the type (Settlement report).

of

transaction

to

report

RPS

Allows you to set report options you want to use for each report. Valid values are the following: Y — Captured N — Not captured V — Visa® M — MasterCard® A — American Express® D — Discover®

HRD

Specifies the printer you want to use to print the report. This field should contain the URL or path to the printer in Windows notation.


Reports

Figure 17

Post-Settlement Report (Introduction)

Credit Card Section

The first section of the report indicates the transactions that settled and the total dollar amount of these transactions. They are broken out by credit card type.

Post-Settlement Report (Credit Card Section)

The information shown in Figure 18 is the segment that summarizes the credit card section.

Figure 18

Post-Settlement Report (Credit Card Section)


Reports Authorized Only Transaction Section

The next section of the report identifies those transactions that did not settle— these transactions were authorized only. It also breaks down these transactions by credit card type. Credit card type Total dollar amount of settled transactions

Post-Settlement Reports (Authorized Only Transactions)

Figure 19 displays a summary of Authorized Only transactions that did not settle.

Figure 19

Post-Settlement Reports (Authorized Only Transactions)


Reports

Post-Settlement Report (Unsettled Transactions)

Figure 20 displays a summary of transactions that did not settle.

Figure 20

Post-Settlement Report (Unsettled Transactions)


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 RequestAnswer Interface

To use the Request-Answer file interface, the ICVERIFY application must be set up with a request directory that is used to process transactions. If you are unsure how to do this, refer to the ICVERIFY Setup Guide. The ICVERIFY software polls this directory for request files (.REQ) and writes responses into answer files (.ANS) in a first-in, first-out (FIFO) model. Table 6 illustrates the file naming conventions used when processing transactions using this interface.


Tutorials

Table 6

File Naming Conventions

File Extension

Description

.TMP

A temporary file that stores transactions used to store transactions that need to be processed (one transaction per line). The extension of this file is arbitrary so long as the file extension is NOT .REQ, .HLD, .ZZZ, or .ANS.

.REQ

Rename the temporary file to ICVERxxx.REQ where xxx is the station number. In a single user environment, this is always 001.

.HLD

Created by ICVERIFY® for processing.

.ZZZ

Created by ICVERIFY® for processing.

.ANS

The answer for the transaction(s) processed.


Tutorials

Sample Code Program Flow

To integrate successfully, the client application must follow some basic guidelines. The table below describes the process flow.

Step 1. 2.

3.

4. 5.

Identify global constants Prepare temporary request file or message. For Request-Answer file method, encrypt the transaction records using ICVTnsClient and prepare a temporary request file Rename request file to active file type, or submit the message to the ICVERIFY request directory or ICVERIFY DLL interface for processing. Wait for answer file or response to DLL interface call Process answer file or response


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.


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.


Tutorials Step 3.

Action Rename request file Function Rename_File() As Boolean Dim sTempFile Dim sRequestFile As String

As

String

'build temporary and request file names sTempFile = App.Path + "\" + REQ_FILE_PREFIX + STATION_NUM + ".TMP" sRequestFile = REQUEST_DIR + "\" + REQ_FILE_PREFIX + STATION_NUM + ".REQ" On Error GoTo ErrFileRename 'rename temporary file into REQ file Name sTempFile As sRequestFile The code above renames the temporary request file name (ICVER001.TMP) to a valid request file name (ICVER001.REQ). 4.

Wait for answer file The request file is picked up by the ICVERIFY application and processed into an answer file. Depending on the transaction, the ICVERIFY application may dial the processor (e.g. credit card), request a PIN from the PIN Pad (debit card), return inquiry information such as merchant name, etc. Public Function WaitFor_AnswerFile() As Boolean Dim sAnswerFile As String bCancelWait = False sAnswerFile = REQUEST_DIR + "\" + REQ_FILE_PREFIX + STATION_NUM + ".ANS" 'loop until an answer file is available in the request directory or 'the user clicks the Cancel Wait button Do While (Dir(sAnswerFile) = "") And (Not bCancelWait) DoEvents Sleep (WAIT_SECONDS) Loop The code sample above waits in a while loop for the answer file.


Tutorials 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.


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. transaction.

257

Transaction was declined due to insufficient funds.

258 259

Invalid card number or routing number (if a check transaction.) Expired card or other payment instrument.

260

Call the issuer before proceeding with the transaction.

Do not proceed with the


Response Codes Value 1023 1024

1026

1027

1028 1029 1030 1034

1035

8191

Description 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) Unknown or unexpected error.


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 ACI act

RoutingNumber AccountType PriorAccountNumber

Number Text Number

ACT

AccountInfo. AccountNumber or Track1 or Track2 ApplicationInfo. Applicant. Address2 AdditionalAmount

Check routing (ABA) number Account Type Prior Account Number, generally used if value is being transferred from one stored value card to another Account Number

Primary Applicant Address Line 2 (GE Application Processing)

Text

Additional (Surcharge) Amount Billing Address Primary Applicant Address Line 1 (GE Application Processing)

$Amount

AD2

ADA ADD ADG

ADN ADS

ADT

Amn AMN

BillingAddress ApplicationInfo. Applicant. Address1 ApplicationDisplayName Application Display Name LineItem. Amount Sign, + for debit and – AmountSign for credit, from the cardholder‘s perspective LineItem. Amount Type, used to report a AmountType breakdown of charges by type (for example, tips, fees, and so on) CashBackAmount Additional Cash CashBackAmount

Additional Cash (Cash Back Amount)


Number

Text Text

Text Text

Text

$Amount $Amount

Field Definitions

Field

AMP Amt AMt AMT ANI APV ATM AID BDC BIN BIP BLK CCD CGE

Ch2 CH2 CH3 CHK CID CKN CKR CLK cMa cMA CMA CMc CMD Cme CME CMF

XML Element Name PurchaseInfo. PurchaseItems. LineItem. ItemAmount TransactionAmount TransactionAmount TransactionAmount CustomerPhoneNumber ApprovalNumber LodgingInfo. ArrivalTime ApplicationID BypassDupCheckFlag BalanceInformation BillPaymentIndicator n/a DccInfo. CurrencyCode ApplicationInfo. Applicant. City AccountInfo. AccountNumber AccountInfo. AccountNumber AccountInfo. AccountNumber AccountInfo. AccountNumber CardVerificationFlag CheckNumber RoutingNumber ClerkID LodgingInfo. DepartureDate LodgingInfo. OriginalDepartureDate LodgingInfo. ArrivalDate ClerkID LodgingInfo. DepartureDate LodgingInfo. ChargeCodes LodgingInfo. ExtraChargeAmount Descriptor

Description

Data Type

Purchase Amount

$Amount

Additional Amount Total Amount Amount Customer Phone Number Approval Code Arrival Time

$Amount $Amount $Amount Text Text Number

Application ID Duplicate Check Balance Information Bill Payment Indicator Blank field Foreign Currency Code

Text Text Y/N Y/N Text Text

City

Text

Account Number

Text

Account Number

Number

Account Number

Text

Account Number

Number

Card Verification Indicator Check Number Check routing (ABA) number Clerk Number New Departure Date

Text Number Number Number Date

Original Departure Date

Date

Arrival Date

Date

Clerk Departure Date

Text Date

Charge Codes

Number

Additional Charges

$Amount

Charge Description

Text


Field Definitions

Field

XML Element Name

Cmi CMI

InvoiceNumber LodgingInfo. InvoiceNumber PurchaseInfo. DiscountAmount Comment CustomerName CustomerOrderID PurchaseInfo. OrderDate CustomerOrderID CustomerOrderID CustomerOrderID OperatorID PurchaseInfo. ShippingPostalCode PurchaseInfo. SendingPostalCode LodgingInfo. PreferredCardholderFlag DescriptorCode ReferenceNumber LodgingInfo. RoomRate LodgingInfo. RoomNumber PaymentTermCode ClerkID PurchaseInfo. PurchaseOrderID PurchaseInfo. PurchaseOrderID PurchaseInfo. CustomerCode PurchaseInfo. AlternateOrderID PurchaseInfo. CustomerCode SalesTaxAmount SalesTaxAmount SalesTaxAmount PurchaseInfo. DutyAmount PurchaseInfo. PurchaseItemCount PurchaseInfo. FreightAmount

Cmm CMM CMN cmO cMo Cmo CmO CMO CMo cmp cmP CmP CMP cmR Cmr CmR CMR CMS Cmt CMt Cmw CMw CMW cMX CMx CMX CMY CMz CMZ

Description

Data Type

Invoice Number Invoice/folio Number

Number Number

Discount Amount

$Amount

Comment Customer name Reference Number Order Date

Text Text Text Date

Customer Order Number Customer Order Number Customer Order Number Operator ID Destination zip code

Text Text Text Text Text

Original zip code

Text

Preferred cardholder?(y/n)

Text

Descriptor codes Reference number Room rate Room number Ticket terms Server ID Merchant Order Number

Number Text $Amount Text Number Text Text

Merch Order #/Purchase ID

Text

Customer Code

Text

Alternate purchase order number Customer Code/Reference ID

Text Text

Sales Tax Tax Amount Tax Amount Duty Amount

$Amount $Amount $Amount $Amount

Total Addenda

Number

Freight Amount

$Amount


Field Definitions

Field

XML Element Name

Description

Data Type

CNB

Client Order ID

Text

COD COI CPI CRD

CustomerANICode CashOutFlag CardPresentFlag DccInfo. ConversionDate DccInfo. ConversionTime PurchaseInfo. PurchaseItems. LineItem. ItemCode ApplicationInfo. CrossSellFlag PurchaseInfo. SummaryCommodityCode CardVerificationValue CardVerificationValue DestCountryCode ApplicationInfo. DualCreditFlag DeferredBillingFlag PurchaseInfo. PurchaseItems. LineItem. ItemDescription PurchaseInfo. PurchaseItems. LineItem. ItemDescription DccInfo. DccStatusIndicator ApplicationInfo. Applicant. IdentificationNumber IdentificationNumber IdentificationNumber IdentificationNumber ApplicationInfo. Applicant. IdentificationState DeferredNumberOfPayme nts BirthDate ShippingState DepartmentCode

Client Order ID (Citi Private Label) Customer ANI Code Cash out Card Present Indicator Currency Conversion Date

Text Y/N Y/N Date

Currency Conversion Time

Text

Commodity Code

Text

Cross-Sell Indicator

Y/N

Summary Commodity Code

Text

CVV2/CVC2/CID CVV2/CVC2/CID Destination Country Code Dual Credit Indicator

Text Text Text Y/N

Deferred Billing Flag Description

Text Text

Description

Text

DCC Status

Text

Drivers License Number

Text

Drivers License Number Customer ID Drivers License Number Drivers License State

Text Text Text Text

CRT CT3

CSI CT4 CVv CVV DCC DCI DEF DEM

DEV

DFG DL1

DLE DLI DLN DLS

DNP DOB DPC dpc

Deferred Number of Payments Date of Birth Destination State Code Department Code


Number Date Text Text

Field Definitions

Field

XML Element Name

DPM DPP DSC

DebtPaymentFlag DeferredPaymentPlan PurchaseItems. LineItem. ItemDiscountAmount Descriptor

dsc DTM DTP DXP

E01 E03

E09

E16

E18

E19

E20

EDT EMV EST EXP

EXR FAM

LodgingInfo. DepartureTime DeferredTimePeriod ApplicationInfo. Applicant. IdentificationExpiration Date PurchaseInfo. NationalTaxAmount PurchaseInfo. CustomerVatRegistration Number PurchaseInfo. PurchaseItems. LineItem. ItemUnitOfMeasure PurchaseInfo. PurchaseItems. LineItem. ItemUnitCost PurchaseInfo. PurchaseItems. LineItem. ItemTaxAmount PurchaseInfo. PurchaseItems. LineItem. ItemQuantity PurchaseInfo. UniqueVatInvoice ReferenceNumber ReportEndDate EMVTagInfo EscheatableFlag ExpirationInfo. ExpirationMonth & ExpirationYear DccInfo. ExchangeRate DccInfo.

Description Debt payment Deferred Payment Plan Discount amount

Data Type Text Number $Amount

Description of purchase for GE private label transactions Departure Time

Number

Deferred Time Period Drivers License Expiration

Number Date

National Tax Amount

$Amount

Customer Number

VAT

Registration

Unit of measure

Text

Text

Text

Unit cost

Number

VAT / Tax Amount

$Amount

Quantity

Number

Unique VAT Invoice Reference Number Ending date EMV Tag Info Escheatable Indicator Expiration Date

Foreign Currency Rate Foreign Amount

Exchange


Text

Date Text Y/N/X Date

Amount Amount

Field Definitions

Field FBC

FBK HRD IAT INC ins IQT ISW

LNI

XML Element Name ForeignAmount PurchaseItems. LineItem. ItemDCFlag EMVFallBack PrintFlag LineItem. ItemAmount InvoiceNumber InstallmentCount LineItem. ItemQuantity SwipeData

MON NRI NSF OAM OPR OTD OTT pc1

ApplicationInfo. LanguageIndicator MerchantOrderNumber NetworkReferenceID NoNSFFlag OriginalTransactionAmount OriginalTransactionID OriginalTransactionDate OriginalTransactionTime ProductCode1

pc2

ProductCode2

pc3

ProductCode3

pc4

ProductCode4

pc5

ProductCode5

pCI

ApplicationInfo. CreditInsuranceFlag ApplicationInfo. Applicant. MobilePhoneNumber ApplicationInfo. Applicant. BirthDate ApplicationInfo. Applicant. HousingFlag ApplicationInfo.

PCN

PDB

pHI

pHN

Description Debit/credit flag

Data Type Text

EMV FallBack Printer?(y/n) Unit cost of line item

Text Y/N Amount

Invoice Number Number of Installments Item quantity

Text Number Number

Data for check transaction processing; may be manually entered or retrieved from a MICR reader Language Indicator

Text

Merchant Order Number Network Reference Identifier No NSF Original Transaction Amount Original Purchase Reference Original Transaction Date Original Transaction Time Product Code 1 (Citi Private Label) Product Code 2 (Citi Private Label) Product Code 3 (Citi Private Label) Product Code 4 (Citi Private Label) Product Code 5 (Citi Private Label) Credit Insurance

Text Number Y/N/X $Amount Text MM/DD/YYYY hhmmss Text

Primary Cell Phone

Text

Text Text Text Text Y/N Number

Date of Birth

Date

Housing Information

Text

Home Phone


Number

Field Definitions

Field

PIF

pIM pIN

PIN pJI pPC Pmn

pMn

pmN

PR6 PR8 PRD

PRI pRN

pSN

PSU PTA

PTC PTJ

pWN

XML Element Name Applicant. HomePhoneNumber ApplicationInfo. Applicant. IncomeFrequency ApplicationInfo. RequestedAmount ApplicationInfo. Applicant. Income PINData ApplicationInfo. JointApplicationFlag ApplicationInfo. ProductCode ApplicationInfo. Applicant. FirstName ApplicationInfo. Applicant. MiddleName ApplicationInfo. Applicant. LastName SKUData DeferredBillingFlag PurchaseInfo. ProductCode PartialRedemptionFlag ApplicationInfo. Applicant. RelativePhoneNumber ApplicationInfo. Applicant. SSN SKUData ApplicationInfo. Applicant. TimeAtResidence PromotionalCode ApplicationInfo. Applicant. TimeAtJob ApplicationInfo. Applicant. WorkPhoneNumber

Description

Data Type

Income Frequency

Text

Initial Requested Amount

Number

Monthly Income

Number

Pin data

Text

Joint Indicator

Y/N

Product Code First Name

Text Text

Middle Name

Text

Last Name

Text

SKU Data Deferred Payment Indicator Summary Product Code for Visa purchasing card transactions Partial Redemption Indicator Relative Phone Number

Text Number Text

SSN

Number

Y/N Number

Product SKU Time at Residence

Text Text

Promotional Code Time at Job

Number Text

Application Number

Work

Phone


Number

Field Definitions

Field

XML Element Name

Description

Data Type

PYN

PurchaseCardFlag

Y/N

PYT

PaymentType

QUa

PurchaseInfo. PurchaseItems. LineItem. ItemQuantity TransactionID RecurringFlag TransactionReversalFlag ReportOptions ReportOptions RetailTermsCode ApplicationInfo. CoApplicant. Address2 ApplicationInfo. CoApplicant. Address1 ApplicationInfo. CoApplicant. MobilePhoneNUmber ApplicationInfo. CoApplicant. City ApplicationInfo. CoApplicant. BirthDate ApplicationInfo. CoApplicant. IdentificationNumber ApplicationInfo. CoApplicant. IdentificationState ApplicationInfo. CoApplicant. IdentificationExpiration Date ReportStartDate ApplicationInfo. CoApplicant. IncomeFrequency ShippingMethod ApplicationInfo.

Purchase Card Indicator for American Express transactions Payment Type indicator for Paymentech Stored Value transactions; used for reporting purposes only Quantity

REF RER REV RPD RPS RTM SA2

SAD

SCN

SCY

sDB

SDL

SDS

SDX

SDT SIf

SIM sIN

Text

Text

Reference Number Recurring Flag Reversal Flag Report options (or enter) Report options (or enter) Retail Terms Secondary Applicant Address 2nd Line

Number Text Y/N Rpt. Options Rpt. Options Text Text

Secondary Applicant Address

Text

Secondary Phone

Applicant

Cell

Secondary Applicant City

Number

Text

Secondary Applicant Date of Birth

Number

Secondary Applicant Drivers License

Text

Secondary Applicant DL State

Text

Secondary Expiration

DL

Text

Starting date Secondary Applicant Income Frequency

Date Text

Applicant

Shipping Method Secondary Applicant Income


Text Number

Field Definitions

Field

Smn

sMn

smN

SMT sPH

SPN

SRS

sSN

SST

StE STA

STC STE STG

STJ

SUM SVI SZP

TDT

XML Element Name CoApplicant. Income ApplicationInfo. CoApplicant. FirstName ApplicationInfo. CoApplicant. MiddleName ApplicationInfo. CoApplicant. LastName SurchargeAmount ApplicationInfo. CoApplicant. WorkPhoneNUmber ApplicationInfo. CoApplicant. HomePhoneNUmber ApplicationInfo. CoApplicant. HousingFlag ApplicationInfo. CoApplicant. SSN ApplicationInfo. CoApplicant. State IdentificationState ApplicationInfo. CoApplicant. TimeAtResidence ShippingCountry IdentificationState ApplicationInfo. Applicant. State ApplicationInfo. CoApplicant. TimeAtJob ReportSummaryIndicator StoredValueIndicator ApplicationInfo. CoApplicant. PostalCode AccountInfo. Track1 or Track2

Description

Data Type

Secondary Applicant First Name

Text

Secondary Applicant Middle Name

Text

Secondary Applicant Last Name

Text

Surcharge Amount Secondary Applicant Work Phone Number

Number Number

Secondary Phone Number

Number

Secondary Housing Info

Secondary SSN

Text

Number

Secondary Applicant State of Residence

Text

State code Secondary Applicant Time at Address

Text Text

Ship-To Country Code State Code State Code

Text Text Text

Secondary Applicant Time at Job

Text

Summary only? (y/n/s/d) Stored Value Card Indicator Secondary Applicant ZIP Code

Text Text Text

Track data

Text


Field Definitions

Field

XML Element Name

TDY TIP

TenderType RestaurantInfo. TipAmount TypeOfIndustry ProcessingTypeIndicator

TOI TOP

TTI

TXD TXI

UOM

PurchaseInfo. PurchaseItems. LineItem. TaxTypeIdentifier HostTransactionID TaxAmountIndicator

UR1

PurchaseInfo. PurchaseItems. LineItem. ItemUnitOfMeasure PurchaseInfo. PurchaseItems. LineItem. ItemUnitCost UserField1

UR2

UserField2

Vat

PurchaseInfo. VatTaxAmount VisaPaywave PurchaseInfo. VatTaxRate PurchaseInfo. PurchaseItems. LineItem. ItemTaxRate PurchaseInfo. PurchaseItems. LineItem. TaxRate PurchaseInfo. ShippingPostalCode BillingPostalCode ApplicationInfo. Applicant. PostalCode

UPR

VPW VtR VT2

VT5

Zip ZIP ZP2

Description Tender Type Tip Amount

Data Type Text $Amount

Type of Industry Type of Processing for GE private label transactions: E = Easy LID, M = Manufacturer Tax Type Identifier

Text Text

Transaction ID Tax Amount Indicator (0 = tax not provided, 1 = tax included, 2 = tax exempt) Unit of Measure

Text Text

Unit Price

User Field 1 for First Data Gift Card transactions User 2 for First Data Gift Card transactions VAT / Tax Amount

Text

Text

$Amount

Text Text $Amount

Visa Paywave taginfo Summary VAT / Tax Rate for a purchasing card transaction VAT / Tax Rate for an individual line item within a purchasing card transaction.

Text Number

VAT / Tax Rate for an individual line item within a purchasing card transaction.

Number

Destination ZIP Code ZIP Code ZIP Code


Number

Text Text Number

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.


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

Book B Ship S

Sale S Void Sale V

Sale S

Credit/Return C or R Credit Void V Pre-Auth/ AuthOnly P Force Sale F

Void Sale V Credit/Return C or R Credit Void V Pre-Auth/ AuthOnly P Force Sale F

Food Charge Card Types

Hotel / Lodging Charge Card Types

Authorization A Add Tips T (force) Sale S

Check-in I Check-out O

Void Sale V Credit/ Return C or R Credit Void V Pre-Auth/ AuthOnly P Force Sale F

No-show N Sale S


Extended Stay E

Void Sale V Credit/Return C or R Credit Void V Pre-Auth/ AuthOnly P Force Sale F

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

Description

ABA (American Bankers Association) Routing Number Account number

Unique bank identifying number that directs electronic ACH deposits to the proper bank—this number precedes the account number printed at the bottom of a check. This number is usually printed with magnetic ink.

ACH

A method of transferring funds between banks via the Federal Reserve System. ACH is used by most, but not all, financial institutions.

Acquirer

See acquiring financial institution.

Acquiring financial institution

A financial institution enables the merchant to accept credit card transactions. Merchants must maintain accounts with an acquiring financial institution to be able to process credit card transactions.

A unique sequence of numbers assigned to a cardholder account, which identifies the issuer and type of financial transaction card.

The acquiring financial institution deposits the daily credit card sales into the merchant‘s account, minus applicable fees. Address Verification Service (AVS)

See AVS.

Agent bank

A bank that participates in another bank's card program, usually by turning over its applicants for bankcards to the bank administering the bankcard program and by acting as a depository for merchants.

Approval

An acceptance of payment—a code is issued by a card-issuing bank allowing a sale to be charged against a cardholder‘s account. The amount is within the cardholder‘s remaining credit limit and that the card has not been reported lost or stolen. Approvals are requested via an authorization.

American Express®

An organization that issues cards and acquires transactions (unlike Visa® and MasterCard®, which are bank associations). Copyright © 2011, ICVERIFY, Inc., a First Data company. All trademarks are the property of their respective holders. Page 108 of 119

Glossary Term

Description

Arbitration

The procedure used to determine the responsibility for a Chargebackrelated dispute between two member banks. See Chargeback.

Asynchronous

A method of transmitting data in which the data elements are identified with special start and stop characters. An asynchronous modem cannot communicate with a synchronous modem. Contrast synchronous.

Auth file

See transaction file.

Auth only

See Terminal Capture.

Automated Clearing House Authorization

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

An alphanumeric value returned from the processor for successful transactions. If a transaction fails authorization, an authorization code is not returned from the processor.

Average ticket

The average dollar amount of merchant credit transactions.

AVS (Address Verification Service)

AVS matches the first five digits of the street address and the ZIP code information from the cardholder‘s collected billing address to the corresponding bill information on record with the card issuers. A code representing the level of match is returned. AVS codes cannot be obtained independent of an authorization, and it‘s up to the merchant to decide whether to fulfill an order. If the AVS code fails, the authorization will not fail. For Terminal Capture merchants, the authorization will be returned successfully. For Host Capture (AuthCapture and Auth/PostAuth) merchants, the authorization will be downgraded to an auth. The downgraded authorization must then be manually settled.

Bank Identification Number

The digits of a credit card that identify the issuing bank. The first six digits of a card number are often referred to as a BIN.

Basis Point

One one-hundredth of a percent. Discount rates are expressed as basis points. Copyright © 2011, ICVERIFY, Inc., a First Data company. All trademarks are the property of their respective holders. Page 109 of 119

Glossary Term

Description

Batch

A collection of transactions. Usually a merchant has one batch per day or per shift.

Batch processing

A type of data processing where related transactions are transmitted as a group for processing.

BIN

See Bank Identification Number.

Bundled rate

A discount rate that includes communications costs as well as transaction fees. Also referred to as flat rate.

Cancellation number

A number provided by a resort, hotel or motel to verify a cardholder's notification to cancel a guaranteed reservation or advance deposit.

Capture

A process in which a credit card sale or return transaction is submitted for financial settlement. Authorized credit card sales must be captured and settled for a merchant to receive the funds. See settlement.

Card issuer

See issuing financial institution.

Chargeback

The act of taking back funds (for a disputed or improper credit card transaction) that have been paid to a merchant. This procedure is initiated by the issuer after the acquirer has begun the clearing process.

Chargeback period

The number of calendar days in which an issuer may charge sales back to the merchant, beginning the day after the date the record is first received by the merchant or bank, and continuing until the end of the day on which it‘s dispatched as a Chargeback item.

Chargeback reason code

A two-digit code identifying the specific reason for the Chargeback.

Check guarantee

A service which guarantees check payment (up to the limit defined for the account) provided that the merchant follows correct procedures in accepting the check. The service determines whether the check writer has previously written delinquent checks.

Clearing

The process of exchanging financial details between an acquirer and an issuer to facilitate posting of a cardholder's account and reconciliation of a customer's settlement position.

Close batch

The process by which transactions with authorization codes are sent to the processor for payment to the merchant.


Glossary Term

Description

Confirmation letter

A letter sent by a processor to a merchant at a specified interval to verify batch deposits.

Copy request

See retrieval request.

Credit

A return of funds to a cardholder's account (crediting entry) for a sale that has already been authorized and settled.

Custom Payment Services (CPS)

CPS regulations require additional customer information to be sent from the merchant to the credit card processor, increasing security of the transaction. CPS compliant transactions receive the best possible transaction rates.

CID CVC2 CVV Indicator

Card Identification. Only for American Express®, Discover®, JCB/Discover and Diners/Discover cards Card Verification Code 2. Only for MasterCard®. 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)

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.

Debit card

An ATM bankcard used to purchase goods and services and to obtain cash, which debits the cardholder's personal deposit account. Requires a Personal Identification Number (PIN) for use.

Decline

A response to a transaction request meaning that the issuing bank will not authorize the transaction. A decline message is accompanied by the error code from the Processing Network. Each Processing Network has its own set of error codes, so the format of the error response will vary according to the Processing Network that the merchant has been Copyright © 2011, ICVERIFY, Inc., a First Data company. All trademarks are the property of their respective holders. Page 111 of 119

Glossary Term

Description configured to use. If transactions are declined with a Call Center or Voice Auth message, this usually indicates that the merchant needs to call the Processing Network to obtain an approval code for the transaction. This approval code can then be used by the merchant to complete the transaction using a Force/Ticket Only/Post Authorization transaction.

Deferred Billing Deferred 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

The bank into which merchant deposits funds from credit card transactions.

Discount rate

The percentage of credit card sales amounts the acquiring financial institution charges the merchant for the settlement of the transaction.

Draft capture

Refers to settlement.

DUKPT PINpad

A Derived Unique Key Per Transaction (DUKPT) PINpad is used if you want to process debit card transactions. DUKPT PINpads have already been properly encrypted by your Processor or Merchant bank with the Processor‘s configuration and key injection.

ECI

Electronic Commerce Indicators.

Electronic Cash Register (ECR)

The combination of a cash register and a point-of-sale (POS) terminal, often PC-based.

Electronic Draft Capture (EDC)

A system in which each transaction is routed to the host computer for processing and storage. The stored transactions are used to create settlement files and transaction reports.

Electronic Funds Transfer (EFT)

A method of incrementing or decrementing an account through electronic means, eliminating the need for paper checks or withdrawal Copyright © 2011, ICVERIFY, Inc., a First Data company. All trademarks are the property of their respective holders. Page 112 of 119

Glossary Term

Description slips.

Encrypt

To scramble a message so that a key, held only by authorized recipients is needed to unscramble and read the message. When the encrypted data is routed through a gateway, it‘s decrypted and processed. All processed information (approved/declined transactions) is then 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.

External Sales Agent (ESA)

A term used by American Express® for Independent Sales Organizations (ISOs) and MSPs.

Floor limit

Rarely used now, this was a preset limit established by an issuer that allowed merchants to accept credit card sales without authorization provided the merchant check to see that the card number was not listed on a Warning Bulletin for lost or stolen cards.

Force

A transaction type used primarily to enter a voice approved sale transaction into an open batch. For example, a merchant submits a card for approval gets a ―voice authorization‖ message and calls the merchant help desk for a voice authorization. The merchant help desk gives the merchant an approval code for the transaction over the phone. The merchant can then enter the transaction into the open batch using a force transaction and the approval code provided by the merchant help desk. A force can also be used to complete a Terminal Capture transaction.

Host Capture

A processing model by which payment information is stored at the processor rather than the software. This processing model consists of two methods for authorizing and capturing transactions: AuthCapture and Auth/PostAuth. See AuthCapture and Auth/PostAuth.

Host computer

Refers to the computer at the processor that is dialed for authorization and settlement.

Imprint

A form of proof that the credit card was present for the transaction. It can be electronic (by swiping a card through a card reader) or manual (by obtaining a physical imprint using an imprinter), but one of the two ways is always required for card-present transactions.

Independent Sales Organization (ISO)

See ISO.

Interchange

The flow of information between issuers and acquirers (for example, transactions, retrieval requests, and chargebacks). Copyright © 2011, ICVERIFY, Inc., a First Data company. All trademarks are the property of their respective holders. Page 113 of 119

Glossary Term

Description

Interchange fee

The fee that the merchant‘s bank pays the consumer‘s bank for each credit card transaction that is settled.

ISO

A Visa® term for a company that is sponsored by an acquiring bank to solicit, and sometimes support, merchants.

Issuing

Providing a bankcard to a cardholder and authorizing that person to use it to complete financial transactions.

Issuing financial institution

The financial institution that extends credit to a consumer through credit card accounts. The financial institution issues a credit card and bills the consumer for purchases against the credit card account. Also referred to as the cardholder‘s financial institution or issuer.

Keyed entry

See manual entry.

Local review

The ability for a merchant to review, from his or her terminal, the contents of a batch before or after settlement.

Magnetic Ink Check Reader (MICR) MAG stripe

A device that reads characters (i.e. account information) printed on a check with ink containing particles of a magnetic material.

Magnetic stripe

A stripe on the back of a bankcard that contains magnetically encoded cardholder account information. The name of the cardholder is stored on Track I, the account number and expiration date are stored on Track II. Also referred to as MAG stripe.

Manual entry

Credit card information that is entered via terminal keypad or keyboard instead of swiping the card through a card reader.

MasterCard

An association of banks that governs the issuing and acquiring of MasterCard credit card transactions and Maestro debit transactions.

Member

A financial institution that is a member of Visa ® USA and/or MasterCard® International. A member is licensed to issue cards to holders and/or accept merchant drafts.

Member Provider Merchant

Service

See magnetic stripe.

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. Copyright © 2011, ICVERIFY, Inc., a First Data company. All trademarks are the property of their respective holders. Page 114 of 119

Glossary Term

Description

Merchant agreement

A written agreement between a merchant and a bank (or possibly a merchant, a bank, and ISO) containing their respective rights, duties, and warranties with respect to acceptance of the bankcard and matters related to bankcard activity.

Merchant bank

A bank that has entered into an agreement with a merchant to process bank card transactions. Also referred to as acquirer or acquiring bank.

Merchant category code Merchant Identification Number (MID) Merit

See SIC code.

MID

See Merchant Identification Number.

MICR

See Magnetic Ink Check Reader.

Modem

MOdulator / DEModulator. An electronic telecommunications hardware device that is used by the terminal or PC POS to dialup the processor.

MOTO

Mail Order/Telephone Order.

MSP

See Member Service Provider.

Multi-trans mode

A host computer that allows multiple transactions with the same telephone call.

Net bank

The bank that maintains the settlement account and that executes funds transfers with member clearing banks.

settlement

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.

Network

The setup of hardware and software that allows multiple computers to connect and communicate with each other electronically or through the use of fiber optics.

Network Reference Identifier (NRID) Node

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.

Non-qualified

A broad term that describes a transaction that did not interchange at the best rate because it was entered manually or it was not settled in a timely manner. Copyright © 2011, ICVERIFY, Inc., a First Data company. All trademarks are the property of their respective holders. Page 115 of 119

Glossary Term

Description

Offline

An operating mode in which the software or service is not connected to the processor in real time. This mode is often used when a merchant is batch-processing transactions.

Online inquiry

Some processors offer PC inquiry to the host system to view transactions, Chargebacks, and so on.

Open to buy

The amount of credit available at a given time on a cardholder's account.

Original draft

The original copy of the forms and signature used in the transaction. Also referred to as hard copy.

Packet-switched network

A nationwide network of circuits that allow a computer to dial a local number and communicate with another computer also on the network, such as the Internet.


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.

PC application

POS

Personal Identification Number (PIN) PIN

See PIN.

Point of Sale (POS)

The place and time at which a transaction occurs. This term also refers to the devices or software used to capture transactions.

POS

See Point of Sale.

Post-Authorization

A transaction that has been submitted for completion and has completed a payment.

Posting

The process of recording debits and credits to individual cardholder account balances.

Pre-Authorization

See Auth only.

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.


Glossary Term

Description

Prestigious properties

A $500, $1000 or $1500 floor limit at designated hotels/resorts. Floor limit‘s returned as part of authorization response.

Prior sale

A transaction for which authorization was obtained at an earlier time (for example, a merchant had to call for authorization or a merchant authorized the card before services were rendered). See Terminal Capture.

authorized

Private label card

A bankcard that can be used only in a specific merchant's store. Typically not a bankcard.

Processor

A transaction processor; a large computer center that processes data from credit card transactions and settles funds to merchants.

PSIRF

The highest qualification that a Visa® transaction can obtain. Card must be swiped and transaction deposited within 24 hours.

Qualification

A level at which a transaction interchanges. The level of qualification is dependent on how credit card number is entered, how quickly a transaction is settled, type of industry, specific information, and so on.

Receipt

A hard copy description of the transaction that occurred at the point of sale. Minimum information contained on a receipt is: date, merchant name and location, account number, type of account used (for example, Visa®, MasterCard®, American Express®, and so on), amount, reference number and/or authorization number, and action code.

Recurring transaction

A transaction that is periodically charged to the cardholder‘s account, such as a subscription fee. The merchant must get permission from the cardholder to do this.

Reference number

A code given to a transaction by Host Capture processors.

Release

The merchant instructs the software to close a batch. This applies only to the Host Capture processing model. Cardholders are not charged (or merchant accounts credited) until a batch is released. Compare deposit.

Retrieval request

A request to a merchant for documentation concerning a transaction, usually a Cardholder dispute or suspicious sale/return. A retrieval request can lead to a Chargeback.

Settle

See settlement.

Settlement

A process in which a credit card transaction is settled financially Copyright © 2011, ICVERIFY, Inc., a First Data company. All trademarks are the property of their respective holders. Page 117 of 119

Glossary Term

Description between the merchant‘s acquiring financial consumer‘s credit card issuing financial institution.

institution

and

the

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. contain 2 entries: SKU code/value

SKU Data

Corresponding dollar amount for this SKU A maximum of 7 SKU data can be entered per transaction. Slid entry

See swiped card. Compare manual entry.

Standard

The lowest qualification level at which a Visa® or MasterCard® transaction may interchange. Caused when a transaction is deposited several days after the original authorization and not swiped.

Stripe read

See swiped card.

Surcharges

Any additional charges to a merchant's standard processing fees. They are a result of non-qualified transactions of different communications methods. 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.

Suspense

Swiped card

Credit card information that is read into ICVERIFY® directly as a result of swiping (or sliding) the credit card through a card reader. The information magnetically encoded in the magnetic stripe is transmitted. This information includes secret data that helps validate the card. Compare manual entry.

Synchronous

A method of transmitting data in which the data elements are sent at a specific rate so that start and stop characters are not needed. This is used by older modems. Contrast asynchronous. Copyright © 2011, ICVERIFY, Inc., a First Data company. All trademarks are the property of their respective holders. Page 118 of 119

Glossary Term

Description

Travel and Entertainment (T&E) Card

Credit cards that typically require payment in full each month (for example, American Express®, Diner‘s Club®, and Carte Blanche®).

Terminal Capture

A processing model by which payments are authorized immediately and stored in a batch file. Batch files are sent by the merchant to the processor for settlement. Also referred to as Auth Only.

Third-party processor

A non-member agent employed by an acquiring bank, which provides authorization, settlement and merchant services to a merchant.

Ticket only

A sale transaction for which you have received a voice authorization.

Transaction

A financial interaction that changes the financial position of the parties involved. The Cash Register recognizes several types of transactions: invoiced, authorized, and post-authorized transactions; returns, voids, and voided returns; payment transactions and refund transactions. See authorized transaction, refund, return, void, and voided return.

Transaction fee

A ―per transaction‖ charge incurred by merchants who are on scale pricing. This is in addition to the percentage discount fees.

Transaction file

A file created by processors that contain all of the transactions for the previous day. Some processors create two files, one of authorizations and one of settled transactions.

Vendor file

See transaction file.

Visa®

An association of banks that governs the issuing and acquiring of Visa ® credit card transactions.

Voice authorization

A transaction authorization that is provided by an operator, usually when an issuer sends a ―Please Call‖ message to the merchant instead of an authorization number.

Void

A correction transaction used by a merchant. There is only a small period of time in which a purchase can be canceled. Voids are typically handled by issuing credit to the consumer‘s account. A void is transaction specific, and must be entered in the same batch as the original purchase.


ICVERIFY SDK Guide

ICVERIFY SDK Guide

Suggest Documents

Mobile SDK Development Guide - GitHub

sdk integration guide - Adattract [PDF]

sdk integration guide - Adattract [PDF]

AtariArcade SDK Quick- Start Guide

Virtual Infrastructure SDK Programming Guide

Salesforce Mobile SDK Development Guide

SAP BusinessObjects Dashboards Component SDK User Guide

SAP BusinessObjects Dashboards Component SDK Installation Guide

vSphere SDK for .NET Developer's Guide - VMware

SAP BusinessObjects Dashboards Component SDK User Guide

Adobe Photoshop Lightroom SDK 3.0 Guide

Installation Guide for SAP Mobile SDK

AWS SDK for Java Developer Guide — Amazon.com

Foxit PDF SDK DLL 2.0 Guide

SAP BusinessObjects Dashboards Component SDK User Guide

Adobe Photoshop Lightroom SDK 4 Programmers Guide

Installation Guide for Sybase Mobile SDK

vSphere SDK for Perl Programming Guide - VMware

VMware Guest SDK Programming Guide - VMware Documentation

ACTi SDK

SDK Reinvented

Tutorial - C2Call iOS SDK - C2Call SDK Reference

FxISO sdk

Android SDK