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.