Important Note

The Advanced Integration Method (AIM), Server Integration Method (SIM), and Direct Post Method (DPM) are now obsolete and in the process of being phased out. We strongly suggest using one of our modern connection methods to integrate with the Authorize.net Payment Gateway. Visit our Developer Center and Upgrade Guide for more information on our updated APIs.

Advanced Integration Method (AIM)

The AIM is designed for server-to-server connections, allowing your software to directly submit transactions and receive responses from us. This is different from the SIM, which uses the customer's web browser, not your server, to connect to our servers.

AIM Transaction Flow

• A customer places an order on the merchant's website, submitting an order form with their credit card information.
• This form will post to a script on the web server.
• The script will establish a Transport Layer Security (TLS) connection with the Authorize.net Payment Gateway.
• The script will then post a request with all of the transaction details through the TLS connection to the payment gateway.
• Our payment gateway connects with the merchant's payment processor to request authorization for the charge and waits for the results. The TLS connection remains open while this happens.
• Our payment gateway receives a response from the processor and posts it back through the TLS connection to the script that sent the original request to us.
• The script handling the request will generate a receipt page based on the results and will display this to the customer.

Due to the use of TLS connections to transmit information, Authorize.net's role is never visible, and your customer never leaves your website. However, AIM does require the web server to have a TLS certificate; it cannot establish the TLS connection without one.

Delimited Direct Response String

If you are trying to use AIM, but are running the AIM script from a customer's web browser instead of directly from your own server, the customer may see the AIM Direct Response string instead of a receipt page. Such a Direct Response string would look something like this:

1,1,1,This transaction has been accepted.,123456,Y, ...

Note that the exact formatting may vary if the account's Direct Response settings have been changed, or if your software tells us to send the response in a different format.

Proper AIM Implementation

A proper AIM implementation would follow these particular steps:

1. The customer connects to your website using their web browser, and completes a payment form that your site would host.
2. The payment form would submit the customer's details to a script that uses AIM to:
   • Connect to our Gateway URL (https://secure.authorize.net/gateway/transact.dll) using Transport Layer Security (TLS) to encrypt an HTTPS connection;
   • Submit the transaction details;
   • Immediately receive a Direct Response from our Gateway URL; and
   • Either generate a receipt page, or redirect to one, using the Direct Response information to provide a more customer-friendly confirmation or decline page.
3. Display the receipt page in the customer's web browser.

AIM should be handled by your server, and not by the customer's web browser. If a customer's web browser submits the AIM request, the response will go to the browser, and not to your server. Authorize.net is never seen during this process because all processing is done in the background from server to server. Also, please be aware that you must have your own secure server to use AIM.

Direct Response

The Direct Response settings page allows you to adjust the formatting of Advanced Integration Method (AIM) responses.

The Default Field Encapsulation Character setting specifies the character used to enclose all of the data within a field. By specifying an encapsulation character, the system will know that all characters that fall within the encapsulation characters are part of the same field, even if one or more of those characters are the same as the field delimiting characters.

To change this setting, you can choose a new encapsulating character from the drop-down list. If the character that you would like to use is not in the drop-down list, the "other" choice should be selected so that the desired character can be typed in the box to the right of the list.

To Format Direct Response

1. Log into the Merchant Interface.
2. Click Direct Response under Transaction Format Settings - Transaction Response Settings.
3. Click Yes or No to specify whether you would like to receive transaction responses as delimited text strings.
4. Select a default field separator, or delimiting character, from the Default Field Separator drop-down list. Alternately, if you would like to use a custom field separator, enter the desired character into the appropriate text field.
5. Select a default field encapsulation character from the Field Encapsulation Character drop-down list. If you would like to use a custom field encapsulation character instead, enter the desired character into the appropriate text field.
6. Click Submit. A confirmation message indicates that your setting has been successfully applied.

Why Are My AIM Transactions Timing out After Submitting the Request?

The Advanced Integration Method (AIM) uses a direct, server-to-server connection. When using AIM, transaction response timeouts should be rare because AIM uses the same connection for receiving the transaction request and returning the transaction response.

If no transactions are being recorded in the Merchant Interface for the account in question, and you do not appear to be receiving any response from Authorize.net, you may not be successfully connecting to Authorize.net in the first place.

If Authorize.net receives the transaction request, but is unable to return the transaction response within 20 seconds, we will update the transaction with the status, General Error (Unable to Send Notification). Such errors usually occur when the connection to the payment gateway is prematurely closed, or when it doesn't close within 20 seconds. If the bulk of your transactions process without problems, then your network might have had a temporary lag or connection failure. These sorts of issues would be outside Authorize.net's control, but should also be very rare as long as your network is generally stable and reliable. If the Unable to Send Notification error occurs repeatedly but sporadically, or if the error only occurs in short bursts, then you may want to consult with your web hosting company or Internet Service Provider to find out if there are any issues that might cause Internet connections to drop or time out. Possible causes include occasional web server load spikes, routing or load balancing issues, and Internet congestion.

If all of your transaction requests result in Unable to Send Notification errors, your web host or developer should:

• Confirm that port 443 is available for incoming Internet traffic. Blocking this port at any point in your network will cause Unable to Send Notification errors.
• Make sure that your software or website receives the full transaction response and closes the connection before it begins any actual processing or storage of the response. If you begin to process the data as it comes in, this may potentially delay the completion of the transaction response long enough to cause Unable to Send Notification errors.
• Check to see if errors in the software or in the web server configuration may be causing the connection to end abruptly. Review your server or software connection logs for errors occurring at about the same time as the Unable to Send Notification errors. Resolving those errors may allow us to complete the connection.