iveri Networked Credit Card System BATCH PROCESSING FIXED FORMAT SPECIFICATION Version 1.20

Transcription

1 iveri Networked Credit Card System BATCH PROCESSING FIXED FORMAT SPECIFICATION Version 1.20

2 iveri Batch Processing Page 2 of 10 Preface Changes included in this document include : 1. Original Document. 2. Changes made by R. Elferink changing the Merchant Invoice Field to 32 characters and adding the Merchant Reference Field as well as the Budget Period 3. Added the reconciliation status to indicate whether the transaction has been reconciled with the bank and if so, if it is correct. 4. Changed the brand name to iveri from Set2Go 5. Added the ability to Perform Authorisations and Authorisation Reversal. Corrected CCYY to YYYY to clear up confusion with 2101 being the year 01 in the 21 st Century. Corrected formatting in Reference Invoice Number 6. Change the names of the following fields in line with that used thoughout the iveri Gateway (previous name new name): Merchant Invoice Number Merchant Reference Transaction Request Date/Time Purchase Date/Time Transaction Response Date/Time Acquirer Date/Time 7. Added Recurring payments transaction type as Transaction Code 5.

3 iveri Batch Processing Page 3 of 10 INTRODUCTION This document describes the fixed specification format of the Batch Upload File and the Batch Result File. Both of these are ASCII text files with fixed field record structure where each transaction is recorded as a single line in the text file. The Batch Upload File can be uploaded either from the iveri BackOffice or by using the ivericlient software (the latter applies to Enterprise merchants only). The Batch Result File can be downloaded through these same mechanisms. Note that the Batch Result File is available for download only after processing of the batch has completed. Note that the Reconciliation Status of the individual transactions might not yet be updated, since the reconciliation process only occur the day after processing.

4 iveri Batch Processing Page 4 of 10 The Batch Upload File Record Layout The Batch Upload File consists of three sections namely :- Header Transaction records Trailer HEADER RECORD Record Type N*2 "00" Bank Code Identifier for the N*2 "NN" bank at which the USN is valid Merchant USN The USN to use to N*10 "NNNNNNNNNN" process the batch with File Processing Date If this date is the N*8 "YYYYMMDD" current date or up to 1 calendar month old then the file will be processed on the date on which it is uploaded. If the date is up to 1 calendar month in advance of the date on which the file is uploaded, then the file will be held on the iveri server until the specified date when it will then be processed on that specified date. Application ID Your ApplicationID A*36 "AAA AAA" allocated by iveri Merchant Name Your Merchant Name under which your ApplicationID has been registered A* "AAA "

5 iveri Batch Processing Page 5 of 10 CREDIT CARD TRANSACTION RECORD Record Type N*2 "01" Merchant Terminal Used to group transactions A*8 "AAAAAAAA" Number Merchant Reference together Unique identifier for this invoice or credit note. NOTE: DO NOT USE ANY COMMA s AS PART OF THIS IDENTIFIER A*32 "AAA AAA" Transaction Code See Appendix B N*2 "NN" Purchase Date Date the invoice or credit N*8 "YYYYMMDD" note was raised Purchase Time Time the invoice or credit N*4 "HHMM" note was raised Amount Value is in cents N*10 "NNNNNNNNNN" CCNumber Credit Card Number NOTE: Pad with zeros from the left to fill the required field of twenty numbers N*20 "NNN...NNN" Card Start Date The beginning of the period for which the card is valid. If this is not available use the current month and year. N*6 "YYYYMM" Card Expiry Date N*6 "YYYYMM" Authorisation Code Pre-authorisation code if one has been obtained for this transaction N*6 "NNNNNN" Set to "000000" if it does not exist Budget Period Original Merchant Reference TRAILER RECORD The Budget period to request this authorisation to be used with. In number of months The Invoice Number of the original invoice which is being refunded. This is only used for the case where a refund is being performed or in the case of a recurring transaction. Note that the format of this field must be right justified irrespective of whether it is numeric or alphanumeric. N*2 NN Set to "00" if it does not exist A*32 "AAA AAA" Set to " " (all spaces) if it does not exist. Record Type N*2 "09" Total number of N*6 "NNNNNN" transactions Total Amount The simple sum of all the amounts without regard to whether it is a sale or a refund etc N*10 "NNNNNNNNNN"

6 iveri Batch Processing Page 6 of 10 The Batch Result File Record Layout The Batch Result File consists of three sections namely :- Header Transaction records Trailer HEADER RECORD Record Type N*2 "90" Bank Code Identifier for the bank at N*2 "NN" Merchant USN Date when file was created which the USN is valid The USN used to process the batch with N*10 "NNNNNNNNNN" N*8 "YYYYMMDD" CREDIT CARD TRANSACTION RECORD Record Type N*2 "91" Merchant Terminal Used to group transactions A*8 "AAAAAAAA" Number together Merchant Reference Unique identifier for this A*32 "AAA AAA" invoice or credit note Transaction Code See Appendix B N*2 "NN" Transaction Status Refer to Appendix B N*5 "NNNNN" Acquirer Date Actual Date of the N*8 "YYYYMMDD" transaction Acquirer Time Actual Time of the N*4 "HHMM" transaction Amount Value is in cents N*10 "NNNNNNNNNN" CCNumber The credit card number is N*20 "NNNN...NN" passed back in mangled form e.g " " Authorisation Code Authorisation code N*6 "NNNNNN" allocated to this transaction Cycle Number Along with the Trace N*6 "NNNNNN" Number this forms a unique identifier for this transaction Trace Number Along with the Cycle N*6 "NNNNNN" Number this forms a unique identifier for this transaction Reconciliation Status The Reconciliation Status for this transaction as per Appendix B - Reconciliation Status N*5 "NNNNN" TRAILER RECORD

