With Business::OnlinePayment and the Business::OnlinePayment::AuthorizeNet backend module, there are two ways to do testing against the actual Authorize.net system without transferring any funds. You can set a test mode variable in the data you send, or you can place the account into a test mode at Authorize.net's web site.

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.