Aloha Adding Extra Zeros

[ProcessorTech]

Has anyone here encountered an Aloha system adding additional zeros to the end of transactions during settlement?

Last week one went through and every customer was between $20K and $90K negative in their bank account because of it. A batch just came through about an hour ago for $31 million.

I work for one of the big processors and have seen this particular issue about 6 times in the last couple months.

Anyone seeing this out there?

 

[AlohaRoss]

I have seen when it preauthorize for over the amount. This happens when Aloha is setup to see if there is 20% more than the authorized amount and instead of it doing .20 it does 20 times the amount. This happens when they type the wrong setting in Aloha.

AlohaRoss

http://www.needalohahelp.com

 

[ProcessorTech]

The authorizations are for the correct amount; the issue is happening during settlement. So far all of the Aloha techs involved say the EDC is reporting the correct amounts, however, when we receive it at the processor each transaction has 3 zeros added to the end.

As you could imagine, this is causing quite a stir.

When this issue starts the merchant/tech will receive an error upon settlement that says "Batch rejected. Transaction X is corrupt". After several tries the batch will eventually go through and report Settlement Successful in the Aloha. When we receive it that's when the digits are added.

The merchants/Aloha techs say that it is occurring on our end and our Product Development team is saying that it's happening on the merchant's end. Everyone is pointing fingers at the other guy.

Although I do work for the processor I try to keep a non-biased view on the situation. Since the error refers to a specific transaction that is corrupt I believe that once the merchant/tech forces the batch (by trying 7 or 8 times) the batch goes through and the corrupt data skews the rest of the batch.

In addition to it adding the extra zeroes it also messes with the transaction date. For some reason, in almost every case, it changes 1/3rd of the batch to have transaction dates of early December, 2013.

My role at the processor is Help Desk, meaning I provide low level support to merchants; mostly customer care type of stuff. Since no one seems to be "owning" the issue on either side I'd like to be the one that comes up with the fix. (Eventually I'd like to get into a more technical Product Development role)

I've been keeping a running log of EDC versions, dates, merchant account numbers ect. in the hopes that it will come in handy.

There is a serious lack of transparency between my department and Product but I am being told that they are working with NCR techs on the issue.

What makes identifying the origin difficult is that we can't see the raw data being sent to us. If I could spot this happening in real-time I may be able to convince the Aloha tech to set up some kind of network sniffing tool like WireShark. That way we could get the raw data and determine whether it's occurring in the POS, during transmission or here at the processor.

There are only two things constant and they are that we are always the processor involved and that it only happens on Aloha software. (various versions)

Have any of you guys seen this issue before or know what may be causing it?