Settlement Troubleshooting - TSYS Sierra

Settlement Overview

On TSYS Sierra, the settlement process consists of sending several records, in a prescribed order. The bulk of these records consist of Detail Records which contain information about an individual transaction. Detail Record submission is how the TSYS host captures a transaction for settlement. 

The TSYS settlement process is an all or nothing process. Either all records are accepted or none of the records are accepted. This means if a single issue is detected, then the batch is not accepted. The issue(s) must be resolved to successfully close the batch. 

What shows below is the order of the records as they should appear in the batch transmission. Required records are marked with an asterisk.

• *Header Record

• *Parameter Record

• *Detail Record 1 Contains data fields related to individual transaction requests. There is no limit to the number of Detail records that can be settled in a batch. There is generally 1 Detail Record for each transaction in the batch.

• Detail Record 2

• Detail Record N-1

• Detail Record N – this is the final Detail Record

• *Trailer Record – Signifies end of settlement and contains info such as Batch Number, # of records submitted, Batch Submission Date, Net Totals, Cashback Totals

Batch Results

SUCCESS

Good Batch

– standard response for accepted batch. Response Code is ‘GB’ 

ERROR

Duplicate Batch

– Response Code is ‘QD’. The host could respond Duplicate Batch to either a Header or Parameter record if a duplicate batch number is detected to exist. Batch numbers should not be repeated for a minimum of five calendar days. Example: if you settle batch 100 on Sunday, then you cannot settle another batch w/ batch number 100 until Saturday.   

Typically, you may encounter a QD if a terminal is deployed and then the payment app is removed completely and re-installed within a very short period of time while the deployment team figures out the proper configuration for a merchant. 

How to Resolve:

1. TSYS must be contacted to determine the following information 

2. Was the current batch number associated with another already settled batch used within the last 5/6 calendar days? Answer is expected to be Yes. 

3. The contents of the current batch should be validated against the last successful batch w/ the same batch number with TSYS. For example, if Batch 101 was successfully settled w/in the last 5 days, and a terminal is trying to settle Batch 101 again, then it must be determined if the transactions in the current Batch 101 match the transactions in the previous Batch 101?  

4. Total Net Amount and # of transactions are quick proxies to check this. If they match it is a strong indicator that you’re trying to submit a previously closed batch w/ the same transactions. If they don’t match, it indicates just the Batch Number is being reused 

5. I’d recommend that you validate all transactions with TSYS, if possible, by faxing/emailing Detail Reports to TSYS support 

6. If validating all transactions is not possible, then spot checking random transactions as well as first/last transactions 

7. First Transaction in terminal side batch: are there earlier transactions which have not been settled yet? 

8. Last Transaction in terminal side batch: are there later transactions which have not been settled yet? 

9. How to resolve QD issue. After checking w/ TSYS for conditions above, you will know whether the current batch is a duplicate of a previously settled batch. 

10. If the current batch is a 100% match then  

11. Clear Batch on device. This will wipe the transaction database and increment the batch number by 1. Its highly recommend that you execute one test transaction and settle it to ensure you’ll not hit another QD settlement error. 

12. If the current batch is NOT a 100% match for a previous batch w/ the same Batch Number (i.e. All transactions are unique OR there is some overlap of matching transactions) then do the following: 

    1. All transactions are unique:
       Change the batch number at the device level and attempt settlement again. Try incrementing by 1. You may check w/ TSYS support to ensure the new batch number also was not used w/in the last 5 days to avoid another QD. You may use any arbitrary 3 digit batch number (001 to 999), as long as it has not been settled in the last 5 days.  

    2. Some transactions were previously captured, some are new:
       If some of the transactions from the original batch are still present in your current batch, this indicates when the previous batch with same batch number was submitted for settlement, it was not purged from your device upon successful closing and the merchant has accepted additional transactions. The resolution is to validate that the SHARED transactions between both iterations of the batch were properly settled and then only the previously settled transactions should be Voided. Batch number should be incremented, and Settlement should be attempted again to capture the new transactions. 

Rejected Batch

- Response code is ‘RB’.  This is general catch-all response code for a variety of issues. TSYS returns a rejected batch response which should contain the fields below. These fields are printed on the report generated by the terminal when batch fails due to RB condition 

• Error Type 

• Error Sequence Number 

• Error Record Type 

• Error Data Field Number 

• Error Data 

 How to Resolve:

Contact TSYS support and ask for information regarding the cause of the RB. You may also provide the terminal generated report which should assist them in determining the cause. It is not unexpected that Level 1 TSYS Support may not be properly trained to interpret the cause of an RB.  

Scenarios which can cause RBs: 

1. A specific transaction or transaction cannot be captured during settlement due to errors with transaction/card.  For example, a merchant executed a PreAuth transaction. Several days later, after the authorization period has expired, the merchant performs a Completion followed by Settlement. Settlement may result in RB due to the expired authorization. Resolution would be to Void this specific transaction and re-attempt settlement. If another RB is encountered, then you’d need to contact TSYS support again w/ the updated error report to determine what is the current cause of failure and then act accordingly. This specific example can be generalized to cover any transaction which is causing settlement to fail > typical resolution is to Void it and attempt settlement. If Void(s) must be performed in order to bypass an RB condition, it is the merchant’s responsibility to work w/ TSYS/merchant services and determine how to be paid for voided transaction (potentially via back-office operation) outside of the current batch settlement transaction. 

2. Merchant Parameters are not properly configured – there are several TSYS merchant parameters which may lead to RB conditions during settlement. These misconfigured parameters may not result in any errors while running transactions. This is why it’s important to always run test transactions and settlement when deploying a new device or when updating an already deployed device. 

Stand Alone Terminals – How to Access Functions Used for Batch Settlement Troubleshooting

Update Batch Number 

Idle Screen > Main menu > Admin > Update Batch Number 

You’ll be prompted to enter a new batch number. The current batch number will also be shown on screen for reference. 

Void Transactions 

1. Idle Screen > Main Menu > Transactions >  Void 

2. You can then retrieve a specific transaction by providing the relevant search criteria 

3. Idle Screen > Main Menu > Transaction Recall >  

4. You can then navigate the transaction database using various search criteria. If the transaction selected can be Voided, it will be presented as an option 

Semi-Integrated Terminals – How to Access Functions Used Batch Settlement Troubleshooting

Update Batch Number

Use the UpdateBatchNumber command (Always refer to AMP Connect Developer’s guide for full documentation on how to use this command).
Sample request, using WLAN interface: 

Note: The BatchNumber field above is the new batch number you want to use. 

Void Transactions

Use the Void command (Always refer to AMP Connect Developer’s guide for full documentation on how to use this command).
The samples below are VoidTypes supported by the TSYS Unattended application as of 02.02.004UTCp. 

Void – Last Transaction

Void – Invoice Number

Note: This Voids the transaction w/ Invoice Number 10.

Void – Authorization Code

Note: This Voids the transaction w/ Authorization Code TAS034.

Void – Reference Number

Note: This voids the transaction with the Reference Number, known as the Retrieval Reference Number (RRN) on TSYS, of 206921501320.