Duplicate transactions

A problem of a duplicate transaction can occur if a merchant submits a previously successful transaction in a new request. A duplicate transaction of this nature is typically due to a user's unintentional mistake, e.g. pressing the “Submit” button twice, or submitting the same batch twice. It is responsibility of the merchant to ensure that a single transaction request is not submitted successfully more than once.

Nevertheless, the iVeri Gateway provides three mechanisms to protect against duplicate transactions. Specifying a unique MerchantTrace is a client-side configuration, while the latter to require contacting your local distributor.

Specify a unique Merchant Trace for each step in a Transaction Sequence

A MerchantTrace is a unique identifier for each request sent to the gateway and is an optional parameter. The MerchantTrace corresponds to a database index that was generated by the merchant before a request was sent to the gateway. In short, the MerchantTrace refers to a particular step in the transaction sequence.

The recommended way to control duplicate transactions is to always specify a MerchantTrace.  This has two benefits.

• If a merchant does not receive a reply to a request, then they have the choice of either voiding or retrying  the transaction by using the same MerchantTrace.

• A merchant can re-use a MerchantReference with different MerchantTraces for the same TransactionIndex.

Merchant Reference validity period

• A MerchantReference is a unique identifier allocated by the merchant for a transaction sequence.
• The MerchantReference validity period is a mechanism to protect merchants against undesired double debiting.
• When performing an initial transaction request (i.e. no TransactionIndex provided), then if the last use of that MerchantReference (within a time period) was a successful, then a new Transaction is not performed.
• When performing a follow up transaction (i.e. TransactionIndex provided), then if the last use of the MerchantReference (within a time period) of the same transaction type was successful, then a new Transaction is not performed. [Assuming the Transaction Type Repetition option has not been activated].
• The default time period (Merchant Reference validity period) discussed above is 6 months. This can be changed to a minimum of 3 days.

Recurring transaction checking

• The Recurring transaction checking period is an additional mechanism to protect merchants against undesired double debiting.
• By default, recurring transaction checking is disabled.
• When enabled, if a transaction is attempted with the same PAN, Amount, Command combination, but a different MerchantReference as a previously successful transaction done within a period, then the subsequent transaction request will fail.
• If a Merchant explicitly requests this to be enabled, a time period (in seconds / minutes / hours) should be specified. This is typically 5 minutes.
• If a Merchant uses MerchantTrace to uniquely assign each individual transaction before submission to the iVeri Gateway, then this option should not be needed.
• This option is recommended for merchants who are forced to have poor state handling - for example those that generate a merchant’s reference in memory and only write to the database after sending a request to the iVeri Gateway.
• Note that even when this option is disabled, an acquirer or issuer “downstream” may have their equivalent option enabled