Transaction Life Cycle

The following diagrams describe how related stages can be executed during the life cycle of a transaction. There are three diagrams to illustrate the three possible starting points that a transaction life cycle can start from and, once it has started, what follow-up transactions can be performed on them. The data which links transactions together is the MerchantReference which is generated by the POS Till and/or MerchantTrace which is generated by the Indigo Server and returned in appropriate response messages to the POS Till.

There is a subtle distinction between a Refund (command = Credit) and Payment (command = Credit); a Refund is the term used when returning money previously taken from a cardholders account by a Sale (command = Debit). A Payment is not linked to any previous transaction and is simply giving money to a cardholder.

The void is used when there is a system problem e.g. no response received to make absolutely sure that systems do not get out of sync where the POS Till or POS Server thinks that a transaction failed but the Issuers host thinks that a transaction was successful. As such, the void must be executed during the same business day as the transaction which is being voided i.e. it must be sent fairly close to the transaction it relates to. Another instance in which a void command would be used by the POS Till or POS Server would be if something went wrong in the POS systems after a successful financial transaction was completed. In this case, the POS Till or Server needs to roll the entire transaction back so that the net effect is as if nothing ever happened. If no response was returned by the channel, then a Void can be done with the Original transaction's MerchantReference otherwise the OriginalMerchantTrace will be used to void the transaction. A Void command can be used irrespective of whether a card has been presented or not. If no card has been present then the Void functions a lot like a Cancel but if a card has been presented then it will ensure that whatever the state of the transaction, it will be reversed.

The flow just shows what can be done, not what must be done. In most transactions and at most merchants the only transaction really used is the Sale (command = Debit). It is only at a later stage if there happens to be some kind of problem with the goods not being delivered or the amount being incorrect that a Refund or a Payment (command = Credit) may be used to correct the situation.

The basic difference between a void, Refund and Payment is the following:
• Void - The transaction against which the void was processed will not show up on the cardholder’s statement.
• Refund - The transaction against which the refund was processed will show up on the cardholder’s statement as will the refund so the cardholder will have two transactions of opposite sign showing up on their statement.
• Payment – Since this is not linked like a Refund to a previous transaction the cardholder would only see money being deposited into their account.

Tap-In/Tap-Out transaction processing can be performed by executing the GetHMAC command on both the tap-in and the tap-out and using the returned HMAC, which is the same for both calls, to determine the duration that needs to be charged for. The result of this is the amount to be charged which is passed, along with the HMAC and all the other parameters into the “Debit” command which works out whether the cardholder needs to authenticate the transaction by means of a PIN based on the card requirements as well as the value or whether the transaction can be processed without having to prompt for a second presentation of the card and the relevant authentication.
If a device has been activated to prompt for a transaction but the customer chooses to use another payment medium, then the transaction can be cancelled. Note that this can only be used if a card is not presented at all, if a card is presented then a Void should be used in preference to a Cancel command. Note that calling the “Cancel” command after a card has been dipped, swiped, or tapped will NOT “Void” the transaction. The “Cancel” command is ONLY to be used to regain control in the event that a card transaction is not being performed. In the event that a card transaction is “in process” the “Cancel” command will return a HTTP Status code 405 “Method Not Allowed” and the calling application should thereafter execute a “Void” command to ensure that the card transaction is rolled back. If “Cancel” is successful, then an HTTP Status code of 200 would be returned and if the “Cancel” is malformed or missing essential information then an HTTP Status code of 400 “Bad Request” will be returned. To add, transaction processing should not be init

The GetSystemInfo command can be used to expose information about the status of the estate and the connection to the gateway. Because of this it returns two sets of information. One relates to the devices that are connected to the Indigo server and the other relates to the connection from the Indigo server to the configured iVeri Gateway. Note that the DeviceInfo response is an array with a length of one if a single device’s status is requested but will generally be of variable length according to the number of devices connected. In the case that all devices are requested and there are not any devices connected at all this could be an array of zero length. Note also that GatewayInfo is also an array; usually there will only be one item in this array, but it is possible that there are multiple items. This call initiates a message to each connected device so if there are multiple devices that are disconnected this call could take some time to return because each request to a disconnected device would take some time. This also means that use of this call must not be too frequent i.e. not less than a minute between calls to GetSystemInfo to prevent monitoring interfering with the actual operation of Indigo.