Showing results for 
Search instead for 
Did you mean: 

Which method to use: AIM, SIM, CIM, DPM???

I would like the follwing in order of priority:

  1. no PCI issues, all data stored on servers
  2. customization of the payment pages look and feel
  3. customers to stay on my site (url and design)

Here is my take:

AIM can do 2 and 3, but not 1. It takes CC data and requires much stricter PCI standards.


SIM can do 1 and 2, but takes you away from your URL


CIM can do 1, 2 and 3


Not sure about DPM.  


I am using ExpressionEngine and CartThrob if that matters...




I am new to Authorize.Net, I need your advice to understand CIM method. For our project I have plan to use CIM for first/ intial payment and for ongoing paymnets. Please let me know can we achieve  using CIM ?




Yes, you can charge a profile immediately after you create it with CIM.

Thanks for your reply! Also could you please explain where can I get detailed response for Custom Receipt after I submit


Are you going to use hosted CIM (forms are hosted on or regular CIM (forms are hosted on your site)? If the latter, it's probably fairly easy to do a custom receipt page, just print_r on $response or $transactionResponse (not sure which it would be) after putting in a sample transaction, and this will give you all the fields that returns. if the former, there should be sample code here (see the CIM section):

Your discussion of what portion of the framework to use, but in the real world, as with my site that has both memberships and one-off purchases, do I then use CIM for purchases from my "members" and simply AIM to process individual transactions where I do not have a previously saved customer ID?


The issue is that I wonder why both AIM and CIM have a transaction processing method, would it not be easier if there was just one transaction processing method with an optiponal customer ID that could be passed in instead of individual field for name, card #, etc?


That seems logical to me, having it all wrapped up in one all encompassing method so that I would not have to use two completely different modules to do the same thing, namely charging purchases.  what makes no sense to me is the following logic:  If (is a member) use CIM; else use AIM. 

Re: do I then use CIM for purchases from my "members" and simply AIM to process individual transactions where I do not have a previously saved customer ID?


Correct. However, you should never use AIM for new development, use DPM instead. And likewise, you should never use standard CIM for new development, use "Hosted CIM" (see the api docs) instead. 


You want to reduce your server's exposure to the card data (and to PCI) when-ever possible.


Re: why both AIM and CIM have a transaction processing method?


You're right, the api's could be better integrated with each other. The good news is that the transaction fields for the different methods tend to be the same. 


The feeling I get is that one thing they're working on is better integration between CIM, DPM and the ARB system. -- There should be no need to re-enter ARB payer info if it was recently entered as part of a transaction (AIM, DPM, etc) or is already within the CIM system.


I don't think has many developers, so enhancements seem to roll out slowly. The good news is that their competitors are causing to be more pro-active than they used to be. "All hail capitalism!"



The PCI requirements for even AIM and regular CIM are not terribly difficult as long as only one person has access to the hosting and that person doesn't walk around with the password taped to his forehead. And a lot of people (myself included) prefer to charge things internally rather than forward to another site. Saying that they should -never- be used is going a bit overboard, imho. As long as they're available, they'll be an option that many people prefer. If they're ever disabled, you can kiss a large chunk of's user base goodbye.


I still argue that as long as you're not actually storing the credit card data locally, security starts and ends with access to the hosting. If someone gets into your hosting, you're doomed. Period. No amount of security is going to protect your customers. Only takes maybe 30 minutes to hack together an identical, fake payment form and then redirect people to that instead, for instance.

We are new to and would like to go this foute in favor of our current paypal process.


We are a youth sports group where parents register their children for tournaments.


1. enter player information and select tournaments on first page (ASP)

2. save entered information on previous form in access db, presents payment page with paypal paynow button

3. paynow button when clicked routes the customer to paypal via the following code:


  <input type="hidden" name="cmd" value="_xclick">
  <input type="hidden" name="business" value="">
  <input type="hidden" name="item_name" value="<%=Request.Form("email")%>">
  <input type="hidden" name="amount" value="<%=(feeplus)%>">
  <input type="hidden" name="item_number" value="<%=(REGID)%>">
  <input type="hidden" name="no_shipping" value="0">
  <input type="hidden" name="no_note" value="1">
  <input type="hidden" name="currency_code" value="USD">
  <input type="hidden" name="notify_url" value="">
  <input type="hidden" name="return" value="">


When the transaction is complete in paypal, the ipnpaypal.asp is executed automatically on our site to post paid to the transaction.


Can we do this with and are there any practice native ASP examples we can use?