duplicate batch from EDC settlement

Hi. The customer is using VITAL as their processor. After setting up their EDC, we did test transactions and settled the batch on June 8th. Then after real operations, they settled on June 13th. But for some reason, the batch number did not change and received a duplicate error. The problem is all the transactions are regarded as settled, when they actually are still open. I talked to VITAL support and apparently I need to change the batch number and settle the batch again. I found a way to change the batch number through SQL query and set all transactions' status back to open, but when trying to settle, I get technical error. Is there anyway to do this?

Reply to
dha
Loading thread data ...

you should post software and version number you are running too :)

Reply to
root

Hi. The customer is using VITAL as their processor. After setting up their EDC, we did test transactions and settled the batch on June 8th. Then after real operations, they settled on June 13th. But for some reason, the batch number did not change and received a duplicate error. The problem is all the transactions are regarded as settled, when they actually are still open. I talked to VITAL support and apparently I need to change the batch number and settle the batch again. I found a way to change the batch number through SQL query and set all transactions' status back to open, but when trying to settle, I get technical error. Is there anyway to do this?

Reply to
CptSoft

Looks like RMS does not have a way to solve this issue gracefully. Since settled transactions have credit card informations deleted, there is no way to revert them back to OPEN status or retrieve credit card information. Tinkering around with VisaNetAuthorization table and VisaNetBatch table confirmed my belief.

What I did was contact the processor to obtain credit card numbers and did tenders for the same amount using the same approval code. The batch was successful then.

By the way, this problem occurred because right after EDC was configured, I did a test transaction and batch settlement (batch #1). Then there were test transactions for training purposes and after training, the transactions were deleted using Delete Transaction.. from Administrator. This resets the batch number to 1 again. So when batch from the live operation was settled the processor (VITAL) rejected it because it was still batch # 1. What I don't understand is why RMS would consider the transactions as settled when the response was DUPLICATE.

Anyway, I just wanted to leave this reply as a reference for anyone who might have this problem in the future.

Reply to
dha

I just ran smack-dab into this very problem.

I had setup my merchant account on my test box, ran a few test charges against EDC batch 1, and settled the charges. A week later, I put this merchant account on my live system, rang up over $41,000 in charges, the charges went into EDC batch 1, and settled the charges. Surprise! The charges say they were settled successfully, but the batch info says DUPLICATE.

Fortunately, this was a sale for our internal customers, so we have phone numbers for most of them. We're going to call them, get thier credit card numbers, and charge them again using an external CC application (PCCharge). Not going to be a pleasant week.

Reply to
Bill Yater

Just another reason I keep my trusty old stand alone terminal over built in processing. The 5 extra seconds it takes to process just isn't a big enough concern to risk all these headaches and potentially devastating financial risks we read about. I feel for you Bill. Not only do you have to try to re-enter all the transactions(hope this goes well for you)but you will get charged extra for hand keying everything. Ouch! Craig

Reply to
Craig

Craig,

We keep our dial-ups as backup, but there is one thing you do have to consider. Prior to handling charges directly from RMS there were occasions where a cashier would mis-key the transaction amount when keying it into the dial-up. One time they missed a digit, keying a charge for $23.00 instead of $123. Using built-in charge capability does eleiminate one step and one more chance of inducing an error.

Marc

Reply to
Marc

Marc, That is definitly a concern, but can be avoided by double checking yourself before sending charges over(which all our cashiers are trained to do). I can honestly say that in 15 years of using a stand alone terminal I have never had that issue. There are definite advantages to using built in processing but the chances of something going wrong and costing you hours of work and hundreds if not thousands of dollars is just too great a risk for me to take. I understand there are those of you that disagree with me, but if you go back through this NG and look at all the horror stories involving built-in processing you at least will understand my reasoning. Craig

Reply to
Craig

I'll give you that one ... I have read them.

Marc

Reply to
Marc

I just ran smack-dab into this very problem.

I had setup my merchant account on my test box, ran a few test charges against EDC batch 1, and settled the charges. A week later, I put this merchant account on my live system, rang up over $41,000 in charges, the charges went into EDC batch 1, and settled the charges. Surprise! The charges say they were settled successfully, but the batch info says DUPLICATE.

Fortunately, this was a sale for our internal customers, so we have phone numbers for most of them. We're going to call them, get thier credit card numbers, and charge them again using an external CC application (PCCharge). Not going to be a pleasant week.

-- Bill Yater The Worth Collection snipped-for-privacy@worthltd.com

"dha" wrote:

Reply to
CptSoft

BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.