[ic] payment gateways

[Mike Heins]

Quoting tOMMY gunnn (Kerpal at dopplegangers.com):
> (his is a resend, my first was in html format so its in reply format)
> 
> >I am very new to all of this "stuff", and it is 6:00 am here, been up 
> >all night so please excuse any discoherance. I am researching what 
> >shopping software I will use for my "project"  I am pretty confident 
> >that interchange will be it. 
> > 
> >I have been reading through the list and I am wandering how payment 
> >gateways (P.G.'s)work. I see that you have 4-6 in the demo. One of them 
> >cybercash.com has been bought out by verisign btw. But, are their others 
> >that are not viewable in the demo? Are you using the perl module known 
> >as "Bussiness Online::Payment"? I wander as I am *NOT* a perl 
> >programmer, and think that the "Bussiness Online::Payment" method would 
> >be easier to use as many the B.O. Devolpers have many  P.G.'s allready 
> >p.m.ed. I really do not have a ton of money and would like to get the 
> >cheapest payment gateway possible. 
> 
> >From what I have scene from the list most of these services cost a 150$ 
> setup fee, and 30-25$ mo charge, and a 10cents per transaction after so 
> many transactions (500-1000).
> 
> Also I have gone through the interchange code and have scene that they 
> are not using the Bussiness Online Payement System. What I do see in this 
> is that they are probally very wise to stick to a system that they are in 
> control of. However what would be a wise compromise is to have a "local" 
> payment gateway that could work with a system such as Bussiness 
> Online::Payment. Basically, "Local Payment Gateway" would trigger a 
> simple script that would be a preproccesor for a generic "Bussiness 
> Online::Payment" system.  That preproccesor would recieve all possible 
> variables in the "Bussiness Online::Payment system" after it has the 
> variables it would discard this and that and then push whats left to the 
> defined payment gateway. (I hope all of this is understandable as I am 
> learning programming and am not a programmer)

We aren't using Business::OnlinePayment because we predated it. Had
it been in full flower at the time we needed it, undoubtedly we
would have used it.

We usually look closely at a module before basing our stuff -- it is
easy to get burned by using a module too early. Sometimes, as in 
SQL::Statement, an incompatible interface change happens. We don't
like to have this happen -- sometimes, as in the case of DBD::Pg
(which started using runtime requires) we have no choice but to grin
and bear it.

By the way, we know and greatly respect the author, Jason Kohles. He is
an ex-Red Hat employee from the Interchange group and has done quite a
bit of work on Interchange.

Looking at the code, it would not be too difficult to build what
you said, a bridge between IC and Business::OnlinePayment.
The biggest problem I see is that there seems to be no constraint
on data format -- it is left up to the processor module to determine
in all cases. This is a problem for portablility, obviously -- if
the expiration date we provide is "0606" and the module expects
"06/06", we aren't really generic. And looking at the AuthorizeNet
and LinkPoint modules, they use incompatible formats.
 
-- 
Mike Heins
Perusion -- Expert Interchange Consulting    http://www.perusion.com/
phone +1.513.523.7621      <mike at perusion.com>

Research is what I'm doing when I don't know what I'm doing.
-- Wernher Von Braun