iTransact iTransact, Gateway User Manual

Download

iTransact Gateway User's Guide

Table of Contents

1. Version and Legal Information ................................................................................... 1

2. Credit Card Merchant Accounts ..................................................................................2

Which Credit Card Processing Platforms/Networks Is The Gateway Compatible With? What

Information Is Required To Enable Credit Card Processing? ........................................2

FIRST DATA - Canada/NABANCO/FDMS SOUTH .....................................2

FIRST DATA - CARDNET ........................................................................ 2

FIRST DATA - FDR OMAHA ETC TYPE 7 ................................................ 2

PAYMENTECH/GENSAR .........................................................................2

NDC/GLOBAL ATLANTA EAST ............................................................... 3

ELAVON/NOVA ....................................................................................... 3

TSYS - VITAL/VISANET .......................................................................... 3

EXCHANGE - HEARTLAND ....................................................................3

3. Transaction Formats .................................................................................................5

Should I Use The HTML Connection Method Or The XML Connection Method? ...........5

Why Should I Use The HTML Connection Method? ..........................................5

Why Should I Use the XML Connection Method? .............................................5

How Can I Verify A Card Without Actually Charging It? ........................................... 5

4. The Control Panel ....................................................................................................6

What Are The Features Of The Control Panel? How Do I Log In? ................................ 6

The Virtual Terminal - How Do I Run A Transaction? ....................................... 6

The Account Settings - How Do I Modify My Information? .............................. 25

The Merchant Toolkit - What Information Should I Give To My Web Designer? .. 35

The Transaction Listing - How Can I View My Transactions? ........................... 47

The Transaction Detail Window - How Can I View My Customer's Information? .. 56

The Batch Settlement Options Window ......................................................... 64

The Form Wizard - How Can I Generate An Order Form For My Site Quickly? .... 66

The Auction PayMe Interface - Can I Use My Account For Auction Sales? .......... 78

The Recurring Transaction Window - How Does The Recurring Billing System Work?

............................................................................................................... 80

The ChargeBack Interface - What If I Get A Chargeback? .............................. 117

The Post-A-Credit Interface - How Can I Generate A Refund? ......................... 118

The Card Setup Interface - How Do I Add My Merchant Account To My Gateway Ac-

count? ................................................................................................... 120

The Check Setup Interface - How Do I Accept Payments From Checking Accounts?

............................................................................................................. 140

5. Gateway Emails .................................................................................................. 143

What Emails Are Sent By The Gateway? ............................................................. 143

Account Activation Email ......................................................................... 143

Transaction Confirmations ........................................................................ 143

Transaction Failure Notifications ............................................................... 156

Credit Card Settlement Notifications ........................................................... 158

Check Statistics Reports ........................................................................... 158

Auction PayMe Communications ............................................................... 159

Gateway Notifications .............................................................................. 161

6. Transaction Failure Responses ............................................................................... 164

What Are The Potential Failure Responses On Credit Card Transactions? .................. 164

NBE Errors ............................................................................................ 164

NAVS Errors ......................................................................................... 170

NBF Errors ............................................................................................ 172

NCVV Errors ......................................................................................... 174

THR Errors ............................................................................................ 175

VCC Errors ............................................................................................ 175

VALSYS Errors ...................................................................................... 175

iTransact Gateway User's Guide

REQUEST_VALIDATION Errors ............................................................. 175

REQUEST_FORMAT Errors .................................................................... 175

7. Deposits ............................................................................................................. 176

How Long Do Deposits Take? ........................................................................... 176

Credit Card Deposits ................................................................................ 176

Check Deposits ....................................................................................... 176

8. Gateway Glossary ................................................................................................ 177

Glossary of Terms ........................................................................................... 177

SEC Code Information ..................................................................................... 179

List of Figures

4.1. Control Panel Example ...........................................................................................6

4.2. Standard Virtual Terminal Welcome Section Example .................................................. 7

4.3. Standard Virtual Terminal Order Section Example ....................................................... 7

4.4. Standard Virtual Terminal Payment Section Example ................................................... 9

4.5. Standard Virtual Terminal Recurring Section Example ............................................... 11

4.6. Standard Virtual Terminal Information Section Example ............................................ 11

4.7. Approval Page Example ....................................................................................... 13

4.8. Classic Virtual Terminal Welcome Section Example .................................................. 13

4.9. Classic Virtual Terminal Transaction Information Section Example .............................. 14

4.10. Classic Virtual Terminal Payment Section Example ................................................. 15

4.11. Classic Virtual Terminal Shipping Section Example ................................................. 17

4.12. Approval Page Example ...................................................................................... 18

4.13. Swipe Virtual Terminal Welcome Example ............................................................ 18

4.14. Swipe Virtual Terminal Transaction Information Example ........................................ 19

4.15. Swipe Virtual Terminal Entry Section Example ....................................................... 21

4.16. Swipe Virtual Terminal Information Section Example .............................................. 21

4.17. Approval Page Example ...................................................................................... 22

4.18. Swipe Express Welcome Section Example ............................................................. 23

4.19. Swipe Express Entry Section Example ................................................................... 23

4.20. Swipe Express Amount Section Example ............................................................... 23

4.21. Approval Page Example ...................................................................................... 24

4.22. Account Settings Welcome Example ..................................................................... 25

4.23. Account Settings General Section Example ............................................................ 26

4.24. Account Settings Email Section Example ............................................................... 26

4.25. Account Settings Advanced Features Section Example ............................................. 27

4.26. Account Settings Test Section Example ................................................................. 28

4.27. Account Settings Customer Email Section Example ................................................. 28

4.28. Account Settings Fraud Controls Example .............................................................. 29

4.29. IP Filter Settings Example ................................................................................... 30

4.30. Account Settings Card Section Example ................................................................ 33

4.31. Account Settings Check Section Example .............................................................. 34

4.32. Account Settings Style Settings Example ............................................................... 34

4.33. Account Settings Style Color Bar Example ............................................................. 35

4.34. Merchant Toolkit Example .................................................................................. 35

4.35. HTML Toolkit Example ..................................................................................... 37

4.36. HTML Order Form Template Section Example ....................................................... 38

4.37. HTML Form Functions Section Example ............................................................... 39

4.38. Advanced HTML Features Section Example ........................................................... 42

4.39. Customizable HTML Section Example .................................................................. 43

4.40. Standard Transaction Listing Example ................................................................... 47

4.41. Advanced Transaction Listing Example ................................................................. 52

4.42. Transaction Detail Window Example .................................................................... 56

4.43. Options Window Example ................................................................................... 59

4.44. Recurring Detail Window Example ....................................................................... 61

4.45. Main Settlement Window Example ....................................................................... 64

4.46. Successful Settlement Response Example ............................................................... 66

4.47. Failed Settlement Response Example .................................................................... 66

4.48. Form Wizard Example ........................................................................................ 67

4.49. Split Form Wizard Example ................................................................................ 68

4.50. Form Wizard Instructions Example ....................................................................... 69

4.51. Form Wizard Items Example ............................................................................... 69

4.52. Split Form Example ........................................................................................... 70

4.53. Standard Form Wizard Example ........................................................................... 71

iTransact Gateway User's Guide

4.54. Form Wizard Instructions Example ....................................................................... 72

4.55. Form Wizard Items Example ............................................................................... 72

4.56. Standard Form Example ...................................................................................... 73

4.57. BuyNow Wizard Example ................................................................................... 75

4.58. Form Wizard Instructions Example ....................................................................... 76

4.59. BuyNow Wizard Items Example ........................................................................... 76

4.60. BuyNow Example ............................................................................................. 77

4.61. Auction PayMe Interface Example ........................................................................ 78

4.62. Auction PayMe Request Email Example ................................................................ 79

4.63. Auction PayMe Form Example ............................................................................ 79

4.64. Payment Success Page Example ........................................................................... 80

4.65. Recurring Transaction Recipe Window Example ..................................................... 80

4.66. Recurring Recipe Builder Example ....................................................................... 82

4.67. Transaction Listing Example ............................................................................... 86

4.68. Transaction Detail Access Window Example .......................................................... 86

4.69. Transaction Detail Example ................................................................................. 87

4.70. Recurring Detail Example: Non-Recurring Transaction ............................................. 88

4.71. Recurring Setup Information Page Example ............................................................ 88

4.72. Recurring Virtual Terminal Welcome Section Example ............................................ 89

4.73. Recurring Virtual Terminal Transaction Information Section Example ......................... 90

4.74. Standard Virtual Terminal Payment Section Example ............................................... 91

4.75. Standard Virtual Terminal Recurring Section Example ............................................. 93

4.76. Standard Virtual Terminal Information Section Example ........................................... 94

4.77. Approval Page Example ...................................................................................... 95

4.78. Transaction Listing Example ............................................................................... 96

4.79. Transaction Detail Access Window Example .......................................................... 96

4.80. Transaction Detail Example ................................................................................. 97

4.81. Recurring Detail Example: Recurring Transaction .................................................... 99

4.82. Recurring User Info Editing Interface Example ..................................................... 100

4.83. Recurring User Info Changed Example ................................................................ 102

4.84. Successful Update Page Example ....................................................................... 102

4.85. Recurring Items Editing Interface Example ........................................................... 103

4.86. Recurring Items Changed Example ..................................................................... 104

4.87. Transaction Listing Example ............................................................................. 107

4.88. Transaction Detail Access Window Example ........................................................ 107

4.89. Transaction Detail Example ............................................................................... 108

4.90. Recurring Detail Example: Recurring Transaction .................................................. 109

4.91. Transaction Listing Example ............................................................................. 110

4.92. Transaction Detail Access Window Example ........................................................ 111

4.93. Transaction Detail Example ............................................................................... 111

4.94. Recurring Detail Example: Recurring Transaction .................................................. 112

4.95. Recurring Setup Edit Page Example: Recurring Transaction .................................... 113

4.96. Recurring Transaction Recipe Window Example ................................................... 114

4.97. Scheduling Tool Example ................................................................................. 115

4.98. Scheduling Calendar Tool Example .................................................................... 116

4.99. Scheduling Tool Example ................................................................................. 116

4.100. Successful Schedule Example ........................................................................... 117

4.101. ChargeBack Interface Example ......................................................................... 117

4.102. Post-A-Credit Interface Example ...................................................................... 118

4.103. Card Setup Interface Example .......................................................................... 120

4.104. FDR Canada Card Interface Example ................................................................. 122

4.105. First Data CardNet Setup Interface Example ....................................................... 124

4.106. First Data Nabanco Setup Interface Example ....................................................... 126

4.107. FDR Omaha Setup Interface Example ................................................................ 128

4.108. Paymentech Setup Interface Example ................................................................ 130

4.109. NDC Setup Interface Example .......................................................................... 132

4.110. Elavon/Nova Setup Interface Example ............................................................... 134

4.111. Visanet Setup Interface Example ....................................................................... 136

vii

iTransact Gateway User's Guide

4.112. Exchange Setup Interface Example .................................................................... 138

4.113. Main Check Setup Interface Example ................................................................ 140

4.114. EFT Setup Interface Example ........................................................................... 141

viii

List of Tables

4.1. Background Example ........................................................................................... 44

4.2. Background Color Example .................................................................................. 44

4.3. Font Color Example ............................................................................................. 44

4.4. Active Link Example ........................................................................................... 44

4.5. Link Example ..................................................................................................... 45

4.6. Visited Link Example .......................................................................................... 45

4.7. MerText Example ............................................................................................... 45

4.8. Disable_Cards Example ........................................................................................ 45

4.9. Disable_Checks Example ..................................................................................... 45

4.10. Show_Items Example ......................................................................................... 46

4.11. Mast Image Example .......................................................................................... 46

4.12. Elavon/Nova AVS Responses .............................................................................. 49

4.13. First Data AVS Responses ................................................................................... 49

4.14. NDC Global AVS Responses ............................................................................... 50

4.15. Visanet AVS Responses ...................................................................................... 50

4.16. Paymentech AVS Responses ............................................................................... 50

4.17. CVV Responses ................................................................................................ 51

4.18. HTML Recurring Example .................................................................................. 85

4.19. XML Recurring Example .................................................................................... 85

4.20. XMLTrans2.cgi RecurUpdate Example ............................................................... 105

4.21. XMLTrans2.cgi RecurUpdateResponse Example ................................................... 106

4.22. XMLTrans2.cgi RecurDetails Example ................................................................ 106

4.23. XMLTrans2.cgi RecurDetailsResponse Example ................................................... 107

5.1. Account Activation Email Example ...................................................................... 143

5.2. Merchant Credit Card Sale Confirmation Email Example .......................................... 143

5.3. Customer Credit Card Sale Confirmation Email Example .......................................... 144

5.4. Merchant Checking Account Sale Confirmation Email Example ................................ 145

5.5. Customer Checking Account Sale Confirmation Email Example ................................ 145

5.6. Merchant Void Transaction Confirmation Email Example ......................................... 146

5.7. Customer Void Transaction Confirmation Email Example ......................................... 146

5.8. Merchant Credit/Refund Transaction Confirmation Email Example ............................ 147

5.9. Customer Credit/Refund Transaction Confirmation Email Example ............................ 147

5.10. Merchant Preauth Transaction Confirmation Email Example .................................... 148

5.11. Customer Preauth Transaction Confirmation Email Example ................................... 149

5.12. Merchant Postauth Transaction Confirmation Email Example .................................. 149

5.13. Customer Postauth Transaction Confirmation Email Example .................................. 150

5.14. Merchant Force Transaction Confirmation Email Example ...................................... 150

5.15. Customer Force Transaction Confirmation Email Example ...................................... 151

5.16. Merchant Recurring Credit Card Transaction Confirmation Email Example ................ 152

5.17. Customer Recurring Credit Card Transaction Confirmation Email Example ................ 153

5.18. Customer Recurring Credit Card Transaction Confirmation Email Example ................ 153

5.19. Merchant Recurring Check Transaction Confirmation Email Example ....................... 154

5.20. Customer Recurring Check Transaction Confirmation Email Example ....................... 155

5.21. Sale Failure Notification Email Example .............................................................. 156

5.22. Recurring Transaction Failure Email Example ....................................................... 156

5.23. Customer Recurring Credit Card Transaction Confirmation Email Example ................ 157

5.24. Settlement Email Example ................................................................................ 158

5.25. Settlement Email Example ................................................................................ 159

5.26. Auction PayMe Customer Request Email Example ................................................ 159

5.27. Auction PayMe Merchant Transaction Confirmation Email Example ......................... 159

