The Business::OnlinePayment modules are where you want to start with but each gateway does things slightly different. Business::OnlinePayment does it's best to abstract those diffs away.

As for testing, once you have a gateway account established, they should provide a way to test offline I know authorize.net does.

But, there are quite a few things in common too (mostly the data they need). Usually there are example scripts (often in Perl) that you can get started quick with too.

I use this scheme:

Site > Sanitiser > CC Processor

Basically, I don't code anything that is CC specific in the site and anything that a CC Processor needs I add to the sanitiser step. The CC Processor step usually ends up being only one subroutine. If I switch processors (which doesn't happen very often) I rewrite the last step and maybe add a few things to the Sanitiser step.

It will never be easy switching CC processors, but I have found that this scheme does make it fairly painless.

That is an appealing idea. Could you please elaborate on specifics?

In reference to the Business:: module spoken-of earlier, do you use it? And if so, how exactly does it fit into your “scheme?”

(Obviously, I do intend to use “CPAN something,” as I have done with every other aspect of this project. I simply want to reserve my personal head-banging for the most interesting things.)

Well, it depends on your processor. For example, I have used PayPal Payflow Pro and have had great success with it. And there are quite a few Business::PayPal modules on CPAN.

I would start with your processor and see if you can find anything on CPAN. If you use some obscure payment method you might be stuck writing your own. Either way, the scheme I mentioned earlier will help... just don't get your processor entangled into your web app or you may be doing some head-banging later on.

Looking back (it has been about a year since I have used Payflow) but it was a little quarky then. Hopefully, it is better developed now (on the PayPal side). Once I got everything sorted out during development it ran great in production.

This allows you to make sure the site works before going live on the clearing house side. Then, once Authorize.net is ready to take actual payments, updates to your code can be tested even against a live Authorize.net account by setting the transaction itself to test mode.

Other credit card processors offer similar features, but they are not handled the same everywhere. PayPal for example, the last I checked anyway, had a separate sandbox server instead of a separate mode on the live server. Most processors that have a back end module for Business::OnlinePayment should be pretty easy once you have targeted one of them. Services that aren't targeted through Business::OnlinePayment are that much more hassle to move among.

Personally, I prefer my customers use Authorize.net specifically. I'm familiar with the merchant account interface on their web site for helping troubleshoot the client's problems. I have code to target them already written for Perl, PHP, and C. Most banks my clients already have credit card merchant accounts through can specify Authorize.net as the online transaction processor for those existing accounts at terms similar to what they already have. Using some other services for online payment means the client doesn't deal with the same local bank and the same merchant account they use for local credit card payments. Using Authorize.net as a processor for an existing account means they can if they want. Some other processing companies may or may not offer this feature, so check into it before obligating your customers to a new merchant account with startup fees at a separate bank.

I'm sure they'll be persuaded to use authorize.net specifically. They're already dropping that name.

Am I going to encounter any grief with regards to that and CPAN? (Don't think so...)

I think it might be a good idea to combine unit testing and mock objects with Roadster001's solution above ( sanitizer -> CC processor). Roadster001 provides a good starting point for breaking down the testing problem into unit tests. Perl has a very rich set of testing modules to get you started on creating both mock objects and test suites.

For the unit testing, you should have at least two test suites. The first would make sure that each and every method of your sanitizer generates the correct sanitized code and handles bad and evil data well. If you are not familiar with taint mode, check the perl docs and consider using it in your application and test suites. The second set of unit tests would make sure that the web requests coming out of your CC processor look exactly as they should (well formed, all fields properly filled in, including the test flag :-), and so on). Again, make sure you have tests that input garbage as well as good data.

Two other hints I find helpful when constructing unit tests are:

• always test for stupid mistakes - usually we are scared of the complex stuff, but often we get the complex stuff right because we need to think hard to write it in the first place. The throw away/pro-forma code is usually where most of the mistakes lurk in the form of cut and paste errors, typos in parameter values, failure to account for undefined values and the like.
• test to prove your code is wrong, not right - it is only natural for us to want our code to be right, but hypothesis confirmation is the fastest way to deception. There is even a psychological principle, "cognitive dissonance" which says that we will go out of our way to make things we have put effort in (i.e. our code) seem right (we don't like dissonance).

As for Perl resources, start by exploring Test::Simple and Test::More if you don't know them already. They provide a great way to compare actual and expected values from your methods. There is also a whole set of objects for simulating interaction with web servers. A search on CPAN for "Test::WWW" might be a good place to start. Putting in "Test Mock" into the CPAN search box should also yield some helpful results.