Setting up an Authorize.net Automatic Recurring Billing (ARB) subscription-based payment system is generally easy to implement. Authorize gives you great libraries to get you started and they are very easy to understand. I used the PHP library and I didn’t have any problems setting this up. I did, however, run into a few issues that anyone new to Authorize.net should consider.

The first thing thing I ran into was that our client had their account in Test Mode. I couldn’t get our clients credentials to work though. The api would respond with an authentication error. I then created a test developer account, which is recommended. I was able to use my new api key and get the calls to work. So what’s up with our clients keys that won’t work? Well after a good amount time spent, I found out it all came down to some really confusing terminology on Authorize’s part. In our configuration, we had the api URL as “apitest.authorize.net”. This is the default value in the library and since our client’s account was in Test Mode, I figured this was correct. This is actually only for test developer accounts like I created. If using with a real account, in Test Mode or not, you need to point to api.authorize.net.

When testing with creating subscriptions, I often ran into an issue of duplicate subscriptions. If the inputs of a subscription creation call are too similar to a previous subscription, it will responds with an error explaining this. The inconvenient part of this is that the error response does not include the Subscription ID for you to update your data without extracting it straight from the error message. You can also manage the current subscriptions in your Authorize.net account dashboard.

If you run into any other issues, Authorize.net does provide a wonderful guide to the xml api. It offers some great samples for most calls you would need but more importantly it shows all error codes and descriptions so you can write your application with anticipation of these codes possibly happening.