Advanced Integration Method (AIM) Developer Guide: Card Not Present Transactions

Advanced Integration Method (AIM)
Developer Guide
Card Not Present Transactions
Authorize.Net Developer Support

http://developer.authorize.net
Authorize.Net LLC 082007 Ver.2.0

Authorize.Net LLC (“Authorize.Net”) has made efforts to ensure the accuracy and completeness of the
information in this document. However, Authorize.Net disclaims all representations, warranties and
conditions, whether express or implied, arising by statute, operation of law, usage of trade, course of
dealing or otherwise, with respect to the information contained herein. Authorize.Net assumes no
liability to any party for any loss or damage, whether direct, indirect, incidental, consequential, special
or exemplary, with respect to (a) the information; and/or (b) the evaluation, application or use of any
product or service described herein.
Authorize.Net disclaims any and all representation that its products or services do not infringe upon
any existing or future intellectual property rights. Authorize.Net owns and retains all right, title and
interest in and to the Authorize.Net intellectual property, including without limitation, its patents,
marks, copyrights and technology associated with the Authorize.Net services. No title or ownership of
any of the foregoing is granted or otherwise transferred hereunder. Authorize.Net reserves the right to
make changes to any information herein without further notice.
Authorize.Net Trademarks:
Authorize.Net®
Authorize.Net Your Gateway to IP Transactions™
Authorize.Net Verified Merchant Seal™
Authorize.Net Where the World Transacts®
Automated Recurring Billing™
eCheck.Net®
Fraud Detection Suite™
FraudScreen.Net®
Last revised: 3/30/2009

Copyright © 1998 - 2009 Authorize.Net, a CyberSource solution 1
Table of Contents
Revision History ................................................................................ 4

Section 1 ........................................................................................... 5
Introduction....................................................................................... 5
AIM Minimum Requirements ............................................................................................. 5
Payment Card Industry (PCI) Data Security Standard ........................................................... 6
Managing Integration Settings .......................................................................................... 6
Features of AIM ................................................................................................................ 7
eCheck.Net®..................................................................................................................... 7
Developer Support ............................................................................................................ 8
Section 2 ........................................................................................... 9
Submitting Transactions................................................................... 9
Minimum Requirements .................................................................................................... 9
Credit Card Transaction Types ....................................................................................... 11
Authorization and Capture ...................................................................................................... 11
Authorization Only ................................................................................................................... 11
Prior Authorization and Capture ............................................................................................ 12
Capture Only ............................................................................................................................ 13
Credit ......................................................................................................................................... 13
Unlinked Credit ........................................................................................................................ 14
Void ........................................................................................................................................... 14
Using the Merchant Interface .......................................................................................... 15
Section 3 ......................................................................................... 16
Transaction Data Requirements ..................................................... 16
Transaction Post Location .............................................................................................. 16
AIM Transaction Submission API ................................................................................... 16
Merchant Information .............................................................................................................. 16
Transaction Information .......................................................................................................... 17
Order Information .................................................................................................................... 20
Itemized Order Information ..................................................................................................... 20
Customer Information ............................................................................................................. 21
Shipping Information ............................................................................................................... 23
Additional Shipping Information (Level 2 Data) ................................................................... 23
Cardholder Authentication ..................................................................................................... 25
Merchant-defined fields .......................................................................................................... 26
Section 4 ......................................................................................... 27
Transaction Response .................................................................... 27
Fields in the Payment Gateway Response ..................................................................... 28
Response for Duplicate Transactions ................................................................................... 32
Response Code Details .................................................................................................. 33
Response Codes ...................................................................................................................... 33
Response Reason Codes and Response Reason Text ....................................................... 33
Email Receipt .................................................................................................................. 42
Section 5 ......................................................................................... 44

Table of Contents
Test Transactions ........................................................................... 44

Testing to Generate Specific Transaction Results............................................................... 45
Appendix A ...................................................................................... 46
Fields by Transaction Type............................................................. 46
Minimum Required Fields ............................................................................................... 46
Required Fields for Additional AIM Features .................................................................. 46
Best Practice Fields ........................................................................................................ 47
Appendix B ...................................................................................... 48
Alphabetized List of API Fields ....................................................... 48

Revision History
PUBLISH DATE UPDATES

August 2007 Release of Ver 2.0 Advanced Integration Method (AIM) Developer Guide
May 2008 Remove SecureSource requirements and various updates
March 2009 Addition of error codes 315-319

Section 1
Introduction
Welcome to the Authorize.Net Advanced Integration Method (AIM) Developer Guide. This guide
describes the Web development required to connect an e-commerce Web site or other application to
the Authorize.Net Payment Gateway in order to submit credit card transactions for authorization
and settlement using AIM.
AIM is a customizable payment processing solution that gives the merchant control over all the
steps in processing a transaction, including:
• Collection of customer payment information through a custom application

• Generation of a receipt to the customer
• Secure transmission to the payment gateway for transaction processing
• Secure storage of cardholder information
• And more, depending on the merchant’s business requirements
The security of an AIM transaction is assured through a 128-bit Secure Sockets Layer (SSL)
connection between the merchant’s Web server and the Authorize.Net Payment Gateway.
AIM is an ideal integration solution because it allows merchants the highest degree of
customization and control over their customers’ checkout experience.
Note: For merchants who prefer a payment solution that handles the collection, transmission and
storage of cardholder data, Authorize.Net recommends the Server Integration Method
(SIM). The SIM Developer Guide can be found in the Authorize.Net Integration Center at
http://developer.authorize.net/guides/SIM/default.htm.
With SIM, merchants never have to collect, transmit, or store sensitive cardholder
information. Additionally, SIM does not require merchants to purchase and install a Secure
Sockets Layer (SSL) digital certificate. This removes the complexity of securely handling
and storing cardholder information, simplifying compliance with the Payment Card
Industry (PCI) Data Security Standard.
AIM Minimum Requirements

Before you begin, check with the merchant to make sure that the following AIM requirements have
already been met. It is strongly recommended that you work closely with the merchant to ensure
that any other business and Web site requirements (for example, bank or processor requirements,
Web site design preferences) are included in their AIM integration.

Section 1 Introduction
• The merchant must have a U.S. based merchant bank account that allows Internet
transactions.
• The merchant must have an e-commerce (Card Not Present) Authorize.Net Payment
Gateway account.
• The merchant must have a valid Secure Sockets Layer (SSL) certificate and their
Web site must be capable of initiating both client and server side SSL connections.
• The merchant’s Web site must have server-side scripting or CGI capabilities such as
ASP Classic, C#, Cold Fusion, Java, Perl, PHP or VB.Net.
• The merchant must be able to store payment gateway account data securely (for
example, API Login ID, Transaction Key, Secret Answer).
Payment Card Industry (PCI) Data Security Standard

IMPORTANT: AIM involves the transmission of sensitive cardholder data via the merchant’s
Web server. As such, the merchant is required to store cardholder information securely and in
accordance with the Payment Card Industry (PCI) Data Security Standard. For more
information about PCI and other industry standard processing practices, please see the Developer
Security Best Practices White Paper at http://www.authorize.net/files/developerbestpractices.pdf
for more information.
If the merchant needs a solution that handles the collection, transmission and storage of cardholder
data, they should use the Server Implementation Method (SIM). For more information about SIM,
please see the SIM Developer Guide at http://developer.authorize.net/guides/SIM/default.htm.
Managing Integration Settings

When integrating to the payment gateway, you should be aware that most settings for a merchant’s
integration can be configured and managed in two ways:
1. Included in the transaction request on a per-transaction basis via the application

programming interface (API), (as described in this guide), OR
2. Configured in the Merchant Interface and applied to all transactions.
IMPORTANT: The Merchant Interface at https://secure.authorize.net is a secure Web site where

merchants can manage their payment gateway account settings, including their Web site integration
settings. It is recommended that you review the Merchant Integration Guide at
http://www.authorize.net/support/Merchant/default.htm for information on managing the
merchant’s payment gateway integration via the Merchant Interface.
Transaction settings submitted in the transaction request will override transaction settings
configured in the Merchant Interface. However, please be aware that some integration settings
must be configured in the Merchant Interface. To help the merchant maintain a robust
integration, it is recommended that you review the integration settings that can be configured in the
Merchant Interface with the merchant and determine which integration settings can be posted on a
per-transaction basis and which should be configured in the Merchant Interface. See the “Appendix

WebLink Developer Guide
A Fields by Transaction Type” section of this document for a list of fields the payment gateway
recommends be submitted on a per-transaction basis.
Features of AIM
In addition to basic transaction processing, AIM provides merchants with several features for
configuring transaction security options and further customizing their customers’ checkout
experience. These features are listed in the AIM Feature Selection Guide provided below. Please
take a few moments to discuss these with your merchant and select which features they would like
to include in their integration.
FEATURE DESCRIPTION REQUIREMENTS

Address This feature allows merchants to compare the To implement AVS, the merchant must
Verification billing address submitted by the customer for require the Address and ZIP Code fields on
Service (AVS) the transaction with the address on file at the their custom payment form.
card issuing bank. Filter settings in the
Filter
Merchant Interface allow the merchant to reject
For more information about AVS, please see
transactions based on the AVS response
the Merchant Integration Guide at
received.
http://www.authorize.net/support/Merchant/de
fault.htm.
Card Code This feature allows merchants to compare the To implement CCV, the merchant must
Verification card code submitted by the customer for the require the Card Code on their custom
(CCV) Filter transaction with the card code on file at the payment form.
card issuing bank. Filter settings in the
Merchant Interface allow the merchant to reject
For more information about CCV, please see
transactions based on the CCV response
the Merchant Integration Guide at
received.
http://www.authorize.net/support/Merchant/de
fault.htm.
Itemized Order This feature allows merchants to submit details To implement Itemized Order Information, the
Information for items purchased. This information is line item field must be submitted on a per-
included in the merchant transaction transaction basis.
confirmation email, in the Transaction Details
for the transaction and in QuickBooks
Please see the “Itemized Order Information”
download reports in the Merchant Interface.
section of this document for details.
Email Receipt This feature allows merchants to opt for an To configure the payment gateway email
automatic email receipt to be sent by the receipt, the merchant must require the
payment gateway to their customers. customer email address on their custom
payment form, and settings must be
configured in the Email Receipts section of
the Settings menu in the Merchant Interface
or submitted on a per-transaction basis.
Please see the “Receipt Options” section of

this document for details.
eCheck.Net®
In addition to processing credit card transactions, the payment gateway also supports electronic
check transactions with our exclusive eCheck.Net® product. Please contact the merchant to
determine whether eCheck.Net is enabled for their payment gateway account or if they would like
to sign up. In the event that eCheck.Net is enabled, you will need to ensure that the merchant’s
Web site integration supports all eCheck.Net field requirements. Please see the eCheck.Net
Developer Guide at http://developer.authorize.net/guides/eCheck.pdf for more information.

Section 1 Introduction
Developer Support
There are several resources available to help you successfully integrate a merchant Web site or
other application to the Authorize.Net Payment Gateway.
• The Integration Center at http://developer.authorize.net provides test accounts, sample

