- Introduction
- Commands & Actions
- Transaction Sequence
- MasterPass
- Visa Checkout
- Foreign Exchange
- Parameter Description & Action
- Gateway Domain Knowledge
- Transaction Result Codes
-
Out Of Band
-
Out of band transaction notification
-
Out Of Band - Merchant Webservice
-
Card on File - Recurring/Adhoc transactions
-
PINBlock encryption via Triple DES DUKPT encryption
-
PINBlock encryption via Master/Session encryption
-
Track2 encryption via Master/Session encryption
-
Track2 encryption via Dukpt encryption
-
Debit with PIN and Balance Enquiry
-
EMV Transactions
-
Coding for EMV data
-
- Tokenization
- SOAP API
- Pos Device Intergration
- Acquire Contact Information
- 3D Secure
-
Enterprise API Samples
-
Transaction Message Examples
-
Merchant Benefits
-
Pre-Auth – “Authorisation with PAN”
-
3D Secure 2
-
Pre-Auth Completion – Follow-up Debit
-
3D Secure 2 implementation using the Pop-Up Method
-
Pre-Auth Reversal – “Authorisation Reversal”
-
3D Secure 2 implementation using the Form Post
-
Refund – “Follow-Credit”
-
Authorisation with 3DS 2 Data
-
Refund – “Initial Credit”
-
Void
-
- Card on File
- Additional Data Transactions
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.
- 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.
|
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) |
- 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 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.
Enquiry
- 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.