7 iveri Batch Processing Page 7 of 10 Record Type N*2 "99" Total number of N*6 "NNNNNN" transactions Total Amount The simple sum of all the amounts without regard to whether it is a sale or a refund etc N*10 "NNNNNNNNNN"

8 iveri Batch Processing Page 8 of 10 Appendix A : Field Justification All Fields are justified in the following manner :- Numeric Fields are pre-pended with 0's to the full width of the format Alphanumeric Fields are left justified and ' ' (spaces) appended to the full width of the format A* means an unspecified length field - we read to the end of the line.

9 iveri Batch Processing Page 9 of 10 Appendix B : Field and Reply Codes Bank Code VALUE DESCRIPTION "01" Nedbank "02" Not used - Yet Transaction Code VALUE DESCRIPTION "01" Sale "02" Refund 03 Authorisation 04 Authorisation Reversal 05 Recurring Sale Transaction Status Transaction Status ResultDescription 0 N/A (Approved) 1 Timeout waiting for response. Try again 3 Hot card 4 Denied 5 Please call 6 Card Address Failure 7 Card Security Code Failure 8 Card Type not accepted 9 Unable to process the transaction 11 Invalid Amount 12 Invalid Budget Period 14 Invalid Card Number 15 Invalid Track2 16 Invalid Expiry Date/Card Period 18 Invalid Authorisation code 255 Unknown Error Reconciliation Status VALUE DESCRIPTION "00000" Unreconciled - The reconciliation process for this transaction has not taken place yet. "10000" Reconciliation has taken place and the result code accurately depicts the status of the transaction "10001" Reconciliation has taken place and the transaction could not be found. "10002" Reconciliation has taken place and the transactions details either in amount, cardholder, result code, cycle number, trace number does not match.

10 iveri Batch Processing Page 10 of 10 Appendix C : Recurring Transaction Processing Recurring transactions are transactions that are processed by the same merchant to the same cardholder for the same services on an ongoing basis and are typically insurance, utility or telecommunications charges. With the advent of PCI the security and storage of sensitive card data (PAN, Expiry etc) requires that merchants take far more care of the data and perform annual audits of their IT infrastructure. The iveri RecurringDebit transaction is designed to alleviate some effort that merchants have to put into place in order to conform to PCI DSS standards. Essentially what the solution entails is that instead of the merchant storing the PAN itself, the merchant must store a transaction identifier that refers to the PAN and it is this identifier that will be required in future transactions instead of a PAN. By way of an example and starting with a merchant taking on a new customer. The first transaction that gets processed MUST use the PAN/Track2 itself since no record of this PAN for this merchant exists in the iveri Gateway's database at this stage. The merchants' reference for this transaction is, for example, MR01 and could be processed using any of the iveri products such as Link, Lite, Enterprise etc and is valid for both card not present and card present environments. Once this transaction has been processed the merchant would use this reference in future to indicate the PAN on which the future transactions should be processed; thus relieving the merchant of the responsibility of storing the actual PAN data to use in future transactions. When the merchant wants to charge the same customer in the future the merchant would submit the following data in the batch file The dotted-out PAN received in the response of the original transaction or calculated by the merchant. The formula for deriving the dotted-out PAN is to take the first four and last four digits and as many '.' as required to maintain the original length of the PAN. E.g. a PAN of dotted out would be (16 digits)and a PAN of would be (15 digits). A transaction Code of 5 if using the fixed format batch. The Expiry Date of the card that should be used for the transaction. The merchant should keep the expiry date up to date in the merchants database. The reference only retrieves the PAN from the iveri Gateway database, not the Expiry Date, so this piece of information must be submitted in the batch. A new MerchantReference for this transaction which in our example is going to be MR21 The old MerchantReference must be submitted in the OriginalMerchantReference field and this value would be MR01 in our example. All other fields in the batch remain valid and are used as for a non recurring transaction. The next time that the merchant wants to charge the same customer the merchant should use a new MerchantReference of MR31 and the OriginalMerchantReference should contain a value of MR21 and so on into the future. The reason for this daisy chaining of reference fields is to limit the time within which a merchantreference can be be used to 6 months. If the merchant refers to an identifier of a transaction which was processed over 6 months ago, the PAN relating to that transaction will not be able to be determined. Merchants must ALWAYS use the identifier for the PAN that they wish to use for the transactions that is the most recent on their records.