[TriLUG] OT: credit/debit card processing.

[skippy1 at hickorytech.net]

> gregbrown at mindspring.com wrote:
>> Luggers:
>>
>> Have any of you set up on-line credit and debit card processing
>> software/websites?
>
> Yep, spent most of the last 5 years doing just that.
>
>> If so, what back-end software did you use?
>
>
[part of Phil's response snipped]
>
> After that, we switched to a web-based service from a company by
> the name of Linkpoint.  They provide an SSL based processing
> service, and an API that can be used to call into their
> service. We used the Java API (all our web stuff was J2EE)
> and that worked reasonably well.  The downside to their service
> is, you have less control over things.  For example, when you
> run your own processing engine, you control the time the
> settlement process runs.  With linkpoint, you are stuck
> with the settlement running when they decide to run it.  That
> might or might not be an issue to you.
>
> By and large though, Linkpoint's service works well, and it's
> what we used for the last 2-3 years or so.  At least, they
> were still using it when I left the company.

We also used Linkpoint using the PHP API as well as their stand alone
binary.  Their stuff worked well enough but we had horrible problems with
their customer service and additude.  Things like changing the API while
it was in use (gee, I wonder why all of our apps dont work properly) and
expiring support for a method we were using on very short notice.  They
had a test server for testing the system, swap in the IP address of the
test server and it doesn't charge the card.  The problem was that the test
server didn't behave the same way that the live server did in every case. 
Actively less than useful.

I certainly wouldn't use them again given any viable other choice.

>  >  I'm strating to dig around for solutions.  I'd like the software
>  > (back-end especially) to be linux or OS X based.
>  > Any pointer would be greatly appreciated!
>
> I'm not sure that there are a lot of *nix based processing
> engines.  The only one I was ever truly familiar with was
> the aforementioned CCVS.  Probably there are others, and I'm just
> not familiar with them.  I do know that there are essentially
> no F/OSS ones, as the credit card processors generally provide
> their protocol specs under an agreement that requires they
> be kept secret.

Some of the bigger e-commerce packages have support for some of the
processing providers built in.  We looked at Interchange for a while and
it seemed to be one of them (disclaimer: we dropped the project before
getting to that point so I didn't look at it carefully).

> And finally, if it comes to it, you can always write your
> own processing engine. The processing provider your sign
> up with will provide you the specs for their protocol and
> you can write your own software, if you *really* want to do that.
> It is time-consuming, error-prone, probably expensive, it means
> dealing with certification testing, constantly updating the
> software to match changes in the protocol, blah, blah.  But
> it also provides the ultimate degree of control, and you can
> run on any platform you choose.  The one I mentioned
> at the beginning of this message ran on OS/2. :-)

We did some of that with Linkpoint and it does give you control and
possibly more importantly, knowledge of the internals.  Given the amount
of pain and suffering it caused among the programmers when something went
wrong, I'd stay away from this unless you really need a capability that
isn't available otherwise.

Skippy
skippy at skippylair.net