Credit Card Processing In Navision

dziegelman

We are evaluating 2 different software products for Credit card processing in Navision. One is written by Simcrest and uses Authorize.net as the processing software. The other is written by Lanham & Associates and uses IC Verify.

Does anyone have experience with one or both and can make a specific recommendation and what features make it great?

Thanks,

Daryl

ara3n

Helllo. I've implemented both. Lanham uses a file transfer method. Meaning a service monitors a folder and answers back with a file. Navision is weak on file handly, so there were a couple of issues that we had to write to fix problem. Lanham solution goes through a main server, where as simcrest is from every workstation. Simcrest is a lot easier to implement. So if you don't mind installing the ocx on every computer then you can go with simcrest. Otherwise go with Lanham.

Also with Lanham you can reconsile within navision, whereas with simcrest you can only do it on their website.

Steve_Contris

Have you had any experience submitting batches of transaction using lanham's software? We are using it and having problems with performance - 3-4 hours to process 300 tranactions which must be done at the end of the day since the processing app is single threaded. That means that the process must be run after working hours which means that any errors encountered cannot be fixed easily the next day.... and on and on....

ara3n

You can process batch process them during the day. Is there a reason why you aren't doing it? As far as performance goes, it all depends on your processor. Since Lanham sends them one file and waits for response, so the bottleneck is the processor not Navision.

themave

We have just went through the same evaluation, and I found another product you should check out.

http://www.chargelogic.com/?PageID=2

We have just signed the purchase contract and are implementing it now.

Steve_Contris

we chose to do the batch process rather than the real time process for the ship transactions because they took so long when processed in realtime (as the orders are invoiced) that one of our work stations would be unusable for quite a long time.

As for the processing of the batch file, lanham creates one large batch file with many transactions but only one transaction at a time is sent to the processor and they are answered immediately - the bottle neck is the icverify application which for some unknown reason does not send the next request as soon as reply is recieved - it usually takes at least 25 seconds.

ara3n

sounds like you need to call icverify and see if that setting change be changed.

Steve_Contris

icverify is in denial of all shortcomings and bugs in its products. what I am after is whether others have experienced the same thing. Besides, I need an expensive ($800) integrators support license to even talk to them about it since it is outside the scope of the icverify client

themave

themave wrote:

We have just went through the same evaluation, and I found another product you should check out.

http://www.chargelogic.com/?PageID=2

We have just signed the purchase contract and are implementing it now.

Sorry didn't give you pro's and Con's

Pro's
1. doesn't use outside program such as icverify or authorize.net
2. 2 second response time.
3. batch processing if desired
4. debit and pin pad support,
5. can integrate telecheck check approval
6. supports level III corp cards, for better rates on processing

Con's
1. must use EFS.net as a gateway, so your processor must support that.
2. efs.net gateway is owned by firstdata, so you will get your best rates from them, but you can also get locked into them.

ara3n

when we were processing the CC, about 100-200 orders, it took no longer tan 3-5 min. this was one year ago on icveryfy 3.4 if i remember.

Steve_Contris

I have heard from others that the older version did not have this performance problem. It seems that when they added the SSL functionality to the "multi-user" application is when the performance problem started. I have examined what is going on with packet inspection and can demonstrate that the "multi-user" app takes 20 or so seconds to pick up the next transaction from a request batch file. However, it will only take 5 seconds to pick one up from a separate request file. This is obviously some kind of bug in Icverify which, judging by the interface is not well written.