The Batch Upload File Record Layout

The Batch Upload File consists of three sections namely:-

• Header
• Transaction records
• Trailer
  
  

Header Record

Credit Card Transaction Record

Trailer Record

Batch Processing Fixed Format Specification

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.

The Batch Result File Record Layout

The Batch Result File consists of three sections namely :-

• Header
• Transaction records
• Trailer

Header Record

Credit Card Transaction Record

Trailer Record

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.
  
  

Field and Reply Codes

Bank Code

Transaction Code

Transaction Status

Reconciliation Status

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 21st Century. Corrected formatting in “Reference Invoice Number”
6. Change the names of the following fields in line with that used though out 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.

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 PCIDSS, 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 Recurring Debit 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 “4242424242424242” dotted out would be “4242........4242” (16 digits)and a PAN of “361544444446349” would be “3615........6349” (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.