5.28. Auction PayMe Customer Transaction Confirmation Example ................................. 160

5.29. Account Activation Email Example .................................................................... 161

5.30. Gateway Settings Notification Example ............................................................... 161

iTransact Gateway User's Guide

5.31. MerchantUpdates Email Example ....................................................................... 162

5.32. Account Suspension Email Example ................................................................... 162

5.33. Account Closure Email Example ........................................................................ 163

5.34. Account Re-Activation Email Example ................................................................ 163

Chapter 1. Version and Legal Information

iTransact Gateway User's Guide

Version: 2.12 Date: 2/2/12 Copyright: iTransact, 2012

Chapter 2. Credit Card Merchant Accounts

Which Credit Card Processing Platforms/Networks Is The Gateway Compatible With? What Information Is Required To Enable Credit Card Processing?

Our software is certified on most of the main credit card processing networks. If you do not have a merchant account, please contact your sales rep. If you do have a merchant account, it must be compatible with the gateway system. The following Processing Platforms/Networks are compatible and can be used by a merchant utilizing the gateway if the required information is submitted:

FIRST DATA - Canada/NABANCO/FDMS SOUTH

Required Information

• Merchant Number (11 Digits)

• Terminal ID (2 Digits - Default 99)

• Serial Exchange/S.E. Numbers (If accepting AMEX/Discover)

• Discover Serial Exchange Number (10 Digits)

• AMEX Serial Exchange Number (10 or 11 Digits)

FIRST DATA - CARDNET

Required Information

• CardNet Merchant Number (12 Digits)

• CardNet Terminal ID (6 Digits)

FIRST DATA - FDR OMAHA ETC TYPE 7

Required Information

• Merchant Number (12, 15 or 16 Digits)

• Device ID (4 Digits - Default 0001)

PAYMENTECH/GENSAR

Account MUST be Terminal-Based

Credit Card Merchant Accounts

Required Information

• Client/ISO/Bank Number (4 Digits)

• Merchant Number (12 Digits)

• Terminal Number (3 Digits)

NDC/GLOBAL ATLANTA EAST

Account MUST be Terminal-Based Required Information

• Bank ID Number (6 Digits)

• Terminal Number (7 - 13 Digits)

ELAVON/NOVA

VAR Type: PaymentClearing Account Settlement Type MUST be Manual - Not Auto Required Information

• Bank ID Number (6 Digits)

• Terminal Number (16 Digits - Generally ending in 99, 98, or 97)

TSYS - VITAL/VISANET

Required Information

• Terminal ID/V# (7 or 8 Digits)

• Merchant Number (12 Digits)

• Bank ID Number / BIN (6 Digits)

• Terminal Number (4 Digits)

• Store Number (4 Digits)

• Agent Number (6 Digits)

• Chain Number (6 Digits)

• Merchant Category / SIC Code (4 Digits)

EXCHANGE - HEARTLAND

Credit Card Merchant Accounts

Required Information

• Terminal ID/V# (7 or 8 Digits)

• Merchant Number (12 Digits)

• Bank ID Number / BIN (6 Digits)

• Terminal Number (4 Digits)

• Store Number (4 Digits)

• Agent Number (6 Digits)

• Chain Number (6 Digits)

• Merchant Category / SIC Code (4 Digits)

Chapter 3. Transaction Formats

Should I Use The HTML Connection Method Or The XML Connection Method?

You can communicate with the gateway via an HTML form post or via an XML query request. Full functionality of the software's features can be utilized in either case.

Why Should I Use The HTML Connection Method?

The HTML Connection Method utilizes an HTTPS form post to pass information securely from your order form to our transaction servers. This method can be easily integrated into any web-site. This method can be used by merchants who have their own secure servers and by merchants who do not have secure servers. Merchants who do not have a secure server should use our Split Form-Based Protocol and merchants who have a secure server should use our Standard Form-Based Protocol. The Form Creation Wizard within the Control Panel may be used to create an HTML order form for the merchant's site, which can modified as needed. Two advanced features of the HTML Method are the Lookup and Passback functions, which allow a merchant to receive transaction data delivered to a dynamic script on their server via an HTTPS post.

Why Should I Use the XML Connection Method?

The Front End XML Connection Method provides merchants with a powerful protocol for submitting transactions to the gateway. This type of integration gives the merchant or developer complete control of the transaction process, since requests and responses are handled within the same HTTPS connection. The use of XML allows developers to create their own Windows COM objects, Java apps, PHP routines, Perl libraries, standardized Web Services, etc. If an application can generate XML, it can process transactions. Since the Front End XML method is simply another method for processing sale transactions, all gateway features remain available

How Can I Verify A Card Without Actually Charging It?

The gateway offers an AVSOnly feature that allows a merchant to submit credit card information to validate without charging the card. This function will validate address verification information and CVV data. To attempt an AVSOnly transaction, submit a $0.00 sale transaction (using any method) and it will be run as an AVSOnly transaction. That transaction will generate an XID. A merchant can set that transaction to recur or can run a resubmit for an actual charge against the card.

Chapter 4. The Control Panel

What Are The Features Of The Control Panel? How Do I Log In?

The Control Panel is an excellent interface that allows a merchant the ability to manage and use all aspects of the Gateway Software account. A merchant can log into and access the Control Panel. To log in, a merchant will need to provide their five digit gateway ID and the then current gateway password. If a merchant has lost the password, they can contact the support team. An open session will expire after 10 minutes of inactivity.

Figure 4.1. Control Panel Example

The Virtual Terminal - How Do I Run A Transaction?

Many merchants enjoy the ease of using our Virtual Terminal system. Many merchants use it in addition

The Control Panel

to their online store front websites. However, some merchants use it as their credit card processing system at their brick and mortar store fronts. This simple interface enables a merchant to process a customer's credit card manually without having to incur the expense of purchasing a credit card swipe terminal. This interface can also be used in conjunction with a manual USB magnetic card reader that will automatically populate the fields for a merchant. There are five separate interfaces that a merchant can use when utilizing the Virtual Terminal.

Virtual Terminal Interface (Standard)

The Standard Virtual Terminal Interface is the page that opens by default when a merchant clicks on the Virtual Terminal link from the Control Panel. This interface allows for a merchant to type in several different items for purchase, as well as separate shipping and tax charges for the entire purchase. Recurring transactions can also be entered here. The interface can be used for check/EFT/NACHA or credit card payments.

Welcome Section

When the Virtual Terminal opens, the merchant is greeted with their business name, gateway ID number and the format options at the top of the interface (See Standard Virtual Terminal Welcome Section Ex- ample). A merchant using the Standard Virtual Terminal does not need to click on any of the optional interfaces.

Figure 4.2. Standard Virtual Terminal Welcome Section Example

Order Information Section

Figure 4.3. Standard Virtual Terminal Order Section Example

The Control Panel

Some of the entry fields in this area are required and others are optional (See Standard Virtual Terminal Order Section Example). A merchant can choose to enter up to ten separate items plus shipping and tax amounts, or can submit a single item which is a total of the amount to be billed to the customer. To access items 6-10, please use the scroll bar on the left side of the "Total" column.

• Item Description - A merchant should enter the name of the product that a customer is purchasing

in this field. This information will be recorded in the merchant's Transaction Listing in the Control Panel and in the Merchant/Customer confirmation emails. Some merchants choose to enter all of the items in a single line item - either with each item detailed, or with a generic description like "Purchased Items". This can be done as long as the value for the Item Qty is "1" and the total price of the purchase is entered into the Item Price field.

• Item Qty - This value will be multiplied by the amount listed in the Item Price field to provide the

value for the Item Total. This value can be "1", even if you are selling multiple quantities - as long as the Item Price amount is the cost of all of the products combined.

• Item Price - The amount listed here will be multiplied by the value listed in the Item Qty to provide

the value for the Item Total.

• Item Total - This value is arrived at when the Virtual Terminal automatically multiplies the value of

the Item Qty and the Item Price for a single item.

• Total - This amount is the sum of the Item Totals for all items purchased.

• Include Shipping Checkbox - This should be selected if a merchant would like shipping to be a

separate line item. This must be used in conjunction with an entry in the Shipping Amount field.

• Shipping Amount - This value should be the amount of shipping for the entire purchase. The Virtu-

al Terminal does not calculate shipping. A merchant will need to calculate that prior to entering the

transaction in this interface. If the Include Shipping checkbox is selected, there must be a value in this field.

• Include Tax Checkbox - This should be selected if a merchant would like tax to be a separate line

item. This must be used in conjunction with an entry in the Tax Amount field.

• Tax Amount - This value should be the amount of tax for the entire purchase. The Virtual Terminal

does not calculate tax rates. A merchant will need to calculate that prior to entering the transaction in this interface. If the Include Tax checkbox is selected, there must be a value in this field.

• Order Total - This value is the sum of the Total, the Shipping amount, and the Tax amount. This is

the amount that will be charged to the customer's card. If this value is zero for a credit card, the transaction will run as an AVSOnly transaction.

• Email Text - This field allows a merchant to enter a message up to 255 characters which will dis-

play on both the merchant confirmation email and on the customer confirmation email.

Payment Information Section

This area of the interface will look different for each merchant depending on what payment types they are authorized to accept.

The Control Panel

Figure 4.4. Standard Virtual Terminal Payment Section Example

To begin to enter payment information, a merchant must select the radio button for the customer's payment method (either Check or Credit Card). This radio button will enable the appropriate/required fields for the payment type and disable the others.

• Credit Card Information - These fields will be enabled if a merchant selects the Credit Card Pay-

ment Method radio button.

• Card Number - The customer's credit card number should be entered into this field without any

The Control Panel

dashes or spaces.

• Exp. Date - The expiration month and year should be selected in this area.

• Approval Code - The value for this field can only be obtained directly from the Credit Card

Merchant Account Processor's Voice Approval phone service. This feature should only be used if a "call authorization center" error response was received during a previous authorization attempt. The approval code will be a numeric or alpha-numeric code provided by the Voice Approval service. The gateway does not provide voice approval codes. Those codes must be obtained directly from the Merchant Account Processor.

• CVV Number - The value for this field is the CVV or CVV2/CID code listed on the credit card.

This three or four digit numeric code is used as a fraud deterrent.

• Auth Only Checkbox - A merchant should never check this box, unless they do not desire to ac-

tually charge a customer's card. When this is selected the transaction will only run a "preauthorization" which verifies the card account and a set amount in the account, but it does not actually charge the card. The pre-authorized amount is "frozen" on the account. A pre-authorized transaction can be converted to a full transaction by running a post-authorization from the Transaction Listing. If no post-authorization is run, the money is never paid to the merchant and the "frozen" funds will be released back to the customer's available credit limit after 10 business days.

• Checking Account Information - These fields will be enabled if a merchant selects the Check Pay-

ment Method radio button.

• ABA Number - This is the nine digit ABA Routing number for a customer's bank. These are

generally the first nine numbers listed in the line of numbers across the bottom of a check.

• Account Number - This is the customer's checking account number as it appears on a check.

• Account Type - (For EFT Transactions Only) A merchant needs to use the selection tool to in-

dicate whether the customer's checking account is a Personal or a Business checking account.

• Account Source - A NACHA authorized merchant needs to use the selection tool to indicate

whether the customer's checking account is a checking or a savings account.

• SEC Code - (For EFT Transactions Only) Depending upon the nature of the EFT processing ac-

count, a merchant may be required to designate the three letter Standard Entry Category for the transaction. Potential values are:

• PPD - Prearranged payment and deposit

• CCD - Corporate credit or debit

• ARC - Accounts receivable entry

• BOC - Back office conversion

• POP - Point of purchase

• RCK - Returned check entry

• WEB - Internet initiated entry

• TEL - Telephone initiated entry

Recurring Information Section

If your transaction needs to be set as a recurring transaction, click the "Toggle" button to display the appripriate entry fields.

Figure 4.5. Standard Virtual Terminal Recurring Section Example

Recurring Fields

• Recipe Name - This drop down menu displays all of a merchant's pre-built recipes, which will

provide the rules and schedule by which a transaction will re-bill when set with at least one remaining repetition.

The Control Panel

• Number of Repetitions - This is the numeric value for the amount of times the Recurring Recipe

needs to cycle. Each successful repetition will cycle down the number of remaining repetitions by one until it reaches zero.

• Recurring Total - If the amount that is to recur is the same as the total amount listed in the Initial

Transaction Information, please leave this blank. This feature can be used in conjunction with Recurring Recipes designated by the merchant as a "Split Amount" recipe. When an amount is entered into this field, that Recurring Total will be the amount billed when the transaction recurs. For example, merchants who bill a one time setup fee and then a different amount for monthly service fees, would put the amount of the monthly service fee in the Recurring Total field.

• Recurring Description - If the Item Description used in the Initial Transaction Information is a suf-

ficient explanation for both the initial payment and any subsequent recurring transactions, please leave this blank. If, however, the merchant would like this to display differently on subsequent recurring billings, please enter an adequate description in this field.

Additional Information Section

This area of the interface allows the merchant do enter customer data that will be saved to the gateway.

Figure 4.6. Standard Virtual Terminal Information Section Example

The Control Panel

• Billing Information - All fields here are required unless otherwise indicated.

• First Name - This should be the customer's first name.

• Last Name - This should be the customer's last name.

• Address - This should be the cardholder's street address as listed with the account issuer.

• City - This should be the cardholder's city as listed with the account issuer.

• State - This should be the state abbreviation of the cardholder as listed with the account issuer.

• ZIP - This should be the cardholder's postal code as listed with the account issuer.

• Country - This should be the cardholder's country as listed with the account issuer.

• Phone - This should be a contact phone number for the customer.

• Cust ID - This is an optional field that allows a merchant to enter a tracking number for their

customers.

• Email - This should be the customer's email address. The transaction confirmation email will be

sent to this address.

• Optional Shipping Information - Each of these fields are optional and can be populated with al-

ternative shipping address data. The processing banks are unable to verify this information.

Submitting a Transaction Through The Virtual Terminal Interface (Standard)

The Control Panel

To submit a transaction through this interface, enter the correct data into the required fields and any of the desired optional fields. Be sure to double check the credit card number as well as the amount of the charge. Click the "Process Payment" button. The transaction will be attempted in real-time. The gateway will either display an approval screen or a failure screen. The failure screen will list the reason for the failure. An approval page will display if the transaction is successful.

Figure 4.7. Approval Page Example

Virtual Terminal Interface (Classic)

