Individual transactions

 
Void
A “Void” of a previous transaction request is a command to ignore (i.e. cancel the effects of) a previous (recently submitted) transaction request. When a merchant receives a successful response for a transaction request, and thereafter “something goes wrong”, then the Merchant has the option to “void” the transaction.

Examples of “something goes wrong” are:

1. communications error between merchant and cardholder
2. printer could not print the invoice
3. problem accessing merchant database
   

A merchant can also call “void” when s/he does not know whether a response was received from the iVeri Gateway (for example a power failure). A successful void (cancellation) typically results in the transaction not being shown on the merchant nor the cardholders’ statements.Transaction sets are settled as a group at predefined periods (cycle cut off time).

A “Void” can only be successful if the transaction being cancelled has not passed its cut off time. Therefore, when a void is required, it should be done as soon as possible (particularly since cycle cut off time is out of the control of a merchant). If the void request is submitted too late, then the void request will fail, and a separate reversal transaction would be required.

Enterprise users call Void with the syntax like:    
enterprise.prepare("Transaction", "Void", applicationID, mode);
A Void request must set one of the following parameters: OriginalMerchantTrace or OriginalRequestID, for example:
enterprise.setTag("OriginalRequestID", requestID)

A Void has one of the following responses

If the iVeri Gateway receives a Void request referring to a MerchantTrace or RequestID that it has no knowledge of, then “Void successful” is replied.
A merchant implementing “Void” command requires a void repeat mechanism which only ends upon receiving a “Void successful” or “Void unsuccessful” response.

If you intend to resubmit the transaction, then you can either:

• Submit it immediately using a new MerchantReference, and have a separate process or thread to manage the sending of Voids (which may only be sent a few minutes later)
• Implement a mechanism where the transaction is only sent after the void process for the transaction is completed.
• Implement a retry mechanism discussed below without using a Void.
  

Retry 
A merchant may want to retry a transaction after receiving an unsuccessful response.

If a merchant is not sure what the iVeri Gateway replied previously, then they might even want to retry after a receiving a successful response. Typically, a retry is relevant after receiving one of the following results on a transaction request:

A retry is relevant after the above responses because then one would expect a different result code. Nevertheless, a retry is supported after other result codes (eg Successful / Denied / Hot card / Black card) for when there is some change that could cause the transaction to be approved, or when the original reply is unknown to the merchant.
The following shows three different approaches to retries. A retry is only recommended in using the first approach, however all these approaches are supported.

Retry with client recorded Merchant Trace
A merchant records transaction information in their database before they send a transaction request to the iVeri Gateway. The database index of this request is given as the MerchantTrace (to uniquely identify an individual transaction request).

The merchant retries a previous transaction with the same MerchantTrace, MerchantReference, Command, Amount, PAN parameters as previously.

The possible responses are:

1. If the previous attempt was successful, a successful result is returned.
2. If the previous attempt was unsuccessful, the transaction request is retried.
3. If the previous attempt is in process, then “Transaction in process” (ResultCode 9 : Unable to process transaction) is returned. The retry can then be reattempted a minute later.
   

If the merchant is only performing debits, and there is a database table where the unique identifier corresponds to the reference number given to a card holder, then it may make sense for the MerchantReference and MerchantTrace to be the same.

NB. The NedbankBICISO provider does not allow a follow-up debit to be Voided. If a transaction cannot be Voided and no response is received from the iVeri Gateway, the transaction has to be retried instead. For this, all transactions done with the ApplicationID has to be with MerchantTrace. Once a response is received for the follow-up debit, a follow-up credit has to be performed to undo the debit if it was successful.

Retry without Merchant Trace
It is not recommended to retry a transaction without a MerchantTrace.
Nevertheless, if the same Command, Amount, PAN, and MerchantReference as a previous transaction are specified (with no Merchant Trace given), then the possible responses are:

• If the previous attempt was successful, then "A transaction with the same MerchantReference was successful" (Result Code 255: Duplicate MerchantReference).
• If the previous attempt was unsuccessful, the transaction request is retried.
• If the previous attempt is in process, then “Transaction in process” (Result Code 9 : Unable to process transaction) is returned. The retry can then be reattempted a minute later.
  

Retry with irrelevant Merchant Trace (or irrelevant Merchant Reference)
A merchant may be tempted to bypass the various checking mechanisms within the iVeri Gateway and just send the current date time stamp as the value for the MerchantTrace or MerchantReference. In this manner there is more chance that a transaction request will be successful. However, there is also more chance that the card holder will be double debited!

For merchants who cannot store an individual request identifier before sending the request to the iVeri Gateway, see section 9.3.3 on “Recurring transaction checking”.

Enquiry
A merchant with a doubt of the current status of a transaction can determine its status by:

1. Performing a “Transaction lookup” within iVeri BackOffice
2. Download a “Reconciliation file” (can be automated with iVeri FileTransfer) and compare records.
3. Check an immediate notification mechanism (such as email for iVeriBatch clients, and SMS for iVeri Voice clients)
4. Look in the logs for an exception message containing details of a misconfiguration or a coding error.

Conclusion
The Void Retry and Enquiry mechanisms discussed above help to either fix an individual transaction integrity or resolve the doubt around what the current state is. A merchant should automate at least one of these mechanisms. If a Void is unsuccessful, or the current state does not correctly correspond to the corresponding transfer of goods or services, then a follow up reversal transaction may be required.