code, FAQs, and troubleshooting tools.
• If you can’t find what you need in the Integration Center, our Integration Team is available
to answer your questions via email at integration@authorize.net. (Please note that our
Integration Team will only be able to assist with support requests specifically about the
Authorize.Net application programming interface (API) and/or services.)
• Be sure to read our Developer Security Best Practices White Paper at

http://www.authorize.net/files/developerbestpractices.pdf for information on how to
maximize the security and reliability of your merchant integration solutions.
If you have any suggestions about how we can improve or correct this guide, please email
documentation@authorize.net.

Section 2
Submitting Transactions
The payment gateway supports several credit card transaction types for transactions submitted via
AIM.
To implement AIM for a merchant’s Web site or proprietary business application, you will need to
develop an application that performs the following:
• Securely obtains all of the information required to process a transaction (including data
requirements specified by the merchant).
• Initiates a secure SSL connection from the merchant’s Web server to the payment gateway
transaction post location to pass transaction data in name/value pairs.
• Receives and parses the transaction response from the payment gateway and displays the
results to the customer.
There are two options for developing the application:
• You may develop a custom application yourself using the information provided in this
document, OR
• You may use Authorize.Net sample code available for free from our Integration Center at
http://developer.authorize.net.
If you choose to use sample code, please be aware that to achieve a successful implementation it
must be modified with the merchant’s specific payment gateway account information. Be sure to
carefully review the readme.txt files and comments included in each file of sample code in order to
achieve a faster, successful integration.
Developer test accounts with API Login IDs and Transaction Keys are also available for testing
your integration methods to the Authorize.Net Payment Gateway at
http://developer.authorize.net/testaccount.
Minimum Requirements
The following table represents the minimum fields required for submitting a credit card transaction
request to the payment gateway using AIM. The data fields are name/value pairs with the syntax of:
x_name_of_field=value of field&.

Section 2 Submitting Transactions
FIELD NAME VALUE FORMAT NOTES

x_login The merchant’s unique Up to 20 characters The merchant API Login ID is provided
API Login ID in the Merchant Interface and must be
stored securely.
The API Login ID and Transaction Key

together provide the merchant
authentication required for access to
the payment gateway.
See the Merchant Integration Guide at

http://www.authorize.net/support/Merc
hant/default.htm for more information.
x_tran_key The merchant’s unique 16 characters The merchant Transaction Key is
Transaction Key provided in the Merchant Interface and
must be stored securely.


x_type The type of credit card AUTH_CAPTURE If the value submitted does not match
transaction (default), AUTH_ONLY, a supported value, the transaction is
CAPTURE_ONLY, rejected. If this field is not submitted or
CREDIT, PRIOR_ the value is blank, the payment
AUTH_CAPTURE, gateway will process the transaction
VOID as an AUTH_CAPTURE.
x_amount The amount of the Up to 15 digits with a This is the total amount and must
transaction decimal point (no dollar include tax, shipping, and any other
symbol) charges.
Ex. 8.95
x_card_num The customer’s credit Between 13 and 16 This is sensitive cardholder
card number digits without spaces information and must be stored
securely and in accordance with the
When x_type=CREDIT, Payment Card Industry (PCI) Data
only the last four digits Security Standard.
are required.
For more information about PCI,
please see the Developer Security
Best Practices White Paper at
http://www.authorize.net/files/develope
rbestpractices.pdf.
x_exp_date The customer’s credit MMYY, This is sensitive cardholder
card expiration date MM/YY, information and must be stored
MM-YY, MMYYYY, securely and in accordance with the
MM/YYYY, Payment Card Industry (PCI) Data
MM-YYYY Security Standard.

rbestpractices.pdf.

AIM Developer Guide

x_trans_id The payment gateway Required only for CREDIT,
assigned transaction PRIOR_AUTH_CAPTURE, and VOID
ID of an original transactions.
transaction
For more information about transaction
types, see the “Credit Card
Transaction Types” section of this
document.
x_auth_code The authorization code 6 characters Required only for CAPTURE_ONLY
of an original transactions. See the “Credit Card
transaction not Transaction Types” section below.
authorized on the
payment gateway
Credit Card Transaction Types

This section describes the credit card transaction types supported by the payment gateway and their
specific field requirements. It’s a good idea to talk to your merchant about how their business plans
to submit transaction so that you can properly integrate their payment gateway account to support
their business processes.
For example, are they submitting transactions mainly through an e-commerce Web site? Do they
need to integrate a custom application to allow call center representatives to enter mail
order/telephone order (MOTO) transactions? Would they like the ability to verify the availability of
funds on a customer’s credit card account at the time of purchase and then charge the credit card at
the time they ship the order?
The payment gateway supports the following credit card transaction types.
Note: Some of the field requirements listed in this section for each credit card transaction type are
in addition to the minimum field requirements already set forth above for ALL transactions
submitted to the payment gateway. For a list of all fields that are required for each credit
card transaction type, please see the “Appendix A Fields by Transaction Type” section of
this document.
Authorization and Capture

This is the most common type of credit card transaction and is the default payment gateway
transaction type. The amount is sent for authorization, and if approved, is automatically submitted
for settlement.
The unique field requirement for an Authorization and Capture is:
• x_type=AUTH_CAPTURE
Authorization Only
This transaction type is sent for authorization only. The transaction will not be sent for settlement
until the credit card transaction type Prior Authorization and Capture (see definition below) is
submitted, or the transaction is submitted for capture manually in the Merchant Interface. For more

information about capturing Authorization Only transactions in the Merchant Interface, see the
Merchant Integration Guide at http://www.authorize.net/support/Merchant/default.htm.
If action for the Authorization Only transaction is not taken on the payment gateway within 30
days, the authorization expires and is no longer available for capture. A new Authorization Only
transaction would then have to be submitted to obtain a new authorization code.
The unique field requirement for an Authorization Only is:
• x_type=AUTH_ONLY
Merchants can submit Authorization Only transactions if they want to verify the availability of
funds on the customer’s credit card before finalizing the transaction. This transaction type can also
be submitted in the event that the merchant does not currently have an item in stock or wants to
review orders before shipping goods.
Prior Authorization and Capture

This transaction type is used to complete an Authorization Only transaction that was successfully
authorized through the payment gateway.
Note: An Authorization Only and a Prior Authorization and Capture together are considered one
complete transaction. Once the Prior Authorization and Capture is submitted, the transaction
will be sent for settlement.
The payment gateway accepts this transaction type and initiates settlement if the following
conditions are met:
• The original Authorization Only transaction was submitted within the previous 30 days
(Authorization Only transactions expire on the payment gateway after 30 days).
• The transaction is submitted with the valid transaction ID (x_trans_id) of an original,

successfully authorized, Authorization Only transaction.
• The original transaction is not yet captured, expired or errored.
• The amount being requested for capture is less than or equal to the original authorized
amount. Please note that only a single Prior Authorization and Capture transaction may
submitted against an Authorization Only.
The unique field requirements for a Prior Authorization and Capture are:
• x_type=PRIOR_AUTH_CAPTURE
• x_trans_id=Transaction ID here
For this transaction type, the amount field (x_amount) is only required in the event that a Prior
Authorization and Capture is submitted for an amount that is less than the amount of the original
Authorization Only transaction. If no amount is submitted, the payment gateway will initiate
settlement for the amount of the original authorized transaction.

AIM Developer Guide
Capture Only
This transaction type is used to complete a previously authorized transaction that was not originally
submitted through the payment gateway or that requires voice authorization.
A Capture Only transaction is most commonly submitted in the Merchant Interface to manually
accept a transaction that was declined by the payment gateway due to Address Verification Service
(AVS) and/or Card Code Verification (CCV) filtering. For more information about overriding AVS
and CCV filter declines, see the Merchant Integration Guide at
http://www.authorize.net/support/Merchant/default.htm.
The payment gateway accepts this transaction type and initiates settlement if the following
conditions are met:
• The transaction is submitted with the valid authorization code issued to the merchant to
complete the transaction.
The unique field requirements for a Capture Only are:
• x_type=CAPTURE_ONLY
• x_auth_code=Authorization Code here
For instructions on how to perform a Capture Only transaction in the Merchant Interface, please see
the Merchant Integration Guide at http://www.authorize.net/support/Merchant/default.htm.
Credit
This transaction type is used to refund a customer for a transaction that was originally processed
and successfully settled through the payment gateway.
The payment gateway accepts Credits if the following conditions are met:

successfully settled transaction.
• The amount being requested for refund is less than or equal to the original settled amount.
• The sum amount of multiple Credit transactions submitted against the original transaction
is less than or equal to the original settled amount.
• At least the last four digits of the credit card number (x_card_num) used for the original,
successfully settled transaction are submitted. An expiration date is not required.
• The transaction is submitted within 120 days of the settlement date of the original
transaction.
The unique field requirements for a Credit are:
• x_type=CREDIT

• x_card_num=Full credit card number or last four digits only

here
Unlinked Credit
This transaction type is used to issue a refund for a transaction that was not originally submitted
through the payment gateway. It also allows the merchant to override restrictions for submitting
refunds for payment gateway transactions, for example, if the merchant is beyond the 120-day
period for submitting a refund or would like to refund an amount that is greater than the original
transaction amount.
The ability to submit unlinked credits is not a standard feature of a merchant’s payment
gateway account. To be enabled for expanded credits capability (ECC), the merchant must submit
an application. For more information about the ECC application, please see the
http://www.authorize.net/files/ecc.pdf.
IMPORTANT: A transaction ID must not be submitted with an Unlinked Credit. If ECC is

enabled for the merchant’s account, and a transaction ID is submitted with the Unlinked Credit
transaction, then the payment gateway will attempt to apply the credit to an original transaction
with the transaction ID submitted.
The unique field requirement for an Unlinked Credit is:
• x_type=CREDIT
Void
This transaction type is used to cancel an original transaction that is not yet settled and prevents it
from being sent for settlement. A Void can be submitted against any other transaction type.
Note: If you are unsure of whether a transaction is settled, you can attempt to submit a Void first. If
the Void transaction errors, the original transaction is likely settled and you can submit a
Credit for the transaction.
The payment gateway accepts Voids if the following conditions are met:

successfully authorized transaction.
• The original transaction is not already settled, expired or errored.
The unique field requirements for a Void are:
• x_type=VOID
Note: Typically, Authorization Only or Authorization and Capture are the primary transaction
types submitted via an e-commerce Web site or other application. Though they most likely
will not be used for the merchant’s Web site integration, all other transaction types listed
above may be integrated for automatic submission into an internal or enterprise application,

AIM Developer Guide
like those used in a call center, or they may also be submitted by the merchant manually via
the Virtual Terminal in the Merchant Interface.
Using the Merchant Interface

The Merchant Interface allows merchants to manage transactions, capture Authorization Only
transactions, void transactions, and issue refunds. These transaction types can also be managed
automatically via the API if you are integrating a custom application to the payment gateway.
However, for most integrations, these transaction types can be more conveniently and easily
managed in the Merchant Interface.
For more information on submitting transactions in the Merchant Interface, see the Merchant
Integration Guide at http://www.authorize.net/support/Merchant/default.htm or click Help in the
top right corner of the Merchant Interface.

Section 3
Transaction Data Requirements
The standard payment gateway application programming interface (API) consists of required
information fields (introduced in the previous section) and additional optional fields that can be
submitted to the payment gateway for real-time transaction processing.
Transaction Post Location

