首页 └Enterprise Developer's Guide └Ensuring end to end transaction integrity

Enterprise Developer's Guide

0 %

已完成

课程内容

Ensuring end to end transaction integrity

前一页 下一个
全屏 分享

Overview

Transaction integrity can be seen as ensuring that all players within an individual iVeri transaction agree on its outcome. When a Card Holder gets his statement from his Issuer, it must correspond to his instruction to the merchant for a corresponding transaction.When transaction integrity is compromised either willfully (fraud) or unintentionally, it can result in a disputed transaction with legal impacts.

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:

  • communications error between merchant and cardholder

  • printer could not print the invoice

  • 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 similar to:    

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:

Result Code

Result Description

Action

0

Void successful

Transaction successfully voided.

13

Void unsuccessful

Too late to void the transaction.

1

Timeout

Void can be automatically retried a minute later

\9

Unable to process

Void can be automatically retried a minute later

255

General Error (Exception)

Void can be retried a minute later after the problem given in the ResultDescription is fixed (which may require manual intervention)













                              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:

                              Result Code

                              Result Description

                              Action

                              1

                              Timeout

                              Transaction can be automatically retried a minute later

                              9

                              Unable to process

                              Transaction can be automatically retried a minute later

                              255

                              General Error (Exception)

                              Transaction can be retried a minute later after the problem given in the ResultDescription is fixed (which may require manual intervention)

                              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:
                                • If the previous attempt was successful, a successful result is returned.
                                • If the previous attempt was unsuccessful, the transaction request is retried.
                                • 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 MerchantTrace 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, “Recurring transaction checking".

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

                              • Performing a “Transaction lookup” within iVeri BackOffice
                              • Download a “Reconciliation file” (can be automated with iVeri FileTransfer) and compare records.
                              • Check an immediate notification mechanism (such as email for iVeriBatch clients)
                              • 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.



                              额定值
                              0 0

                              目前没有任何评论。

                              加入这个课程
                              成为第一个发表评论的人。