Shameless plug for Spreedlycore.com where you can vault your cards separately and work with all the gateways listed here. This is an extreme example (gone into limbo in this case) but one of the motivations for our offering. You could have migrated to Stripe/Braintree etc via a config change.

This looks really cool.

Braintree is pretty great, I like working with their API and customer service (always ready and willing to talk on the phone, which is great).

Avoid Authorize.Net like the plague. Horrifically bad XML API that will make you want to claw your eyes out.

Where is there XML in Authorize.Net's API? Here's how you charge a card using the AIM (Advanced Integration Method) interface (Perl sample code):

    my $post_values	= 
    {
        "x_login"			=> "API_LOGIN_ID",
        "x_tran_key"		=> "TRANSACTION_KEY",
        "x_version"			=> "3.1",
        "x_delim_data"		=> "TRUE",
        "x_delim_char"		=> "|",
        "x_relay_response"	=> "FALSE",
        "x_type"			=> "AUTH_CAPTURE",
        "x_method"			=> "CC",
        "x_card_num"		=> "4111111111111111",
        "x_exp_date"		=> "0115",
        "x_amount"			=> "19.99",
        "x_description"		=> "Sample Transaction",
        "x_first_name"		=> "John",
        "x_last_name"		=> "Doe",
        "x_address"			=> "1234 Street",
        "x_state"			=> "WA",
        "x_zip"				=> "98004"	
    };
    my $useragent	= LWP::UserAgent->new( protocols_allowed => ["https"] );
    my $request		= POST( $post_url, $post_values );
    my $response	= $useragent->request( $request );

That's just a straightforward form post to a CGI. Result is a line of CSV data. No XML in sight.

Does the non-AIM option (I forget what it is called) use XML?

I don't have the code handy (was client work for a third party), but we definitely used XML through Auth.net's AIM. Here are the API docs for it:

http://www.authorize.net/support/AIM_guide_XML.pdf

We also used XML through their CIM to manage customer profiles. To be fair, this was all in PHP, and the code was inherited so I'm not sure if there was a better way to deal with Auth.net's API.

I do know that their dashboards were thoroughly unpleasant to deal with and I felt the API was obtuse in many different locations.

Interesting. Here's the non-XML AIM guide: http://www.authorize.net/support/AIM_guide.pdf

That's the one we use. I didn't even know they had an XML option--and now I'm going to try to forget it! :-)

Interesting! I had no idea they had a non-XML option. If I was still working on the project, I'd totally push for that.

Good to know for future projects =)

Business::OnlinePayment is one of those standup CPAN libraries that may not be well known but solves real(world) problems. I'm using it in a line of business app at work and when we ditched authorize.net I migrated to ippay by changing a couple lines of code.

I think the perl lib formats and sends this as XML, and perhaps dropping down to XML is required if the language lib isn't up to date.

No it doesn't

But it'll be a horrifically bad XML API for years and years :)

You should try WorldPay if your looking for shit but consistent. WorldPay will be around for ever, as will their dog-rough "web service" written by someone who hates the web and where verification tokens are optional. Checkout this FAB API http://www.worldpay.com/support/kb/bg/recurringpayments/rpfp...

That's not really much worse than Authorize.net.

Don't get me wrong. I hate Authorize.net and don't plan on using them for anything in the future. I'd rather refactor code than write comma separated string code once knowing it will work forever.

I used Authorize.net at a previous employer, and don't remember the API being too terrible. We wrote a wrapper for it, and forgot all about it until we needed to add features.

So true! First Data is the grandpa in the room. Their site doesnt render properly on Chrome even :(