Authorize.net has a new API called CIM
“Customer Information Manager”
http://developer.authorize.net/guides/
http://developer.authorize.net/samplecode/
However, there is no PHP sample code provided. Has anyone here had experience with this API?
I’ve been playing with it and have a class almost written for it. Unfortunately there are errors in their documentation and I am also getting errors with my code (they return an error message that isn’t very helpful). I emailed their support twice and no response. I used to be an avid supporter of their support but lately it just totally sucks. Hopefully they fix their guide and offer sample code and actually learn how to respond to emails.
As far as CIM is concerned, it is a wonderful thing. PCI compliance can go right out the window for merchants who use this service.
Yeah saw that a few weeks ago - I don’t need to use it right now. But nice to know something like that exists for future products [if I ever become a power company or something] 
- Tomer
FYI, I already created a class on it about a couple weeks ago.
http://www.bigdoghost.com/blog/authorizenet-cim/
or http://freshmeat.net/projects/authorizenet_cim/
@stymiee - yes, there were minor errors in their documentation, but just examine the api error messages to see what is required even if the manual does not correspond properly. I already called them and asked them to change their manual to reflect what the api requires. So, it would help if their manual was correct, but it can still be figured out if not.
Emailing authorize.net is not recommended at the moment. Just call them and let them know where and how to make changes to the manual once you are certain of an exact issue(s).
Anyway, take a look at the php class for help.
Glad to see you based it off my other Authnet classes. 
As far as correcting their manual, I emailed them already. If they really want to fix, they will.
It’s about time Authnet offered something like this. ARB is so hard to realistically work with (since it doesn’t talk to your site about what it’s doing after you start the subscription), it’ll be much easier to issue each charge separately with the stored customer information.
FYI, I already created a class on it about a couple weeks ago.
Awesome!
Also, Authnet just replied to my email today stating they now have sample php code up.
http://developer.authorize.net/samplecode/
If you use CIM as the main API but want to also process transactions without storing Card details, do you have to use AIM? It would seem that with CIM, you have to create the profile inc card details before you can pass a transaction.
Yes, you would have to use AIM to submit the transactions; the difference is you submit a profile ID (and a payment or shipping ID if the profile has multiple) instead of actual billing information with each transaction after the first. What you store is only whatever information you need to match your customers against a profile ID.
The description of CIM before you sign up for it has a big warning paragraph that you must have a web developer to use it.
That sample code uses the SOAP API so if you are unfamiliar with SOAP you may find it difficult to use.
It seems to be that with CIM, I’m unable simulate a successful credit card transaction, even when putting the account into test mode and using one of the suggested test credit card numbers (as per AIM manual).
Put it into live, charge your own card, and void it?
Or get a developer account and test using that.
I’ve been looking through forums for info on implementing CIM. I got some good information and I am doing create customer profile, create customer pymt profile and create transaction request to charge the card. It’s working okay but I ran into a couple of problems and live chat is not the greatest as you may know.
1 - when the card charges, a first transactiong goes through as a voided charge for $0.01 as a validation. They said this always happens and is a feature of the CIM. Is this really true? Every time a transaction goes through, this happens? That does not seem right. Anyhow, least of my worries.
2 - A successful transaction went through yesterday for like $20.50. The voided 1 cent went through, then the card went through for the actual amt. Today an order went through for $3000.50 or similar and the voided 1 cent went through and I got a successful response but the order didn’t actually come through. No one could give me any answers and I inquired about that max 4 digits including decimal in the guide. Still no one said anything concrete. Can you charge that amt? Or is the CIM really limited to $99.99 and lower? Support suggested to e-mail or use AIM to charge the card. I just wanted some expertise to shine some light on this.
Please let me know about the max transaction amt charging the card through the CIM. I really would hate to change it now.
Thanks so much!!
That shouldn’t happen. They don’t charge a card unless you specifically tell them to.
CIM can handle any charge amount up to $9999.99 if I am reading the documentation correctly. I just did transactions for $500 and $5000.00 with no problems. If you are having issues with using CIM you should have your developer check their code. That 1¢ transaction should not be happening and there shouldn’t be any issues with transaction amounts.
If you want to process a payment immediately AIM is always the best way to do it. After the successful transaction you then should use CIM to establish their CIM account for future transactions.
It may be a bit late but I wanted to clarify that the $0.01 transaction is caused by the ValidationMode. From the CIM_XML_guide.pdf:
Validation mode allows you to generate a test transaction at the time you create a customer payment profile. In Test Mode, only field validation is performed. In Live Mode, a transaction is generated and submitted to the processor with the amount of $0.01. If successful, the transaction is immediately voided. When a value of “none” is submitted, no additional validation is performed. For information about output elements for this function, see the section of this document titled.
John Conde, who posted above, has some great information on his Merchant Account Services website about eCommerce in general and Authorize.net APIs in particualar.
I also have an article I wrote on the CIM API when it came out that goes over some of the holes in both the API and in the documentation. Fortunately, they recently updated the documentation and fixed a lot of the problems. There are still a few places where there are errors, but overall it is much better.
Lastly, for anyone struggling to develop with Authorize.net’s CIM or ARB apis, I created a simple tool which allows you to submit requests as raw XML and then see the raw XML response. To make things a little easier, you can type in your API Login and Transaction Key (recommend only using a Test account) and then select from a drop-down to have a template XML for any of the request types pasted in to the input area. You can try it out here:
Is it possible to send a test request to a live server for CIM, like one can do with AIM?
First of all, it must be understood that “Test Mode” has no meaning for the majority of CIM (or ARB, for that matter) calls. Test mode really only applies to AIM transaction requests in that it instructs AuthNet to only check that the transaction request is valid, and not process it in any way. Thus test mode transactions are never recorded in your transaction log.
Therefore, any calls to CIM or ARB which do not cause a transaction request to be generated to the AIM service will not be affected by test mode. The CIM calls which are affected by test mode are validateCustomerPaymentProfileRequest, createCustomerProfileTransactionRequest, and the various create and update calls which support the validationMode element.
Interestingly, the createCustomerProfileTransactionRequest call, which is the only way to actually request a regular payment transaction to AIM, does not have any direct support for making the request in test mode. It does, however, support the extraOptions element, which will basically take in an AIM style request string (“x_some_opt=value|x_some_other_opt=value|…”) of any options not supported by the regular request XML. I have not personally tried this method to see if x_test_request=TRUE will submit the transaction it test mode, but my guess is it will.
The other alternative, of course, is to place your entire account into Test Mode and then submit your transaction requests.
Does this answer your question?
Thanks, David.
It does answer my question. Actually we sent a request which we had marked with x_test_request = TRUE, but it lead to an actual transaction on our live CIM account yesterday.
We checked all out code many times, but then finally realized that CIM does not support the x_test_request option and wanted to verify this.
That’s unfortunate, but I appreciate you letting us all know the answer.