cancel
Showing results for 
Search instead for 
Did you mean: 

ARB or CIM for Annual Renewal Billings?

We need to automatically bill for annual renewals of a service.  It appears that ARB is more suited to something such as a monthly billing. Can it be used reliably for any annual billing or would it be more appropriate to use CIM?

 

CDeCinko
Contributor
Contributor
9 REPLIES 9

As long as the amount billed each person does not change from year to year, and your frequency of billing can be properly expressed in number of days or months, then ARB should work fine.  You can set the totalOccurrences element to 9999 to indicate "no ending" (until cancelled), so you will not encounter any time limits there.  By using ARB, you get to write against a simpler API and you avoid having to create your own scheduler to fire off the batch billing job once per year.  The only issue you will encounter, which you would encounter with CIM anyway, is handling the expired and/or cancelled credit cards with each billing.  With CIM, you get the immediate response telling you the results of the transaction.  With ARB you would need to use the SilentPost URL feature or perhaps manually download all of the transactions after they are submitted and find any failed ones.


Dave Parker
IT DevWorks, LLC
Makers of the I-Bill IT libraries for Authorize.net
Blog: http://www.itdaveworks.com
Twitter: http://twitter.com/rayrad
Site: http://www.itdevworks.com
itdevworks
Trusted Contributor
Trusted Contributor
The docs are fuzzy to me on the billing frequency.  If I set a billing frequency of 12 months, I'll trigger an auto billing once every 12 months? or one per month 12 times?  The only options are days or months?  Would it be best to set the start date as today or one year from today?

 


@itdevworks wrote:

As long as the amount billed each person does not change from year to year, and your frequency of billing can be properly expressed in number of days or months, then ARB should work fine.  You can set the totalOccurrences element to 9999 to indicate "no ending" (until cancelled), so you will not encounter any time limits there.  By using ARB, you get to write against a simpler API and you avoid having to create your own scheduler to fire off the batch billing job once per year.  The only issue you will encounter, which you would encounter with CIM anyway, is handling the expired and/or cancelled credit cards with each billing.  With CIM, you get the immediate response telling you the results of the transaction.  With ARB you would need to use the SilentPost URL feature or perhaps manually download all of the transactions after they are submitted and find any failed ones.


 

You can think of the billing interval parameters as "every length units".  So if you set the length to 12 and unit to "months", you would bill "every 12 months".  As far as the start date, I always submit the first billing cycle via AIM to get an immediate validation of the credit card, and then create the subscription to start on the next billing cycle.  This way, if the credit card fails, the user knows about it right away and can possibly remedy the problem immediately with no intervention from you.  If you go the other way, and let the first billing cycle be billed via ARB, then when a failure occurrs, you have to contact the customer to resolve the issue or cancel their account and risk an angry customer when they try to log in and discover their card, in fact, did not work when they signed up.


Dave Parker
IT DevWorks, LLC
Makers of the I-Bill IT libraries for Authorize.net
Blog: http://www.itdaveworks.com
Twitter: http://twitter.com/rayrad
Site: http://www.itdevworks.com
itdevworks
Trusted Contributor
Trusted Contributor

We are in a similar situation and I'm trying to figure out the best approach when your product is for a yearly subscription. 

 

The problem with yearly subscriptions and ARB is that the chances of the customer's credit card expiring before the first recurring billing cycle is obviously the most likly case.

 

Let me go through a use case and I would appreciate any feedback.

 

We are selling digital content and want to charge the customer a yearly subscription.  The content should be available immediatly after the user pays.  Let's say the current date is 24 February 2012 and the customer's credit card expires in June 2012.

 

So far, in most of the threads I've read, people are recommending that you use AIM to initiate a transaction that will verify the credit card information and charge the customer the first year's amount.  That part I would agree with.  If that succeedes, you then immediately create an ARB with the credit card information you have and in this case, we would set the ARB start date to 24 February 2013.

 

However, from reading the documentation, I believe that the ARB request is immediately going to fail with the error E00018, "The credit card expires before the subscription startDate."

 

So, to solve that problem, I thought about instead of doing and Auth_Capture on the intial AIM request, just do an Auth_Only instead.  That way, the credit card and funds are still verified and when creating the ARB, we would set the start date to 25 February 2012.  Then I can simply let the Auth_Only request automatically fail after 30 days.

 

Does that sound like a good solution?  Will the Auth_Only request show up on the customer's credit card statement?  Are there any other side effects to just letting the Auth_Only requst automatically fail after 30 days?

 

Even if that solution works, I still don't like the fact that the customer would have to re-enter/update their credit card information before the subscription could be renewed.  I have several companies, like my cellular phone company and my cable company, setup to do automatic billing with my credit card and it's been 10 years with them and I've never had to update my credit card information with them.  How do they do it?

Um. If you're using AIM + ARB, you have the credit card expiration date available right there before you make the first charge. Seems to me you could charge them using AIM,  pop up a message saying "your first payment has been made, but we need another credit card for your ongoing subscription", then validate that card by using $0.00 (if Visa) or $0.01 and immediately voiding. Or you could just send them the failure message immediately, rather than waiting until it actually fails, sending them to your standard "please update your card" page.

Thanks, TJPride.  But the expiration of their current card could be up to 11 months out still.  So I don't know what the customer's reaction would be if an application did what you suggest.

 

Does anybody know how other companies are seemingly able to not require a customer to update the expiration date of their credit card on file and yet still be able to bill them on a recurring basis?  For example, my cellular carrier and cable company have never asked me to update my credit card information.

I would imagine for a company the scale of a major cellular carrier, it would be possible to tie in directly to the credit card companies and get them to update the expiration dates somehow. But we are not cellular carriers. If it were me, I'd just let it expire, detect the expiration when I do the second charge (using CIM), and send the customer a message saying their credit card has expired and here's a link for updating their credit card info.

 

FYI, there are many major companies I've used that do not update the credit card info automatically, so even if we assume for the sake of argument that a few can, it's probably not something that's easy to do or everyone would be doing it.

There are services called Visa Account Updator (VAU) and Mastercard Automatic Billing Updator (MABU) that provide the ability to update stored credit cards by sending a request to your merchant account provider.  Unfortunately, this isn't something that we are currently able to help you with on our platform, so usage of such a service would require you to store the full card numbers on your system in order to perform the updates.

Thanks, guys.