Showing results for 
Search instead for 
Did you mean: 

Simplified, independent examples of AIM for PHP


One of the best how-to articles I've seen so far is entirely independent of the official website:


John Conde does a great job in explaining the various required and optional fields, and the code marks what will happen if the card is accepted or declined.  I wish I could say the same for the official API reference guide (


The article referenced was last modified around 2010, and the variables used do not seem to be corresponding to the modern techniques, such as in this help response, which was posted today (2016-12-05):

Does anyone recommend another, more up-to-date example of the simplified AIM code (based on PHP, in this case, but reference to other platforms are welcome)?


Ideally, it would reference a limited number of files that are included in the "sdk-php-master" folder that is publicly available, such as was done on only the first line of John Conde's sample code (the first link I referenced).





In order to avoid having to go to another website, here is the content from John Conde's final example in the referenced article:

    $user_id = 1;
    $email   = '';
    $product = 'A test transaction';
    $business_firstname = 'John';
    $business_lastname  = 'Smith';
    $business_address   = '123 Main Street';
    $business_city      = 'Townsville';
    $business_state     = 'NJ';
    $business_zipcode   = '12345';
    $business_telephone = '800-555-1234';
    $shipping_firstname = 'John';
    $shipping_lastname  = 'Smith';
    $shipping_address   = '100 Business Rd';
    $shipping_city      = 'Big City';
    $shipping_state     = 'NY';
    $shipping_zipcode   = '10101';
    $creditcard = '4111-1111-1111-1111';
    $expiration = '12-2016';
    $total      = 1.00;
    $cvv        = 123;
    $invoice    = substr(time(), 0, 6);
    $tax        = 0.00;
    $payment = new AuthnetAIM('myapilogin', 'mYtRaNsaCTiOnKEy', true);
    $payment->setTransaction($creditcard, $expiration, $total, $cvv, $invoice, $tax);
    $payment->setParameter("x_duplicate_window", 180);
    $payment->setParameter("x_cust_id", $user_id);
    $payment->setParameter("x_customer_ip", $_SERVER['REMOTE_ADDR']);
    $payment->setParameter("x_email", $email);
    $payment->setParameter("x_email_customer", FALSE);
    $payment->setParameter("x_first_name", $business_firstname);
    $payment->setParameter("x_last_name", $business_lastname);
    $payment->setParameter("x_address", $business_address);
    $payment->setParameter("x_city", $business_city);
    $payment->setParameter("x_state", $business_state);
    $payment->setParameter("x_zip", $business_zipcode);
    $payment->setParameter("x_phone", $business_telephone);
    $payment->setParameter("x_ship_to_first_name", $shipping_firstname);
    $payment->setParameter("x_ship_to_last_name", $shipping_lastname);
    $payment->setParameter("x_ship_to_address", $shipping_address);
    $payment->setParameter("x_ship_to_city", $shipping_city);
    $payment->setParameter("x_ship_to_state", $shipping_state);
    $payment->setParameter("x_ship_to_zip", $shipping_zipcode);
    $payment->setParameter("x_description", $product);
    if ($payment->isApproved())
        // Get info from Authnet to store in the database
        $approval_code  = $payment->getAuthCode();
        $avs_result     = $payment->getAVSResponse();
        $cvv_result     = $payment->getCVVResponse();
        $transaction_id = $payment->getTransactionID();
        // Do stuff with this. Most likely store it in a database.
        // Direct the user to a receipt or something similiar.
    else if ($payment->isDeclined())
        // Get reason for the decline from the bank. This always says,
        // "This credit card has been declined". Not very useful.
        $reason = $payment->getResponseText();
        // Politely tell the customer their card was declined
        // and to try a different form of payment.
    else if ($payment->isError())
        // Get the error number so we can reference the Authnet
        // documentation and get an error description.
        $error_number  = $payment->getResponseSubcode();
        $error_message = $payment->getResponseText();
        // OR
        // Capture a detailed error message. No need to refer to the manual
        // with this one as it tells you everything the manual does.
        $full_error_message =  $payment->getResponseMessage();
        // We can tell what kind of error it is and handle it appropriately.
        if ($payment->isConfigError())
            // We misconfigured something on our end.
        else if ($payment->isTempError())
            // Some kind of temporary error on Authorize.Net's end. 
            // It should work properly "soon".
            // All other errors.
        // Report the error to someone who can investigate it
        // and hopefully fix it
        // Notify the user of the error and request they contact
        // us for further assistance
catch (AuthnetAIMException $e)
    echo 'There was an error processing the transaction. Here is the error message: ';
    echo $e->__toString();



Hi @healingrooms,


That's a good article, indeed. The only problem, as you point out, is that it's geared toward the older AIM methods, and not our new API.


AIM still works, and it's still supported in our PHP SDK (with its own AuthorizeNetAIM.php class). Or, if using John's class from the article, I don't believe there's anything in that article that's invalid or won't function. But, all of our new features are being rolled out in the new API, so obviously we want developers to use that for new projects.


We have a few resources to help developers with the new API. There's the API Reference, which is just that: a reference. It's the comprehensive list of all possible values and a description of each, and isn't intended to be a walkthrough. Then, we have more instructional type things at our "Hello World" page, and in our API documentation.


Beyond that, we have our SDKs to abstract the API and make it easier for your particular language, and then sample code for the SDKs (like the PHP sample code here). The sample code includes samples for just about every scenario, and is generally pretty well commented to explain what it's doing and what is actually required. Again, not the same as a walkthrough, but there should be an example of just about everything you might want to do.


If you've already been through all of these and still feel like something is missing, then that's really good feedback that I can take to hopefully make some things better. If you've got any specific feedback about what you think is unclear, or something that you expected to see but didn't, let me know. If you'd rather not post here, you can PM me or get my email address from my profile and contact me that way.

All Star

Hi, do you have an example of the AIM integration (or whatever the most modern approach is)? The example in this link takes me to a GitHub page with a bunch of scripts which don't seem to have any relevance to checkout.


Is there a one-page PHP and HTML example like the one the poster provided above? I (as well as many others) would REALLY like a script like this.

One page integrations are doable but not without installing the SDK. There is a whole architecture that supports the API call behind the scenes. Your process needs to be: 1) get the php sdk package, 2) get composer, 3) run composer update, 4) copy some of the sample code from the API reference. Depending  on what integration method you intend to use ( which should definitely not be AIM, which is deprecated). This won’t be something you do in 5 minutes. You will have to do some research and debugging at most of these steps. But if you have some basic php knowledge and skills and know how to post variables from forms you’ve got the raw material to get started. The BIG consideration on what integration method to use is the PCI compliance scope you fall under with each option. If there were no PCI SC, 99% of everyone doing this would just run a chargeCreditCard script and be done with it. Unfortunately most if not all variants of that integration method, as well as the AIM script above, will subject you to a list compliance requirements that runs almost 70 pages. So most smaller merchants use the Accept Suite in some form. You will be SAQ A or SAQ A-EP.