Particular attention is drawn to the following message fields:
Reconciliation Number – Field 29
Dual message implementations should set this field to ‘001’.
In a single message configuration, this number corresponds to the internal terminal batch number held and controlled by Elavon. It is incremented with every successful reconciliation/batch closure message received and ranges from 001 to 999. Closure of batch number 999 will restart batch numbering from 001.
The Reconciliation Number is mandatory for all message types with the exception of:
If the incoming Reconciliation Number is not that expected by Elavon, the transaction will be rejected with Response Code 137 (Invalid Batch Number). The correct number expected by Elavon will be returned in Field 29 of the relevant response message.
Acquiring Institution ID Code – Field 32
The Field 32 (Acquiring Institution ID Code) value will be provided to the partner by Elavon. This field must be consistently populated with the assigned value in all applicable messages. This ensures customer identification and whether transaction capture occurs on the Elavon acquiring host system. Request this value from Elavon if it has not already been provided.
Approval Code – Field 38
In addition to reflecting the authorization code for an approved transaction, this data element will be populated when the Elavon acquiring host rejects the incoming message due to a format error or incorrect field contents. Field 38 of the ISO response will contain the ISO field number of the field in error. This will be right justified with leading zeros.
Terminal ID Code – Field 41
There is an implicit relationship between Field 42 – Merchant ID code and Field 41 – Terminal ID Code in Elavon’s ISO 8583 protocol.
If a Merchant ID code is, for example, 123456789, then related terminal IDs will be 12345678901, 12345678902, 12345678903, etc.
The eight digit Terminal ID in Field 41 should be sent as 00000001, 00000002, 00000003, etc.
The TID will be generated and provided by Elavon to the customer.
In the event that Alphanumeric TIDs are being provided, such values need to be populated in Field 63 sub-field 20. Field 41 should still be provided but it can be populated with zeroes. When Field 63 sub-field 05 is present and populated with ‘Y’, the implicit relationship described above between Field 41 and Field 42 does not exist. The terminal ID in Field 41 or Field 63 sub-field 20 will be used in messages switched out to the card schemes, and echoed in Elavon’s response, but as it is not assigned by Elavon, will not be subject to further validation.
Alphanumeric Terminal IDs
The use of an alphanumeric terminal ID is possible but only permitted under special circumstances. Alphanumeric TIDs should be populated as follows:
Field 41 (Card Acceptor Terminal Identification) is zero filled.
Field 63, Tag 05 (Ignore TID Indicator) is set to ‘Y’.
Field 63, Tag 20 (Alphanumeric Terminal ID) carries the required terminal ID number.
Additional Private Data – Field 48
This field is described in more detail on its individual page, but attention is drawn to the following key sub-fields.
Tag 01 – Item number
In a dual message configuration, this tag must always be present in authorisation related messages, but set to the value 001.
In a single message configuration, the following applies:
- Elavon assigns an item number to each approved transaction ‘captured’. These are sales, pre-authorisation completions, ‘force posts’, and refunds.
- The item number will increase in value by 1 from 000 to 999 with each approved transaction in a given batch. Once it reaches the maximum value of 999, the batch must be settled resulting in the batch number increasing by 1 and the item number reverting to 000.
- The Elavon host will return the item number in sub-field 001 in Field 48 of the appropriate 1110, 1210, 1230 or 1430 response message.
- Submitting terminals should supply this value in Field 48 of the next transaction in order to confirm that it received the previous response.
- Should the incoming item number be one less than expected, the Elavon host will compare the transaction type, card account number and transaction amount with that of the previously captured item.
- If these are the same, the most recent transaction is considered a duplicate and the previously issued approval code will be retrieved and sent back to the terminal.
- If the comparison finds that the key details are not the same, then the previously captured item will be automatically reversed by the Elavon host, as it will be assumed that the terminal did not receive the previous response.
- Any other unexpected incoming item number will result in the transaction being declined by Elavon with the Response Code 131 – Invalid Sequence Number.
- Item number ‘000’ should be used by a terminal until the first transaction (eligible for capture) in a new batch is approved, or in authorisation only scenarios.
Tag 05 – Void item number
This sub-field is only required in reversal requests for single message implementations where the Elavon acquiring host captures transactions for settlement.
It is important to emphasise that provided the item number exists in the current batch, it will be reversed by the Elavon host regardless of the contents of other sub-fields and fields.
Details of reversal processing are given in the Reversal Message Format section.