The Batch Upload File XML Specification

 
This section describes the contents of the batch file uploadable by using iVeriClient FileTransfer with Command “Batch” (refer to the iVeri Client Developers Guide documentation (available from the iVeri website) for further details of this command). This file can also be uploaded from the iVeri BackOffice (refer to the “iVeri BackOffice User Guide” (available from the iVeri website) for more details).

The Batch Upload File has the following XML tags (see the iVeriClient V_XML documentation for full details on these tags) :

Introduction

 
This document describes the XML specification of the Batch Upload File and the Batch Result 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 XML specification of other downloadable XML files is described in the “iVeri Download Files XML Specification” document available from the iVeri website.

The Batch Result File XML Specification

 
This section describes the contents of the batch file downloadable by using iVeriClient FileTransfer with Command “Batch” and the “XML” switch set to true (refer to the iVeri Client Developers Guide documentation (available from the iVeri website) for further details of this command). This file can also be downloaded from the iVeri BackOffice (refer to the “iVeri BackOffice User Guide” (available from the iVeri website) for more details).

The Batch Result File has the following XML tags :

Batch Processing Xml Specification

Preface

 
Changes included in this document include :

1. Original Document.
2. Added Recurring payments transaction type.
   
   

Field and Reply Codes

 
Result Status Code

Recon Status

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 or the TransactionIndex received in the response in the 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 command of “RecurringDebit”.
• 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 OR the TransactionIndex received in the response to the original transaction should be put into the “TransactionIndex” tag. The value in our example if using merchantreference would be “MR01”.
• 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” (or the TransactionIndex received in the response to transaction “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.