Duplicate transactions

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
As mentioned in section 8.2, 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 (9.2.1) or retrying (9.2.2) 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.