Note that you can find perl support for a wide variety of credit card processors by searching CPAN for all the classes that begin with the name Business::OnlinePayment.
--
@/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/;
map{y/X_/\n /;print}map{pop@$_}@/for@/
| [reply]
[d/l] |
Hello,
I've evaluated a number of companies that do what you want, and can say that in my experience, almost every single one is using an HTTP POST over SSL for communication. So, from that perspective, using Perl won't be a problem with most.
My most recent direct experiences have been with Verisign
(ick, I know, but they bought Signio out) and Authorize.net.
I would characterize them both as "adequate."
| [reply] |
HTTP POST over SSL for communication.
You mean HTTPS POST.
| [reply] |
| [reply] |
Thanks Boris,
I am looking more for actual credit card processing services rather than fraud protection. The site I am working on is just selling a subscription to a paper magazine only available in the U.S.A. so worst case for fraud is someone gets one issue before it is found out.
| [reply] |
I use to use Network 1 (EFTSecure, https://va.eftsecure.net), they were really easy to interface with using perl. Basically, we would open a secure pipe, send them the info and listen for the error code. They had a script that almost worked, but with a few hacks you could be up in going in 5-10 minutes. They had other hang-ups though, like declining orders if they were too far above you average sale price. But for a subscription service, this should not be a problem.
Cameron | [reply] |
We use Authorize.net, but I don't know how good they are if you're a small business.
cLive ;-)
| [reply] |
Thanks so much for your feedback everybody, this is exactly what I was looking for. PerlMonks (and its members) rule! | [reply] |