The Classic Virtual Terminal Interface can be accessed by clicking on the "Classic Virtual Terminal" link in the Standard interface. Choosing this interface allows for the entry of only one Order Item, as well as separate shipping and tax charges.

Figure 4.8. Classic Virtual Terminal Welcome Section Example

Transaction Information Section

The Control Panel

Figure 4.9. Classic Virtual Terminal Transaction Information Section Example

At the top of this interface, there are links to the Recurring Transaction virtual terminal and the Swipe Card interface. The top of the form also identifies the merchant and displays the five digit gateway ID.

• Required Fields - A merchant using this interface is required to fill out each of the following fields

in the Transaction Information Section:

• First Name - This should be the customer's first name.

• Last Name - This should be the customer's last name.

• Address - This should be the cardholder's street address as listed with the account issuer.

• City - This should be the cardholder's city as listed with the account issuer.

• State - This should be the state abbreviation of the cardholder as listed with the account issuer.

• ZIP - This should be the cardholder's postal code as listed with the account issuer.

• Country - This should be the cardholder's country as listed with the account issuer.

The Control Panel

• Phone Number - This should be a contact phone number for the customer.

• Email Address - This should be the customer's email address. The transaction confirmation

email will be sent to this address.

• Item Description - A merchant should enter the name of the product that a customer is purchas-

ing in this field. This information will be recorded in the merchant's Transaction Listing in the Control Panel and in the Merchant/Customer confirmation emails.

• Item Amount - The amount listed here will be multiplied by the value listed in the Item Qty to

provide the value for the Item Total. If this value is zero (and there are no shipping or tax charges), the credit card transaction will run as an AVSOnly transaction.

• Qty - This value will be multiplied by the amount listed in the Item Amount field to provide the

value for the Total. This value can be "1", even if you are selling multiple quantities - as long as the Item Amount is the cost of all of the products combined.

• Optional Fields - A merchant may place an entry into any of these non-required fields:

• Include Shipping Checkbox - This should be selected if a merchant would like shipping to be a

separate line item. This must be used in conjunction with an entry in the Shipping Amount field.

• Shipping Amount - This value should be the amount of shipping for the entire purchase. The

Virtual Terminal does not calculate shipping. A merchant will need to calculate that prior to entering the transaction in this interface. If the Include Shipping checkbox is selected, there must be a value in this field.

• Include Tax Checkbox - This should be selected if a merchant would like tax to be a separate

line item. This must be used in conjunction with an entry in the Tax Amount field.

• Tax Amount - This value should be the amount of tax for the entire purchase. The Virtual Ter-

minal does not calculate tax rates. A merchant will need to calculate that prior to entering the transaction in this interface. If the Include Tax checkbox is selected, there must be a value in this field.

• Email Text - This field allows a merchant to enter a message up to 255 characters which will

display on both the merchant confirmation email and on the customer confirmation email.

Payment Information Section

Figure 4.10. Classic Virtual Terminal Payment Section Example

The Control Panel

This section allows a merchant to enter either credit card information or checking account information. After the appropriate fields are filled out, a merchant can submit the payment by clicking on the "Process Payment" button.

• Credit Card Information - A merchant can use these fields if the customer would like to pay with

credit card.

• Card Number - The customer's credit card number should be entered into this field without any

dashes or spaces.

• Exp. Date - The expiration month and year should be selected in this area.

• Approval Code - The value for this field can only be obtained directly from the Credit Card

• CVV Number - The value for this field is the CVV or CVV2/CID code listed on the credit card.

This three or four digit numeric code is used as a fraud deterrent.

• Auth Only Checkbox - A merchant should never check this box, unless they do not desire to ac-

tually charge a customer's card. When this is selected the transaction will only run a "preauthorization" which verifies the card account and a set amount in the account, but it does not actually charge the card. A pre-authorized transaction can be converted to a full transaction by running a post-authorization from the Transaction Listing. If no post-authorization is run, the money

The Control Panel

is never paid to the merchant.

• Checking Account Information - These fields will be enabled if a merchant selects the Check Pay-

ment Method radio button.

• ABA Number - This is the nine digit ABA Routing number for a customer's bank. These are

generally the first nine numbers listed in the line of numbers across the bottom of a check.

• Account Number - This is the customer's checking account number as it appears on a check.

• Account Source - A NACHA authorized merchant needs to use the selection tool to indicate

whether the customer's checking account is a checking or a savings account.

• Account Type - A merchant needs to use the selection tool to indicate whether the customer's

checking account is a Personal or a Business checking account.

• SEC Code - Depending upon the nature of the EFT processing account, a merchant may be re-

quired to designate the three letter Standard Entry Category for the transaction. Potential values are:

• PPD - Prearranged payment and deposit

• CCD - Corporate credit or debit

• ARC - Accounts receivable entry

• BOC - Back office conversion

• POP - Point of purchase

• RCK - Returned check entry

• WEB - Internet initiated entry

• TEL - Telephone initiated entry

Shipping Information Section

Figure 4.11. Classic Virtual Terminal Shipping Section Example

This bottom section of the Classical Virtual Terminal is used to submit shipping information if a merchant opts to.

The Control Panel

Submitting a Transaction Through The Virtual Terminal Interface (Classic)

Figure 4.12. Approval Page Example

Swipe Card Interface (Standard)

The Standard Swipe Card Interface can be accessed by clicking on the "Swipe Card" link in the Standard interface. This interface is to be used by merchants who are using a compatible USB-Connected magnetic card swipe reader. The Magtek Stripe Reader-USB and the IDTech MiniMag USB Swipe Reader have been tested with the gateway and found to be compatible. When in this interface, a card may be swiped through the reader and it will populate the required payment fields. This will allow an Address Verification and a CVV check to take place on any transaction attempt.

Figure 4.13. Swipe Virtual Terminal Welcome Example

Initial Transaction Information Section

Figure 4.14. Swipe Virtual Terminal Transaction Information Example

The Control Panel

Some of the entry fields in this area are required and others are optional. A merchant can choose to enter up to three separate items plus shipping and tax amounts, or can submit a single item which is a total of the amount to be billed to the customer.

The Control Panel

• Item Description - A merchant should enter the name of the product that a customer is purchasing

• Item Qty - This value will be multiplied by the amount listed in the Item Price field to provide the

value for the Item Total. This value can be "1", even if you are selling multiple quantities - as long as the Item Price amount is the cost of all of the products combined.

• Item Price - The amount listed here will be multiplied by the value listed in the Item Qty to provide

the value for the Item Total.

• Item Total - This value is arrived at when the Virtual Terminal automatically multiplies the value of

the Item Qty and the Item Price for a single item.

• Total - This amount is the sum of the Item Totals for all items purchased.

• Include Shipping Checkbox - This should be selected if a merchant would like shipping to be a

separate line item. This must be used in conjunction with an entry in the Shipping Amount field.

• Shipping Amount - This value should be the amount of shipping for the entire purchase. The Virtu-

al Terminal does not calculate shipping. A merchant will need to calculate that prior to entering the transaction in this interface. If the Include Shipping checkbox is selected, there must be a value in this field.

• Include Tax Checkbox - This should be selected if a merchant would like tax to be a separate line

item. This must be used in conjunction with an entry in the Tax Amount field.

• Tax Amount - This value should be the amount of tax for the entire purchase. The Virtual Terminal

does not calculate tax rates. A merchant will need to calculate that prior to entering the transaction in this interface. If the Include Tax checkbox is selected, there must be a value in this field.

• Order Total - This value is the sum of the Total, the Shipping amount, and the Tax amount. This is

the amount that will be charged to the customer's card. If this value is zero, the credit card transaction will run as an AVSOnly transaction.

• Email Text - This field allows a merchant to enter a message up to 255 characters which will dis-

play on both the merchant confirmation email and on the customer confirmation email.

• Approval Code - The value for this field can only be obtained directly from the Credit Card Mer-

chant Account Processor's Voice Approval phone service. This feature should only be used if a "call authorization center" error response was received during a previous authorization attempt. The approval code will be a numeric or alpha-numeric code provided by the Voice Approval service. The gateway does not provide voice approval codes. Those codes must be obtained directly from the Merchant Account Processor.

• CVV Number - The value for this field is the CVV or CVV2/CID code listed on the credit card.

This three or four digit numeric code is used as a fraud deterrent.

• Auth Only Checkbox - A merchant should never check this box, unless they do not desire to actu-

ally charge a customer's card. When this is selected the transaction will only run a "pre-authorization" which verifies the card account and a set amount in the account, but it does not actually charge the card. A pre-authorized transaction can be converted to a full transaction by running a post-authorization from the Transaction Listing. If no post-authorization is run, the money is never paid to the merchant.

Swipe Card Entry Section

By clicking the button and then swiping the credit card through a compatible USB-Connected magnetic card swipe reader, this section will be automatically populated by the encrypted data embedded in the magnetic strip on the back of the card.

Figure 4.15. Swipe Virtual Terminal Entry Section Example

Additional Information Section

A merchant needs to manually complete the required fields in this section, and click the "Process Payment" button so that the swiped transaction can complete.

The Control Panel

Figure 4.16. Swipe Virtual Terminal Information Section Example

• Billing Information - All fields here are required unless otherwise indicated.

• Address - This should be the cardholder's street address as listed with the account issuer.

The Control Panel

• City - This should be the cardholder's city as listed with the account issuer.

• State - This should be the state abbreviation of the cardholder as listed with the account issuer.

• ZIP - This should be the cardholder's postal code as listed with the account issuer.

• Country - This should be the cardholder's country as listed with the account issuer.

• Phone - This should be a contact phone number for the customer.

• Cust ID - This is an optional field that allows a merchant to enter a tracking number for their

customers.

• Email - This should be the customer's email address. The transaction confirmation email will be

sent to this address.

• Optional Shipping Information - Each of these fields are optional and can be populated with al-

ternative shipping address data. The processing banks are unable to verify this information.

Submitting a Transaction Through The Swipe Card Interface

To submit a transaction through this interface, enter the correct data into the required fields and any of the desired optional fields. Be sure to double check that the fields have been correctly populated when the card is swiped through the magnetic reader. Click the "Process Payment" button. The transaction will be attempted in real-time. The gateway will either display an approval screen or a failure screen. The failure screen will list the reason for the failure. An approval page will display if the transaction is successful.

Figure 4.17. Approval Page Example

Swipe Card Interface (Express)

The Express Swipe Card entry area allows a merchant to enter minimal information and swipe a credit card to attempt a transaction. This interface is to be used by merchants who are using a compatible USBConnected magnetic card swipe reader. The Magtek Stripe Reader-USB and the IDTech MiniMag USB Swipe Reader have been tested with the gateway and found to be compatible. When in this interface, a card may be swiped through the reader and it will populate the required payment fields. This will not allow an Address Verification or a CVV check to take place.

Figure 4.18. Swipe Express Welcome Section Example

The Control Panel

Swipe Entry Section

Click on the button and then swipe the card through the swipe reader and it will populate the required fields.

Figure 4.19. Swipe Express Entry Section Example

Amount Entry Section

After the swiping the card and a successful automatic field population, the following fields will appear and the merchant must enter the appropriate information for a transaction to complete.

Figure 4.20. Swipe Express Amount Section Example

The Control Panel

• Order Total - The value of this field should be the total amount being charged to the customer. For

an AVSOnly credit card transaction, this value should be 0.00.

• Email - If a merchant fills in this field with the customer's email address, an receipt will be emailed

directly to the customer. This field is optional. Once these fields are complete, the merchant can submit the "Process Payment" button, and the

transaction will be attempted.

Submitting a Transaction Through The Swipe Card Express Interface

Figure 4.21. Approval Page Example

The Control Panel

The Account Settings - How Do I Modify My Information?

The Account Settings interface is used to update contact information, anti-fraud features, email settings, and general transaction functions.

Please remember, any changes to data in this interface require the user to click the "UPDATE" button at the bottom of the Account Settings interface.

The Welcome Section

Figure 4.22. Account Settings Welcome Example

This section lists the Business Name and the Gateway ID. Your gateway ID number will never change. To change the way your business name is listed here, please submit the request through your sales rep. This section also houses the following security code interfaces:

• Password Change - This interface allows a merchant to change their password. Click on the GO

button to open the interface. The new desired password must meet the following requirements:

1) Minimum length: 8 characters

2) Maximum length: 30 characters

3) Must include at least two different character groups (lowercase letters, uppercase letters, digits, punctuation)

4) Cannot include the same character repeated three times (like aaa or 555) or a sequence of three characters (like xyz or 789)

5) Cannot include dictionary words, including common names. To change the password, enter your then-current password into the "Current Password", and then

enter your new desired password in the other two fields.

• PIN Update - This interface allows a merchant to setup or change their PIN number for the Transac-

tion By Telephone system. To change the PIN code, click on the GO button to open the interface, enter your then-current PIN code into the "Current PIN", and then enter your new desired PIN code in the other two fields. All PIN codes must be six numeric digits.

The General Information Section

This section contains contact information for a Merchant to be used by the gateway. The HELP command explains that the fields should be modified if any of the information changes.

The Control Panel

Figure 4.23. Account Settings General Section Example

The Email Settings

Figure 4.24. Account Settings Email Section Example

This interface allows a merchant to change where the gateway sends emails concerning sales, settlements, order form errors and billings. These emails may only be sent to one address. If you would like

The Control Panel

several individuals to receive these emails, please have your Network Administrator/Email Manager setup a multi-recipient alias address and use that to populate these fields. This interface also allows merchants to opt-in to the failure emails and the MerchantUpdates email list. Here is a more in depth explanation of each of these settings:

• Contact Email Address - This address will be sent account activation information and settlements.

• Order Email Address - This address will receive email confirmations of all sales, voids, credits,

forces, pre-authorizations, post-authorizations, recurring billings, and failure emails (if selected). There is no way to turn off these emails (except for the failures). The gateway is required to send these confirmations to a merchant for that merchant's records. If a merchant decides not to do anything with these emails, they may want to setup a "garbage" email account and enter that address as the Order Email Address.

• Receive Failure Emails Checkbox - A merchant should select this feature if they would like to be

sent an email anytime that a customer attempts to pay them but is rejected for some reason. The email will explain the reason for the failure by listing the response from the credit card processing network.

• Error Email Address - This address will be sent messages when there is an error in the order form

script on a merchant's website. Generally, emails are only sent there as a merchant is first integrating the Gateway Software with their website and working to get the integration correct.

• Customer Reply Email Address - This address will be listed in the customer's copy of the email

confirmation receipt as a contact address for the merchant.