The merchant’s Web site should submit transaction requests to the following payment gateway
URL:
https://secure.authorize.net/gateway/transact.dll
Note: If you are developing using an Authorize.Net developer test account, test transactions are
posted to a staging environment at https://test.authorize.net/gateway/transact.dll. If you
do not have a developer test account, you may sign up for one at
http://developer.authorize.net.
AIM Transaction Submission API

The following tables list the transaction data fields that can be submitted via the transaction request
string. Several of these fields may also be configured in the Merchant Interface. For more
information about configuring these settings in the Merchant Interface, please see the Merchant
Integration Guide at http://www.authorize.net/support/Merchant/default.htm.
Fields are name/value pairs with the syntax of:
x_name_of_field = value of the field&.
Merchant Information
FIELD NAME REQUIRED? VALUE FORMAT NOTES
x_login Required The merchant’s Up to 20 The merchant API Login ID is provided
unique API Login characters in the Merchant Interface and must be
ID stored securely.

authentication required for access to the
payment gateway.

http://www.authorize.net/support/Merch
ant/default.htm for more information.

AIM Developer Guide
x_tran_key Required The merchant’s 16 characters The merchant Transaction Key is

unique provided in the Merchant Interface and
Transaction Key must be stored securely.

authentication required for access to the
payment gateway.

http://www.authorize.net/support/Merch
ant/default.htm for more information.
Transaction Information
x_version Required The 3.1 The transaction version
merchant’s represents the set of fields
transaction that is included with the
version transaction response. 3.1 is
the current standard version.
It is highly recommended that

you submit this field on a per-
transaction basis to be sure
that the formats of transaction
requests and the responses
you receive are consistent.
For more information, see the

“Appendix A Fields by
Transaction Type” sections of
this document.
x_type Optional The type of AUTH_CAPTURE If the value submitted does
credit card (default), not match a supported value,
transaction AUTH_ONLY, the transaction is rejected. If
CAPTURE_ONLY, this field is not submitted or
CREDIT, PRIOR_ the value is blank, the
AUTH_CAPTURE, payment gateway will process
VOID the transaction as an
AUTH_CAPTURE.
x_method Optional The payment CC or ECHECK The method of payment for
method the transaction, CC (credit
card) or ECHECK (electronic
check). If this field is not
submitted or is blank, the
value will default to CC.
For more information about

eCheck.Net transaction
requirements, see the
eCheck.Net Developer Guide
at
http://developer.authorize.net/
guides/eCheck.pdf.
x_recurring_billing Optional The recurring TRUE, FALSE, Indicates whether the
billing status T, F, transaction is a recurring
YES, NO, billing transaction.
Y, N,

Section 3 Transaction Data Requirements

1, 0
x_amount Required The amount of Up to 15 digits with This is the total amount and
the transaction a decimal point (no must include tax, shipping,
dollar symbol) and any other charges. The
amount may either be hard
Ex. 8.95 coded or posted to a script.
x_card_num Required The customer’s Between 13 and 16 This is sensitive cardholder
credit card digits without information and must be
number spaces stored securely and in
accordance with the Payment
When Card Industry (PCI) Data
x_type=CREDIT, Security Standard.
only the last four
digits are required. For more information about
PCI, please see the
Developer Security Best
Practices White Paper at
http://www.authorize.net/files/
developerbestpractices.pdf.
x_exp_date Required The customer’s MMYY, This is sensitive cardholder
credit card MM/YY, information and must be
expiration date MM-YY, MMYYYY, stored securely and in
MM/YYYY, accordance with the Payment
MM-YYYY Card Industry (PCI) Data
Security Standard.

PCI, please see the
Developer Security Best
Practices White Paper at
developerbestpractices.pdf.
x_card_code Optional The customer’s Numeric The three- or four-digit
card code number on the back of a
credit card (on the front for
American Express).
This field is required if the

merchant would like to use
the Card Code Verification
(CCV) security feature. For
more information, please see
the Merchant Integration
Guide at
http://www.authorize.net/supp
ort/Merchant/default.htm.
Cardholder information must

be stored securely and in
accordance with the Payment
Card Industry (PCI) Data
Security Standard.
Please see the Developer

Security Best Practices White
Paper at
developerbestpractices.pdf for

AIM Developer Guide

more information.
x_trans_id Conditional The payment For more information about

gateway transaction types, see the
Required only assigned “Credit Card Transaction
for CREDIT, transaction ID Types” section of this
PRIOR_ of an original document.
AUTH_ transaction
CAPTURE,
and VOID
transactions
x_auth_code Conditional The 6 characters See the “Credit Card
authorization Transaction Types” section of
Required only code of an this document.
for original
CAPTURE_ transaction not
ONLY authorized on
transactions the payment
gateway
x_test_request Optional The request to TRUE, FALSE, Indicates if the transaction
process test T, F, should be processed as a test
transactions YES, NO, transaction.
Y, N,
See the “Test Transactions”
1, 0 section of this guide for more
information.
x_duplicate_window Optional The window of Any value between Indicates in seconds the
time after the 0 and 28800 (no window of time after a
submission of comma) transaction is submitted
a transaction during which the payment
that a duplicate gateway will check for a
transaction can duplicate transaction. The
not be maximum time allowed is 8
submitted hours (28800 seconds).
If a value less than 0 is sent,

the payment gateway will
default to 0 seconds. If a
value greater than 28800 is
sent, the payment gateway
will default to 28800. If no
value is sent, the payment
gateway will default to 2
minutes (120 seconds).
If this field is present in the

request with or without a
value, an enhanced duplicate
transaction response is sent.
See the “Response for
Duplicate Transactions”
section of this guide for more
information.

Order Information
x_invoice_num Optional The merchant Up to 20 The invoice number must be
assigned characters (no created dynamically on the
invoice number symbols) merchant server or provided
for the on a per-transaction basis.
transaction The payment gateway does
not perform this function.
x_description Optional The Up to 255 The description must be
transaction characters (no created dynamically on the
description symbols) merchant server or provided
on a per-transaction basis.
The payment gateway does
Itemized Order Information

Based on their respective business requirements, merchants may choose to submit itemized order
information with a transaction. Itemized order information is not submitted to the processor and is
not currently returned with the transaction response. This information is displayed on the
Transaction Detail page and in QuickBooks download file reports in the Merchant Interface.
Note: The value for the x_line_item field is capable of including delimited item information.
In this case, line item values must be included in the order listed below.

x_line_item Optional Any string Line item values Itemized order information.
must be delimited by
a bracketed pipe <|>
Item ID<|> Up to 31 characters The ID assigned to an
item.
<|>item name<|> Up to 31 characters A short description of an
item.
<|>item description<|> Up to 255 characters A detailed description of
an item.
<|>itemX quantity<|> Up to two decimal The quantity of an item.
places
Must be a positive
number
<|>item price (unit cost)<|> Up to two decimal Cost of an item per unit,
places excluding tax, freight, and
duty.
Must be a positive
number The dollar sign ($) is not
allowed when submitting
delimited information.
<|>itemX taxable TRUE, FALSE, Indicates whether the item
T, F, is subject to tax.
YES, NO,
Y, N,
1, 0

AIM Developer Guide
The merchant may submit up to 30 distinct line items containing itemized order information per
transaction. For example:
Sample 6. Submitting itemized order information
x_line_item=item1<|>golf balls<|><|>2<|>18.95<|>Y&x_line_item=
item2<|>golf bag<|>Wilson golf carry bag, red<|>1<|>39.99<|>Y&
x_line_item=item3<|>book<|>Golf for Dummies<|>1<|>21.99<|>Y&
Note: For Prior Authorization and Capture transactions, if line item information was
submitted with the original transaction, adjusted information may be submitted in the
event that the transaction changed. If no adjusted line item information is submitted,
the information submitted with the original transaction will apply.
Customer Information
x_first_name Optional The first name Up to 50 characters
associated with the (no symbols)
customer’s billing
address
x_last_name Optional The last name Up to 50 characters
address
x_company Optional The company Up to 50 characters
address
x_address Optional The customer’s Up to 60 characters Required if the merchant
billing address (no symbols) would like to use the
Address Verification Service
security feature.
For more information on

AVS, see the Merchant
Integration Guide at
http://www.authorize.net/sup
port/Merchant/default.htm.
x_city Optional The city of the Up to 40 characters
customer’s billing (no symbols)
address
x_state Optional The state of the Up to 40 characters
customer’s billing (no symbols) or a
address valid two-character
state code
x_zip Optional The ZIP code of the Up to 20 characters Required if the merchant
customer’s billing (no symbols) would like to use the
address Address Verification Service
security feature.
For more information on


