As I understand it, in the VisaNetAuthorization table RMS is supposed to increment the RequestBatchNumber after each settlement, and roll over after 999 back to 001. Settlement is either manual via Manager at close of business or automatic when reaching 100 transactions in the batch. What we have been seeing occasionally is the number does not properly increment, at times it jumps back to recently used numbers which are then flagged by TSYS as duplicates, when they are really not. When trying to settle one of these false duplicate batches, the user is prompted to delete the duplicate information to complete the settlement. This provides a potential loss of data necessary to complete the day's sales. TSYS is charging us quite a lot of money to rekey the transactions after they have been wiped from RMS. Does anyone else have this issue and a possible solution? All of our batch sizes are default to 100 across all machines.
Our table looks like this:
...
Batch ID 3148, Response ID 078, Accepted
Batch ID 3149, Response ID 079, Accepted
Batch ID 3150, Response ID 077, Duplicate
Batch ID 3151, Response ID 078, Duplicate
Batch ID 3152, Response ID 079, Duplicate
Batch ID 3153, Response ID 080, Accepted
So as you can see, after batch 3149 was accepted by TSYS, the next batch was somehow created with the response ID of 077. Since IDs 77, 78, and 79 had been recently used, they get flagged as duplicate. Once ID 80 comes in we are good to go. Our procedure to workaround this is to manually increment the batch ID when the issue comes up, but that only works if the user doesn't just click "yes" to delete the dupes.
What logic does RMS use to increment the ResponseID? Is there a way to prevent this?