• The Merchant Updates Email List - This link opens a window the interface that allows a merchant

to subscribe to the opt-in MerchantUpdates email list. The MerchantUpdates mailing list is used to notify merchants of system maintenance, feature additions and other important information.

• The HELP Menu - This link provides a list of the functions of each of the email settings.

The Advanced Features Settings

Figure 4.25. Account Settings Advanced Features Section Example

• The Recurring Post-Back URL - If a merchant uses the recurring transaction features of the gate-

way, the merchant may specify a URL to receive transaction postback information generated at the time the transaction recurs. The "ACTIVATE" checkbox must be checked for this feature to function. For complete details concerning the Recurring Billing system and the Recurring Post-Back feature, please see the section detailing this.

• The Settlement Time Selector - By default, this setting is "AUTO", meaning that the software will

cycle through all of the gateway accounts for settlement each night beginning at midnight. If a merchant would like their batch settlement to take place at a specific time each day, that merchant can

select the appropriate time. "MANUAL" should be selected by merchants who want to settle each of their own batches using the "Settle Now" tool in the Settlement Options area of the Control Panel.

• The Order Form UID Value - This is the preferred option to be used as the value for the

"vendor_id" field in an order form or shopping cart. You can change this value by clicking the "RESET" link. NOTE: If your forms are using the UID instead of the Gateway ID and you reset this value, you MUST update the "vendor_id" value in your order form or shopping cart or your transactions will not process.

• The API Username - This the username for people using the XML Connection Method. You can

change this value by clicking the "RESET" link. NOTE: You must update your scripts generating the XML requests if you reset the API Access information.

• The API Key - This is used to help generate the payload signature for people using the XML Con-

nection Method. You can change this value by clicking the "RESET" link. NOTE: You must update your scripts generating the XML requests if you reset the API Access information.

The Test Transaction Settings

This feature allows a merchant to test their order forms and ordering system to make sure that they have integrated their website with the gateway system correctly - without actually charging an account. These settings can also be modified in the Testing Your Forms interface (see the section detailing this).

The Control Panel

Figure 4.26. Account Settings Test Section Example

• The Test Mode Checkbox - This should only be selected if a merchant wants all transactions pro-

cessed as TEST transactions. By default, this is unchecked. When checked, any transactions will run as TEST transactions and will not be processed or charged. Any transactions submitted as TEST transactions will not show up in the Transaction Listing or Transaction Detail interfaces.

• The Test User First Name - When the entry in this field is passed as the customer's first name, the

transaction will be processed as a TEST transaction. Do not use a real name, instead use something like "Test123".

The Customer Confirmation Email Settings

This feature allows a merchant to select/deselect which emails are sent to the email provided by the customer at the time of the transaction. Many merchants who use a shopping cart system prefer that the shopping cart sends a confirmation, rather than the gateway. In that case, they remove the check marks. All emails are set to be sent by default, except for the AVSOnly and Pre-Auth emails. The HELP menu reminds a merchant what each of the emails indicate.

Figure 4.27. Account Settings Customer Email Section Example

The Fraud Control Settings

These settings are provided as additional protection against potential fraud. Each of these features are optional. A merchant may use as many of these features as they desire. None of these features can completely prevent all types of fraud, but these are some of the most powerful anti-fraud options available on any gateway software available today.

Figure 4.28. Account Settings Fraud Controls Example

The Control Panel

• Allow Credits With No Prior Sale - When this is selected, a merchant can log into the Control Pan-

el and utilize the Post A Credit interface to put money into the credit card account of a customer. The interface does not function correctly unless this checkbox is marked. For more information on the Post A Credit feature, please see the section detailing this.

• Allow Refunds Via The Transaction Listing - This should be enabled if a merchant wants to be

able to refund past transactions without having to enter the customer's information in the Transaction Listing or Transaction Detail Options area.

• Refunds Greater Than Sale - This checkbox, when selected, allows a merchant to generate refunds

for a larger amount than the original payment made by the customer.

• Resubmit Greater Than Sale - This allows a merchant to generate a charge to a past customer

without having to re-enter the customer's information. This should be enabled if a merchant would ever possibly "re-bill" a past customer for an amount larger than the original sale. The feature does not effect Recurring transactions, only Resubmit transactions.

• IP Filter Settings Interface - This allows a merchant to access the IP Filter Management window.

This interface allows a Merchant utilizing the HTML or XML connection methods to limit transaction submissions to the IP address/range of a specific server. This is required for XML connection users and optional for HTML users. If used with HTML, be sure to activate the "Restrict Order By IP" feature. The HTML Transproc Module is used for HTML based transactions. The XMLTrans module is used for XML. The status must be set to Active. To delete an IP address, click the "GO" button in the Delete Column.

The Control Panel

Figure 4.29. IP Filter Settings Example

• Restrict Order By IP - This feature allows a merchant to allow HTML-based transactions only

from specific IP addresses. This is activated and used by merchants who will be making all of their customers' order submissions from their own server directly to our system. When enabled, a merchant should also enter acceptable IP addresses into the IP Filter Management window using the HTML Transproc module. It should not be activated if customers will be posting to the gateway system.

• Restrict Order Usage - This fraud prevention module is specifically designed to reduce the number

of 'testers' hitting merchants with credit card numbers attempting to find valid cards. If a transaction is received and is NOT approved, a restriction will be automatically enabled. For the next X minutes no transactions will be allowed from the IP address of the original unapproved transaction. To activate this, click the checkbox and enter an amount of time in the minutes box.

• Proof of Life - This feature is also known as "Captcha Verification". When activated, a page is dis-

The Control Panel

played to the user with a dynamically generated image containing random characters after order submission. The user must enter these characters correctly to complete the transaction submission. If a merchant is logged into an open session of the Control Panel, and submits a transaction through their website, it will not prompt the merchant for the entry. However, if the merchant does not have an open session, they will be prompted for the entry - like a customer.

• Allow Non-VT Sales - This must be selected if you will be accepting transactions via order form.

The only instance in which a merchant would disable this feature would be if the merchant was only using the Virtual Terminal or XML feature to manually enter transactions. If you are only accepting XML and Virtual Terminal transactions, please uncheck this box.

• Require VT Customer ID - This fraud prevention module gives merchants the ability to enforce the

Customer ID value for Virtual Terminal Transactions if they wish to do so.

• Reject Duplicates - This feature will block duplicate transactions sent through the gateway. To be

considered a duplicate transaction the following values must be identical to another successful transaction that has occurred in the last 24 hours. Currently this service only works with credit card transactions. The following fields are used to determine duplication:

• Credit Card Number

• Credit Card Expiration Month

• Credit Card Expiration Year

• Billing Street Address

• Billing Zip/Postal Code

• Order Total

• Require Order Form UIDs - This fraud prevention option gives merchants the ability to enforce

the use of the Order Form UID for the value of the "vendor_id" field on HTML based order forms. The value of the UID is listed in the Account Settings. The twenty character Order Form UID value is randomly generated and keeps fraudsters from guessing what ID you are using to process orders. This does not keep someone from looking at your order form and obtaining this value, but we have found that the majority of fraud is done using automated tools. So this setting keeps fraudsters from stumbling upon your account.

• Maximum Sale - This allows a merchant to place a cap on the highest amount that they will allow to

process through their website. Often, a merchant will set this amount to coincide with the "maximum volume ticket limit" imposed on them by their credit card merchant processing bank. A customer who attempts to place a transaction which exceeds that amount will be shown an error which indicates that they've entered an invalid amount.

• Minimum Sale - This allows a merchant to place an "at least" amount. A customer who attempts to

place a transaction which does not meet at least that amount, will be shown an error which indicates that they've entered an invalid amount.

• Auto-Void Options - These advanced features will automatically void a transaction that would oth-

erwise be approved based on the merchant's own risk tolerance.

• The Address and ZIP Verification Auto-Void/AVS Auto-Void Setting - All of the major

credit card processors will accept transactions that do not pass AVS. The fact that processors do not reject non-AVS transactions is a great concern of ours. Because of this, we've introduced one of the first AVS Auto-Void systems for the Internet. Our system allows the software to void transactions that are allowed through the processor without passing AVS based upon the requirement level set by the merchant. Remember, the gateway does not provide the AVS Responses. Those responses are generated by the credit card issuing bank and reported by the credit card

The Control Panel

processor based on information located in the bank's AVS database (which may or may not match the bank's statement database). However, the gateway system will perform the Auto-Void according to the requirements set by the merchant. These settings may be modified by the merchant at any time. Keep in mind, a(n) void/auto-void of an authorized transaction cancels the charge, but does not cancel an authorization. An authorization freezes funds in an account, so that a completed charge can withdraw those frozen funds. A voided authorization may "freeze" the funds in the customer's account for up to 10 days. The following levels are available:

1. No Auto-Void - This will allow any approved transaction to process regardless of the address

verification response.

2. Void Unless ZIP Matches - This will void any approved transaction for which the processor

indicates that the ZIP Code entered does not match the ZIP Code listed in the bank's AVS database (even if the street address matches).

3. Void Unless Addr Matches - This will void any approved transaction for which the processor

indicates that the street address entered does not match the street address listed in the bank's AVS database (even if the ZIP Code matches).

4. Void Unless Both Match - This setting requires that both the address and the ZIP Code match

exactly what the issuing bank's AVS database has on file for the customer. If either the address or ZIP Code, or both, come back as a non-match, that approved transaction will be voided.

• The Recurring AVS Auto-Void Setting - This feature provides auto-voiding of recurring trans-

actions based on the address and ZIP Code verifications returned by the processing network. Remember, the gateway does not provide the AVS Responses. Those responses are generated by the credit card issuing bank and reported by the credit card processor based on information located in the bank's AVS database (which may or may not match the bank's statement database). However, the gateway system will perform the Auto-Void according to the requirements set by the merchant. These settings may be modified by the merchant at any time. Keep in mind, a(n) void/auto-void of an authorized transaction cancels the charge, but does not cancel an authorization. An authorization freezes funds in an account, so that a completed charge can withdraw those frozen funds. A voided authorization may "freeze" the funds in the customer's account for up to 10 days. The following levels are available:

1. No Auto-Void - This will allow any approved transaction to process regardless of the ad-

dress verification response.

2. Void Unless ZIP Matches - This will void any approved transaction for which the pro-

cessor indicates that the ZIP Code entered does not match the ZIP Code listed in the bank's AVS database (even if the street address matches).

3. Void Unless Addr Matches - This will void any approved transaction for which the pro-

cessor indicates that the street address entered does not match the street address listed in the bank's AVS database (even if the ZIP Code matches).

4. Void Unless Both Match - This setting requires that both the address and the ZIP Code

match exactly what the issuing bank's AVS database has on file for the customer. If either the address or ZIP Code, or both, come back as a non-match, that approved transaction will be voided.

• The CVV Verification Auto-Void Setting - The CVV code is a security feature for 'card not

present' transactions (e.g., Internet transactions), and now appears on most (but not all) major credit and debit cards. This feature is a three or four digit code which provides a cryptographic check of the information embossed on the card. Therefore, the CVV code is not part of the card number itself. This setting allows a merchant to have sale transactions automatically voided if the processing network indicates that the CVV entered does not match the CVV database at the

The Control Panel

customer's credit card issuing bank. Most issuing banks do not require a CVV number to be entered for a transaction to process. A small group of banks do require correct CVV entry for Internet based transactions. The gateway system will perform the Auto-Void according to the requirements set by the merchant. These settings may be modified by the merchant at any time. Keep in mind, a(n) void/auto-void of an authorized transaction cancels the charge, but does not cancel an authorization. An authorization freezes funds in an account, so that a completed charge can withdraw those frozen funds. A voided authorization may "freeze" the funds in the customer's account for up to 10 days. The following levels are available:

1. No Auto-Void - This will allow any approved transaction to process regardless of the CVV

verification response.

2. Void Unless CVV Matches - This setting will void any authorized transaction which is re-

turned with a non-matching or empty CVV response.

3. Void If CVV Not Entered - With this setting a customer's transaction will be voided if the

bank indicates that a CVV code should exist on the card, but was not entered.

• Note - The iTransact gateway does not perform CVV auto-voids for American Express transactions.

Card Processing Settings

This area will only display if the Card Setup has been completed. If you would like the the card acceptance script to display on a Split Form, click the "Card Processing Enabled" checkbox. By default, all US based credit card merchant accounts are established to process transactions on Visa and MasterCards. If a merchant has also established "appendage" accounts (i.e. AMEX, Discover, and Diners), a merchant must provide those merchant IDs to their Visa/MC merchant provider. Once that's complete, a merchant can update the Card Type settings by clicking on the appropriate card types. A merchant can disable a card type by unchecking the card type in the same area. The selected card types will display on the secure half of the split form (if a merchant uses that method).

Figure 4.30. Account Settings Card Section Example

The Check Processing Information Section

This area will only display if the Check Setup has been completed. If you would like the check acceptance script to display on a Split Form, click the "Check Processing Enabled" checkbox. For merchants utilizing the Check system for accepting check payments, up to four email addresses can receive the daily Check Statistics emails. Please enter the desired recipients in the interface fields in the Account Settings of the Control Panel. If you are authorized to use the NACHA processing system, the NACHA Setup fields will display. Enter the necessary values provided by your NACHA processor.

Figure 4.31. Account Settings Check Section Example

Style Settings

The section is used to make the secure page of the Split form to appear the way that a merchant desires it. This can be helpful in making a transaction seem more seamless. Use of any of the supported bodytags will supercede any setting here.

The Control Panel

Figure 4.32. Account Settings Style Settings Example

• Background Color - This can be a six digit hexadecimal value or you can use the color bar tool to

select the desired color.

• Font Color - This can be a six digit hexadecimal value or you can use the color bar tool to select the

desired color.

• Header Background Color - This can be a six digit hexadecimal value or you can use the color bar

tool to select the desired color.

• Background Image - This needs to be the absolute URL of an image. You can upload this image to

the secure server by submitting a ticket at http://support.itransact.com.

• Header Border Color - This can be a six digit hexadecimal value or you can use the color bar tool

to select the desired color.

• Header Image - This needs to be the absolute URL of an image. You can upload this image to the

secure server by submitting a ticket at http://support.itransact.com.

• See Demonstration Page - This will show an example of what the layout of the form will look like.

This will only display settings that have been entered and submitted by the pressing of the UPDATE button at the bottom of the interface

The Control Panel

A helpful color bar tool is displayed when a merchant clicks into one of the color entry fields. This allows a merchant to click on the desired color and it will automatically populate the corresponding field.