AVS, see the Merchant
x_country Optional The country of the Up to 60 characters
address
x_phone Optional The phone number Up to 25 digits (no
associated with the letters)
address Ex. (123)123-1234
x_fax Optional The fax number Up to 25 digits (no
address Ex. (123)123-1234
x_email Optional The customer’s Up to 255 The email address to which
valid email address characters the customer’s copy of the
email receipt is sent when
Ex. Email Receipts is configured
janedoe@customer in the Merchant Interface.
.com The email is sent to the
customer only if the email
address format is valid.

Email Receipts, please see
Guide at
x_cust_id Optional The merchant Up to 20 characters The unique identifier to
assigned customer (no symbols) represent the customer
ID associated with the
transaction.
The customer ID must be

created dynamically on the
merchant server or provided
on a per-transaction basis.
The payment gateway does
x_customer_ip Optional The customer’s IP Up to 15 characters IP address of the customer
address (no letters) initiating the transaction. If
this value is not passed, it
Ex. will default to
255.255.255.255 255.255.255.255.
This field is required when

using the Fraud Detection
Suite™ (FDS) IP Address
Blocking tool. For more
information about FDS, see
Guide at

AIM Developer Guide
Shipping Information
x_ship_to_first_name Optional The first name Up to 50 characters
associated with (no symbols)
the customer’s
shipping
address
x_ship_to_last_name Optional The last name Up to 50 characters
the customer’s
shipping
address
x_ship_to_company Optional The company Up to 50 characters
the customer’s
shipping
address
x_ship_to_address Optional The customer’s Up to 60 characters
shipping (no symbols)
address
x_ship_to_city Optional The city of the Up to 40 characters
customer’s (no symbols)
shipping
address
x_ship_to_state Optional The state of the Up to 40 characters
customer’s (no symbols) or a
shipping valid two-character
address state code
x_ship_to_zip Optional The ZIP code of Up to 20 characters
the customer’s (no symbols)
shipping
address
x_ship_to_country Optional The country of Up to 60 characters
shipping
address
Additional Shipping Information (Level 2 Data)

x_tax Optional The valid tax amount When submitting The tax amount charged OR
OR delimited tax delimited tax when submitting this
information information, values information via the transaction
must be delimited request string, delimited tax
by a bracketed pipe information including the sales
<|> tax name, description, and
amount is also allowed.
The total amount of the

transaction in x_amount must
include this amount.
tax item name<|> The tax item name.
tax description<|> The tax item description.
tax amount The dollar sign ($) The tax item amount.
is not allowed when


submitting delimited The total amount of the
information. transaction in x_amount must
Example: x_tax=Tax1<|>state tax<|>0.0625&
x_freight Optional The valid freight When submitting The freight amount charged
amount OR delimited delimited freight OR when submitting this
freight information information, values information via the transaction
must be delimited request string, delimited freight
by a bracketed pipe information including the freight
<|> name, description, and amount
is also allowed.

freight item name<|> The freight item name.
freight description<|> The freight item description.
freight amount The dollar sign ($) The freight amount.
is not allowed when
Example: x_freight=Freight<|>ground overnight<|>12.95&
x_duty Optional The valid duty When submitting The duty amount charged OR
amount OR delimited delimited duty when submitting this
duty information information, values information via the transaction
must be delimited request string, delimited duty
by a pipe <|> information including the duty
name, description, and amount
is also allowed.

duty item name<|> The duty item name.
duty description<|> The duty item description.
duty amount The dollar sign ($) The duty amount.
is not allowed when
Example: x_duty=Duty1<|>export<|>15.00&
x_tax_exempt Optional The tax exempt TRUE, FALSE, Indicates whether the
status T, F, transaction is tax exempt.
YES, NO,
Y, N,
1, 0
x_po_num Optional The merchant Up to 25 characters The purchase order number
assigned purchase (no symbols) must be created dynamically
order number on the merchant server or
provided on a per-transaction
basis. The payment gateway
does not perform this function.

AIM Developer Guide
Note: Delimited duty, freight, and tax information are not returned in the transaction response or
in the merchant confirmation email. This information is displayed only on the Transaction
Detail page in the Merchant Interface.
Cardholder Authentication
The payment gateway supports the transmission of authentication fields for the following
cardholder authentication programs:
• Verified by Visa
• MasterCard® SecureCode™
Merchants using a third party cardholder authentication solution can submit the following
authentication values with Visa and/or MasterCard transactions.
Note: The cardholder authentication fields are currently supported only through the Chase
Paymentech, FDMS Nashville, Global Payments and TSYS processors for Visa and
MasterCard transactions. If cardholder authentication information is submitted for
transactions processed through any other processor, it will be ignored.

x_authentication_ Optional The electronic Please Required only for
indicator commerce indicator note that AUTH_ONLY and
(ECI) value for a Visa special AUTH_CAPTURE
transaction; or the characters transactions processed
universal cardholder included in through cardholder
authentication field this value authentication programs.
indicator (UCAF) for a must be When submitted with other
MasterCard transaction URL transaction types, this value
obtained by the encoded. is ignored.
merchant after the
authentication process. This field is currently
supported through Chase
Paymentech, FDMS
Nashville, Global Payments
and TSYS.
x_cardholder_ Optional The cardholder Please Required only for
authentication_value authentication note that AUTH_ONLY and
verification value (CAVV) special AUTH_CAPTURE
for a Visa transaction; or characters transactions processed
accountholder included in through cardholder
authentication value this value authentication programs.
(AVV)/ universal must be When submitted with other
cardholder URL transaction types, this value
authentication field encoded. is ignored.
(UCAF) for a MasterCard
transaction obtained by This field is currently
the merchant after the supported through Chase
authentication process. Paymentech, FDMS
Nashville, Global Payments
and TSYS.

Please note that invalid combinations of the x_authentication_indicator and

x_cardholder_authentication_value fields will cause the transaction to error.
Valid value combinations for these fields are as follows:
Visa
AUTHENTICATION CARDHOLDER AUTHENTICATION VALUE
INDICATOR
5 Not null
6 Not null
6 Null/Blank
7 Null/Blank
7 Not null (some international issuers may provide a CAVV
value when ECI is 7)
Null/Blank Null/Blank
MasterCard
AUTHENTICATION CARDHOLDER AUTHENTICATION VALUE
INDICATOR
0 Blank /Null
2 Not null
1 Null
Null Null
For example, when the MasterCard value for x_authentication_indicator is “1,” the value for
x_cardholder_authentication_value must be null. In this scenario, if a value is submitted for
x_cardholder_authentication_value, the transaction fails validation and is rejected.
The authentication verification value returned by Visa or MasterCard is included in the transaction
response from the payment gateway and is also included on the Transaction Detail page for the
transaction in the Merchant Interface.
Merchant-defined fields
Merchants may also choose to include merchant-defined fields to further customize the information
included with a transaction. Merchant-defined fields are any fields that are not recognized by the
payment gateway as standard application programming interface (API) fields.
For example, the merchant may want to provide a field in which customers may provide specific
shipping instructions and product color information. All you need to do is submit a custom field
name and any accompanying text with the transaction request string—for example,
shipping_instructions and product_color.
Note: Standard payment gateway fields that are misspelled are treated as merchant-defined fields.
IMPORTANT: Please avoid submitting unmasked sensitive customer information in merchant

defined fields as you are solely responsible for the security of data submitted in these fields.
Sensitive data should only be collected on secure pages.

Section 4
Transaction Response
The transaction response from the payment gateway is returned as a delimited string and provides
information about the status of a transaction—whether it was accepted or declined—as well as
information included in the transaction request.
Fields in the response are delimited by a character that is specified in the transaction request string
(x_delim_char) or configured in the Merchant Interface. The merchant server can parse this data to
customize receipt messages to display or email to the customer. Transaction results are also
provided in the payment gateway merchant confirmation email, and on the Transaction Detail page
for the transaction in the Merchant Interface.
The following fields can be used to customize the format of the payment gateway transaction
response. These settings may also be configured in the Merchant Interface. For more information
about configuring these settings in the Merchant Interface, please see the Merchant Integration
Guide at http://www.authorize.net/support/Merchant/default.htm.
x_name_of_field=value of the field&.
FIELD NAME VALUE FORMAT DESCRIPTION

x_delim_data The request to TRUE In order to receive a delimited response
receive a delimited from the payment gateway, this field must
transaction response be submitted with a value of TRUE or the
merchant has to configure a delimited
response through the Merchant Interface.
It is recommended that you submit this

field on a per-transaction basis to be sure
that transaction responses are returned in
the correct format.
x_delim_char The delimiting A single symbol The character that is used to separate
character fields in the transaction response. The
Ex. , (comma) payment gateway will use the character
| (pipe) passed in this field or the value stored in
“ (double quotes) the Merchant Interface if no value is
‘ (single quote) passed.
: (colon)
; (semicolon) If this field is passed, and the value is null,
/ (forward slash) it will override the value stored in the
\ (back slash) Merchant Interface and there is no
- (dash) delimiting character in the transaction
* (star) response.

field on a per-transaction basis to be sure

AIM Developer Guide
that transaction responses are returned in

the correct format.
x_encap_char The encapsulating A single symbol The character that is used to encapsulate
character Ex. | (pipe) the fields in the transaction response. This
“ (double quotes) is only necessary if it is possible that your
‘ (single quote) delimiting character could be included in
: (colon) any field values.
; (semicolon)
/ (forward slash) The payment gateway will use the
\ (back slash) character passed in this field or the value
- (dash) stored in the Merchant Interface if no value
* (star) is passed.
Fields in the Payment Gateway Response

The following table lists the fields returned in the response from the payment gateway.
ORDER FIELD NAME VALUE FORMAT NOTES

1 Response Code The overall status of 1 = Approved
the transaction 2 = Declined
3 = Error
4 = Held for Review
2 Response Subcode A code used by the
payment gateway
for internal
transaction tracking
3 Response Reason A code that Numeric See the “Response Code
Code represents more Details” section of this document
details about the for a listing of response reason
result of the codes.
transaction
4 Response Reason A brief description Text You can generally use this text
Text of the result, which to display a transaction result or
corresponds with error to the customer. However,
the response please review the “Response
reason code Code Details” section of this
document to identify any specific
texts you do not want to pass to
the customer.
5 Authorization Code The authorization or 6 characters
approval code
6 AVS Response The Address A = Address (Street) Indicates the result of the AVS
Verification Service matches, ZIP does filter.
(AVS) response not
code B = Address For more information about AVS,
information not see the Merchant Integration
provided for AVS Guide at
check http://www.authorize.net/support/
E = AVS error Merchant/default.htm.
G = Non-U.S. Card
Issuing Bank
N = No Match on
Address (Street) or
ZIP
P = AVS not
applicable for this

Section 4 Transaction Response

transaction
R = Retry – System
unavailable or timed
out
S = Service not
supported by issuer
U = Address
information is
unavailable
W = Nine digit ZIP
matches, Address
(Street) does not
X = Address (Street)
and nine digit ZIP
match
Y = Address (Street)
and five digit ZIP
match
Z = Five digit ZIP
matches, Address
(Street) does not
7 Transaction ID The payment When x_test_request This value must be used for any
gateway assigned is submitted, this follow on transactions such as a
identification value will be “0.” CREDIT,
number for the PRIOR_AUTH_CAPTURE or
transaction VOID.
8 Invoice Number The merchant Up to 20 characters
assigned invoice (no symbols)
number for the
transaction
9 Description The transaction Up to 255 characters
description (no symbols)
10 Amount The amount of the Up to 15 digits
transaction
11 Method The payment CC or ECHECK
method
12 Transaction Type The type of credit AUTH_CAPTURE,
card transaction AUTH_ONLY,
CAPTURE_ONLY,
CREDIT, PRIOR_
AUTH_CAPTURE,
VOID
13 Customer ID The merchant Up to 20 characters
assigned customer (no symbols)
ID
14 First Name The first name Up to 50 characters
address
15 Last Name The last name Up to 50 characters
address
16 Company The company Up to 50 characters

AIM Developer Guide

address
17 Address The customer’s Up to 60 characters
billing address (no symbols)
18 City The city of the Up to 40 characters
address
19 State The state of the Up to 40 characters
state code
20 ZIP Code The ZIP code of the Up to 20 characters
address
21 Country The country of the Up to 60 characters
address
22 Phone The phone number Up to 25 digits (no
address Ex. (123)123-1234
23 Fax The fax number Up to 25 digits (no
address Ex. (123)123-1234
24 Email Address The customer’s Up to 255 characters
valid email address
25 Ship To First Name The first name Up to 50 characters
customer’s shipping
address
26 Ship To Last Name The last name Up to 50 characters
address
27 Ship To Company The company Up to 50 characters
address
28 Ship To Address The customer’s Up to 60 characters
shipping address (no symbols)
29 Ship To City The city of the Up to 40 characters
customer’s shipping (no symbols)
address
30 Ship To State The state of the Up to 40 characters
customer’s shipping (no symbols) or a
state code
31 Ship To ZIP Code The ZIP code of the Up to 20 characters
address
32 Ship To Country The country of the Up to 60 characters


address
33 Tax The tax amount Numeric Delimited tax information is not
charged included in the transaction
response.
34 Duty The duty amount Numeric Delimited duty information is not
charged included in the transaction
response.
35 Freight The freight amount Numeric Delimited freight information is
charged not included in the transaction
response.
36 Tax Exempt The tax exempt TRUE, FALSE,
status T, F,
YES, NO,
Y, N,
1, 0
37 Purchase Order The merchant Up to 25 characters
Number assigned purchase (no symbols)
order number
38 MD5 Hash The payment Because transaction responses
gateway generated are returned via an SSL
MD5 hash value connection, this feature is not
that may be used to necessary for AIM.
authenticate the
transaction
response.
39 Card Code The card code M = Match Indicates the result of the CCV
Response verification (CCV) N = No Match filter.
response code P = Not Processed
S = Should have For more information about
been present CCV, see the Merchant
U = Issuer unable to Integration Guide at
process request http://www.authorize.net/support/
Merchant/default.htm.
40 Cardholder The cardholder Blank or not present
Authentication authentication = CAVV not
Verification verification validated
Response response code 0 = CAVV not
validated because
erroneous data was
submitted
1 = CAVV failed
validation
2 = CAVV passed
validation
3 = CAVV validation
could not be
performed; issuer
attempt incomplete
4 = CAVV validation
could not be
performed; issuer
system error
5 = Reserved for
future use
6 = Reserved for
future use

AIM Developer Guide

7 = CAVV attempt –
failed validation –
issuer available
(U.S.-issued
card/non-U.S
acquirer)
passed validation –
issuer available
(U.S.-issued
card/non-U.S.
acquirer)
failed validation –
issuer unavailable
(U.S.-issued
card/non-U.S.
acquirer)
A = CAVV attempt –
passed validation –
issuer unavailable
(U.S.-issued
card/non-U.S.
acquirer)
B = CAVV passed
validation,
information only, no
liability shift
Response for Duplicate Transactions

The AIM API allows you to specify the window of time after a transaction is submitted during
which the payment gateway checks for a duplicate transaction (based on credit card number,
invoice number, amount, billing address information, transaction type, etc.) using the duplicate
window field (x_duplicate_window). The value for this field can be between 0 and 28800 seconds
(maximum of 8 hours).
In the event that the transaction request does not include the duplicate window field, and the
payment gateway detects a duplicate transaction within the default window of 2 minutes, the
payment gateway response will contain the response code of 3 (processing error) with a response
reason code of 11 (duplicate transaction) with no additional details.
In the event that the transaction request does include the duplicate window field and value, and the
payment gateway detects a duplicate transaction within the window of time specified, the payment
gateway response for the duplicate transaction will include the response code and response reason
code listed above, as well as information about the original transaction (as outlined below).
If the original transaction was declined, and a value was passed in the duplicate window field, the
payment gateway response for the duplicate transaction will include the following information for
the original transaction:
• The AVS result

• The CCV result
• The transaction ID

If the original transaction was approved, and a value was passed in the duplicate window field, the
payment gateway response will also include the authorization code for the original transaction. All
duplicate transactions submitted after the duplicate window, whether specified in the transaction
request or after the payment gateway’s default 2 minute duplicate window, are processed normally.
Response Code Details

The following tables describe the response codes and response reason texts that are returned for
each transaction. In addition to the information in this document, the Authorize.Net Integration
Center at http://developer.authorize.net/tools/responsereasoncode provides a valuable tool for
troubleshooting errors.
• Response Code indicates the overall status of the transaction with possible values of
approved, declined, errored, or held for review.
• Response Reason Code is a numeric representation of a more specific reason for the
transaction status.
• Response Reason Text details the specific reason for the transaction status. This
information can be returned to the merchant and/or customer to provide more information
about the status of the transaction.
Response Codes
RESPONSE CODE DESCRIPTION
1 This transaction has been approved.
2 This transaction has been declined.
3 There has been an error processing this transaction.
4 This transaction is being held for review.
Response Reason Codes and Response Reason Text

RESPONSE RESPONSE RESPONSE REASON TEXT NOTES
CODE REASON
CODE
1 1 This transaction has been approved.
2 2 This transaction has been declined.
2 3 This transaction has been declined.
2 4 This transaction has been declined. The code returned from the processor
indicating that the card used needs to
be picked up.
3 5 A valid amount is required. The value submitted in the amount
field did not pass validation for a
number.
3 6 The credit card number is invalid.
3 7 The credit card expiration date is invalid. The format of the date submitted was
incorrect.
3 8 The credit card has expired.
3 9 The ABA code is invalid. The value submitted in the
x_bank_aba_code field did not pass
validation or was not for a valid

AIM Developer Guide

CODE REASON
CODE
financial institution.
3 10 The account number is invalid. The value submitted in the
x_bank_acct_num field did not pass
validation.
3 11 A duplicate transaction has been A transaction with identical amount
submitted. and credit card information was
submitted two minutes prior.
3 12 An authorization code is required but not A transaction that required
present. x_auth_code to be present was
submitted without a value.
3 13 The merchant API Login ID is invalid or
the account is inactive.
3 14 The Referrer or Relay Response URL is The Relay Response or Referrer URL
invalid. does not match the merchant’s
configured value(s) or is absent.
Applicable only to SIM and WebLink
APIs.
3 15 The transaction ID is invalid. The transaction ID value is non-
numeric or was not present for a
transaction that requires it (i.e., VOID,
PRIOR_AUTH_CAPTURE, and
CREDIT).
3 16 The transaction was not found. The transaction ID sent in was properly
formatted but the gateway had no
record of the transaction.
3 17 The merchant does not accept this type The merchant was not configured to
of credit card. accept the credit card submitted in the
transaction.
3 18 ACH transactions are not accepted by The merchant does not accept
this merchant. electronic checks.
3 19 - 23 An error occurred during processing.
Please try again in 5 minutes.
3 24 The Nova Bank Number or Terminal ID
is incorrect. Call Merchant Service
Provider.
3 25 - 26 An error occurred during processing.
Please try again in 5 minutes.
2 27 The transaction resulted in an AVS
mismatch. The address provided does
not match billing address of cardholder.
2 28 The merchant does not accept this type The Merchant ID at the processor was
of credit card. not configured to accept this card type.
2 29 The Paymentech identification numbers
are incorrect. Call Merchant Service
Provider.
2 30 The configuration with the processor is
invalid. Call Merchant Service Provider.
2 31 The FDC Merchant ID or Terminal ID is The merchant was incorrectly set up at
incorrect. Call Merchant Service the processor.
Provider.
3 32 This reason code is reserved or not
applicable to this API.
3 33 FIELD cannot be left blank. The word FIELD will be replaced by an
actual field name. This error indicates
that a field the merchant specified as


CODE REASON
CODE
required was not filled in.
2 34 The VITAL identification numbers are The merchant was incorrectly set up at
incorrect. Call Merchant Service the processor.
Provider.
2 35 An error occurred during processing. The merchant was incorrectly set up at
Call Merchant Service Provider. the processor.
3 36 The authorization was approved, but
settlement failed.
2 37 The credit card number is invalid.
2 38 The Global Payment System The merchant was incorrectly set up at
identification numbers are incorrect. Call the processor.
Merchant Service Provider.
3 40 This transaction must be encrypted.
2 41 This transaction has been declined. Only merchants set up for the
FraudScreen.Net service would
receive this decline. This code will be
returned if a given transaction’s fraud
score is higher than the threshold set
by the merchant.
3 43 The merchant was incorrectly set up at The merchant was incorrectly set up at
the processor. Call your Merchant the processor.
Service Provider.
2 44 This transaction has been declined. The card code submitted with the
transaction did not match the card
code on file at the card issuing bank
and the transaction was declined.
2 45 This transaction has been declined. This error would be returned if the
transaction received a code from the
processor that matched the rejection
criteria set by the merchant for both
the AVS and Card Code filters.
3 46 Your session has expired or does not
exist. You must log in to continue
working.
3 47 The amount requested for settlement This occurs if the merchant tries to
may not be greater than the original capture funds greater than the amount
amount authorized. of the original authorization-only
transaction.
3 48 This processor does not accept partial The merchant attempted to settle for
reversals. less than the originally authorized
amount.
3 49 A transaction amount greater than The transaction amount submitted was
$[amount] will not be accepted. greater than the maximum amount
allowed.
3 50 This transaction is awaiting settlement Credits or refunds may only be
and cannot be refunded. performed against settled transactions.
The transaction against which the
credit/refund was submitted has not
been settled, so a credit cannot be
issued.
3 51 The sum of all credits against this
transaction is greater than the original
transaction amount.
3 52 The transaction was authorized, but the
client could not be notified; the

AIM Developer Guide

CODE REASON
CODE
transaction will not be settled.
3 53 The transaction type was invalid for If x_method = ECHECK, x_type cannot
ACH transactions. be set to CAPTURE_ONLY.
3 54 The referenced transaction does not
meet the criteria for issuing a credit.
3 55 The sum of credits against the The transaction is rejected if the sum
referenced transaction would exceed the of this credit and prior credits exceeds
original debit amount. the original debit amount
3 56 This merchant accepts ACH The merchant processes eCheck.Net
transactions only; no credit card transactions only and does not accept
transactions are accepted. credit cards.
3 57 - 63 An error occurred in processing. Please
try again in 5 minutes.
2 65 This transaction has been declined. The transaction was declined because
the merchant configured their account
through the Merchant Interface to
reject transactions with certain values
for a Card Code mismatch.
3 66 This transaction cannot be accepted for The transaction did not meet gateway
processing. security guidelines.
3 68 The version parameter is invalid. The value submitted in x_version was
invalid.
3 69 The transaction type is invalid. The value submitted in x_type was
invalid.
3 70 The transaction method is invalid. The value submitted in x_method was
invalid.
3 71 The bank account type is invalid. The value submitted in
x_bank_acct_type was invalid.
3 72 The authorization code is invalid. The value submitted in x_auth_code
was more than six characters in length.
3 73 The driver’s license date of birth is The format of the value submitted in
invalid. x_drivers_license_dob was invalid.
3 74 The duty amount is invalid. The value submitted in x_duty failed
format validation.
3 75 The freight amount is invalid. The value submitted in x_freight failed
format validation.
3 76 The tax amount is invalid. The value submitted in x_tax failed
format validation.
3 77 The SSN or tax ID is invalid. The value submitted in
x_customer_tax_id failed validation.
3 78 The Card Code (CVV2/CVC2/CID) is The value submitted in x_card_code
invalid. failed format validation.
3 79 The driver’s license number is invalid. The value submitted in
x_drivers_license_num failed format
validation.
3 80 The driver’s license state is invalid. The value submitted in
x_drivers_license_state failed format
validation.
3 81 The requested form type is invalid. The merchant requested an integration
method not compatible with the AIM
API.
3 82 Scripts are only supported in version The system no longer supports version
2.5. 2.5; requests cannot be posted to
scripts.


CODE REASON
CODE
3 83 The requested script is either invalid or The system no longer supports version
no longer supported. 2.5; requests cannot be posted to
scripts.
3 91 Version 2.5 is no longer supported.
3 92 The gateway no longer supports the
requested method of integration.
3 97 This transaction cannot be accepted. Applicable only to SIM API.
Fingerprints are only valid for a short
period of time. This code indicates that
the transaction fingerprint has expired.
3 98 This transaction cannot be accepted. Applicable only to SIM API. The
transaction fingerprint has already
been used.
3 99 This transaction cannot be accepted. Applicable only to SIM API. The
server-generated fingerprint does not
match the merchant-specified
fingerprint in the x_fp_hash field.
3 100 The eCheck.Net type is invalid. Applicable only to eCheck.Net. The
value specified in the x_echeck_type
field is invalid.
3 101 The given name on the account and/or Applicable only to eCheck.Net. The
the account type does not match the specified name on the account and/or
actual account. the account type do not match the
NOC record for this account.
3 102 This request cannot be accepted. A password or Transaction Key was
submitted with this WebLink request.
This is a high security risk.
3 103 This transaction cannot be accepted. A valid fingerprint, Transaction Key, or
password is required for this
transaction.
3 104 This transaction is currently under Applicable only to eCheck.Net. The
review. value submitted for country failed
validation.
review. values submitted for city and country
failed validation.
review. value submitted for company failed
validation.
review. value submitted for bank account

AIM Developer Guide

CODE REASON
CODE
name failed validation.
review. values submitted for first name and
last name failed validation.
review. values submitted for first name and
last name failed validation.
review. value submitted for bank account
name does not contain valid
characters.
3 116 The authentication indicator is invalid. This error is only applicable to Verified
by Visa and MasterCard SecureCode
transactions. The ECI value for a Visa
transaction; or the UCAF indicator for a
MasterCard transaction submitted in
the x_authentication_indicator field is
invalid.
3 117 The cardholder authentication value is This error is only applicable to Verified
invalid. by Visa and MasterCard SecureCode
transactions. The CAVV for a Visa
transaction; or the AVV/UCAF for a
MasterCard transaction is invalid.
3 118 The combination of authentication This error is only applicable to Verified
indicator and cardholder authentication by Visa and MasterCard SecureCode
value is invalid. transactions. The combination of
authentication indicator and cardholder
authentication value for a Visa or
MasterCard transaction is invalid. For
more information, see the “Cardholder
Authentication” section of this
document.
3 119 Transactions having cardholder This error is only applicable to Verified
authentication values cannot be marked by Visa and MasterCard SecureCode
as recurring. transactions. Transactions submitted
with a value in
x_authentication_indicator and
x_recurring_billing=YES will be
rejected.
3 120 An error occurred during processing. The system-generated void for the
Please try again. original timed-out transaction failed.
(The original transaction timed out
while waiting for a response from the
authorizer.)
Please try again. original errored transaction failed. (The
original transaction experienced a
database error.)
Please try again. original errored transaction failed. (The
original transaction experienced a
processing error.)
3 123 This account has not been given the The transaction request must include
permission(s) required for this request. the API Login ID associated with the
payment gateway account.
2 127 The transaction resulted in an AVS The system-generated void for the


CODE REASON
CODE
mismatch. The address provided does original AVS-rejected transaction
not match billing address of cardholder. failed.
3 128 This transaction cannot be processed. The customer’s financial institution
does not currently allow transactions
for this account.
3 130 This payment gateway account has IFT: The payment gateway account
been closed. status is Blacklisted.
3 131 This transaction cannot be accepted at IFT: The payment gateway account
this time. status is Suspended-STA.
3 132 This transaction cannot be accepted at IFT: The payment gateway account
this time. status is Suspended-Blacklist.
2 141 This transaction has been declined. The system-generated void for the
original FraudScreen-rejected
transaction failed.
original card code-rejected and AVS-
rejected transaction failed.
3 152 The transaction was authorized, but the The system-generated void for the
client could not be notified; the original transaction failed. The
transaction will not be settled. response for the original transaction
could not be communicated to the
client.
original card code-rejected transaction
failed.
3 170 An error occurred during processing. Concord EFS – Provisioning at the
Please contact the merchant. processor has not been completed.
2 171 An error occurred during processing. Concord EFS – This request is invalid.
Please contact the merchant.
2 172 An error occurred during processing. Concord EFS – The store ID is invalid.
Please contact the merchant.
3 173 An error occurred during processing. Concord EFS – The store key is
Please contact the merchant. invalid.
2 174 The transaction type is invalid. Please Concord EFS – This transaction type is
contact the merchant. not accepted by the processor.
3 175 The processor does not allow voiding of Concord EFS – This transaction is not
credits. allowed. The Concord EFS processing
platform does not support voiding
credit transactions. Please debit the
credit card instead of voiding the
credit.
3 180 An error occurred during processing. The processor response format is
Please try again. invalid.
Please try again. original invalid transaction failed. (The
original transaction included an invalid
processor response format.)
4 193 The transaction is currently under The transaction was placed under
review. review by the risk management
system.
2 200 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. The credit
card number is invalid.

AIM Developer Guide

CODE REASON
CODE
merchants on FDC Omaha. The
expiration date is invalid.
transaction type is invalid.
merchants on FDC Omaha. The value
submitted in the amount field is invalid.
department code is invalid.
merchants on FDC Omaha. The value
submitted in the merchant number field
is invalid.
merchant is not on file.
merchant account is closed.
merchant is not on file.
merchants on FDC Omaha.
Communication with the processor
could not be established.
merchant type is incorrect.
cardholder is not on file.
merchants on FDC Omaha. The bank
configuration is not on file
merchant assessment code is
incorrect.
merchants on FDC Omaha. This
function is currently unavailable.
encrypted PIN field format is invalid.
merchants on FDC Omaha. The ATM
term ID is invalid.
transaction experienced a general
message format problem.


CODE REASON
CODE
merchants on FDC Omaha. The PIN
block format or PIN availability value is
invalid.
merchants on FDC Omaha. The ETC
void is unmatched.
primary CPU is not available.
merchants on FDC Omaha. The SE
number is invalid.
merchants on FDC Omaha. Duplicate
auth request (from INAS).
transaction experienced an unspecified
error.
merchants on FDC Omaha. Please re-
enter the transaction.
3 243 Recurring billing is not allowed for this The combination of values submitted
eCheck.Net type. for x_recurring_billing and
x_echeck_type is not allowed.
3 244 This eCheck.Net type is not allowed for The combination of values submitted
this Bank Account Type. for x_bank_acct_type and
x_echeck_type is not allowed.
3 245 This eCheck.Net type is not allowed The value submitted for
when using the payment gateway x_echeck_type is not allowed when
hosted payment form. using the payment gateway hosted
payment form.
3 246 This eCheck.Net type is not allowed. The merchant’s payment gateway
account is not enabled to submit the
eCheck.Net type.
3 247 This eCheck.Net type is not allowed. The combination of values submitted
for x_type and x_echeck_type is not
allowed.
3 248 The check number is invalid. Invalid check number. Check number
can only consist of letters and numbers
and not more than 15 characters.
2 250 This transaction has been declined. This transaction was submitted from a
blocked IP address.
2 251 This transaction has been declined. The transaction was declined as a
result of triggering a Fraud Detection
Suite filter.
4 252 Your order has been received. Thank The transaction was accepted, but is
you for your business! being held for merchant review. The
merchant may customize the customer
response in the Merchant Interface.
4 253 Your order has been received. Thank The transaction was accepted and was
you for your business! authorized, but is being held for
merchant review. The merchant may

AIM Developer Guide

CODE REASON
CODE
customize the customer response in
the Merchant Interface.
2 254 Your transaction has been declined. The transaction was declined after
manual review.
3 261 An error occurred during processing. The transaction experienced an error
Please try again. during sensitive data encryption and
was not processed. Please try again.
3 270 The line item [item number] is invalid. A value submitted in x_line_item for
the item referenced is invalid.
3 271 The number of line items submitted is The number of line items submitted
not allowed. A maximum of 30 line items exceeds the allowed maximum of 30.
can be submitted.
2 315 The credit card number is invalid. This is a processor-issued decline.
2 316 The credit card expiration date is invalid. This is a processor-issued decline.
2 317 The credit card has expired. This is a processor-issued decline.
2 318 A duplicate transaction has been This is a processor-issued decline.
submitted.
2 319 The transaction cannot be found. This is a processor-issued decline.
Note: A very helpful tool for troubleshooting errors is available in our Integration Center at
http://developer.authorize.net/tools/responsereasoncode.
Email Receipt
Merchants can opt to send a payment gateway generated email receipt to customers who provide an
email address with their transaction. The email receipt includes a summary and results of the
transaction. To the customer, this email appears to be sent from the merchant contact that is
configured as the Email Sender in the Merchant Interface. (For more information about the Email
Sender setting, please see the Merchant Integration Guide at
http://www.authorize.net/support/Merchant/default.htm.)
To send the payment gateway generated customer email receipt, the following API fields may be
submitted with the transaction request string. These settings may also be configured in the
Merchant Interface. For more information about configuring these settings in the Merchant
Interface, please see the Merchant Integration Guide at
x_name_of_field=value of the field&.

x_email The customer’s Up to 255 characters The email address to which the
valid email customer’s copy of the email
address Ex. receipt is sent when Email
janedoe@customer.com Receipts is configured in the
Merchant Interface. The email is
sent to the customer only if the

email address format is valid.
For more information about Email

Receipts, please see the Merchant
http://www.authorize.net/support/
x_email_customer The customer TRUE, FALSE, Indicates whether an email receipt
email receipt T, F, should be sent to the customer.
status YES, NO,
Y, N, If set to TRUE, the payment
gateway will send an email to the
1, 0 customer after the transaction is
processed using the customer
email address submitted with the
transaction. If FALSE, no email is
sent to the customer.
If no value is submitted, the

payment gateway will look up the
configuration in the Merchant
Interface and send an email only if
the merchant has enabled the
setting. If this field is not submitted
and the setting is disabled in the
Merchant Interface, no email is
sent.

configuring Email Receipts in the
Merchant Interface, see the
Merchant Integration Guide at
http://www.authorize.net/support/
x_header_email_receipt The email receipt Plain text This text will appear as the header
header of the email receipt sent to the
customer.
x_footer_email_receipt The email receipt Plain text This text will appear as the footer
footer on the email receipt sent to the
customer.
In addition, the merchant may receive a transaction confirmation email from the payment gateway
at the completion of each transaction, which includes order information and the results of the
transaction. Merchants can sign up for confirmation emails in the Merchant Interface. For more
information, please see the Merchant Integration Guide at

Section 5
Test Transactions
You will need to test the payment gateway integration carefully before going live to ensure
successful and smooth transaction processing.
Ideally, an integration is tested in the following phases:
• First, using an Authorize.Net developer test account. In this environment, test transactions
are posted to https://test.authorize.net/gateway/transact.dll. Although this is a staging
environment, its behavior mimics the live payment gateway. Transactions submitted to the
test environment using a developer test account are not submitted to financial institutions
for authorization and are not stored in the Merchant Interface.
In order to use this environment, you must have an Authorize.Net developer test account
with an associated API Login ID and Transaction Key. Test transactions to this
environment are accepted with these credentials only. If you do not have a developer test
account, you may sign up for one at http://developer.authorize.net.
Note: You do not need to use Test Mode when testing with a developer test account. For
more information about Test Mode, see the Merchant Integration Guide at
• Once the integration is successfully tested in the developer test environment, the
merchant’s Authorize.Net Payment Gateway API Login ID and Transaction Key may be
plugged into the integration for testing against the live environment. (Developer test
account credentials will not be accepted by the live payment gateway.) In this phase, testing
can be done in one of two ways:
o By including the x_test_request field with a value of “TRUE” in the transaction
request string to https://secure.authorize.net/gateway/transact.dll. See the
sample below.
Sample 1. Submitting the test request field
<INPUT TYPE="HIDDEN" NAME="x_test_request" VALUE="TRUE">
o By placing the merchant’s payment gateway account in Test Mode in the Merchant
Interface. New payment gateway accounts are placed in Test Mode by default. For
more information about Test Mode, see the Merchant Integration Guide at
http://www.authorize.net/support/Merchant/default.htm. Please note that when
processing test transactions in Test Mode, the payment gateway will return a
transaction ID of “0.” This means you cannot test follow-on transactions, e.g.

Section 5 Test Transactions
credits, voids, etc., while in Test Mode. To test follow-on transactions, you can
either submit x_test_request=TRUE as indicated above, or process a test
transaction with any valid credit card number in live mode, as explained below.
Note: Transactions posted against live merchant accounts using either of the above
testing methods are not submitted to financial institutions for authorization and
are not stored in the Merchant Interface.
• If testing in the live environment is successful, you are ready to submit live transactions
and verify that they are being submitted successfully. Either remove the x_test_request
field from the transaction request string or set it to “FALSE;” or if you are using Test
Mode, turn it off in the Merchant Interface. To receive a true response, you must submit a
transaction using a real credit card number. You can use any valid credit card number to
submit a test transaction. You will be able to void successful transactions immediately to
prevent live test transactions from being processed. This can be done quickly on the
Unsettled Transactions page of the Merchant Interface. It is recommended that when
testing using a live credit card, you use a nominal value, such as $0.01. That way, if you
forget to void the transaction, the impact will be minimal.
Testing to Generate Specific Transaction Results

When testing transaction results in the developer test environment as well as the production
environment, you can produce a specific response reason code by submitting a test transaction
using a test credit card number designed to generate specific transaction results: Visa test credit
card number “4222222222222.” This card number is intended for testing and should only be used
for that purpose. Submit the test transaction by either placing the account in Test Mode, or
submitting x_test_request=TRUE, with a dollar amount value equal to the response reason code
you would like to produce.
For example, to test the AVS response reason code number 27, submit the test transaction with the
credit card number “4222222222222” and the amount “27.00.”
To test the AVS or CCV responses in the live environment, you will need to submit live
transactions with correct street address, ZIP Code and Card Code information to generate
successful responses, and incorrect street address, ZIP Code and Card Code information to generate
other responses. You can void successful transactions immediately to prevent live test transactions
from being processed. This can be done quickly on the Unsettled Transactions page of the
Merchant Interface. It is not possible to test the AVS or CCV responses in the developer test
environment. For more information about AVS, see the Merchant Integration Guide at
For more information about response reason codes, see the “Transaction Response” section of this
guide.

Appendix A
Fields by Transaction Type
This appendix provides a complete listing of all API fields that should be submitted for each
transaction type supported for AIM. It is divided into the following sections:
• the minimum fields required to submit a transaction,

• additional fields that are required in order to configure advanced features of AIM
• “best practice” fields, or fields that the payment gateway recommends should be submitted
on a per-transaction basis in order to maintain a strong connection to the payment
gateway—for example, to prevent possible conflicts in the event that integration settings in
the Merchant Interface are inadvertently changed.
Minimum Required Fields

The following table provides a quick reference of all API fields that are required for each
transaction type supported for AIM.
AUTHORIZATION AUTHORIZATION PRIOR CAPTURE CREDIT VOID

AND CAPTURE ONLY AUTHORIZATION ONLY
AND CAPTURE
Merchant x_login x_login x_login x_login x_login x_login
Information x_tran_key x_tran_key x_tran_key x_tran_key x_tran_key x_tran_key
Transaction x_type = x_type = x_type = x_type = x_type = x_type =

Information AUTH_CAPTURE AUTH_ONLY PRIOR_AUTH_ CAPTURE_ CREDIT VOID
CAPTURE ONLY x_trans_id* x_trans_id
x_trans_id x_auth_code
Payment x_amount x_amount x_amount x_amount x_amount N/A

Information x_card_num x_card_num (required only x_card_num x_card_num
x_exp_date x_exp_date when less than the x_exp_date x_exp_date**
original
authorization
amount)
* For merchants enabled for expanded credit capabilities (ECC), a Transaction ID should NOT be
submitted for Unlinked Credits. For more information, see the “Credit Card Transaction Types”
section of this document.
** The expiration date is only required for Unlinked Credits.
Required Fields for Additional AIM Features

The following table provides a quick reference of additional fields that are required for advanced
features of AIM and that cannot be configured in the Merchant Interface. For example, if the
merchant wants to submit itemized order information, you must submit fields in addition to the
minimum required fields.

Appendix B Alphabetized List of API Fields

AND CAPTURE
Itemized Order x_line_item x_line_item x_line_item x_line_item x_line_item N/A
Information
Cardholder x_authentication_ x_authentication_ N/A N/A N/A N/A
Authentication indicator indicator
x_cardholder_ x_cardholder_
authentication_ authentication_
value value
Fraud x_customer_ip x_customer_ip N/A N/A N/A N/A

Detection (required only (required only
Suite™ (FDS) when the when the merchant
merchant is using is using the FDS IP
the FDS IP blocking tool)
blocking tool)
Best Practice Fields

The following table provides a quick reference of additional API fields that the payment gateway
highly recommends should be submitted on a per-transaction basis in order to maintain a strong
connection.

AND CAPTURE
Transaction x_version = 3.1 x_version = 3.1 x_version = 3.1 x_version x_version = x_version =
Information = 3.1 3.1 3.1
Transaction x_delim_data = x_delim_data = x_delim_data = x_delim_ x_delim_ x_delim_

Response TRUE TRUE TRUE data = data = data =
x_delim_char x_delim_char x_delim_char TRUE TRUE TRUE
x_encap_char x_encap_char x_encap_char x_delim_ x_delim_ x_delim_
char char char
x_relay_response x_relay_response x_relay_response =
= FALSE* = FALSE* FALSE* x_encap_ x_encap_ x_encap_
char char
char
x_relay_ x_relay_
x_relay_
response response =
response =
= FALSE* FALSE*
FALSE*
* The x_relay_response field is not technically an AIM feature; however, it is recommended that
you submit this field on a per-transaction basis with the value of “FALSE” as a best practice to
further define the AIM transaction format.

AIM Developer Guide
Appendix B
Alphabetized List of API Fields

x_address Optional The customer’s Up to 60 characters Required if the merchant would like to
billing address (no symbols) use the Address Verification Service
security feature.
For more information on AVS, see the

hant/default.htm.
x_amount Required if The amount of Up to 15 digits with The total amount to be charged or
x_type = AUTH the transaction a decimal point (no credited including tax, shipping and
_ CAPTURE, dollar symbol) any other charges. The amount may
AUTH_ONLY, either be hard coded or posted to a
CAPTURE Ex. 8.95 script.
_ONLY,
CREDIT
x_auth_code Required if The authorization 6 characters Required only for CAPTURE_ONLY
x_type = code for an transactions. See the “Credit Card
CAPTURE original Transaction Types” section of this
_ONLY transaction not document.
authorized on the
payment gateway
x_authentication_ Optional The electronic Please note that Required only for AUTH_ONLY and
indicator commerce special characters AUTH_CAPTURE transactions
indicator (ECI) included in this processed through cardholder
value for a Visa value must be URL authentication programs. When
transaction; or encoded. submitted with other transaction types,
the universal this value is ignored.
cardholder
authentication This field is currently supported
field indicator through Chase Paymentech, FDMS
(UCAF) for a Nashville, Global Payments and TSYS.
MasterCard
transaction
obtained by the
merchant after
the authentication
process.
x_card_code Optional The customer’s Must be a valid The three- or four-digit number on the
card code CVV2, CVC2 or CID back of a credit card (on the front for
value. American Express).
This field is required if the merchant

would like to use the Card Code
Verification (CCV) security feature. For
more information, please see the
hant/default.htm.
x_card_num Required if The customer’s Between 13 and 16 This is sensitive cardholder information
x_type = AUTH credit card digits without and must be stored securely and in
_CAPTURE, number spaces accordance with the Payment Card
AUTH_ONLY, Industry (PCI) Data Security Standard.


CAPTURE When
_ONLY, x_type=CREDIT, For more information about PCI,
CREDIT only the last four please see the Developer Security
digits are Best Practices White Paper at
required. http://www.authorize.net/files/develope
rbestpractices.pdf.
x_cardholder_ Optional The cardholder Please note that Required only for AUTH_ONLY and
authentication_value authentication special characters AUTH_CAPTURE transactions
verification value included in this processed through cardholder
(CAVV) for a Visa value must be URL authentication programs. When
transaction; or encoded submitted with other transaction types,
accountholder this value is ignored.
authentication
value (AVV)/ This field is currently supported
universal through Chase Paymentech, FDMS
cardholder Nashville, Global Payments and TSYS.
authentication
field (UCAF) for a
MasterCard
transaction
obtained by the
merchant after
the authentication
process.
x_city Optional The city of the Up to 40 characters
address
x_company Optional The company Up to 50 characters
the customer’s
billing address
x_country Optional The country of Up to 60 characters
billing address
x_cust_id Optional The merchant Up to 20 characters The unique identifier to represent the
assigned (no symbols) customer associated with the
customer ID transaction.
The customer ID must be created

dynamically on the merchant server or
provided on a per-transaction basis.
The payment gateway does not
perform this function.
x_customer_ip Optional The customer’s Up to 15 characters The IP address of the customer
IP address (no letters) initiating the transaction. If this value is
not passed, it will default to
Ex. 255.255.255.255.
255.255.255.255
This field is required when using the
Fraud Detection Suite™ (FDS) IP
Address Blocking tool. For more
information about FDS, see the
hant/default.htm.
x_delim_char Optional The delimiting Ex. , (comma) The character that is used to separate
character | (pipe) fields in the transaction response. The
“ (double quotes) payment gateway will use the
‘ (single quote) character passed in this field or the
: (colon) value stored in the Merchant Interface
; (semicolon) if no value is passed.
/ (forward slash)
\ (back slash) If this field is passed, and the value is
- (dash) null, it will override the value stored in

AIM Developer Guide

* (star) the Merchant Interface and there is no
delimiting character in the transaction
response.

field on a per-transaction basis to be
sure that transaction responses are
returned in the correct format.
x_delim_data Required for The request to TRUE, FALSE, In order to receive a delimited
AIM receive a T, F, response from the payment gateway,
transactions delimited YES, NO, this field must be submitted with a
transaction Y, N, value of TRUE or the merchant has to
response 1, 0 configure a delimited response through
the Merchant Interface.

field on a per-transaction basis to be
sure that transaction responses are
returned in the correct format.
x_description Optional The transaction Up to 255 (no The description must be created
description symbols) dynamically on the merchant server or
provided on a per-transaction basis.
The payment gateway does not
x_duplicate_window Optional The window of Any value between Indicates in seconds the window of
time after the 0 and 28800 (no time after a transaction is submitted
submission of a commas) during which the payment gateway will
transaction that a check for a duplicate transaction. The
duplicate maximum time allowed is 8 hours
transaction can (28800 seconds).
not be submitted
If a value less than 0 is sent, the
payment gateway will default to 0
seconds. If a value greater than 28800
is sent, the payment gateway will
default to 28800. If no value is sent,
the payment gateway will default to 2
minutes (120 seconds).
If this field is present in the request

with or without a value, an enhanced
duplicate transaction response is sent.
See the “Response for Duplicate
Transactions” section of this guide for
more information.
x_duty Optional The valid duty When submitting The duty amount charged OR when
amount OR delimited duty submitting this information via the
delimited duty information, values transaction request, delimited duty
information must be delimited information including the duty name,
by a bracketed pipe description, and amount is also
<|> allowed.
The total amount of the transaction in

x_amount must include this amount.
duty item The duty item name.
name<|>
duty The duty item description.
description<|>
duty amount The dollar sign ($) is The duty amount.
not allowed when
submitting delimited The total amount of the transaction in
information. x_amount must include this amount.
Example: x_duty=Duty1<|>export<|>15.00&


x_email Optional The customer’s Up to 255 The email address to which the
valid email characters customer’s copy of the email receipt is
address sent when Email Receipts is
Ex. configured in the Merchant Interface.
janedoe@customer. The email is sent to the customer only
com if the email address format is valid.
For more information about Email

Receipts, please see the Merchant
hant/default.htm.
x_email_customer Optional The customer TRUE, FALSE, Indicates whether an email receipt
email receipt T, F, should be sent to the customer.
status YES, NO,
Y, N, If set to TRUE, the payment gateway
1, 0 will send an email to the customer after
the transaction is processed using the
customer email address submitted with
the transaction. If FALSE, no email is
sent to the customer.
If no value is submitted, the payment

gateway will look up the configuration
in the Merchant Interface and send an
email only if the merchant has enabled
the setting. If this field is not submitted
and the setting is disabled in the
Merchant Interface, no email is sent.
For more information about configuring

Email Receipts in the Merchant
Interface, see the Merchant Integration
Guide at
hant/default.htm.
x_encap_char Optional The Ex. | (pipe) The character that is used to
encapsulating “ (double quotes) encapsulate the fields in the
character ‘ (single quote) transaction response. This is only
: (colon) necessary if it is possible that your
; (semicolon) delimiting character could be included
/ (forward slash) in any field values.
\ (back slash)
- (dash) The payment gateway will use the
* (star) character passed in this field or the
value stored in the Merchant Interface
if no value is passed.
x_exp_date Required The customer’s MMYY, This is sensitive cardholder information
credit card MM/YY, and must be stored securely and in
expiration date MM-YY, MMYYYY, accordance with the Payment Card
MM/YYYY, Industry (PCI) Data Security Standard.
MM-YYYY
rbestpractices.pdf.
x_fax Optional The fax number Up to 25 digits (no
associated with letters)
the customer’s
billing address Ex. (123)123-1234.
x_first_name Optional The first name Up to 50 characters
the customer’s
billing address

AIM Developer Guide

x_footer_email_receipt Optional The email receipt Plain text This text will appear as the footer on
footer the email receipt sent to the customer.
x_freight Optional The valid freight When submitting The freight amount charged OR when
amount OR delimited freight submitting this information via the
delimited freight information, values transaction request string, delimited
information must be delimited freight information including the freight
by a bracketed pipe name, description, and amount is also
<|> allowed.

freight item The freight item name.
name<|>
freight The freight item description.
description<|>
freight amount The dollar sign ($) is The freight item amount.
not allowed when
Example: x_freight=Freight<|>ground overnight<|>12.95&
x_header_email_receipt Optional The email receipt Plain text This text will appear as the header of
header the email receipt sent to the customer.
x_invoice_num Optional The merchant Up to 20 characters The invoice number must be created
assigned invoice (no symbols) dynamically on the merchant server or
number for the provided on a per-transaction basis.
transaction The payment gateway does not
x_last_name Optional The last name Up to 50 characters
the customer’s
billing address
x_line_item Optional Any string Line item values Itemized order information.
must be delimited
All line item by a bracketed pipe
values are <|>
required when
Item ID<|> Up to 31 characters The ID assigned to an item.
this field is
submitted <|>item name<|> Up to 31 characters A short description of an item.
<|>item Up to 255 A detailed description of an item.
description<|> characters
<|>itemX Up to two decimal The quantity of an item.
quantity<|> places
Must be a positive
number
<|>item price Up to two decimal Cost of an item per unit, excluding tax,
(unit cost)<|> places freight, and duty.
Must be a positive The dollar sign ($) is not allowed when

number submitting delimited information.
<|>itemX TRUE, FALSE, Indicates whether the item is subject to
taxable<|> T, F, tax.
YES, NO,
Y, N,
1, 0
x_login Required The merchant’s Up to 20 characters The merchant API Login ID is provided
unique API Login in the Merchant Interface.
ID



x_method Optional The payment CC or ECHECK The method of payment for the
method transaction, CC (credit card) or
ECHECK (electronic check). If left
blank, this value will default to CC.

eCheck.Net transaction requirements,
see the eCheck.Net Developer Guide
at
http://developer.authorize.net/guides/e
Check.pdf.
x_phone Optional The phone Up to 25 digits (no
number letters)
associated with
the customer’s Ex. (123)123-1234
billing address
x_po_num Optional The merchant Up to 25 characters The purchase order number must be
assigned (no symbols) created dynamically on the merchant
purchase order server or provided on a per-transaction
number basis. The payment gateway does not
x_recurring_billing Optional The recurring TRUE, FALSE, Indicates whether the transaction is a
billing status T, F, recurring billing transaction.
YES, NO,
Y, N,
1, 0
x_ship_to_address Optional The customer’s Up to 60 characters
shipping address (no symbols)
x_ship_to_company Optional The company Up to 50 characters
the customer’s
shipping address
x_ship_to_country Optional The country of Up to 60 characters
shipping address
x_ship_to_city Optional The city of the Up to 40 characters
customer’s (no symbols)
shipping address
x_ship_to_first_name Optional The first name Up to 50 characters
the customer’s
shipping address
x_ship_to_last_name Optional The last name Up to 50 characters
the customer’s
shipping address
x_ship_to_state Optional The state of the Up to 40 characters
customer’s (no symbols) or a
shipping address valid two-character
state code
x_ship_to_zip Optional The ZIP code of Up to 20 characters
shipping address
x_state Optional The state of the Up to 40 characters

AIM Developer Guide

state code
x_tax Optional The valid tax When submitting The tax amount charged OR when
amount OR the delimited tax submitting this information via the
delimited tax information, values transaction request string, delimited
information must be delimited tax information including the sales tax
by a bracketed pipe name, description, and amount is also
<|> allowed.

tax item name<|> The tax item name.
tax description<|> The tax item description.
tax amount The dollar sign ($) is The tax item amount.
not allowed when
Example: x_tax=Tax1<|>state tax<|>0.0625&
x_tax_exempt Optional The tax exempt TRUE, FALSE, Indicates whether the transaction is tax
status T, F, exempt.
YES, NO,
Y, N,
1, 0
x_test_request Optional The request to TRUE, FALSE, Indicates if the transaction should be
process test T, F, processed as a test transaction.
transactions YES, NO,
Y, N, See the “Test Transactions” section of
1, 0 this guide for more information.
x_tran_key Required for The merchant’s 16 characters The merchant Transaction Key is
merchant unique provided in the Merchant Interface and
authentication Transaction Key must be stored securely.


hant/default.htm.
x_trans_id Required when The payment Numeric Required only for CREDIT,
x_type = gateway PRIOR_AUTH_CAPTURE, and VOID
CREDIT, assigned transactions.
PRIOR_AUTH transaction ID of
_CAPTURE, the original For more information about transaction
VOID transaction types, see the “Credit Card
Transaction Types” section of this
guide.
x_type Optional The type of credit AUTH_CAPTURE If the value submitted does not match
card transaction (default), a supported value, the transaction is
AUTH_ONLY, rejected. If this field is not submitted or
CAPTURE_ONLY, the value is blank, the payment
CREDIT, gateway will process the transaction as
PRIOR_AUTH an AUTH_CAPTURE.
_CAPTURE, VOID,
x_version Optional, but The merchant’s 3.1 The transaction version represents the
highly transaction set of fields that is included with the
recommended version transaction response. 3.1 is the current
standard version.
It is highly recommended that you

submit this field on a per-transaction


basis to be sure that the formats of
transaction requests and the
responses you receive are consistent.
For more information, see the

“Appendix A Fields by Transaction
Type” section of this document.
x_zip Optional The ZIP code of Up to 20 characters Required if the merchant would like to
the customer’s (no symbols) use the Address Verification Service
billing address security feature.
For more information on AVS, see the

hant/default.htm.


Advanced Integration Method (AIM) Developer Guide: Card Not Present Transactions

Uploaded by

Copyright:

Available Formats

Advanced Integration Method (AIM) Developer Guide: Card Not Present Transactions

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Advanced Integration Method (AIM) Developer Guide: Card Not Present Transactions

Uploaded by

Copyright:

Available Formats

Advanced Integration Method (AIM)

Authorize.Net Developer Support

Authorize.Net LLC 082007 Ver.2.0

Last revised: 3/30/2009

Revision History ................................................................................ 4

Last revised: 3/30/2009

Test Transactions ........................................................................... 44

Last revised: 3/30/2009

PUBLISH DATE UPDATES

Last revised: 3/30/2009

• Collection of customer payment information through a custom application

AIM Minimum Requirements

Last revised: 3/30/2009

Payment Card Industry (PCI) Data Security Standard

Managing Integration Settings

1. Included in the transaction request on a per-transaction basis via the application

IMPORTANT: The Merchant Interface at https://secure.authorize.net is a secure Web site where

Last revised: 3/30/2009

FEATURE DESCRIPTION REQUIREMENTS

Please see the “Receipt Options” section of

Last revised: 3/30/2009

• The Integration Center at http://developer.authorize.net provides test accounts, sample

• Be sure to read our Developer Security Best Practices White Paper at

Last revised: 3/30/2009

There are two options for developing the application:

Last revised: 3/30/2009

FIELD NAME VALUE FORMAT NOTES

The API Login ID and Transaction Key

See the Merchant Integration Guide at

The API Login ID and Transaction Key

See the Merchant Integration Guide at

For more information about PCI,

Last revised: 3/30/2009

FIELD NAME VALUE FORMAT NOTES

Credit Card Transaction Types

Authorization and Capture

The unique field requirement for an Authorization and Capture is:

Last revised: 3/30/2009

The unique field requirement for an Authorization Only is:

Prior Authorization and Capture

• The transaction is submitted with the valid transaction ID (x_trans_id) of an original,

• The original transaction is not yet captured, expired or errored.

Last revised: 3/30/2009

The unique field requirements for a Capture Only are:

• The transaction is submitted with the valid transaction ID (x_trans_id) of an original,

The unique field requirements for a Credit are:

Last revised: 3/30/2009

• x_card_num=Full credit card number or last four digits only

IMPORTANT: A transaction ID must not be submitted with an Unlinked Credit. If ECC is

The unique field requirement for an Unlinked Credit is:

• The transaction is submitted with the valid transaction ID (x_trans_id) of an original,

• The original transaction is not already settled, expired or errored.

The unique field requirements for a Void are:

Last revised: 3/30/2009

Using the Merchant Interface

Last revised: 3/30/2009

Transaction Post Location

AIM Transaction Submission API

Fields are name/value pairs with the syntax of: