Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Aloha EDC issue with Amex

Status
Not open for further replies.

alohaakamai3

IS-IT--Management
Aug 11, 2006
482
US
So this is a weird one...

Setup an existing client with a new processor using CES/Cardnet to process cards. Works fine with Visa and MC, but Amex will not process. I get an error that says "Service not allow" when trying to run an Amex through either the back of house or directly (EDC 6.1.7).

I've contacted the processor who assures me many times over that they are setup for Amex through them (not a split-settle situation). I've gone through the settings for Amex in Aloha Manager and they match settings at other clients (they don't use the same processor though), and also these Amex settings were working fine with the previous processor. Everything looks totally fine.

Typically I would insist that this was something on their end.. and it still technically might be, but one weird thing I noticed is that when watching the EDC interface when I try to run a card, it appears that I get the error message before it even tries to connect to the processor. In other words, where you would normally see EDC try to trasmit info, it almost seems like I'm getting the error message before it even tries- which seems is what makes me think it may be something wrong on our setup. But if it is, I have no idea what it might be.

The only odd thing in the edc debout is that it seems to keep referencing something about Visanet and SSL, which is odd because Visanet is not a processor that is currently configured on this setup. Not sure if that's somehow related to the issue tho.
 
Thanks Dauphin, yes.

In fact, they had to keep using the existing processor, so when I'm doing my testing, I have manually switch it to CES to try it. If leave it set to the old processor, it will actually work.

I'm also using a test card since I don't have an Amex. I'm not sure if that matters, but under the old processor (RBS Lynk), EDC connects normally and declines the card (which it should be because it's not an active account, just for testing). I figured I would throw that out there, that I'm using a test card. I wouldn't think that would matter, but I'm leaving no stone unturned at this point. I've tried multiple test cards for Amex too, not just the one.
 
AMEX is usually the only one that merchants don't setup properly, something to do with linking the accounts. If it works on the old merchant and not on the new one after changing it under cards, then it is on the merchant. Seems to happen on at least half of the switchovers I've seen and no matter how many times the merchant tells me it's not on their end, it's always on their end.
 
For the most part, I'm in complete agreement with you.

Again, the only thing that maybe think possibly that might not be the case was when it looked like EDC never tried to dial out. But when I looked in the log files, it almost look like it did try, so who knows.

Your understanding is correct. The way it's currently setup under Tenders had not changed. The only somewhat suspicious looking setting I saw was it checked to use a 3 digit code for Amex. This was obviously set up this way and working under the old processor and was not a problem for years, but when the new one didn't work, I turned it off... to no avail.

No good ever comes from processor changes and Aloha. It seems like you have fiddle with it at least half the time to get it to work, and about once every 20 changeovers, you get one that's a complete and utter pain to get working. And the processors themselves are usually no help, no matter how many clients they claim to have running with the same software. Then wouldn't you have more information on how to get it working? Sigh. I guess I was overdue for an EDC headache.
 
I have had the same issues with CES and AMX. The issue is with the processor and not Aloha. They have not put the check box on the back end to take AMX. As long as the AMX is set to use CES there is nothing more that can be done in Aloha to make it work. Call the rep at First data and have the look at the configuration on there end. they need to put a check box in the AMX field. First time this happened I was opening a night club at 11:45pm. took them less the 3 minutes to fix but to get someone on the phone to help almost 45 mintues.



AlohaRoss
 
Thanks Ross, I think you're right. I had about a 10 minute conversation on the phone yesterday with one of their non-technical but higher up sales people, and to my surprise he actually seemed to be taking in what I was saying about it being on their end. The way I explained it was that once we point EDC in the direction of the new processor, there isn't much more to do. We know the processor setup is correct because it's accepting VISA and MC without issue. Beyond that, about the only other thing it could is not having the EDC set to go their processor under "Cards", not having "authorize using EDC" checked to process for that card under Tenders, or that some setting under Tenders was maybe accidentally modified (you know, the settings that we generally never touch like prefix, card number length, etc). But that fact that they are able to process Amex under their old processor simply by switching it back to them under Cards greatly reduces the likelihood that there is problem with any of those settings.

And not that this is worth much, but the message "service not allowed" they receive when trying to run Amex seems to suggest that EDC is being told - by some setting, somewhere- that Amex is not configured to be used. Because we are not getting that message with the old processor, this setting is probably *not* on the Aloha end.

I told him he needed to triple check that Amex was setup on their end, and about the only other I could think of is if they have a client running roughly the same version of Aloha whom they had a good relationship with, perhaps we could get into their system to mimic their settings exactly. But I sort of already did this with another client who doesn't use them, but does use the CES configuration sheet.

I also told him to feel free to call NCR directly, but they are probably going to charge you $800 bucks to tell you the same thing. I feel more confident telling him that because of you knowledgeable people reassuring me that it's not an Aloha issue. That said, I would like to thank you guys once again for all the feedback.
 
First Data misses things all the time. For South/Nabanco, they often don't setup Diners to work so the first time someone attempts to settle a batch with Diners in it, it fails. Then you have to explain to them how they need to setup Diners so it will settle.
 
I have found its always good to test on one of my test aloha environments the new config sheet before I present to the clients. Firstdata is not the best at setting up on there side, but on the Aloha side it has to be the easiest to setup. MID, TID and DID and your done. Don't forget north.fdc and the gateway.

AlohaRoss
 
Yep, that was one of my "unknowns" at first, was the gateway correct, and I asked one of their guys over there and he said that was right.

I agree that setting up processors is generally not complicated, especially if you do it on semi regular basis. The part that get's confusing is that there are different names and versions of setup sheets on different versions of Aloha, and add to that, the terms used by the banks don't always correspond to the terminology or names (and sometimes the field names) used in the Aloha software. It's gotten better- it was far worse when I was setting up people on Aloha 10 years where there was much more guess work or finagling to get things to work.

One of the things that frustrates me that I mentioned in an earlier post is that these processors brag to the clients how they have 1000s of clients on Aloha and how it will be so easy to change them over, yet act completely clueless as to what information required when they get on the phone with me. It seems to that if you're a processor doing this on a regular basis, you would have various forms for the popular pos systems and their versions that correspond exactly to what is needed, and you send that sheet over filled out and ready to go, to the point where they would need little more from me than an email address to send the form over. But they never do that and you usually get some sales guy (and sometimes even technical people) asking a bunch of questions like this is their first time doing it.

Same thing happens when there is a problem- so if you've done this thousands of times, don't you keep a knowledge base handy for when problems arise? I find it hard to believe that this is the only client they've seen this error message from- the truth is that they are just to disorganized to keep a record of things and so you have to get lucky and hope you run into a technical guy who had the problem and remembers the solution. Which is probably going to end up being some guy in the company breakroom who overhears the conversation and says "Oh, that error message just means that they are not properly setup to take Amex on our end.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top