EDC Modem error

[justadoode]

Hi, you guys have helped me SO much before, so I have a new kind of strange question. Here are the stats, Aloha version 5.2.8.224 processing credit cards over dial up. I have an US Robotics V90 external modem connected over serial that was processing transactions just fine for the last two days, now suddenly when we go to process a credit card it "delays" even the init for about 4-5 minutes. I don't know why this has changed and don't know where to set it right. We are using payment tech, I'm assuming the modem init string is correct although on the Aloha EDC under processor the modem registers as US Robotics Sportster 28800 and the init strings read: AT&F0&K0&Q6S46=0S11=55&C1&D2X4
While in the EDC.INI file the init strings read: AT&F0&K0&Q6S46=0S11=55&C1&D2X4

On the hardware properties of Windows 2000, the modem seems to be connected on Com3 while in EDC manager, it registers under Com 1. Any help would be GREATLY appreciated!

Justadoode

 

[justadoode]

I'm sorry, I lied. Both EDC and Windows 2000 register the modem under com 1. I can't think why it would delay. Any thoughts?

 

[ArgoNavis]

You might try using Hyperterminal to communicate directly with the modem on COM1. I would probably disconnect the phone line prior to trying this. First, give it the command "AT" (no quotes, terminate with the enter-key). The response should be "OK". Next, give it the command "AT&F0" (that's a zero) -- this should set the modem to factory defaults. Again, the response should be "OK". Finally, paste in the modem init string you specify above -- see what happens. The modem should react quickly, and always respond with "OK".

If the modem doesn't respond properly, then I would verify the serial cable between the PC and modem. It may be excessively basic to mention this, but power-cycling the modem may help. Another pretty basic diagnostic approach would be to substitute another modem which is known to be in good condition.

Just to be sure of what you're dealing with, you might use a normal telephone on the phone line to ensure it is possible to make calls.

As an aside, it is not uncommon for a modem to take a power hit from an unprotected phone line. This can cause an array of unpredictable pathologies.

Finally, you may also want to double-check the DIP switches on the modem to make sure that they are both sane, and fully engaged in either the "on" or the "off" position.

The modem init string you give can be read as follows:

&F0	Factory read-only configuration, generic template
&K0	Data compression disabled
&Q6	Set asynchronous operation in normal/buffered mode (*)
S46	Data compression control (*)
S11	Sets tone dialing duration and spacing (milliseconds)
&C1	Normal Carrier Detect (CD) operations
&D2	Normal Data Terminal Ready (DTR) operations
X4	Sets result code displayed (default)

(*) I was unable to find the &Q6 command, nor the S46 in the
USR documentation -- I had to resort to a generic AT-command
summary.  These [i]might[/i] not be valid USR commands.

Good luck!

AN.

 

[justadoode]

It turns out that EDC was expecting to process a transaction with a .hld extension and there was not one there, so it would wait 300 seconds, then would eventually process the next .ans transaction. I found this out by looking at the deboutedc.txt file. However, your modem init commands helped me verify and eliminate the modem as the issue, which saved me a TON of time because I was totally headed down the wrong path. Thanks so much for your help!!

 

[Shift4SMS]

With high speed Internet access being so inexpensive now a days, my suggestion would be to use a solution that takes advantage of it and dump your dial up modem. Your average authorization time will decrease from 12-25 seconds to around 3 seconds. Also, the number of communication issues and failures usually decrease significantly.

Good luck.

Steve Sommers

http://www.shift4.com

-- Creators of $$$ ON THE NET(tm) payment processing services

Blog:

http://shift4sms.blogspot.com

 

[justadoode]

The only problem with that is that our Paymentech processor told us we have to upgrade the Aloha system and EDC manager from 5.2.8.224 to at least 5.3 to process credit cards over broad band. Is it possible that it's not true? Can credit card transactions be processed over high speed on such an old version of Aloha?

 

[Shift4SMS]

Aloha also has an interface to Shift4's $$$ ON THE NET (it may be called $$$ IN THE BANK) and it has high speed connectivity to Paymentech as well as all the other big name processors.

 

[oxygenetic]

Hi justadoode...

Not to take you into another path in this thread...

Listen to Paymentech. If that's what they require then so be it. However, currently, you are NOT CISP compliant. I believe the earliest version that is is 5.3.13. Get yourself on AT LEAST 5.3.29. Even if you have to go through a dealer to do this and pay whatever licensing fees or maintenance they charge, it will save you MEGA $$$ versus what you're looking at if an ambulance chasing lawyer eats at your restaurant.

Good luck!

 

[posknowitall]

I say switch to Vital if you have no plans on upgrading. They do not have a specific version for high speed processing. Listen to the others though, you are not compliant using the older aloha version. Upgrade as soon as you can or you will end up having to use a stand-alone machine!

 

[Shift4SMS]

While I would love to have you use our services, in hind sight I have to agree with oxygenetic - you should upgrade to a PCI (CISP/PABP) compliant version. Once your compliant then you'll have all sorts of options.

Steve Sommers

http://www.shift4.com

-- Creators of $$$ ON THE NET(tm) payment processing services

Blog:

http://shift4sms.blogspot.com