Figure 4.33. Account Settings Style Color Bar Example

PLEASE REMEMBER TO CLICK THE "UPDATE" BUTTON AT THE BOTTOM OF THE INTERFACE WINDOW WHEN MAKING ANY CHANGES IN THE ACCOUNT SETTINGS INTERFACE.

The Merchant Toolkit - What Information Should I Give To My Web Designer?

The Merchant Toolkit provides full integration instructions for the HTML Connection Method and the XML Connection Method. This area provides the tools that will simplify the process of integrating the gateway system with a website. The toolkit includes examples of the simplest and most advance methods for linking a website with the gateway. It also includes downloads of support documentation. Additionally, instruct your designer to download the Developer's Guide.

Figure 4.34. Merchant Toolkit Example

The Control Panel

Transaction Testing

A merchant can run tests on the order forms and shopping carts being used for their account. Please reference THIS area of this documentation for full details.

Recurring Transactions

A merchant can use the gateway's Recurring Transaction system to bill customers according to a subscription or according to a set schedule. Please reference THIS area of the documentation for full details.

Fraud Controls

The potential for fraud on Internet-based transactions is unfortunately higher than the potential for fraud in brick-and-mortar businesses. To prevent potential fraud, there are several features in place explained in the toolkit. Those features are explained in detail in THIS area of the documentation.

The HTML Connection Method

The HTML Connection Method Details

By opening the HTML information, a merchant will have access to a series of required and optional HTML codes that will allow them to access all of the transaction functions of the gateway.

HTML Form Instructions and Examples

The Control Panel

Figure 4.35. HTML Toolkit Example

The Control Panel

• Form Post and Input Field Details - This link opens a window which includes the list of required

and optional fields for the Standard Form-Based order page, a Split Form-Based order page, and a Buy-Now Form-Based order page.

• Form Creation Wizard - This link returns a merchant to the Control Panel so that they may use the

Form Creation Wizard. For full instructions, please see the section detailing this.

• Order Form Templates - Clicking this link opens a window with links to full examples of various

options and methods for building simple forms. A merchant can view the source of these forms to review the different options for input types and layouts. A merchant can use these HTML forms which they can build their own order forms around with some minor modifications. If these templates are used, be certain to modify all of the required fields with the account-specific values.

Figure 4.36. HTML Order Form Template Section Example

• Split Form Templates - These examples can be used by merchants who do not have their own

secure server. It allows the customer to be taken to a secure page to enter their payment information. The examples include forms that accept credit cards and checks.

• Credit Card Templates - These links open demonstrations of Standard Form-based order pages

that only accept credit cards. One example includes a form that allows for a separate shipping address. Please remember that the credit card banks can not verify alternative shipping addresses.

• EFT Templates - This link opens an example of a Standard Form-based order page that can be

used for check draft payments or EFT payments.

• Combination Templates - This link displays a Standard Form-based order page that accepts

checks or EFTs and credit card payments.

HTML Form Functions

Figure 4.37. HTML Form Functions Section Example

The Control Panel

The optional features of these three functions enable a merchant to pass data to and receive information

The Control Panel

from the gateway via the "query_string" or via the HTML Post.

• The Passback Function - This feature allows a merchant the ability request and receive information

that was submitted as a part of the order form post submission. This feature can be used to access any of the data that can not be retrieved via the Lookup Function. Fields reserved for the Lookup Function can not be requested using the Passback Function. The Passback and Lookup Functions can both be used on the same form. The Passback Function enables you to include input variables in your order form that are passed back to your return address after the transaction is completed. The value for the "ret_addr" must be a dynamic page or script that can accept, parse, and interpret name/ value pairs. When in the Merchant Toolkit, click on the link to open full Passback details.

• The Lookup Function - Don't be confused by the name of this function. This feature provides the

same functionality of the Passback Function for 30 separate name/value pairs. The Passback and Lookup Functions can both be used on the same form. The Lookup Function allows you to request specific customer data from the processing server at the time a transaction is processed. All data requested using the Lookup Function is sent directly to the return address (ret_addr) specified in the order form. The value for the "ret_addr" must be a dynamic page or script that can accept, parse, and interpret name/value pairs. A merchant can request as many of the 30 name/value pairs as needed. When in the Merchant Toolkit, click on the link to open full Lookup details.

• The following fields can be received in the Post via the Lookup Function:

first_name - Returns the value entered as the first_name. last_name - Returns the value entered as the last_name. address - Returns the value entered as the address. city - Returns the value entered as the city. state - Returns the value entered as the state. zip - Returns the value entered as the ZIP. country - Returns the value entered as the country. phone - Returns the value entered as the phone. email - Returns the value entered as the email. sfname - Returns the value entered as the sfname. slname - Returns the value entered as the slname. saddr - Returns the value entered as the saddr. scity - Returns the value entered as the scity. sstate - Returns the value entered as the sstate. szip - Returns the value entered as the szip. sctry - Returns the value entered as the sctry. authcode - Returns the credit card authorization code. cc_last_four - Returns the last four digits of the card number. ck_last_four - Returns the last four digits of the checking account number.

The Control Panel

cc_name - Returns the name of the card type used. "Visa", for example. total - Returns the transaction total. test_mode - Returns "1" if your account is in test mode or "0" if it is not in test mode. when - Time/date stamp in format of "20010509134443" - meaning 05/09/2001 at 13:44:43. xid - Returns the transaction ID. batch_number - Returns the batch number for all transactions except EFT, since EFT transac-

tions aren’t currently assigned batch numbers.

avs_response - Returns the address verification response. cvv2_response - Returns the CVV response. confemail - Returns "1" if your account is set to send email confirmations to your customers or

"0" if confirmations are not sent.

email_text (email_text2-email_text9) - Returns the value(s) entered as the email_text field(s). billing_update_token- If a transaction is initiating a recurring transaction tied to a recipe with

"Allow Customer Update" enabled, this is the value of the token to be used in a link to the secure billing update page. Should be 60-80 characters.

• The Return Mode Function - The function allows important information to be posted back to a

merchant's server after a transaction attempt. The Return Mode Function enables a merchant to have their customers by-pass the intermediate "Continue" page that is displayed after a transaction completes. This is useful if a merchant desires their transaction system to be "transparent" to the enduser. This applies for both valid and declined transactions. By default, customers are shown a "Thank You" page on the secure server after a successful transaction. When the customer clicks the "Continue" button all name/value pairs are returned to a merchant's script using GET. However, the Return Mode Function allows the customer to bypass the "Thank You" page and be directed to the merchant's ret_addr. This function also has a feature enabling you to receive error messages and failures (declines) returned to a specified script on the merchant's server. There are two values that can be used with the Return Mode Function. They are "post" and "redirect". Each has a specific function explained below:

• Redirect Method - The "redirect" ret_mode value can be used if your ret_addr is a static HTML

document. After a successful transaction, your customer is automatically redirected to your ret_addr, by-passing the "Thank You" page. Since this is a simple redirect, no Passback or Lookup values can be returned.

• Post Method - This method can only be used if the ret_addr page is a dynamic script/page. After

a successful transaction, the information you have requested from the processing server will be posted to your ret_addr. All Lookup and Passback name/value pairs will be returned via the POST.

• Post of Error Messages - If you would like decline and error messages also sent to your

ret_addr, you may use this feature. This feature is very powerful, giving you complete control of the entire transaction process, because you can take the error message and display it in your own error screen.

• Considerations and Restrictions

• When using ret_mode with the "redirect" option, your ret_addr page should reside on a se-

The Control Panel

cure server. Otherwise your customer's will receive a security warning.

• When using ret_mode with the "post" option, your ret_addr URL may be on a secure (https) or non-secure (http) server. In either case, the page will be displayed securely as an emulated page in the secure server environment.

