Choosing a method

[sneakyimp]

It's been awhile since I did an authorize.net integration and I'm currently wondering which implementation method to use (AIM, SIM, Direct Post Method, etc.).  Is there any sort of document to help one choose or any kind of laundry list of features to help one decide?

[sneakyimp]

Well I found this, but it's not particularly informative:

http://developer.authorize.net/api/compare

[sneakyimp]

OK I'm slowly beginning to understand a few things here.  Can anyone corroborate or refute these statements?

* AIM does not allow one to create subscriptions/recurring transactions

* ARB allows one to create subscriptions/recurring transactions but the amount of the recurring payment cannot change.

* There's no SDK or code library for CIM.  Just the sample code here.

Questions:

* Does ARB let you modify a subscription to have a different amount?  Are the credit card details or other sensitive information required to change the subscription?

* Can CIM be used for an immediate auth + capture?

* Can one set up a subscription with CIM that will be handled automatically by authorize.net or do I need to set up a cron job on my server to create a transaction each month?

[TJPride]

- Correct, no recurring subscriptions for AIM. Though you can subscriptions manually from one-time transactions through your control panel, which may be an option if you get few subscriptions.

- Incorrect. You can change the amount, just not the starting date or payment interval (unless the first payment hasn't gone through yet).

- Incorrect, at least with PHP, Ruby, Java, C#. I know for a fact the PHP SDK supports CIM, since there's a file called CIM.markdown in the doc folder of the SDK and the code is very straightforward.

- Yes. Yes, as far as I know.

- Yes.

- You need to do a cron job. But I personally prefer having this level of control.

[sneakyimp]

Thanks, TJ.

It sounds to me like CIM is what I should use for this project.  If you have a moment, perhaps you can weigh in on this.  These are the features required:

* We need to perfrom an auth+capture to make sure the transaction works before granting access to the site.  I'm under the impression that ARB would establish a subscription to be billed at some point in the future as opposed to capturing the funds immediately so it does not sound like ARB is suitable for immediate capture of funds.  We might be able to schedule their subscription to start tomorrow, but would not be able with any certainty to know that the user will reliably supply funds. 

* We would like to create a (fairly costly) annual subscription.  CIM should work for this purpose because we will have created a profile for our users which can be used next year to bill them again.  If the profile is no longer valid (expired card, etc.) then we can revoke access and send a notification.

I also wonder about a couple of other things:

* How long are CIM profiles valid?

* Does ARB offer any noteworthy features or advantages relative to CIM beyond that automation of purchases is handled by authorize.net rather than our own cron job?  I.e., is there any other good reason to use ARB instead of manually handling with CIM such as features in the authorize.net console?

[TJPride]

- Most people use AIM for the first charge when integrating ARB, so it's not technically impossible to use ARB. I just don't enjoy integrating it a whole lot, it's harder to deal with failures.

- Yes

- Forever, as far as I know.

- Not really. It's a matter of what style better matches your personal preference, and whether your hosting has cron.

[sneakyimp]

Thanks again, TJ.

I think we have decided to go with CIM.  cron not a problem for us.

One last question:

* Am I right in understanding that one needs the original credit card information in order to make changes to a subscription created with ARB?  E.g., if we had an ARB subscription set to renew on Feb 1 and our subscription price increased on January 1 by $10/yr then we'd need the original credit card to make this change to the subscription?

[TJPride]

I posted here recently that it was necessary to include the card info. The documentation actually says:

You must submit the subscriptionID of the subscription to be updated.
All other fields are optional.

So you'd probably only need to include the credit card info if the credit card info is changing, unless I'm missing something. I'm pretty sure in one of my implementations I have it updating the amount without including the card info.