• When using ret_mode, your ret_addr must be an absolute URL, not a relative URL. (i.e. http://www.yoursite.com/cgi-bin/return.cgi is absolute. ../cgi-bin/return.cgi is relative.) In addition, all links located on your ret_addr page must also be absolute URLs.

• The ret_mode function uses a standard http 1.1 post. If your ASP or Cold Fusion application cannot "see" the incoming name/value pairs, you will

need to consult your documentation/system admin.

• For security reasons, you must use a standard port for post-back data. (port 80 for http or port 443 for https) In other words, a ret_addr of http://www.yoursite.com:9876 will not work correctly.

• The Return Mode Function is MUCH more dynamic than the standard GET method used to return customers to your site. Please be aware that if your ret_addr is not available, unreadable, incomplete, times out, etc., your customer's account will have already been billed and they will receive an error message. Only use the Return Mode Function if you are very familiar with CGI scripting. Always test your applications before making them available to your users.

Advanced HTML Features

Figure 4.38. Advanced HTML Features Section Example

These optional features add prevention of duplicated transaction submissions and verification that returned data came from the gateway server.

• JavaScript Duplicate Prevention Script - Merchants can use this script to prevent multiple submis-

sions of the same transaction. This will block a transaction from being billed more than once on the submission of the same order form. This is already built into the HTML Split Form-based transac-

tion pages. The JavaScript must be copied completely and must exist within your order form between the HTML tags of <HEAD> and </HEAD>. Please modify the POST URL so that it reflects this:

• PGP Signature Verification - To utilize this feature, a merchant's server must have PGP installed.

This feature allows a merchant to verify that any Passback and Lookup values received in the URL string were sent by the gateway processing server. Please access this link in the Merchant Toolkit to access the necessary encryption/decryption keys to use this feature.

Responses will appear as follows: If a transaction is declined, you will receive a name/value pair of "err=TEXT OF ERROR..." along

with the name/value pairs for each passback variable requested. If an internal error is encountered, you will receive a name/value pair of "die=1" If the transaction is successful, neither of these will appear.

Customizable HTML Fields

Figure 4.39. Customizable HTML Section Example

The Control Panel

These features allow a merchant to make the transaction system more transparent to the end user.

• The Return Address Field - The value for this field is the address to which a customer will be

taken to after a successful transaction. This is the same address which data returned via the Lookup and/or Passback function will be posted to.

• The Email Text Fields - This/these command(s) can be used to add up to ten additional messages

up to 255 characters each on the confirmation email generated by the gateway. This information will appear on both the customer and merchant emails.

• The Form Tag Options - Any or all of these can be used to make the half of the Split Form or

BuyNow Form which resides on the gateway server - the final checkout page - look and feel more like your web site. For Split Forms, the Style Settings in the Account Settings provide a more userfriendly way to implement many of these features. If you use any of these commands with a Split Form, they will override any settings in the Style Settings.

• background (This command allows your script to call an image that you have uploaded to our

server to display as the background of the final checkout page.)

Table 4.1. Background Example

Follow the instructions listed in the Toolkit to upload the necessary images.

• bgcolor (This tag allows you to designate the background color of the final checkout page.)

Table 4.2. Background Color Example

• fontcolor (This tag allows you to designate the color of the text on the final checkout page.)

Table 4.3. Font Color Example

• alink (This tag allows you to designate the color of an active link.)

Table 4.4. Active Link Example

The Control Panel

• link (This tag allows you to designate the color of a link.)

Table 4.5. Link Example

• vlink (This tag allows you to designate the color of a visited link.)

Table 4.6. Visited Link Example

• mertext (This tag allows you to add a line of text at the bottom of the final checkout page.)

Table 4.7. MerText Example

• disable_cards (This tag allows you to remove the card acceptance fields from the final check out

page.)

Table 4.8. Disable_Cards Example

• disable_checks (This tag allows you to add a line of text at the bottom of the final checkout

page.)

Table 4.9. Disable_Checks Example

The Control Panel

• show_items (This tag allows you to display the order items, quantities, and costs of the items be-

ing purchased on final checkout page.)

Table 4.10. Show_Items Example

• Header Graphic Commands - This line allows you to call an order form that displays your

company's logo across the top of the final check out page.

• mast (This command allows your script to call an image that you have uploaded to our serv- er to display as the header graphic of the final checkout page.)

Table 4.11. Mast Image Example

Follow the instructions listed in the Toolkit to upload the necessary images.

The XML Connection Method

The XML Connection Method Details

Merchants wishing to interface directly with the transaction processing server may do so using XML. XML requests are posted directly to the processing server via HTTPS, ensuring the security of the submitted information. XML responses are generated during the same connection, reducing the number of connections required to process a transaction. The XML schema provides an easy alternative for developers wishing to process real-time transactions. Because XML is open-architecture, developers may create their own Windows COM objects, Java apps, PHP routines, Perl libraries, standardized Web Services, etc. If a merchant's application can generate XML, the merchant can process transactions using this method. Since the XML method is simply another method for processing transactions, all gateway features remain available. This includes the Virtual Terminal, Transaction Listing, Testing Interface, etc. By default, this feature is not activated on a gateway account. Please contact your sales rep to have this feature activated.

XML Functions

The XML Interface allows use ofa all transaction functions including recurring billing and refunds. Please have your developer review the XML API information.

XML Considerations

• If using Java, download the Java Secure Socket Extension package available at http://java.sun.com.

• If using a Microsoft technology (such as ASP), a merchant may use the XMLHTTPRequest object of msxml.dll. This solution is built upon wininet.dll, which is not scalable. Consult Microsoft documentation for details.

The Control Panel

• If using PHP, a merchant may use the CURL Library functions found at http://www.php.net/manual/en/ref.curl.php.

• The XML Connection method is not activated on a gateway account by default. If a merchant desires to use the XML Connection method, an XML activation request needs to be sent to the sales rep. Also, be sure to enable the XML API in the Account Setting section of the Control Panel.

The Transaction Listing - How Can I View My Transactions?

This interface transaction displays information in several formats according to a date range or search criteria.

The Standard Transaction Listing

The Transaction Listing allows a merchant to view a history of transactions based on a date range selected in the Control Panel interface.

Figure 4.40. Standard Transaction Listing Example

Across the top of the Transaction Listing, a merchant's name and gateway ID is displayed. Each of the items across the top have important features:

• Page Links - These indicate how many pages of transactions a date range includes. Each transaction listing page lists up to 50 transactions. The pages may be moved through by clicking on the "First", "Prev", "Next" and "Last" buttons at the top or the bottom of the page.

• The Print Listing Button - This instructs a computer to print the page being viewed.

• The Explanation of Codes Button - This opens a window explaining the information displayed in the Status, AVS, and CVV columns.

• The Close Window Button - This closes the Transaction Listing window.

The Control Panel

• Download Data Options - By selecting CSV or XML in the drop down menu and clicking the "GO" button, a file will download that includes the details of all of transactions in the opened date range.

• The Estimated Open Batch Total Link - This link opens a window that displays the then-current batch total based on information in the gateway. This may or may not match with the batch amount on the processor's system.

• DATE AND TIME - This value in this column is the date and time of the original transaction attempt.

• XID - This value is the ID number assigned automatically to a transaction when it is submitted through the gateway system. When a merchant clicks on the XID number, the Transaction Detail for that XID will open. For an explanation of the Transaction Detail window, please see the section detailing this.

• PXID - This value is the Parent XID, or the XID of the transaction which is the originating XID of a recurring transaction, a void, a credit/refund, a postauth, or a resubmitted transaction. This field will be blank unless the transaction has an originating XID. When a merchant clicks on the PXID number, the Transaction Detail for that XID will open. For an explanation of the Transaction Detail window, please see the section detailing this.

• CXID - This value is the Child XID, or the XID of the transaction which is a transaction which has used this transaction as the originating transaction for a recurring transaction, a void, a credit/refund, a postauth, or a resubmitted transaction. This field will be blank if the transaction has no child transactions. When a merchant clicks on the CXID number, the Transaction Detail for that XID will open. For an explanation of the Transaction Detail window, please see the section detailing this.

• ACTION - This field identifies what type of transaction was submitted.

• STATUS - The field identifies whether a transaction was successful or not. Potential values are listed below:

• Ok - Valid Transaction

• Incomplete - Generally indicates transaction is currently in process.

• Error - Error receiving response from network. May be caused by user error or an unknown re-

sponse during transaction processing.

• Fail - Could be any of the following reasons:

• Declined

• Card Expired

• Invalid Card Number

• Lost or Stolen Card

• Card Type Not Supported

• Service Not Allowed

• User Input Data Error

• No Answer From Processing Network

• No Response From Processing Network

The Control Panel

Review the Transaction Detail "Error Message" field for the specific reason for failure. See the section to review the possible "Response" values.

• AVS - This column is blank for check or EFT transactions. The value is the response received from the processing network to indicate whether the address and ZIP Code matched the credit card's account address on file in the bank's AVS database or not. Different processors have different values. To keep the listing simple, the listing shows 6 easy to understand categories (A&Z - address and ZIP match, ZIP - address does not match but ZIP does, Addr - address matches but ZIP does not, GNP Global Non-Participator/foreign card can not be verified, U - unsupported AVS, and N - neither address nor ZIP matches). Those simple categories include several types of responses generated from the processors. Here are the possible responses from the different processors:

1. Elavon/Nova

Table 4.12. Elavon/Nova AVS Responses

A - Address match. ZIP does not match. D - Address and postal match. E - AVS error. G - Global non-participant. AVS not available for international customers. I - International address not verified. N - No match. Neither address nor ZIP match. O - No response to AVS request. S - AVS service not supported for this transaction. U - AVS unavailable. Y - Address and 5-digit ZIP Code match. Z - ZIP Code match. Address does not match.

2. First Data

Table 4.13. First Data AVS Responses

Visa/MasterCard/American Express A - Address Match Only. B - Address match for non-US transaction. Postal code not verified. C - Address & postal code not verified for non-US transaction. D - Address & postal code match for non-US transaction. E - Address Verification Not Allowed for Card Type. G - Global Non-AVS participant. Non-U.S. Card issuing bank does not support AVS. I - Address information not verified for non-US transaction. M - Address and postal code match for non-US transaction. N - Neither the Address nor ZIP Match. P - Postal code match for non-US transaction. Address not verified. R - Retry/System unavailable. S - Service not supported. U - Address information not verified for domestic transaction. W - 9-digit ZIP match only. X - Address & 9-Digit ZIP Match. Y - Address & 5-Digit ZIP Match. Z - 5-Digit ZIP Match Only

Discover A - Address & 5-Digit ZIP Match. B - Address match for non-US transaction. Postal code not verified. C - Address & postal code not verified for non-US transaction. D - Address & postal code match for non-US transaction. E - Address Verification Not Allowed for Card Type.

The Control Panel

G - Global Non-AVS participant. Non-U.S. Card issuing bank does not support AVS. I - Address information not verified for non-US transaction. M - Address and postal code match for non-US transaction. N - Neither the Address nor ZIP Match. P - Postal code match for non-US transaction. Address not verified. R - Retry/System unavailable. S - Service not supported. U - Address information not verified for domestic transaction. W - Card number not on File. Y - Address match only. Z - 5-Digit ZIP Match Only

3. NDC Global

Table 4.14. NDC Global AVS Responses

A - Address Match Only. B - Incompatible formats (postal code). Street address match. Postal code not verified. C - Incompatible formats (all information). Street address & postal code not verified. D - Street address & postal codes match. E - Edit error. For example, AVS not allowed for this transaction. G - Global Non-AVS participant. Non-U.S. Card issuing bank does not support AVS. I - International Transaction. Address information not verified. M - Match. Street address and postal codes match. N - No. Address and ZIP Code do not match. P - Postal codes match. Street address not verified. R - Retry. System unavailable or timed-out. S - Service not supported. Issuer does not support AVS. U - Unavailable. Address information not verified for domestic transactions. W - Whole ZIP. 9-digit ZIP match only. X - Exact. Address & 9-digit ZIP Match. Y - Yes. Address & 5-digit ZIP Match. Z - ZIP. 5-digit ZIP Code matches. Address does not match.

4. Visanet/VITAL

Table 4.15. Visanet AVS Responses

A - Street address matches. ZIP Code does not. E - AVS error. No service. N - No match. Neither address nor ZIP Code match. R - Retry. AVS not available. S - No AVS service. U - Unavailable. Y - Street address and 5-digit ZIP Code match. Z - 5-digit ZIP Code matches. Street address does not.

5. Gensar/Paymentech

Table 4.16. Paymentech AVS Responses

The Control Panel

Visa A - Address matches, ZIP Code does not. E - Transaction is ineligible for address verification. G - Global non-participant. Foreign card. Cannot verify address. N - Neither the ZIP nor the address matches. R - Issuer's authorization system is unavailable. Try again later. S - AVS not supported at this time. U - Unable to perform address verification because either address

information is unavailable or the Issuer does not support AVS. Y - Address & 5-digit or 9-digit ZIP match Z - Either 5-digit or 9-digit ZIP matches. Address does not.

MasterCard A - Address matches, ZIP Code does not. G - Global non-participant. Foreign card. Cannot verify address. N - Neither the ZIP nor the address matches. R - Retry. System unable to process. S - AVS not supported at this time. U - No data from Issuer/BankNet switch. W - 9-digit ZIP Code matches, but address does not. X - Exact. All digits match, 9-digit ZIP Code. Y - Exact, all digits match, 5-digit ZIP Code. Z - 5-digit ZIP Code matches, but address does not.

Discover A - ZIP and address both match. G - Global non-participant. Foreign card. Cannot verify address. N - Neither the ZIP nor the address matches. U - Unable to verify address. W - Cardholder record. Y - Address only matches. Z - Zip only matches.

American Express A - Address only is correct. G - Global non-participant. Foreign card. Cannot verify address. N - Neither the ZIP nor the address matches. R - Issuer's authorization system is unavailable. Try again later. S - AVS not supported at this time. U - The necessary information is not available.

Account number is neither U.S. nor Canadian. Y - Yes, address and ZIP Code are both correct. Z - Zip Code only is correct.

• CVV Response - This field is blank for check or EFT transactions. The value is the response re-

ceived from the processing network to indicate whether the CVV/CID/CVV2 code matched or not. Here are the possible responses:

Table 4.17. CVV Responses

M - Match N - No Match P - Not Entered/Processed S - CVV should be present, but was not entered/processed. X - No response from card issuer. U - Unavailable. Card issuer not certified for CVV.

• TYPE - This area displays the payment instrument/card type was used for the transaction.

• FIRST NAME- This value is the customer's first name as submitted with the transaction informa-

tion.

• LAST NAME - This value is the customer's last name as submitted with the transaction informa-

tion.

• AUTH # - This is the authorization code issued by the credit card issuing bank for approved transac-

tions.

• BATCH - This number indicates the batch that the transaction is a part of. This is not listed for

check or EFT transactions.

• AMOUNT - This value is the total amount that was billed to a customer's account.

• RECUR - The "GO" button in this column opens the "Recurring Detail" window where a merchant

can modify the recurring commands for a transaction.

• OPTIONS - The "GO" button in this column opens the "Transaction Options" window where a mer-

chant can run refunds, voids, forces, resubmits, postauths, mark returns, and resend emails. For further details, see the section.

The Advanced Transaction Listing

To use the Advanced Transaction Listing system, click the "Advanced" check box, set the date range, and click the "GO" button. As many (or as few) of the search features can be used for a single request. The more search criteria entered, the more specific the search will be. When doing any type of search, be sure to enter a valid date range in the "Transaction Date Information" section. For a general search, use fewer search criteria.

The Control Panel

Figure 4.41. Advanced Transaction Listing Example

The Control Panel

Transaction Details

This search section searches using card information. These are the explanations of search criteria:

• Type - Use this drop down to view a certain kind of transaction (i.e. Order, Credit, Void, Postauth).

This defaults to "All" and allows for a search for any transaction type.

• Payment Type - This identifies whether a merchant is searching for a credit card payment, check

payment, or EFT payment. This defaults to "All" and will search for any payment type.

• Card Type - This is used when a merchant needs to search for transactions run on a specific card

type (i.e. American Express, Discover, Diners Club/Carte Blanche, MasterCard, Visa). This defaults to "All" and allows for a search for any card transactions.

• AVS Category - This allows for a search of transactions with a specific AVS category.

• Batch Numbers - Use this feature to pull open a list of all transactions in a specific batch.

• IP - This is used to search for transactions generated from a specific IP address.

• Trans Source - Use this to search for transactions generated from a specific source (i.e. Auto-

Voided, Web Form, Phone System, Recurring, Virtual Terminal, XML).

The Control Panel

• Sub-Action - This allows for a search of different types of order transactions (i.e. Sale, Force, Pr-

eAuth). This defaults to "All" and will search for any type of order transaction.

• Status - This allows for a search of transactions using the status as the criteria (i.e. OK, Failure, Er-

ror, AVS Failure, Unknown Error, Incomplete). This defaults to "All" and will search for a transaction with any status.

• Last Four - This is used to search for transactions which were generated from an account ending in

a specific last four digits of the account.

• AVS Response - This allows for a search of transactions with a specific AVS response.

• Approval - This is used to search for a transaction with a specific authorization code.

• CVV2 Response - This allows for a search of transactions with a specific CVV response.

• XID First - This is the first entry if doing a search of all transactions in an XID range.

• XID Last - This is the ending entry if doing a search of all transactions in an XID range.

• Total - This is total amount of a transaction.

Customer Home Information

This search section searches using customer information that was submitted at the time of the transaction. This is not necessarily the cardholder information. The following search criteria can be used:

• First Name - This can be used to search for all transactions generated using a specific customer first

name.

• Last Name - This can be used to search for all transactions generated using a specific customer last

name.

• Address - This allows for a search for transactions using a specific street address.

• City - This will search for transactions submitted from a specific city.

• State - This allows for transactions to be searched for using the state as the criteria.

• Zip - This searches transactions generated using a specific ZIP Code.

• Country - This allows a merchant to search for all transactions submitted using a specific country.

Customer Shipping Information

This search section searches using customer shipping information that was submitted at the time of the transaction. This is not necessarily the cardholder information. The following search criteria can be used:

• First Name - This can be used to search for all transactions generated using a specific shipping first

name.

• Last Name - This can be used to search for all transactions generated using a specific shipping last

name.

• Address - This allows for a search for transactions using a specific shipping street address.

The Control Panel

• City - This will search for transactions submitted from a specific shipping city.

• State - This allows for transactions to be searched for using the shipping state as the criteria.

• Zip - This searches transactions generated using a specific shipping ZIP Code.

• Country - This allows a merchant to search for all transactions submitted using a specific shipping

country.

Recurring Information

This search section is designed to assist a merchant in reviewing specific recurring transactions. These are the explanations of search criteria:

• Parent XID - This is used to search for any transactions that were generated as child transactions

from the same parent transaction.

• Recipe Name - This allows for a merchant to find all transactions associated with a specific recur-

ring recipe.

• Recur Status - This searches for recurring transactions based on the status of the transaction (i.e.

Begun, Error, Complete).

• Recur XID - This searches by the Recurring XID.

Customer Contact Information

This search section searches using contact information that was submitted at the time of the transaction. This is not necessarily the cardholder information. The following search criteria can be used:

• Phone - This allows a search of transactions by phone number.

• Email - A merchant can search for all transactions submitted with a specific email address.

• Ext Cust ID - This can be used to search for a specific transaction that was submitted with the

"cust_id" field.

Transaction Date Information

This section is the cornerstone of the entire search mechanism. When doing any type of search, enter a valid date range. The date range only allows a merchant to view the current and previous calendar year.

Output Information

This section allows a merchant to determine how much information and in what format the search data is displayed.

• Records Per Page - This is used to display the number of transactions in the search display. The de-

fault value is 100 transactions, but alternate values are 25, 50, 250, 500.

• Output Format - This is used to create different types of files for the data to display. Here are the

options:

• HTML List - This is the default display. It will pull open an HTML page that displays the information in a version much like the Standard Transaction Listing.

The Control Panel

• XML List - This will download the data in an XML file.

• CSV List - This will download the data in a CSV (comma separated value) file. Microsoft Excel or similar applications can be used to view the CSV file.

Saved Meta-Data Retrieval

The Save Meta-Data function enables merchants to save their own transaction data on the gateway. This feature is typically used to save fields such as the fields requested using the "Passback" function. This data can be used to search for transactions using the advanced transaction search and is displayed in the transaction details page. This data is retrieved in the XML download report. While in test mode, no meta-data is saved. Data is only saved when a transaction processes live.

The Transaction Detail Window - How Can I View My Customer's Information?

A merchant can access the data for a specific transaction by entering the XID number into the Transaction Detail interface and pressing the "GO" button.

Figure 4.42. Transaction Detail Window Example

The Control Panel

The Transaction Information Section

This section includes the same information displayed about a transaction in the Transaction Listing (see the section detailing this). This is the definition of each of those fields:

• DATE AND TIME - This value is the date and time of the original transaction attempt.

• XID - This value is the ID number assigned automatically to a transaction when it is submitted

through the gateway system.

• PXID - This value is the Parent XID, or the XID of the transaction which is the originating XID of a

recurring transaction, a void, a credit/refund, a postauth, or a resubmitted transaction. This field will be blank if the transaction is an originating transaction itself.

• CXID - This value is the Child XID, or the XID of the transaction which is a transaction which has

used this transaction as the originating transaction for a recurring transaction, a void, a credit/refund, a postauth, or a resubmitted transaction. This field will be blank if the transaction has no child transactions.

The Control Panel

• ACTION - This field identifies what type of transaction was submitted.

• STATUS - The field identifies whether a transaction was successful or not. Potential values are lis-

ted below:

• Ok - Valid Transaction

• Incomplete - Generally indicates transaction is currently in process.

• Error - Error receiving response from network. May be caused by user error or an unknown response during transaction processing.

• Fail - Could be any of the following reasons:

• Declined

• Card Expired

• Invalid Card Number

• Lost or Stolen Card

• Card Type Not Supported

• Service Not Allowed

• User Input Data Error

• No Answer From Processing Network

• No Response From Processing Network

Review the Transaction Detail "Error Message" field for the specific reason for failure.

• INSTR - This area displays the payment instrument/card type was used for the transaction.

• FIRST NAME - This value is the customer's first name as submitted with the transaction informa-

tion.

• LAST NAME - This value is the customer's last name as submitted with the transaction informa-

tion.

• AUTH # - This is the authorization code issued by the credit card issuing bank for approved transac-

tions.

• AMOUNT - This value is the total amount that was billed to a customer's account.

• OPTIONS - The "GO" button in this column opens the "Transaction Options" window where a mer-

chant can run refunds, voids, forces, resubmits, postauths, and resend emails. For further information, please see the section detailing this.

• RECUR - The "GO" button in this column opens the "Recurring Detail" window where a merchant

can modify the recurring commands for a transaction.

The Options Window

By clicking the "GO" button in the "OPTIONS" column in the Transaction information Section, the Options window opens.

The Control Panel

Figure 4.43. Options Window Example

The Control Panel

The features displayed are the options available for a successful sale transaction. In addition to these, the Postauth option is available on Pre-Authorized transactions. Here is what these features do:

• Void - This feature can be used to cancel sale, resubmit, postauth, or refund/credit transactions.

Voids may only be issued prior to the batch settlement for the open batch that the original transaction is processed in. Batch settlement cycles daily. The "Text for Email" field can be used to add a message of up to 255 characters which will display on the emailed transaction confirmation.

• Refund - This interface is used to generate a refund to a customer's account. By default, the amount

in the interface will be the amount of the original transaction. A merchant can modify the amount as needed. The "Text for Email" field can be used to add a message of up to 255 characters which will display on the emailed transaction confirmation. Additionally, a separate description value may be entered.

• Force - This feature should only be used if instructed to by the credit card processing network.

When instructed to process a forced transaction, enter the approval code in the "Auth Code" field. The "Text for Email" field can be used to add a message of up to 255 characters which will display on the emailed transaction confirmation.

• PostAuth - Although not displayed in Figure 2.45, this interface is used to complete a sale on a pre-

authorized transaction.

• Mark as Returned - Although not displayed in this image, this feature is used to notate bounced or

returned RediCheck or NACHA transactions. Marking a transaction as returned will not initiate any action with your bank. It will however set a recurring transaction to an 'on hold/held for failure' state if your recipes have the 'Hold On Failure' feature enabled. These return transactions will also show up in your reports so that you have a more accurate accounting of your check activity. This feature is not available for EFT transactions.

• Resubmit Options - There are two options to be used in different situations.

1. Resubmit Original Transaction - This will generate a new transaction using all of the inform-

ation, including amount and description, processed during the original transaction.

2. Resubmit New Transaction - This will generate a new transaction using all of the billing in-

formation from the original transaction, but will process using the newly entered amount and description.

• Resend Email Confirmation - This generates a copy of the email(s) sent at the time of the transac-

tion. This can send either the Customer Confirmation, the Merchant Confirmation, or both.

• View Email Confirmation - This displays copies of the emails sent at the time of the transaction.

The Recurring Detail Window

Clicking on the "GO" button in the "RECUR" column opens the Recurring Detail Window.

Figure 4.44. Recurring Detail Window Example

The Control Panel

Please review THIS for information about this feature.

The Customer Information Section

The Customer Information displays the information that was entered concerning the cardholder at the time of the transaction. This is the definition of each of those fields:

• Name - This displays the first and last name entered for the cardholder.

• Address - This displays the street address, city, state, ZIP Code, and country entered at the time the

transaction was submitted. It is this information that is submitted as the data to the AVS (address verification system) at the card processor.

• Telephone - This value is the phone number entered at the time of the transaction.

• Email - This is the email address which was submitted at the time of the transaction, and the address

to which customer confirmation emails will be sent to (if the merchant has that feature enabled).

The Shipping Address Information Section

This area will be blank unless the optional shipping information is submitted with the transaction at-

tempt.

The Transaction Data Section

This area provides information about how a transaction was submitted and the status of the transaction.

• Last Four - These are the last four digits of the credit card number. This is not listed for check or

EFT transactions.

• Batch - This number indicates the batch that the transaction is a part of. This is not listed for check

or EFT transactions.

• Order Total - This value is the full amount that was billed to the customer.

• Account Source - This value is for EFT/Check transactions and identify the type of account the pay-

ment was drafted from.

• Transaction Source - This indicates how a transaction was submitted. The possible values are:

• Cust - This indicates that a transaction was submitted via an HTML form post generated from an Internet order form.

The Control Panel

• HTML - This indicates that a transaction was submitted via a password v credentialed HTML form post generated from an Internet order form.

• Phone - This indicates that a transaction was submitted via the Call-A_Charge transaction by telephone service.

• Session - This indicates that a transaction was submitted via any of the Control Panel interfaces.

• Recur - This indicates that a transaction was generated through the automated recurring billing system.

• XML - This indicates that a transaction was submitted via an XML query.

• Upload - This indicates that a transaction was submitted via a file upload.

• AV - This indicates that a transaction was a void generated by an auto-void setting.

• AVS Response - This field is blank for check or EFT transactions. The value is the response re-

ceived from the processing network to indicate whether the address and ZIP Code matched the credit card's account address on file in the bank's AVS database or not. Different processors have different values. To view those, please see the section detailing this.

• CVV Response - This field is blank for check or EFT transactions. The value is the response re-

ceived from the processing network to indicate whether the CVV/CID/CVV2 code matched or not. To view possible responses, please see the section detailing this.

• IP Address - This value is the IP address from which a transaction was submitted.

• Error Message - When a transaction fails, the response from the processor is listed in this field.

This field is blank on a successful transaction.

The Form Items Section

For each item submitted to the gateway system as a part of a total transaction, a separate Item Explanation will be displayed.

• Item Explanation - Displays item number.

• Cost - This value is the price of each quantity of an item. This value is multiplied by the "Qty" value

to populate the "Tot" field.

• Desc - This value is the description of the item submitted with the transaction.

• Qty - This value is the number of this item purchased. This value is multiplied by the "Cost" value to

populate the "Tot" field.

• Tot - This value is the item total. The value is reached by multiplying the "Cost" by the "Qty".

The Recurring Information Section

When a transaction is set to be a recurring transaction, this area will display.

• Start Date - The day of when a transaction was set as a recurring transaction. This date may or may

not coincide with the date of the original transaction.

• Recipe Name - This value is the name of the recurring recipe that is set to the transaction at that

time.

The Control Panel

• Remaining Reps - The number of repetitions left that the transaction will continue to rebill until it

cycles to zero or is set to zero.

• Recurring Total - The amount that will be charged for future transactions.

• On Hold - This will display a red YES or a green NO indicating whether the transaction is on hold

to prevent future billings or not. By clicking on the value, you can toggle between on hold (YES) or no on hold (NO).

• Recurring History - Clicking this "GO" button will pull open the history of the recurring attempts

on the specific transaction.

The Batch Settlement Options Window

This window provides information about settlements of an account. Using this window, a merchant to view a batch history, the data from the current open batch, download NACHA files, and can generate a manual settlement. EFT data does not list in this interface. This only displays information for Credit Card, NACHA, and RediCheck transactions.

Figure 4.45. Main Settlement Window Example

The Control Panel

The Credit Card Settle Now Tool

This allows a merchant to run settlement at any time without the assistance of Gateway Service Technicians. When the "GO" button is selected, the account will begin the settlement request for the account. Batch settlements may take a few minutes depending on the number of transactions in the open batch and network traffic. When the batch has settled it will either display a successful response or a failed response. A failed response will indicate the purpose of the error.

The Control Panel

Figure 4.46. Successful Settlement Response Example

Figure 4.47. Failed Settlement Response Example

This tool can be used by merchants who have any settlement setting (Auto, Manual, or Specified time) in the Account Settings. Remember, if an account is set to "MANUAL" settlement, it will not batch until you use the Settle Now tool.

The NACHA Download Tool

If you are authorized by your bank and iTransact to use the NACHA payment system, your NACHA formatted files will be available to download in this interface. The interface creates a plain text (.txt) file with your NACHA data. When you download your NACHA file, it will lock the batch. Until the batch is locked, you can void check transactions using the Transaction Options tool.

The Form Wizard - How Can I Generate An Order Form For My Site Quickly?

The Form Wizard was designed to allow a merchant to create forms quickly and easily for use with the Split Form, Standard Form, and BuyNow formats. This simple interface walks a merchant through several questions and then builds an HTML form which a merchant can copy the source of and upload directly into their webserver. It can also be used to generate a simple HTML form which can be modified by the merchant to add advanced features or functionality.

The Control Panel

Figure 4.48. Form Wizard Example

Generating Split Forms

The Split Form format is used by merchants who do not have their own secure servers. This enables a customer to enter non-secure information on the merchant's server and enter the secure billing information on the gateway's secure server. Building a simple Split Form using the Form Wizard is an easy process. By filling out the fields in the wizard, it will generate a form that is ready to go or a form that can be additionally modified to look and feel like a merchant's site. Here are the instructions for generating a Split Form:

1. Log into the Control Panel.

The Control Panel

2. Access the Form Wizard.

3. Chose the Secure "Split" Form option. A new window will open.

Figure 4.49. Split Form Wizard Example

4. Enter your UID. This number is listed in your Account Settings.

5. Enter the correct address for the Return URL. This will be the address of the page or script that a customer will be directed to after a successful transaction. This becomes the value of the "ret_addr" field.

6. Select the appropriate check marks for Credit Card Acceptance Options. None of these features are required.

7. If a merchant would like to display the billing address on the secure page that was entered by the customer on the order form page, check the "Display Billing Address" check box. This feature is optional.

8. If a merchant would like to display an entry field for a shipping address, the "Allow Separate Shipping Address" must be checked. This feature is optional.

9. If a merchant would like to display an entry field for a CVV security code, the "Allow CVV Entry" must be checked. This feature is optional.

10. Enter the number of items that will display on the order form page and click "PROCEED". (For this illustrated example, the value for this field is "3")

The Control Panel

11. A dialogue box will open displaying instructions for the rest of the Form Wizard (See Form Wizard Instructions Example).

Figure 4.50. Form Wizard Instructions Example

12. Immediately, a second window, the Order Form Items page, will open (See Form Wizard Items Example).

Figure 4.51. Form Wizard Items Example

13. The "A B C" layout options determine the way an item will display on an order form page. A merchant may use the same format for each item, or any combination of formats on a form. Here are examples of each:

• Format A - This style allows for the purchase of a single quantity of one item, by clicking a

checkbox and completing the billing information.

The Control Panel

• Format B - This style allows for the purchase of multiple quantities of an item by entering the

quantity value into a textbox.

• Format C - This style allows a customer to select the item by clicking the checkbox and choos-

ing the quantity from a drop-down menu.

14. After selecting the display format, enter the name of the item in the appropriate item fields (in the examples above, the item names are "Format A", "Format B", and "Format C").

15. Finally, enter the cost of each item (entered without "$") and click the "Create Order Form" button.

16. The order form will then be created and displayed (See Split Form Example). This form will be the half of the split form that resides on the merchant's web server. It is not displayed the billing information request fields on the first half of the split form. The secure half of the order form (where payment information is entered) resides on the gateway's secure server. The HTML coding that is included in the order form page will generate merchant specific information on the secure half of the split form.

Figure 4.52. Split Form Example

17. Right-click with the mouse on the form page and view the source of the page. Copy and save that source, edit/modify it as needed, and upload the page into your website.

Generating Standard Forms

Standard Forms should only be used by merchants who have their own secure servers and meet CISP/ PCI standards. This format allows a merchant to collect all order and payment information on their own secure server and then post that information to the gateway's secure server. Building a simple Standard Form using the Form Wizard is an easy process. By filling out the fields in the wizard, it will generate a form that is ready to go or a form that can be additionally modified to look and feel like a merchant's site. Here are the instructions for generating a Split Form:

1. Log into the Control Panel.

2. Access the Form Wizard.

3. Chose the Standard Form option. A new window will open.

Figure 4.53. Standard Form Wizard Example

The Control Panel

4. Enter your UID. This number is listed in your Account Settings.

The Control Panel

6. Select the appropriate check marks for the payment types to display on the payment page. A merchant should only select a payment type for which they are approved to accept.

7. Select the appropriate check marks for Credit Card Acceptance Options. None of these features are required.

8. If a merchant would like to display an entry field for a shipping address, the "Allow Separate Shipping Address" must be checked. This feature is optional.

9. If a merchant would like to display an entry field for a CVV security code, the "Allow CVV Entry" must be checked. This feature is optional.

10. Enter the number of items that will display on the order form page and click "PROCEED". (For this illustrated example, the value for this field is "3")

11. A dialogue box will open displaying instructions for the rest of the Form Wizard (See Form Wizard Instructions Example).

Figure 4.54. Form Wizard Instructions Example

12. Immediately, a second window, the Order Form Items page, will open (See Form Wizard Items Example).

Figure 4.55. Form Wizard Items Example

The Control Panel

• Format A - This style allows for the purchase of a single quantity of one item, by clicking a

checkbox and completing the billing information.

• Format B - This style allows for the purchase of multiple quantities of an item by entering the

quantity value into a textbox.

• Format C - This style allows a customer to select the item by clicking the checkbox and choos-

ing the quantity from a drop-down menu.

14. After selecting the display format, enter the name of the item in the appropriate item fields (in the examples above, the item names are "Format A", "Format B", and "Format C").

15. Finally, enter the cost of each item (entered without "$") and click the "Create Order Form" button.

16. The order form will then display (See Standard Form Example).

Figure 4.56. Standard Form Example

The Control Panel

17. Right-click with the mouse on the form page and view the source of the page. Copy and save that source, edit/modify it as needed, and upload the page into your website's secure server.

Generating BuyNow Buttons

The Control Panel

BuyNow buttons are used by merchants who do not have their own secure servers. This enables a customer to choose an item on the merchant's server and enter the secure billing information on the gateway's secure server. Building a BuyNow button using the Form Wizard is an easy process. By filling out the fields in the wizard, it will generate a button, or an entire form, that can be added to a merchant's site. Here are the instructions for generating a BuyNow button:

1. Log into the Control Panel.

2. Access the Form Wizard.

3. Chose the Standard Form option. A new window will open.

Figure 4.57. BuyNow Wizard Example

4. Enter your UID. This number is listed in your Account Settings.

6. Select the appropriate check marks for the payment types to display on the payment page. A merchant should only select a payment type for which they are approved to accept.

7. Select the card types to display on the payment page. A merchant should only select card types which they have merchant accounts for.

8. Select the appropriate check marks for Credit Card Acceptance Options. None of these features are

The Control Panel

required.

9. If a merchant would like to display an entry field for a shipping address, the "Allow Separate Shipping Address" must be checked. This feature is optional.

10. If a merchant would like to display an entry field for a CVV security code, the "Allow CVV Entry" must be checked. This feature is optional.

11. Enter the number of items that will need separate buttons and click "PROCEED". (For this illustrated example, the value for this field is "1")

12. A dialogue box will open displaying instructions for the rest of the Form Wizard (See Form Wizard Instructions Example).

Figure 4.58. Form Wizard Instructions Example

13. Immediately, a second window, the Order Form Items page, will open (See BuyNow Wizard Items Example).

Figure 4.59. BuyNow Wizard Items Example

The Control Panel

14. In the "Name" field, enter the item (in this example, that value is ITEM 1).

15. In the "Cost" field, enter the cost of the item (in this example, the cost is $5).

16. In the Description field, enter a message about the item (in this example, the description is "This item is fantastic!").

17. In the Image URL field, include an absolute address of an image file (i.e. ht- tp://www.domain.com/imagefile.jpg) and the click the "Create Order Form" button.

18. The BuyNow button form page will then display (See BuyNow Example).

Figure 4.60. BuyNow Example

19. Right-click with the mouse on the form page and view the source of the page. Copy and save that source, edit/modify it as needed, and upload the page into your website's secure server in it's entirety, or cut the button commands and paste it into a separate page.

The Control Panel

The Auction PayMe Interface - Can I Use My Account For Auction Sales?

For merchants who sell items at online auctions sites, one of the biggest frustrations is receiving payment from the winning bidder in a prompt manner. The Auction PayMe system solves the problem. With very little effort, a merchant can obtain instant check or credit card payments from bid winners using the Auction PayMe secure transaction services--even if they don't have their own web site. By filling out this simple form, the buyer receives an email with a link to the merchant's secure Auction PayMe page that's hosted on the gateway's secure server where payment can be made.

Figure 4.61. Auction PayMe Interface Example

• eBay Seller ID - The value for this field should be the merchant's registered seller id.

• Seller E-Mail Address - This should be the email address to which a merchant wants to receive

contact from a buyer.

• Buyer ID - The value for this field should be the winning bidder's registered buyer id.

• Buyer E-Mail Address - This address will receive an email with the link to the merchant's secure

Auction PayMe page that's hosted on the gateway's secure server where payment can be made.

• eBay Item # - This should be the item ID assigned by eBay at the time of the posting of the auction.

The Control Panel

• Bid Amount - This value should be the amount of the winning bid (enetered without "$").

• Type of Payments to Accept - These checkboxes will indicate to the gateway which payment fields

will display when a customer access the Auction PayMe page.

• Submit AuctionPay Request Button - This button needs to be click once the fields are filled out

correctly.

• Close Window Button - This is to be used to cancel an Auction PayMe request prior to clicking the

"Submit AuctionPay Request" button.

When an Auction PayMe request is submitted, an email is sent to the winning bidder.

Figure 4.62. Auction PayMe Request Email Example

When the email is received by the winning bidder, the buyer can click on the payment link and be taken to a payment page where the transaction can be completed.

Figure 4.63. Auction PayMe Form Example

The Control Panel

The payment will be attempted, email confirmations will be sent, and the customer will be shown a success message if the transaction is successful.

Figure 4.64. Payment Success Page Example

The Recurring Transaction Window - How Does The Recurring Billing System Work?

The window can be accessed from the Recurring Transaction link in the Control Panel, the "List Recipes" link in the Recipe Builder, and from the "View/Select Recipe" button in the Recurring Detail interface of any transaction (See Figure 3.1).

Figure 4.65. Recurring Transaction Recipe Window Example

The Control Panel

Considerations

• A Recurring Recipe is the schedule which contains the instructions as to when a recurring transac-

tion is billed. The Recurring Repetitions/Remaining Repetitions is the number of times that a transaction follows the recipe. Once a transaction is set as a Recurring Transaction, it will continue to follow the recipe until the number of repetitions cycles down to or is manually set to zero.

• Separate recipes do not need to be built for transactions following the same schedule, even if the

transactions are initiated at different times, have different amounts, and different necessary repetitions. There is no limit to the number of transactions that can use the same recipe.

• There is no limit to the number of recipes that a merchant can build.

• The recurring cycle begins each night at 12 Midnight, Mountain time. Any necessary modifications

to a recurring transaction, or recurring recipe must be completed prior to 11:59 PM for it to be reflected as a part of the next day's recurring cycle. For instance, if it is January 31st and a recurring transaction is scheduled to process on February 1st, that transaction can be modified up to 11:59 PM on January 31st. In further explanation, if a merchant needed to set the remaining repetitions to zero to prevent future transactions, but missed the 11:59 PM deadline, the merchant would have access to change the number of remaining repetitions to zero. However, since the cycle had already begun, the transaction would still be billed. Future transactions would be prevented, but a refund or void would now be necessary because the transaction which the merchant had intended to stop was billed. The remaining repetitions in such a case would display as "-1".

• When a transaction is initially submitted for processing, recurring details may be passed as part of

the form that will automatically create future recurring charges, based on the details that you provide. In addition, you may also modify previously submitted transactions and mark them as recurring. This is done via the Transaction Listing.

• If you do not need to initiate a charge at the time of entry, use a zero amount AVSOnly transaction

type.

• The calculations used to determine when a transaction will recur are based on the initial transaction

date.

• The largest allowed value for the Recurring Repetitions is "99999".

The Recurring Recipe Builder

To access the Recurring Recipe Builder, please click the "Add Recipe" link in the Recurring Transaction window. Complete this interface and click the "Create Recipe" button and the recipe will be added to the list of recipes.

Figure 4.66. Recurring Recipe Builder Example

The Control Panel

Recipe Name

When selecting a recipe name, please remember that it will be case-sensitive (must be lowercase) and can be only one word. Any alpha-numeric characters can be used. You should make it easy to remember. For instance, you may want to name a recipe "1stofmonth" if it's designed to bill on the first day of the month.

Recipe Types

The next section of the Recipe Builder is the Recipe Types. Only one Recipe Type may be used per recipe.

• Scheduled Recipes - Using a Scheduled Recipe allows you to run ALL transactions linked to a re-

The Control Panel

cipe at a date that can be controlled and scheduled manually using the scheduling tool. The scheduling tool may be accessed from your Recipe List after a Scheduled Recipe is built. The scheduling tool is only available for scheduled recipes. The "Delay Period" can be used to prevent a transaction from recurring too soon after the initial transaction is processed. The "Delay Period" is the number of days after the original transaction before it is eligible for a scheduled recurrence. To build a Scheduled Recipe, choose a recipe name, click the radio button to the left of "Scheduled", enter a numeric value for the number of days in the "Delay Period", add any additional features, and click the "Create Recipe" button.

• Day Recipes - This type of recipe allows a merchant to bill transactions applied to a recipe to bill

every X number of days after the initial billing (and from billing to billing). To build a Day Recipe, choose a recipe name, click the radio button to the left of "Day", enter the value for the number of days between recurrings, add any additional features, and click the "Create Recipe" button.

• Week Recipes - Building a Week Recipe allows a merchant to bill a transaction on specific days of

the week - even multiple days during the same week. A merchant can select 1, 2, or 3 weeks between billings and can check any day or (days) for the billings to take place. To build a Week Recipe, choose a recipe name, click the radio button to the left of "Week", select the value for the number of weeks between recurrings, select the day (or days) of the week on which the billings will take place, add any additional features, and click the "Create Recipe" button.

• Month Recipes - The type of recipe allows a merchant to bill transactions every X number of

months on the Nth day (or days) of that month. Since some months have only 28, 30, or 31 days in the month, days 29-31 are covered under the "Last Day" selection. This type of recipe assumes that the recurring will begin in the calendar month after the initial transaction is processed. This means if, for instance, a transaction is billed on January 5th, and the recipe instructions are built to bill every 1 month on the 15th day of the month, the transaction would experience its first recurring billing on February 15th (not on January 15th). To build a Month Recipe, choose a recipe name, click the radio button to the left of "Month", select the value for the number of months between recurrings, select the day (or days) of the month on which the billings will take place, add any additional features, and click the "Create Recipe" button.

The Split Amounts Function

Don't be confused by the name of this feature. This feature can be used with any of the Recipe Types. This feature allows the recurring transactions to be billed a different amount than the initial transaction. The amount can be changed automatically is setting up a form based recurring transaction using a recipe built with the Split Amounts function, or the amount can be changed manually in the "Edit Recurring Items" interface. If there is ever the potential that the amount of a billing may increase, it is wise to set all recipes to allow Split Amounts.

The Hold On Failure Function

This feature is available for credit card transactions only. If this is enabled on a recipe and a recurring at-

tempt fails, that transaction will be put "on hold" automatically to prevent future billing attempts so that account information can be updated (either by the merchant or the customer). If this is enabled, the recurring postback will include the "on hold" parameter to notify if this has been triggered due to a failure.

The Allow Customer Update Function

This feature is available for credit card transactions only. If enabled for a recipe, confirmation emails for successful and failed recurring transactions will include a link to a secure billing update page. A cardholder will be able to follow the simple instructions to change their credit card billing information through a secure billing interface. If a recurring transaction failure triggered the necessary update, a new transaction will be attempted at the time of the update to bring the account payments up to date for the failed billing. If enabled, the recurring postback will include the "billing_update_token".

The Email Text Entry

This allows a merchant to pass a generic message in the text of each of the confirmation emails sent out when a transaction using the recipe recurs.

The Recurring Help Window

This window offers a quick reference guide when creating new recipes or setting transactions as recurring.

The Control Panel

Setting Transactions To Recur

A transaction can be set to recur automatically at the time of the transaction or manually anytime there after.

Automatic Recurring Activation Using HTML

Recurring transactions may be initiated at the time the original transaction is processed. To initially set a transaction as recurring, simply add the following input fields to your HTML order form. In this example we'll use the "monthly13" recipe and have the transaction recur six times, with a recurring total of $100.00 and a recurring description of "test2":

Table 4.18. HTML Recurring Example

Automatic Recurring Activation Using XML

Recurring transactions may be initiated at the time the original transaction is processed. To initially set a transaction as recurring, simply include the following fields to your XML query. In this example we'll use the "monthly13" recipe and have the transaction recur six times, with a recurring total of $100.00 and a recurring description of "test2":

Table 4.19. XML Recurring Example

<RecurringData> <RecurRecipe>monthly13</RecurRecipe> <RecurReps>6</RecurReps>  <RecurTotal>100.00</RecurTotal>  <RecurDesc>test2</RecurDesc>  </RecurringData>

Manual Recurring Activation

This manual activation method can be used for transactions that were submitted via HTML or XML. Once a sale transaction has been processed successfully, it can be set as a recurring transaction by following these simple steps:

1. Log into the Control Panel and open the Transaction Listing for the day when the original transaction was processed. Locate the transaction that needs to be set to recur and click on the XID number to open the Transaction Detail request screen.

The Control Panel

Figure 4.67. Transaction Listing Example

2. From the Transaction Detail request screen, click the "Get Detail" button.

Figure 4.68. Transaction Detail Access Window Example

The Control Panel

3. In the Transaction Detail Screen, click on the "GO" button in the "RECUR" column.

Figure 4.69. Transaction Detail Example

The Control Panel

4. In the Recurring Detail window, enter the number of repetitions (number of times a transaction needs to rebill) and choose the Recurring Recipe Name from the drop down menu. If you need to change the amount to be billed or the items, uncheck the "Use Original Order Items" box and editing and additional line tools will display. Once the necessary fields are completed, click the "Setup Recurring" button.

Figure 4.70. Recurring Detail Example: Non-Recurring Transaction

5. The Recurring Setup information page will display if all of the fields have been filled out correctly and the detail has been updated.

Figure 4.71. Recurring Setup Information Page Example

The Control Panel

Recurring Activation In The Virtual Terminal

The Recurring Transaction Virtual Terminal Interface can be accessed by opening the Standard Virtual Terminal interface. Choosing this interface allows for the entry of multiple Order Items, as well as separate shipping and tax charges. It also allows for the entry of recurring billing information by clicking the Recurring toggle. Using this interface will charge a transaction in real-time, but will also schedule future transactions on that payment account. If you do not need to initiate a credit card charge at the time of entry, use a zero amount AVSOnly transaction type. This interface will not charge a card without valid recurring billing information.

Figure 4.72. Recurring Virtual Terminal Welcome Section Example

The Control Panel

This Initial Transaction Information section is where a merchant enters the general customer information when generating the initial charge. This same general information will be default information for future recurring transactions (unless the user information is modified in the Recurring Transaction Detail interface).

Figure 4.73. Recurring Virtual Terminal Transaction Information Section Example

amounts, or can submit a single item which is a total of the amount to be billed to the customer. To access items 6-10, please use the scroll bar on the left side of the "Total" column.

• Item Description - A merchant should enter the name of the product that a customer is purchasing

• Item Qty - This value will be multiplied by the amount listed in the Item Price field to provide the

value for the Item Total. This value can be "1", even if you are selling multiple quantities - as long as the Item Price amount is the cost of all of the products combined.

• Item Price - The amount listed here will be multiplied by the value listed in the Item Qty to provide

the value for the Item Total.

iTransact iTransact, Gateway User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual