AIM Guide Authorizenet

Advanced Integration Method (AIM)
Implementation Guide
Card-Not-Present Transactions

Page 2 of 56

This version of AIM supports Transaction Key
Last revised: 7/11/2006
2006 Authorize.Net, a Service of Lightbridge, Inc.
Table of Contents
INTRODUCTION .......................................................................................................................... 4
ADVANCED INTEGRATION METHOD (AIM) ............................................................................. 5
What is AIM? .............................................................................................................................5
How Does AIM Work? ...............................................................................................................5
What is Required to Implement AIM? ........................................................................................5
The AIM Application Program Interface (API)............................................................................5
AIM Implementation...................................................................................................................6
Using the Merchant Interface to Configure AIM.........................................................................6
Minimum Requirements for AIM................................................................................................6
Security Considerations for AIM........................................................................................................ 7
STANDARD TRANSACTION SUBMISSION API FOR AIM........................................................ 9
Merchant Account Information...................................................................................................9
Gateway Response Configuration...........................................................................................10
Customer Name and Billing Address.......................................................................................11
Additional Customer Data........................................................................................................12
Email Settings..........................................................................................................................12
Invoice Information..................................................................................................................13
Itemized Order Information......................................................................................................13
Customer Shipping Address....................................................................................................14
Transaction Data.....................................................................................................................14
Level 2 Data.............................................................................................................................17
TRANSACTION SUBMISSION API FOR AIM WELLS FARGO SECURESOURCE
MERCHANTS............................................................................................................................. 19
Customer Name and Billing Address.......................................................................................19
Email Settings..........................................................................................................................20
Additional Customer Data........................................................................................................20
GATEWAY RESPONSE API...................................................................................................... 22
Fields in the Gateway Response.............................................................................................22
Response for Duplicate Transactions ............................................................................................. 24
AIM Transaction Response Types...........................................................................................25
Version 3.0.......................................................................................................................................... 25
Version 3.1.......................................................................................................................................... 25
Upgrading the Transaction Version................................................................................................. 25
Response Code Details...........................................................................................................25
Description of Response Fields ....................................................................................................... 25
Response Codes................................................................................................................................ 26
Response Reason Codes & Response Reason Text ..................................................................... 26
HTTP Error Codes & Reason Text.................................................................................................... 35
APPENDIX A TYPES OF CREDIT CARD TRANSACTIONS................................................. 37
Credit Card Transaction Types................................................................................................37
APPENDIX B TYPES OF ECHECK.NET TRANSACTIONS .................................................. 40
Page 3 of 56

eCheck.Net Types ...................................................................................................................40
APPENDIX C FEATURES OF THE GATEWAY..................................................................... 42
Address Verification System....................................................................................................42
Credit Card Identification Code (CVV2/CVC2/CID).................................................................43
APPENDIX D CUSTOMIZING NOTIFICATION TO CUSTOMERS ........................................ 44
APPENDIX E THE MD5 HASH SECURITY FEATURE.......................................................... 45
What is the MD5 Hash Security Feature? ...............................................................................45
How is the Signature Constructed? .........................................................................................45
How Should the Feature be Set Up on the Merchants Server?..............................................45
How is the MD5 Hash Value Set Up in the Merchant Interface? .............................................46
APPENDIX F CARDHOLDER AUTHENTICATION PROGRAMS.......................................... 47
Cardholder Authentication Validation Rules ............................................................................48
Visa...................................................................................................................................................... 49
MasterCard ......................................................................................................................................... 49
APPENDIX G SUBMITTING TEST TRANSACTIONS TO THE SYSTEM.............................. 50
Test Mode................................................................................................................................50
Running a Test Transaction ............................................................................................................. 50
Test Credit Card Numbers ................................................................................................................ 51
APPENDIX H CERTIFICATION.............................................................................................. 52
APPENDIX I CURRENCY CODES ......................................................................................... 53

Page 4 of 56

Introduction

Payment gateways facilitate electronic commerce by enabling merchants to accept credit cards
and electronic checks as methods of payment for goods and services sold online. The gateway
acts as a bridge between the merchant's Website and the financial institutions that process
payment transactions. Payment data is collected online from the shopper and submitted to the
gateway for real-time authorization.

Authorization is the process of checking the validity and available balance of a customer's credit
card before the transaction can be accepted. To authorize a given credit card transaction, the
gateway transmits the transaction information to the appropriate financial institutions for
validation, then returns the response (approved or declined) from the institution to the merchant
or customer. The payment gateway supports real-time and offline requests for credit card
authorization.

Note: The payment gateway is targeted towards merchants that process Card-Not-Present
transactions. In a Card-Not-Present transaction, the merchant and the shopper are not in
the same physical location and the customer usually calls in the payment data or keys in
the details of the credit card on a Website. All e-commerce and mail/telephone orders are
Card-Not-Present transactions.

The gateway also supports electronic check transactions. Merchants can collect customer bank
account numbers and routing numbers to pay for purchases.

This document describes how transactions can be submitted to the gateway for real-time
processing using Advanced Integration Method (AIM).

AIM is the recommended integration method for merchants who have the capability to initiate
both client and server side SSL connections. This method offers the merchant a high degree of
security and control because transaction data is submitted to the gateway over a secure server-to-
server connection that is initiated by the merchant server. Since the merchant server will receive
a response directly from the gateway, the merchant has more control over the response to the end
customer.
Page 5 of 56


What is AIM?
AIM is the recommended method of submitting transactions to the payment gateway. This
method allows a merchants server to securely connect directly to the payment gateway to submit
transaction data. The merchant retains full control of the payment data collection and the user
experience. This method requires merchants to be able to initiate and manage secure Internet
connections.

How Does AIM Work?
When using AIM, transactions flow in the following way:
1. The Customers browser connects securely to the Merchants server to transmit payment
information.
2. The Merchants server initiates a secure connection to the payment gateway and then
initiates an HTTPS post of the transaction data to the gateway server.
3. The payment gateway receives and processes the transaction data.
4. The payment gateway then generates and submits the transaction response to the
Merchants server.
5. The Merchants server receives and processes the response.
6. Finally, the Merchants server communicates the success or failure of the authorization to
the Customers browser.

What is Required to Implement AIM?
Merchants must be able to perform the following functions in order to submit transactions to the
gateway using AIM:
1. Establish a secure socket connection
2. Provide both server and client side encryption
3. Develop scripts on a Web server for the integration to the gateway (e.g., for submitting
transaction data and receiving and translating system responses)
4. Securely store a transaction key to be accessed by the script that submits the transaction
to the gateway.

The AIM Application Program Interface (API)
The Standard Transaction Submission API defines how transactions should be submitted to the
gateway using AIM. The gateway response API describes the gateways responses to
transactions submitted to the gateway. These APIs are discussed in detail in this document.

Note: The merchant will use the Merchant Interface to configure the transaction response from
the gateway. (The Merchant Interface is a tool through which merchants can manage their
accounts and transaction activity. A user login ID and password are required to access
this tool. The URL to the Merchant Interface is available to the merchant from their
merchant service provider.)

Page 6 of 56

AIM Implementation
To implement AIM, a developer would design a script that does the following:
1. Securely obtains all of the information needed to process a transaction.
2. Initiates a secure HTTPS post from their server to
https://secure.authorize.net/gateway/transact.dll. Note: Authorize.Net will only
accept transactions on port 443. This post will include all system variables mentioned in
the tables below (see the following section entitled Standard Transaction Submission
API for AIM).
3. Receives the response from the gateway and processes the response to display the
appropriate result to the end user.

Using the Merchant Interface to Configure AIM
Merchants submitting transactions via AIM can configure how the gateway should construct the
response back to the merchant server initiating the request.
By default, the response fields will be delimited with a comma. The merchant can
override the default separator and specify what character should separate the response
fields.
The response fields will not be encapsulated by default. The merchant can configure the
encapsulation character. It is recommended that the merchant override the system default
and set an encapsulation character.

The delimiting character and the encapsulation character can be set in the Merchant Interface by
doing the following (only users with the appropriate permissions will be able to access this
setting):
1. Log into the Merchant Interface
2. Select Settings from the Main Menu
3. Click Direct Response from the Transaction Response section
4. Configure the settings:
a. Set Delimited Response to Yes
b. Choose the Default Delimited Separator from the drop-down box or enter a
customized value
c. Choose the Field Encapsulation Character from the drop-down box or enter a
customized value
6. Click Submit to save changes

Minimum Requirements for AIM
The following is the minimum set of NAME/VALUE pairs that should be submitted to the
gateway when using AIM for a credit card transaction.

FIELD NAME FIELD VALUE
x_version 3.1
x_delim_data True
x_relay_response False
x_login API login ID for the payment gateway account
Page 7 of 56

x_tran_key Transaction key obtained from the Merchant Interface
x_amount Amount of purchase inclusive of tax
x_card_num Customer's card number
x_exp_date Customer's card expiration date
x_type
Type of transaction (AUTH_CAPTURE, AUTH_ONLY, CAPTURE_ONLY,
CREDIT, VOID, PRIOR_AUTH_CAPTURE

The following is the minimum set of NAME/VALUE pairs that should be submitted to the
gateway when using AIM for an eCheck.Net transaction.

FIELD NAME FIELD VALUE
x_version 3.1
x_delim_data True
x_relay_response False
x_login API login ID for the payment gateway account
x_tran_key Transaction key obtained from the Merchant Interface
x_amount Amount of purchase inclusive of tax
x_bank_aba_code ABA routing number
x_bank_acct_num Bank Account Number
x_bank_acct_type Type of Account Checking, Business Checking or Savings
x_bank_name Name of bank at which account is maintained
x_bank_acct_name Name under which the account is maintained at the bank
x_type Type of transaction (AUTH_CAPTURE, CREDIT)
x_echeck_type Type of eCheck.Net transaction (CCD, PPD, TEL, WEB)

Security Considerations for AIM
Every transaction submitted to the system using AIM should have a transaction key. The
transaction key needs to be securely stored on the merchant server and submitted with each
transaction. The gateway rejects all transactions that do not have a transaction key or that include
an invalid key. The transaction key is generated by the system and can be obtained from
Merchant Interface. To obtain the transaction key from the Merchant Interface (only users with
the appropriate permissions will be able to access this setting):

3. Click on API Login ID and Transaction Key in the Security section
4. Type in the answer to the secret question configured on setup
5. Click Submit

It is strongly recommended that the merchant periodically change the transaction key. The
merchant will have to disable the old key and generate a new key. The old key will be valid for
24 hours before it expires. To disable the old key on the Merchant Interface (only users with the
appropriate permissions will be able to access this setting):

Page 8 of 56

3. Click on Obtain Transaction Key in the Security section
4. Type in the answer to the secret question configured on setup
5. Check the box that says Disable Old Key
6. Click Submit

Note: Use only port 443 for AIM information transfers for reasons of security.
Page 9 of 56

Standard Transaction Submission API for AIM

The Standard Transaction Submission API defines the information that can be submitted to the
gateway for real-time transaction processing. The API consists of a set of fields that are required
for each transaction, and a set of fields that are optional. Under the API, the gateway accepts a
NAME/ VALUE pair. The NAME is the field name and indicates to the gateway what
information is being submitted. VALUE contains the content of the field.

The following tables contain the data fields that may be submitted to the system with any
transaction. The fields are grouped logically in the tables, based on the information submitted.
Each table contains the following information:
Field Name of the parameter that may be submitted on a transaction.
Required Indicates whether the field is required on a transaction. If Conditional,
indicates that the field is required based on the existence or value of another field. In
cases where a dependency exists, an explanation is provided.
Value Lists the possible values that may be submitted for the field. In cases where a
format is validated, an explanation is provided.
Max Length Indicates the maximum number of characters that may be supplied for each
field.
Description Provides additional details on how the field is used.

Merchant Account Information
The following fields in the API allow the system to identify the merchant submitting the
transaction and the state of the merchants account on the gateway.

FIELD REQUIRED VALUE MAX
LENGTH
DESCRIPTION
x_login Required Varies by
merchant
20 Pass the API Login ID for the
payment gateway account.
x_tran_key Required Varies by
merchant
16 Pass the transaction key
obtained from the merchant
interface.
x_version Optional

If no value is specified,
the value located in the
Transaction Version
settings within the
Merchant Interface will
be used.
2.5, 3.0, 3.1 3 Indicates to the system the set
of fields that will be included in
the response:
3.0 is the standard
version
3.1 allows the
merchant to utilize the
Card Code feature
x_test_request Optional TRUE, FALSE 5 Indicates whether the
transaction should be processed
as a test transaction. Please
refer to Appendix G for further
information on this field.

Page 10 of 56

Gateway Response Configuration
The following fields determine how a transaction response will be returned once a transaction is
submitted to the system. The merchant has the option of sending in the configuration of the
response on a per-transaction basis or configuring the response through the Merchant Interface.
Submitting values in these fields on a per-transaction basis overrides the configuration in the
Merchant Interface for that transaction. It is recommended that the values be set in the Merchant
Interface for these fields and not submitted on a per-transaction basis.

LENGTH
DESCRIPTION
x_delim_data Required

TRUE

5 In order to receive a delimited response from
the gateway, this field has to be submitted with
a value of TRUE or the merchant has to
configure a delimited response through the
Merchant Interface.
x_delim_char Optional Any valid
character
1 Character that will be used to separate fields in
the transaction response. The system will use
the character passed in this field or the value
stored in the Merchant Interface if no value is
passed.

If this field is passed, and the value is null, it
will override the value stored in the Merchant
Interface and there will be no delimiting
character in the transaction response.
x_encap_char Optional Any valid
character
1 Character that will be used to encapsulate the
fields in the transaction response.

The system will use the character passed in this
field or the value stored in the Merchant
Interface if no value is passed.
x_relay_response Required FALSE N/A Indicates whether a relay response is desired.
As all AIM transactions are direct response, a
value of FALSE is required.
x_duplicate_window Optional Any value
between 0
28,800
Indicates in seconds the window of time after a
transaction is submitted during which the
payment gateway will check for a duplicate
transaction. The maximum time allowed is 8
hours (28,800 seconds).

If a value less than 0 is sent, the payment
gateway will default to 0 seconds. If a value
greater than 28,000 sent, the payment gateway
will default to 28,000. 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 will be sent. Please see the
Page 11 of 56

LENGTH
DESCRIPTION
section of this document titled Response for
Duplicate Transactions for more information.

Customer Name and Billing Address
The customer billing address fields listed below contain information on the customer billing
address associated with each transaction.

LENGTH
DESCRIPTION
x_first_name Optional Any string 50 Contains the first name of the
customer associated with the billing
address for the transaction.
x_last_name Optional Any string 50 Contains the last name of the
x_company Optional Any string 50 Contains the company name
associated with the billing address for
the transaction.
x_address Optional Any string 60 Contains the address of the customer
the transaction.
x_city Optional Any string 40 Contains the city of the customer
the transaction.
x_state Optional

If passed, the value
will be verified.
Any valid two-
digit state code or
full state name
40 Contains the state of the customer
the transaction.
x_zip Optional Any string 20 Contains the zip of the customer
the transaction.
x_country Optional

will be verified.
Any valid two-
digit country code
or full country
name (spelled in
English)
60 Contains the country of the customer
the transaction.
x_phone Optional Any string

Recommended
format is
(123)123-1234
25 Contains the phone number of the
x_fax Optional Any string

Recommended
format is
(123)123-1234
25 Contains the fax number of the

Page 12 of 56

Additional Customer Data
Merchants may provide additional customer information with a transaction, based on their
respective requirements.

LENGTH
DESCRIPTION
x_cust_id Optional Any string 20 Unique identifier to represent the
customer associated with the
transaction.
x_customer_ip Optional

Required when
using the Fraud
Detection Suite IP
Address Blocking
tool.
Required format
is
255.255.255.255.
If this value is not
passed, it will
default to
255.255.255.255
15 IP address of the customer initiating
the transaction.
x_customer_tax_id Optional 9 digits/numbers
only
9 Tax ID or SSN of the customer
initiating the transaction.

Email Settings
The following fields describe how and when emails will be sent when transactions are processed
by the system.

LENGTH
DESCRIPTION
x_email Optional Any valid email
address
255 Email address to which the
customers copy of the confirmation
email is sent.

No email will be sent to the
customer if the email address does
not meet standard email format
checks.
x_email_customer Optional TRUE, FALSE

If no value is
submitted, system
will default to the
value configured
in the Merchant
Interface.
5 Indicates whether a confirmation
email should be sent to the
customer.
x_merchant_email Optional Any valid email
address
255 Email address to which the
merchants copy of the customer
confirmation email should be sent.
If a value is submitted, an email will
be sent to this address as well as the
address(es) configured in the
Merchant Interface.

Page 13 of 56

Invoice Information
Based on their respective requirements, merchants may submit invoice information with a
transaction. Two invoice fields are provided in the gateway API.

LENGTH
DESCRIPTION
x_invoice_num Optional Any string 20 Merchant-assigned invoice
number.
x_description Optional Any string 255 Description of the
transaction.

Itemized Order Information
Based on their respective requirements, merchants may submit itemized order information with a
transaction. Itemized order information is not submitted to the processor and is not returned with
the transaction response. This information is displayed on the Transaction Detail page in the
Merchant Interface.

LENGTH
DESCRIPTION
x_line_item Optional

Required if the order is
itemized.
Any string. Line
item values must
be delimited by
<|>.
N/A Itemized order
information.
item ID<|> Optional

itemized.
Any string 31 Item ID.
<|>item name<|> Optional

itemized.
Any string 31 Item name.
<|>item description<|> Optional

itemized.
Any string 255 Item description.
<|>itemX quantity<|> Optional

itemized
Any positive
number (two
decimal places
allowed)
N/A Item quantity.
<|>item price (unit cost)
<|>
Optional

itemized
Any positive
number (two
decimal places
allowed)
N/A Item unit price,
excluding tax, freight
and duty.

The dollar sign ($) is
not allowed when
submitting delimited
information.
<|>itemX taxable Optional

YES, NO N/A Indicates whether the
item is taxable.
Page 14 of 56

LENGTH
DESCRIPTION
itemized

The merchant may submit up to 30 line items containing itemized order information per
transaction. For example:

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_Auth_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 Shipping Address
The following fields describe the customer shipping information that may be submitted with
each transaction.

LENGTH
DESCRIPTION
x_ship_to_first_name Optional Any string 50 Contains the customer
shipping first name.
x_ship_to_last_name Optional Any string 50 Contains the customer
shipping last name.
x_ship_to_company Optional Any string 50 Contains the customer
shipping company.
x_ship_to_address Optional Any string 60 Contains the customer
shipping address.
x_ship_to_city Optional Any string 40 Contains the customer
shipping city.
x_ship_to_state Optional

will be verified.
Any valid two-
digit state code or
full state name
40 Contains the customer
shipping state.
x_ship_to_zip Optional Any string 20 Contains the customer
shipping zip.
x_ship_to_country Optional

will be verified.
Any valid two-
digit country code
or full country
name (spelled in
English)
60 Contains the customer
shipping country.

Transaction Data
The following fields contain transaction-specific information such as amount, payment method,
and transaction type.
Page 15 of 56


LENGTH
DESCRIPTION
x_amount Required Any amount 15 Total value to be charged
or credited inclusive of tax.
x_currency_code Optional Valid currency
code

3 Currency of the transaction
amount. If left blank, this
value will default to the
value specified in the
Merchant Interface. See
Appendix I for other
values.
x_method Required CC, ECHECK N/A Indicates the method of
payment for the transaction
being sent to the system. If
left blank, this value will
default to CC.
x_type Required AUTH_CAPTUR
E, AUTH_ONLY,
CAPTURE_ONL
Y, CREDIT,
VOID,
PRIOR_AUTH_C
APTURE

N/A Indicates the type of
transaction. If the value in
the field does not match
any of the values stated, the
transaction will be rejected.

If no value is submitted in
this field, the gateway will
process the transaction as
an AUTH_CAPTURE

x_recurring_billing Optional

Required if
x_echeck_type =
WEB
YES, NO 3 Indicates whether the
transaction is a recurring
billing transaction.
x_bank_aba_code Conditional

Required if
x_method =
ECHECK
Valid routing
number
9 Routing number of a bank
for eCheck.Net
transactions.
x_bank_acct_num Conditional

Required if
x_method =
ECHECK
Valid account
number
20 Checking or savings
account number.
x_bank_acct_type Conditional

Required if
x_method =
ECHECK
CHECKING,
BUSINESSCHEC
KING, SAVINGS
Describes the type of bank
account; if no value is
provided, default is set to
CHECKING.
x_bank_name Conditional

Required if
x_method =
Valid bank name 50 Contains the name of the
customers financial
institution.
Page 16 of 56

LENGTH
DESCRIPTION
ECHECK
x_bank_acct_name Conditional

Required if
x_method =
ECHECK
Name on the
customers bank
account
Is the customers name as
it appears on their bank
account.
x_echeck_type Conditional

Required if
x_method =
ECHECK
CCD, PPD, TEL,
WEB
Indicates the type of
eCheck.Net payment
request. If left blank, the
default when
x_bank_acct_type =
CHECKING or SAVINGS
is WEB. The default when
x_bank_acct_type =
BUSINESSCHECKING is
CCD.

See Appendix B for details
on eCheck.Net types.
x_card_num Conditional

Required if
x_method =CC
Numeric credit
card number
22 Contains the credit card
number.
x_exp_date Conditional

Required if
x_method =CC
MMYY,
MM/YY,
MM-YY,
MMYYYY,
MM/YYYY,
MM-YYYY,
YYYY-MM-DD,
YYYY/MM/DD
N/A Contains the date on which
the credit card expires.
x_card_code Optional Valid CVV2,
CVC2 or CID
value
4 Three- or four-digit
number on the back of a
credit card (on front for
American Express).
x_trans_id Conditional

Required if x_type =
CREDIT,
VOID, or
PRIOR_AUTH_CA
PTURE
Valid transaction
ID
10 ID of a transaction
previously authorized by
the gateway.
x_auth_code Conditional

Required if x_type =
CAPTURE_ONLY
Valid
authorization code
6 Authorization code for a
previous transaction not
authorized on the gateway
that is being submitted for
capture.
x_authentication_indicator Optional

Required only for
Valid ECI or
UCAF indicator
value (obtained by
N/A The electronic commerce
indicator (ECI) value for a
Visa transaction; or the
Page 17 of 56

LENGTH
DESCRIPTION
AUTH_ONLY and
AUTH_CAPTURE
transactions
processed through
cardholder
authentication
programs. When
submitted with other
transaction types,
this value is ignored.
the merchant after
the authentication
process).
universal cardholder
authentication field
indicator (UCAF for a
MasterCard transaction.

This field is currently
supported through FDC
Nashville and Vital.

This field is also supported
by Wells Fargo
SecureSource for Visa
transactions only.
x_cardholder_
authentication_value
Optional

Required only for
AUTH_ONLY and
AUTH_CAPTURE
transactions
processed through
cardholder
authentication
programs. When
transaction types,
Valid CAVV,
AVV, or UCAF
value (obtained by
the merchant after
the authentication
process).
N/A The cardholder
authentication verification
value (CAVV) for a Visa
transaction; or
accountholder
authentication value
(AVV)/ universal
cardholder authentication
field (UCAF) for a


by Wells Fargo
transactions only.

Level 2 Data
The system supports Level 2 transaction data by providing the following fields as part of the
transaction submission API. The tax, freight, and duty fields allow a delimited string for
submitting extended information.

LENGTH
DESCRIPTION
x_po_num Optional Any string 25 Contains the purchase
order number.
x_tax Optional Any valid tax amount
OR
the following
delimited values:
tax item name <|>
tax description<|>
tax amount
N/A Contains the sales tax
amount OR delimited tax
information including the
sales tax name, description,
and amount.

The dollar sign ($) is not
Page 18 of 56

LENGTH
DESCRIPTION
allowed when submitting
delimited information.
x_tax_exempt Optional TRUE, FALSE 5 Indicates whether the
transaction is tax exempt.
x_freight Optional Any valid freight
amount
OR
the following
delimited values:
freight item name <|>
freight description<|>
freight amount
N/A Contains the freight
amount charged OR
delimited freight
information including the
freight name, description,
and amount.

extended information.
x_duty Optional Any valid duty amount
OR
the following
delimited values:
duty item name <|>
duty description<|>
duty amount
N/A Contains the amount
charged for duty OR
delimited duty information
including the duty name,
description, and amount.

extended information.

Note: For Prior_Auth_Capture transactions, if extended tax, freight, and/or duty information
was submitted with the original transaction, adjusted information may be submitted in the
event that the transaction amount changed. If no adjusted tax, freight, and/or duty
information is submitted, the information submitted with the original transaction will
apply.

Page 19 of 56

Transaction Submission API for AIM Wells Fargo
SecureSource Merchants

For merchants who process transactions through the Wells Fargo SecureSource product, some
additional rules apply to transaction processing. Fields that are optional in the standard gateway
API are required for Wells Fargo SecureSource merchants. The following tables describe these
required fields. Only those fields that are different from the standard API are called out in this
section.

Customer Name and Billing Address

LENGTH
DESCRIPTION
x_first_name Required Any string 50 Contains the first name of
the customer associated
with the billing address for
the transaction.
x_last_name Required Any string 50 Contains the last name of
the transaction.
x_company Required Any string 50 Contains the company
name associated with the
billing address for the
transaction.
x_address Required Any string 60 Contains the address of
the transaction.
x_city Required Any string 40 Contains the city of the
customer associated with
the billing address for the
transaction.
x_state Required Any valid two-
digit state code or
full state name
40 Contains the state of the
transaction.
x_zip Required Any string 20 Contains the zip of the
transaction.
x_country Required Any valid two-
digit country code
or full country
name (spelled in
English)
60 Contains the country of
the transaction.
x_phone Required Any string

25 Contains the phone
number of the customer
Page 20 of 56

LENGTH
DESCRIPTION
Recommended
format is
(123)123-1234
associated with the billing

Email Settings

LENGTH
DESCRIPTION
x_email Required Any valid email
address
255 Email address to which a
confirmation email is sent.

Additional Customer Data

LENGTH
DESCRIPTION
x_customer_ip Required Required format is
255.255.255.255.
If this value is not
passed, it will
default to
255.255.255.255
15 IP address of the customer
initiating the transaction.
x_customer_organization_t
ype
Required I, B
I =Individual
B =Business
N/A Required for all eCheck
transactions for Wells
Fargo SecureSource
Merchants.
x_customer_tax_id Conditional

IF x_type =
ECHECK, merchant
must provide
EITHER
x_customer_tax_id
OR
x_drivers_license_n
um AND
x_drivers_license_st
ate AND
x_drivers_license_D
OB
9 digits or
numbers only
9 Tax ID or SSN of the
customer initiating the
transaction. If the Tax ID
or SSN is not available, the
customers drivers license
number, drivers license
state and date of birth must
be used in its place.
x_drivers_license_num Conditional

IF x_type =
ECHECK, merchant
must provide
EITHER
x_customer_tax_id
OR
x_drivers_license_n
50 Required for all eCheck
Fargo SecureSource
Merchants where the Tax
ID or SSN is not provided.
Page 21 of 56

LENGTH
DESCRIPTION
um AND
ate AND
x_drivers_license_d
ob
x_drivers_license_state Conditional

IF x_type =
ECHECK, merchant
must provide
EITHER
x_customer_tax_id
OR
x_drivers_license_n
um AND
ate AND
x_drivers_license_d
ob
2-character state
abbreviation
2 Required for all eCheck
Fargo SecureSource
x_drivers_license_dob Conditional

IF x_type =
ECHECK, merchant
must provide
EITHER
x_customer_tax_id
OR
x_drivers_license_n
um AND
ate AND
x_drivers_license_d
ob
YYYY-MM-
DDD,
YYYY/MM/DD,
MM/DD/YYYY,
MM-DD-YYYY,
N/A Required for all eCheck
Fargo SecureSource

Page 22 of 56

Gateway Response API

This section describes the response returned by the gateway when a merchant server submits a
transaction for processing. The response is a set of fields that give merchants information about
the status of a transaction. The fields will be comma delimited by default or delimited by the
character specified by the merchant. The merchant server can parse this data and determine the
message to display to the customer.

Fields in the Gateway Response
The following table indicates the order of the fields returned in the AIM response from the
gateway to the merchant server.

POSITION IN
RESPONSE
FIELD NAME OF
VALUE IN
RESPONSE
DESCRIPTION
1 Response Code Indicates the result of the transaction:
1 = Approved
2 = Declined
3 = Error
2 Response Subcode A code used by the system for internal transaction tracking.
3 Response Reason Code A code representing more details about the result of the transaction.
4 Response Reason Text Brief description of the result, which corresponds with the Response
Reason Code.
5 Approval Code The six-digit alphanumeric authorization or approval code.
6 AVS Result Code Indicates the result of Address Verification System (AVS) checks:
A = Address (Street) matches, ZIP does not
B = Address information not provided for AVS check
E = AVS error
G = Non-U.S. Card Issuing Bank
N = No Match on Address (Street) or ZIP
P = AVS not applicable for this transaction
R = Retry System unavailable or timed out
S = Service not supported by issuer
U = Address information is unavailable
W = 9 digit ZIP matches, Address (Street) does not
X = Address (Street) and 9 digit ZIP match
Y = Address (Street) and 5 digit ZIP match
Z = 5 digit ZIP matches, Address (Street) does not
7 Transaction ID This number identifies the transaction in the system and can be used
to submit a modification of this transaction at a later time, such as
voiding, crediting or capturing the transaction.
8 Invoice Number Echoed from input value for x_invoice_num.
9 Description Echoed from input value for x_description.
10 Amount Echoed from input value for x_amount.
11 Method Echoed from input value for x_method.
12 Transaction Type Echoed from input value for x_type.
13 Customer ID Echoed from input value for x_cust_id.
Page 23 of 56

POSITION IN
RESPONSE
FIELD NAME OF
VALUE IN
RESPONSE
DESCRIPTION
14 Cardholder First Name Echoed from input value for x_first_name.
15 Cardholder Last Name Echoed from input value for x_last_name.
16 Company Echoed from input value for x_company.
17 Billing Address Echoed from input value for x_address.
18 City Echoed from input value for x_city.
19 State Echoed from input value for x_state.
20 Zip Echoed from input value for x_zip.
21 Country Echoed from input value for x_country.
22 Phone Echoed from input value for x_phone.
23 Fax Echoed from input value for x_fax.
24 Email Echoed from input value for x_email.
25 Ship to First Name Echoed from input value for x_ship_to_first_name.
26 Ship to Last Name Echoed from input value for x_ship_to_last_name.
27 Ship to Company Echoed from input value for x_ship_to_company.
28 Ship to Address Echoed from input value for x_ship_to_address.
29 Ship to City Echoed from input value for x_ship_to_city.
30 Ship to State Echoed from input value for x_ship_to_state.
31 Ship to Zip Echoed from input value for x_ship_to_zip.
32 Ship to Country Echoed from input value for x_ship_to_country.
33 Tax Amount Echoed from input value for x_tax.
34 Duty Amount Echoed from input value for x_duty.
35 Freight Amount Echoed from input value for x_freight.
36 Tax Exempt Flag Echoed from input value for x_tax_exempt.
37 PO Number Echoed from input value for x_po_num.
38 MD5 Hash System-generated hash that may be validated by the merchant to
authenticate a transaction response received from the gateway.
39 Card Code
(CVV2/CVC2/CID)
Response Code
Indicates the results of Card Code verification:
M = Match
N = No Match
P = Not Processed
S = Should have been present
U = Issuer unable to process request
40 Cardholder
Authentication
Verification Value
(CAVV) Response Code
Indicates the results of cardholder authentication verification:
Blank or not present = CAVV not validated
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
7 = CAVV attempt failed validation issuer available (U.S.-
issued card/non-U.S acquirer)
Page 24 of 56

POSITION IN
RESPONSE
FIELD NAME OF
VALUE IN
RESPONSE
DESCRIPTION
8 = CAVV attempt passed validation issuer available (U.S.-
issued card/non-U.S. acquirer)
9 = CAVV attempt 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
41 - 68 Reserved for future use.

69 -
Echo of merchant-defined fields.

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. To use this functionality, you
must pass the Duplicate Window (x_duplicate_window) field with a value between 0 to 28,800
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 system default window of 2 minutes,
the gateway response will contain the response code of 3 (processing error) with a 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
gateway response for the duplicate transaction will also include 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 Code result
The Card Code result
The Transaction ID
The MD5 Hash (if this feature was used for the original transaction)

If the original transaction was approved, and a value was passed in the Duplicate Window field,
the 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 default 2 minute duplicate window, will be processed
normally.
Page 25 of 56


AIM Transaction Response Types
There are two versions of the AIM response string:

Version 3.0
The version 3.0 response contains system fields from position 1 to 38 and echoes merchant
defined fields from 39 on, in the order received by the system. Version 3.0 is the Payment
Gateway default.

Version 3.1
The version 3.1 response string contains 68 system fields with field number 39 representing the
Card Code (CVV2/CVC2/CID) response code. Merchant-defined fields are echoed from field 69
on. Merchants wishing to use the Card Code feature must use transaction version 3.1.

Upgrading the Transaction Version
To upgrade the transaction version, do the following (only users with the appropriate permissions
will be able to access this setting):
3. Click on Transaction Version in the Transaction Response section
4. Change the Transaction Version by using the drop-down box

Note: You can only upgrade to a higher transaction version. You cannot set your transaction
version to a previous version.

Response Code Details
When a payment transaction is submitted to the gateway, the gateway returns a response that
indicates the general status of the transaction, including details of what caused the transaction to
be in that state. The fields in the response that describe the status of the transaction are Response
Code, Response Reason Code, and Response Reason Text. The following tables define the
values that the gateway may return in these fields.

Description of Response Fields
The three status fields in the transaction response are defined as follows:
The Response Code indicates the overall status of the transaction with possible values of
approval, decline, or error.
The Response Reason Code gives merchants more information about the transaction
status.
The Response Reason Text is a text string that will give more detail on why the
transaction resulted in a specific response code. This field is a text string that can be
echoed back to the customer to provide them with more information about their
transaction. It is strongly suggested that merchants not parse this string expecting certain
text. Instead, a merchant should test for the Response Reason Code if they need to
Page 26 of 56

programmatically know these results; the Response Reason Code will always represent
these meanings, even if the text descriptions change.

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 & Response Reason Text

RESPONSE
CODE
RESPONSE
REASON
CODE
RESPONSE REASON TEXT NOTES
1 1 This transaction has been
approved.

declined.

declined.

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 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
submitted.
A transaction with identical amount and credit
card information was submitted two minutes
prior.
3 12 An authorization code is required
but not present.
A transaction that required 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 invalid.
The Relay Response or Referrer URL does not
match the merchants 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.,
Page 27 of 56

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 of credit card.
The merchant was not configured to accept the
credit card submitted in the transaction.
3 18 ACH transactions are not
accepted by this merchant.
The merchant does not accept electronic checks.
3 19 An error occurred during
processing. Please try again in 5
minutes.

minutes.

minutes.

minutes.

minutes.

3 24 The Nova Bank Number or
Terminal ID is incorrect. Call
Merchant Service Provider.

minutes.

minutes.

2 27 The transaction resulted in an
AVS mismatch. The address
provided does not match billing
address of cardholder.

3 28 The merchant does not accept this
type of credit card.
The Merchant ID at the processor was not
configured to accept this card type.
3 29 The PaymentTech identification
numbers are incorrect. Call

3 30 The configuration with the
processor is invalid. Call

3 31 The FDC Merchant ID or
Terminal ID is incorrect. Call
The merchant was incorrectly set up at the
processor.
3 32 This reason code is reserved or
not applicable to this API.

Page 28 of 56

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 required was not filled in.
3 34 The VITAL identification
numbers are incorrect. Call
processor.
processing. Call Merchant
Service Provider.
processor.
3 36 The authorization was approved,
but settlement failed.

3 37 The credit card number is invalid.
3 38 The Global Payment System
identification numbers are
incorrect. Call Merchant Service
Provider.
processor.
3 39 The supplied currency code is
either invalid, not supported, not
allowed for this merchant or
doesnt have an exchange rate.

3 40 This transaction must be
encrypted.

declined.
Only merchants set up for the FraudScreen.Net
service would receive this decline. This code
will be returned if a given transactions fraud
score is higher than the threshold set by the
merchant.
3 42 There is missing or invalid
information in a required field.
This is applicable only to merchants processing
through the Wells Fargo SecureSource product
who have requirements for transaction
submission that are different from merchants not
processing through Wells Fargo.
3 43 The merchant was incorrectly set
up at the processor. Call your
processor.
declined.
The merchant would receive this error if the
Card Code filter has been set in the Merchant
Interface and the transaction received an error
code from the processor that matched the
rejection criteria set by the merchant.
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 may not be greater
than the original amount
authorized.
This occurs if the merchant tries to capture funds
greater than the amount of the original
authorization-only transaction.
Page 29 of 56

3 48 This processor does not accept
partial reversals.
The merchant attempted to settle for less than
the originally authorized amount.
3 49 A transaction amount greater than
$99,999 will not be accepted.

3 50 This transaction is awaiting
settlement and cannot be
refunded.
Credits or refunds may only be 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 transaction will not
be settled.

3 53 The transaction type was invalid
for ACH transactions.
If x_method =ECHECK, x_type cannot 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
referenced transaction would
exceed the original debit amount.
The transaction is rejected if the sum of this
credit and prior credits exceeds the original debit
amount.
3 56 This merchant accepts ACH
transactions only; no credit card
transactions are accepted.
The merchant processes eCheck transactions
only and does not accept credit cards.
3 57 An error occurred in processing.
Please try again in 5 minutes.







3 64 The referenced transaction was
not approved.
This error is applicable to Wells Fargo
SecureSource merchants only. Credits or refunds
cannot be issued against transactions that were
not authorized.
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 processing.
The transaction did not meet gateway security
guidelines.
Page 30 of 56

3 67 The given transaction type is not
supported for this merchant.
This error code is applicable to merchants using
the Wells Fargo SecureSource product only.
This product does not allow transactions of type
CAPTURE_ONLY.
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 drivers license date of birth
is invalid.
The format of the value submitted in
x_drivers_license_num 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 invalid.
The value submitted in x_card_code failed
format validation.
3 79 The drivers license number is
invalid.
The value submitted in x_drivers_license_num
failed format validation.
3 80 The drivers 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 2.5.
The system no longer supports version 2.5;
requests cannot be posted to scripts.
3 83 The requested script is either
invalid or no longer supported.
The system no longer supports version 2.5;
requests cannot be posted to scripts.







3 91 Version 2.5 is no longer
supported.

Page 31 of 56

3 92 The gateway no longer supports
the requested method of
integration.

3 93 A valid country is required. This code is applicable to Wells Fargo
SecureSource merchants only. Country is a
required field and must contain the value of a
supported country.
3 94 The shipping state or country is
invalid.
This code is applicable to Wells Fargo
SecureSource merchants only.
3 95 A valid state is required. This code is applicable to Wells Fargo
3 96 This country is not authorized for
buyers.
SecureSource merchants only. Country is a
required field and must contain the value of a
supported country.
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.
accepted.
Applicable only to SIM API. The transaction
fingerprint has already been used.
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 type is invalid. Applicable only to eCheck. The value specified
in the x_echeck_type field is invalid.
3 101 The given name on the account
and/or the account type does not
match the actual account.
Applicable only to eCheck. The specified name
on the account and/or 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.
accepted.
A valid fingerprint, transaction key, or password
is required for this transaction.
3 104 This transaction is currently
under review.
Applicable only to eCheck. The value submitted
for country failed validation.
under review.
Applicable only to eCheck. The values
submitted for city and country failed validation.
under review.
for company failed validation.
under review.
for bank account name failed validation.
under review.
submitted for first name and last name failed
validation.
under review.
submitted for first name and last name failed
validation.
3 110 This transaction is currently Applicable only to eCheck. The value submitted
Page 32 of 56

under review. for bank account name does not contain valid
characters.
3 111 A valid billing country is
required.
3 112 A valid billing state/province is
required.
3 116 The authentication indicator is
invalid.
This code is applicable only to merchants that
include the x_authentication_indicator in the
transaction request. 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 invalid.
include the x_cardholder_authentication_value
in the transaction request. The CAVV for a Visa
transaction; or the AVV/UCAF for a MasterCard
transaction is invalid.
3 118 The combination of
authentication indicator and
cardholder authentication value is
invalid.
include the x_authentication_indicator and
x_authentication_value in the transaction
request. The combination of authentication
indicator and cardholder authentication value for
a Visa or MasterCard transaction is invalid.
3 119 Transactions having cardholder
authentication values cannot be
marked as recurring.
include the x_authentication_indicator and
x_recurring_billing in the transaction request.
Transactions submitted with a value in
x_authentication_indicator AND
x_recurring_billing =YES will be rejected.
processing. Please try again.
The system-generated void for the original
timed-out transaction failed. (The original
transaction timed out while waiting for a
response from the authorizer.)
errored transaction failed. (The original
transaction experienced a database error.)
errored transaction failed. (The original
transaction experienced a processing error.)
3 123 This account has not been given
the permission(s) required for this
request.
The transaction request must include the API
login ID associated with the payment gateway
account.
2 127 The transaction resulted in an
AVS mismatch. The address
provided does not match billing
address of cardholder.
The system-generated void for the original AVS-
rejected transaction failed.
processed.
The customer's financial institution does not
currently allow transactions for this account.
3 130 This payment gateway account
has been closed.
IFT: The payment gateway account status is
Blacklisted.
3 131 This transaction cannot be IFT: The payment gateway account status is
Page 33 of 56

accepted at this time. Suspended-STA.
accepted at this time.
IFT: The payment gateway account status is
Suspended-Blacklist.
declined.
FraudScreen-rejected transaction failed.
declined.
The system-generated void for the original card
code-rejected and AVS-rejected transaction
failed.
2 152 The transaction was authorized,
but the client could not be
notified; the transaction will not
be settled.
transaction failed. The response for the original
transaction could not be communicated to the
client.
declined.
The system-generated void for the original card
code-rejected transaction failed.
processing. Please contact the
merchant.
Concord EFS Provisioning at the processor has
not been completed.
merchant.
Concord EFS This request is invalid.
merchant.
Concord EFS The store ID is invalid.
merchant.
Concord EFS The store key is invalid.
3 174 The transaction type is invalid.
Please contact the merchant.
Concord EFS This transaction type is not
accepted by the processor.
3 175 The processor does not allow
voiding of credits.
Concord EFS This transaction is not allowed.
The Concord EFS processing platform does not
support voiding credit transactions. Please debit
the credit card instead of voiding the credit.
The processor response format is invalid.
invalid transaction failed. (The original
transaction included an invalid processor
response format.)

4 193 The transaction is currently under
review.
The transaction was placed under review by the
risk management system.
declined.
This error code applies only to merchants on
FDC Omaha. The credit card number is invalid.
declined.
FDC Omaha. The expiration date is invalid.
declined.
FDC Omaha. The transaction type is invalid.
declined.
FDC Omaha. The value submitted in the amount
Page 34 of 56

field is invalid.
declined.
FDC Omaha. The department code is invalid.
declined.
FDC Omaha. The value submitted in the
merchant number field is invalid.
declined.
FDC Omaha. The merchant is not on file.
declined.
FDC Omaha. The merchant account is closed.
declined.
FDC Omaha. The merchant is not on file.
declined.
FDC Omaha. Communication with the processor
could not be established.
declined.
FDC Omaha. The merchant type is incorrect.
declined.
FDC Omaha. The cardholder is not on file.
declined.
FDC Omaha. The bank configuration is not on
file
declined.
FDC Omaha. The merchant assessment code is
incorrect.
declined.
FDC Omaha. This function is currently
unavailable.
declined.
FDC Omaha. The encrypted PIN field format is
invalid.
declined.
FDC Omaha. The ATM term ID is invalid.
declined.
FDC Omaha. This transaction experienced a
general message format problem.
declined.
FDC Omaha. The PIN block format or PIN
availability value is invalid.
declined.
FDC Omaha. The ETC void is unmatched.
declined.
FDC Omaha. The primary CPU is not available.
declined.
FDC Omaha. The SE number is invalid.
declined.
FDC Omaha. Duplicate auth request (from
INAS).
2 223 This transaction has been This error code applies only to merchants on
Page 35 of 56

declined. FDC Omaha. This transaction experienced an
unspecified error.
declined.
FDC Omaha. Please re-enter the transaction.
3 243 Recurring billing is not allowed
for this eCheck.Net type.
The combination of values submitted for
x_recurring_billing and x_echeck_type is not
allowed.
3 244 This eCheck.Net type is not
allowed for this Bank Account
Type.
The combination of values submitted for
x_bank_acct_type and x_echeck_type is not
allowed.
allowed when using the payment
gateway hosted payment form.
The value submitted for x_echeck_type is not
allowed when using the payment gateway hosted
payment form.
allowed.
The merchants payment gateway account is not
enabled to submit the eCheck.Net type.
allowed.
The combination of values submitted for x_type
and x_echeck_type is not allowed.
declined.
This transaction was submitted from a blocked
IP address.

declined.
The transaction was declined as a result of
triggering a Fraud Detection Suite filter.
4 252 Your order has been received.
Thank you for your business!
The transaction was accepted, but is being held
for merchant review. The merchant may
customize the customer response in the
Merchant Interface.
4 253 Your order has been received.
Thank you for your business!
The transaction was accepted and was
authorized, but is being held for merchant
review. The merchant may customize the
customer response in the Merchant Interface.
2 254 Your transaction has been
declined.
The transaction was declined after manual
review.
The transaction experienced an error 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 not allowed. A
maximum of 30 line items can be
submitted.
The number of line items submitted in
x_line_item exceeds the allowed maximum of
30.

Note: Response code reasons that are not included in numerical order are reserved, or may not
be applicable to this API.

HTTP Error Codes & Reason Text

HTTP CODE RESPONSE REASON TEXT NOTES
503 Our servers are currently too busy to handle The payment gateway has momentarily reached
Page 36 of 56

your request. Please wait a minute and
resubmit. Thank you.
transaction queuing capacity.
Page 37 of 56

Appendix A Types of Credit Card Transactions

There are two steps to credit card transaction processing:
1. Authorization is the process of checking the validity and available balance of a
customer's credit card before the transaction is accepted. The transaction submission
methods describe the request for authorization.
2. Settlement, also referred to as Capture, is the process by which the funds are actually
transferred from the customer to the merchant for goods and services sold. Based on the
transaction type specified in the authorization request, the gateway will initiate the
settlement step. As part of the settlement process, the gateway will send a settlement
request to the financial institution to request transfer of funds. Please note that the
timeframe within which funds are actually transferred is not controlled by the gateway.

Note: The merchant can specify when the last transaction is picked up for settlement by
the gateway. To modify the Transaction Cut-Off Time, do the following (only
users with the appropriate permissions will be able to access this setting):
2. Select Settings
3. Select Transaction Cut-Off Time from the General section
4. Using the drop-down boxes, select the desired cut-off time

Credit Card Transaction Types
The following table describes the type of transactions that can be submitted to the gateway and
how the gateway will process them.

TRANSACTION TYPE DESCRIPTION
AUTH_CAPTURE Transactions of this type will be sent for authorization. The transaction will be
automatically picked up for settlement if approved. This is the default transaction
type in the gateway. If no type is indicated when submitting transactions to the
gateway, the gateway will assume that the transaction is of the type
AUTH_CAPTURE.
AUTH_ONLY Transactions of this type are submitted if the merchant wishes to validate the credit
card for the amount of the goods sold. If the merchant does not have goods in stock
or wishes to review orders before shipping the goods, this transaction type should be
submitted. The gateway will send this type of transaction to the financial institution
for approval. However this transaction will not be sent for settlement. If the merchant
does not act on the transaction within 30 days, the transaction will no longer be
available for capture.
PRIOR_AUTH_CAPTURE This transaction is used to request settlement for a transaction that was previously
submitted as an AUTH_ONLY. The gateway will accept this transaction and initiate
settlement if the following conditions are met:
The transaction is submitted with the ID of the original authorization-only
transaction, which needs to be settled.
The transaction ID is valid and the system has a record of the original
authorization-only transaction being submitted.
Page 38 of 56

The original transaction referred to is not already settled or expired or
errored.
The amount being requested for settlement in this transaction is less than or
equal to the original authorized amount.

If no amount is submitted in this transaction, the gateway will initiate settlement for
the amount of the originally authorized transaction.

Note: If extended line item, tax, freight, and/or duty information was submitted
with the original transaction, adjusted information may be submitted in the
event that the transaction amount changed. If no adjusted line item, tax,
freight, and/or duty information is submitted, the information submitted with
the original transaction will apply.

In addition to the required fields in the API, the following is required to submit a
PRIOR_AUTH_CAPTURE type transaction:
x_version = 3.1
x_login = merchant API login ID
x_tran_key = transaction key
x_trans_id = the transaction ID of the previously authorized transaction
CREDIT This transaction is also referred to as a Refund and indicates to the gateway that
money should flow from the merchant to the customer. The gateway will accept a
credit or a refund request if the transaction submitted meets the following conditions:
The transaction is submitted with the ID of the original transaction against
which the credit is being issued (x_trans_id).
The gateway has a record of the original transaction.
The original transaction has been settled.
The sum of the amount submitted in the Credit transaction and all credits
submitted against the original transaction is less than the original
transaction amount.
The full or last four digits of the credit card number submitted with the
credit transaction match the full or last four digits of the credit card number
used in the original transaction.
The transaction is submitted within 120 days of the settlement date and time
of the original transaction.

A transaction key is required to submit a credit to the system (i.e., x_tran_key should
have a valid value when a CREDIT transaction is submitted).

For details about how to submit CREDIT transactions to the Payment Gateway,
please see the Issuing Credits Guide at
http://www.authorizenet.com/files/creditreturnsummary.pdf.
CAPTURE_ONLY This is a request to settle a transaction that was not submitted for authorization
through the payment gateway. The gateway will accept this transaction if an
authorization code is submitted. x_auth_code is a required field for
CAPTURE_ONLY type transactions.
VOID This transaction is an action on a previous transaction and is used to cancel the
previous transaction and ensure it does not get sent for settlement. It can be done on
any type of transaction (i.e., CREDIT, AUTH_CAPTURE, CAPTURE_ONLY, and
AUTH_ONLY). The transaction will be accepted by the gateway if the following
conditions are met:
The transaction is submitted with the ID of the transaction that has to be
Page 39 of 56

voided.
The gateway has a record of the transaction referenced by the ID.
The transaction has not been sent for settlement.

For a transaction of type VOID, the following fields are required (in addition to the
other required fields in the API):
x_version = 3.1
x_login = merchant API login ID
x_tran_key = merchant transaction key
x_trans_id = the transaction ID that needs to be voided

Page 40 of 56

Appendix B Types of eCheck.Net Transactions

eCheck.Net transactions are not authorized in real time like credit card transactions. Instead, they
are automatically submitted for settlement.

There are two steps to eCheck.Net transaction processing:

1. Settlement occurs when the payment gateway initiates an Automated Clearing House
(ACH) entry through the ACH system to request the collection of the appropriate funds
from the consumers financial institution.
2. Funding occurs when funds collected for eCheck.Net transactions, less service and other
fees or withholdings, are transferred to the merchants bank account. Please note that the
timeframe for funding depends on the risk settings for their payment gateway account.

Note: The merchant can specify when the last transaction is picked up for settlement by
the gateway. To modify the Transaction Cut-Off Time, do the following (only
users with the appropriate permissions will be able to access this setting):
2. Select Settings
3. Select Transaction Cut-Off Time from the General section
4. Using the drop-down boxes, select the desired cut-off time

eCheck.Net Types
The following table describes the eCheck.Net types supported by the payment gateway. Each
code indicates how an eCheck.Net transaction was originated.

ECHECK.NET TYPE DESCRIPTION
CCD Cash Concentration
or Disbursement

CCD represents a charge or refund eCheck.Net transaction against a business
checking account. Authorization is required for both one-time and recurring
transactions.

CCD transactions are funds transfers to or from a corporate entity.

A CCD eCheck.Net transaction may be submitted via the Virtual Terminal, Batch
Upload, your Web site payment form, any of the payment gateway connection
methods (AIM, SIM, WebLink), Automated Recurring Billing or via shopping cart.

PPD Prearranged
Payment and Deposit Entry
PPD represents a charge or refund eCheck.Net transaction against a consumer
checking or savings account.

PPD transactions may only be originated when payment and deposit terms between
the merchant and the customer are prearranged, for example with Automated
Recurring Billing (ARB) transactions. A written authorization is required for one-
time transactions and a written standing authorization is required for recurring
transactions.

Page 41 of 56

A PPD eCheck.Net transaction may be submitted via the Virtual Terminal, Batch
Upload, any of the payment gateway connection methods (AIM, SIM, WebLink) or
via Automated Recurring Billing.

TEL Telephone-Initiated
Entry
TEL represents a charge eCheck.Net transaction against a consumer checking or
savings account, and for which payment authorization was obtained from the
customer via the telephone.

TEL transactions may only be originated when an existing relationship between the
merchant and the customer exists; or if no relationship exists, only when the
customer initiates the telephone call to the merchant.

TEL supports only one-time transactions.

A TEL eCheck.Net transaction may be submitted via the Virtual Terminal, Batch
Upload, or any of the payment gateway connection methods (AIM, SIM, WebLink).

WEB Internet-Initiated
Entry

WEB represents a charge eCheck.Net transaction against a consumer checking or
savings account, and for which payment authorization was obtained from the
customer via the Internet.

WEB can be one-time or recurring transactions.

One-time WEB transactions may be submitted via the Virtual Terminal, Batch
Upload, your Web site payment form, any of the payment gateway connection
methods (AIM, SIM, WebLink), or a shopping cart.

Recurring WEB transactions may be submitted via the Virtual Terminal, Batch
Upload, any of the payment gateway connection methods (AIM, SIM, WebLink) and
Automated Recurring Billing (ARB).

Merchants are required to obtain the proper payment authorization from the customer for each
eCheck.Net type, as dictated by the National Automated Clearing House Association. For more
information about the specific payment authorization requirements for each eCheck.Net type, see
the eCheck.Net Operating Procedures and User Guide at
http://www.authorizenet.com/files/echecknetuserguide.pdf.
Page 42 of 56

Appendix C Features of the Gateway

The following features are supported by the gateway in an effort to reduce merchants
chargeback liability.

Address Verification System
The Address Verification System (AVS) helps merchants to detect suspicious transaction
activity. To use this system, the merchant must submit the customers credit card billing address
to the gateway for validation. This information is submitted by the gateway to the financial
institutions. The financial institutions compare the submitted address with the billing address on
file for that particular credit card and return an AVS response code to the gateway. The gateway
includes this code in the response back to the merchant.

The merchant can configure the gateway to reject or accept transactions based on the AVS code
returned. To configure rejection or acceptance of a transaction based on the AVS code, do the
following (only users with the appropriate permissions will be able to access this setting):
3. Click on the Address Verification System (AVS) link from the Security section
4. Check the box(es) next to the AVS codes that the system should reject

AVS CODE DESCRIPTION (Italics denote a default setting)
A Address (Street) matches, ZIP does not
B Address information not provided for AVS check
E AVS error
G Non-U.S. Card Issuing Bank
N No Match on Address (Street) or ZIP
P AVS not applicable for this transaction
R Retry System unavailable or timed out
S Service not supported by issuer
U Address information is unavailable
W 9 digit ZIP matches, Address (Street) does not
X Address (Street) and 9 digit ZIP match
Y Address (Street) and 5 digit ZIP match
Z 5 digit ZIP matches, Address (Street) does not

Note: It is recommended that merchants enable some level of Address Verification to avoid
non-qualified transaction surcharges that can be levied by merchant banks and merchant
service providers. Please note, however, that the merchant will incur applicable
transaction fees for transactions that are declined due to an AVS mismatch (as with any
other declined transaction). System defaults are marked in italics in the table above.

Page 43 of 56

Credit Card Identification Code (CVV2/CVC2/CID)
The Credit Card Identification Code, or Card Code, is a three- or four-digit security code that
is printed on the back of credit cards in reverse italics in the cards signature panel (or on the
front for American Express cards). The merchant can collect this information from the customer
and submit the data to the gateway. The gateway will pass this information to the financial
institution along with the credit card number. The financial institution will determine if the value
matches the value on file for that credit card and return a code indicating whether the comparison
failed or succeeded, in addition to whether the card was authorized. The gateway passes back
this response code to the merchant. The merchant can configure the gateway to reject or accept
the transaction based on the code returned.

To configure the filter to reject certain Card Code responses, do the following (only users with
the appropriate permissions will be able to access this setting):
3. Click on the Card Code Verification link from the Security section
4. Check the box(es) next to the Card Codes that the system should reject

CARD CODE
RESPONSE
DESCRIPTION
M Card code matches
N Card Code does not match
P Card Code was not processed
S Card Code should be on card but was not indicated
U Issuer was not certified for Card Code

Page 44 of 56

Appendix D Customizing Notification to
Customers

Merchants will be sent a confirmation email after the gateway completes processing on a
transaction submitted to the system. The confirmation email enables merchants to know the
results of a given transaction. Multiple contacts can be configured to receive these email
notifications. Additionally, merchants can choose to send a confirmation email to their
customers.

Configuration of these contacts can be done through the Merchant Interface (only users with the
2. Click on the Settings link from the left navigation bar
3. Click on the Email Receipts link from the Transaction Response section
4. Check the box if email receipts should be sent to the customer
5. Configure the header and footer of the email message

It is possible to configure the confirmation email on a per-transaction basis by submitting the
information with each transaction. The following table describes the fields used in the API to
configure email notification to the customer; all fields are optional.

FIELD VALUE DESCRIPTION
x_email_customer TRUE,
FALSE
If set to TRUE, the gateway will send an email to the customer
after the transaction is processed using the customer email
supplied in the transaction. If FALSE, no email will be sent to
the customer.

If no value is submitted, the gateway will look up the
configuration in the Merchant Interface and send an email only if
the merchant has configured the option to be TRUE.

If there are no incoming parameters and the merchant has not
configured this option, no email will be sent to the customer.
x_header_email_receipt Any valid text This text will appear as the header on the transaction
confirmation email sent to the customer.
x_footer_email_receipt Any valid text This text will appear as the footer on the transaction confirmation
email sent to the customer.

Page 45 of 56

Appendix E The MD5 Hash Security Feature

What is the MD5 Hash Security Feature?
The MD5 Hash security feature enables merchants to verify that the results of a transaction
received by their server were actually sent from the Payment Gateway. The MD5 Hash works
likes this:
1. The merchant sets a value in the Merchant Interface
2. The gateway uses this value, along with a predefined set of fields submitted in the
transaction, to create a unique signature
3. The merchant server that receives the transaction response containing this signature
determines whether it was returned from the gateway

The mathematical algorithm used to construct this signature is designed in such a way that any
change to the information used in its calculation will cause a completely different signature to be
created. Also, the information used in the calculation of the signature cannot be discovered
through any analysis of the signature itself.

How is the Signature Constructed?
The MD5 signature is a hash of the following four fields: MD5 Hash Value, API Login ID,
Transaction ID, and Amount, in the following order:

"MD5 Hash Value" "API Login ID" "Trans ID" "Amount"

For example, if the merchants hash value was "wilson," the merchant API Login ID was
"myAPIlogin," the transaction ID was "987654321," and the amount was "1.00," the MD5
algorithm would be run on the following string:

"wilsonmyAPIlogin9876543211.00"

Note: The value passed in x_amount is formatted with the correct number of decimal places and
the decimal point for the type of currency used in the transaction. For transactions that do
not include a transaction amount, mainly VOIDs, the amount used to calculate the MD5
Hash is formatted as 0.00.

How Should the Feature be Set Up on the Merchants Server?
The following steps are used by the merchant to evaluate the MD5 signature:
1. Create a script to receive transaction results
2. Run the MD5 algorithm on the fields indicated above
3. Determine if the signature created matches the signature that was returned by the gateway
4. If the signatures match, the response was sent by the gateway

Page 46 of 56

How is the MD5 Hash Value Set Up in the Merchant Interface?
To set the MD5 Hash Value in the Merchant Interface, do the following (only users with the
3. Click on MD5 Hash in the Security section
4. Enter the MD5 Hash Value
5. Confirm the MD5 Hash Value entered
Page 47 of 56

Appendix F Cardholder Authentication
Programs

The payment gateway supports the following cardholder authentication programs:

Verified by Visa
MasterCardSecureCode

Merchants participating in the cardholder authentication programs are required to submit the
following authentication values with Visa and/or MasterCard transactions.

LENGTH
DESCRIPTION
x_authentication_indicator Optional

Required only for
AUTH_ONLY and
AUTH_CAPTURE
transactions
processed through
cardholder
authentication
programs. When
transaction types,
Valid ECI or UCAF
indicator (obtained
by the merchant
after the
authentication
process).
N/A The electronic commerce
indicator (ECI) value for a
Visa transaction; or the
universal cardholder
authentication field
(UCAF) indicator for


by Wells Fargo
transactions only.
x_cardholder_
authentication_value
Optional

Required only for
AUTH_ONLY and
AUTH_CAPTURE
transactions
processed through
cardholder
authentication
programs. When
transaction types,
Valid CAVV, AVV,
or UCAF value
(obtained by the
merchant after the
authentication
process).
N/A The cardholder
authentication verification
value (CAVV) for Visa
transactions; or
accountholder
authentication value
(AVV)/ universal
cardholder authentication
field (UCAF) for
MasterCard transactions.


by Wells Fargo
transactions only.
Page 48 of 56


Note: The cardholder authentication fields are currently supported only through the FDC
Nashville and Vital processors and through Wells Fargo SecureSource for Visa
transactions only. If these fields are submitted for transactions processed through any
other processor, they will be ignored by the system.

For merchants using transaction version 3.1, x_cavv_response is included in the transaction
response for Visa and/or MasterCard transactions. Merchants using transaction version 2.5 or 3.0
may not see the CAVV response code if they receive a transaction response. However, the
CAVV response may be viewed on the Transaction Detail page for the transaction in the
Merchant Interface.

The following table lists possible CAVV code responses.

CAVV CODE DESCRIPTION
Blank or not
present
CAVV not validated
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
7 CAVV attempt failed validation issuer available
(US issued card/non-US acquirer)
8 CAVV attempt passed validation issuer available
9 CAVV attempt failed validation issuer unavailable
A CAVV attempt passed validation issuer unavailable
B CAVV passed validation, information only, no liability
shift

Cardholder Authentication Validation Rules
Invalid combinations of the two fields (x_authentication_indicator and
x_cardholder_authentication_value) will cause the system to reject the transaction. Valid value
combinations are as follows:

Page 49 of 56

Visa
AUTHENTICATION
INDICATOR
CARDHOLDER AUTHENTICATION
VALUE
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
INDICATOR
CARDHOLDER AUTHENTICATION
VALUE
0 Blank /Null
2 Not null
1 Null
Null Null

Page 50 of 56

Appendix G Submitting Test Transactions to
the System

Test Mode
Test Mode is a special mode of interacting with the system that is useful during the initial setup
phase, where a merchant may want to test their setup without processing live card data.

To set an account to Test Mode, do the following (only users with the appropriate permissions
will be able to access this setting):
3. Click on the Test Mode Link in the General section
4. Click on the Turn Test On button

In Test Mode, all transactions appear to be processed as real transactions. The gateway accepts
the transactions, but does not pass them on to the financial institutions. Accordingly, all
transactions will be approved by the gateway when Test Mode is turned on. Transactions
submitted in Test Mode are not stored on the system, and will not appear in any reports or lists.

Note: Test Mode is only supported if the merchant is submitting transactions from a Website or
through the Virtual Terminal. If the merchant uploads a file of transactions for offline
processing, the gateway will reject the file.

Running a Test Transaction
It is possible to run a test transaction if Test Mode has been turned off. This can be done by
indicating to the gateway in the transaction submission request that the transaction should be
processed as a test transaction. The corresponding field in the transaction submission API is
x_test_request. If a test transaction is desired, the value of this field should be set to TRUE.

The following table describes the gateway behavior based on the incoming field value and the
mode configured through the Merchant Interface.

VALUE PASSED IN
X_TEST_REQUEST
CONFIGURATION
IN MERCHANT
INTERFACE
GATEWAY BEHAVIOR
TRUE ON Transaction processed as test
FALSE ON Transaction processed as test
TRUE OFF Transaction processed as test
FALSE OFF Transaction processed as a live
transaction

If there is no value submitted in the x_test_request field, the system will use the configuration
specified in the Merchant Interface.

Page 51 of 56


Test Credit Card Numbers
Any of the following card numbers can be used to run test transactions. Please note that these
numbers do not represent real card accounts; they will return a decline in live mode, and an
approval in test mode. Any expiration dates after the current day's date can be used with these
numbers.

TEST CARD
NUMBER
CARD TYPE
370000000000002 American Express
6011000000000012 Discover
5424000000000015 MasterCard
4007000000027 Visa

There is also a test credit card number that can be used to generate errors. THIS CARD IS
INTENDED TO PRODUCE ERRORS, and should only be used if that is the intent.

To cause the system to generate a specific error, set the account to Test Mode and submit a
transaction with the card number 4222222222222. The system will return the response reason
code equal to the amount of the submitted transaction. For example, to test response reason code
number 27, a test transaction would be submitted with the credit card number,
4222222222222, and the amount, 27.00.
Page 52 of 56

Appendix H Certification

It is possible for a merchant to test their integration using a test gateway system. In order to test
the integration, the merchant should post transactions to
https://certification.authorize.net/gateway/transact.dll. The test gateway behavior will be
identical to the primary gateway. Transactions sent to the test gateway are not submitted to
financial institutions for authorization, will not be stored on the system and cannot be retrieved
from the system (as is the case when using Test Mode set to TRUE with the primary gateway
system).
Page 53 of 56

Appendix I Currency Codes

CURRENCY COUNTRY CURRENCY CODE
Afghani (Afghanistan) AFA
Algerian Dinar (Algeria) DZD
Andorran Peseta (Andorra) ADP
Argentine Peso (Argentina) ARS
Armenian Dram (Armenia) AMD
Aruban Guilder (Aruba) AWG
Australian Dollar (Australia) AUD
Azerbaijanian Manat (Azerbaijan) AZM
Bahamian Dollar (Bahamas) BSD
Bahraini Dinar (Bahrain) BHD
Baht (Thailand) THB
Balboa (Panama) PAB
Barbados Dollar (Barbados) BBD
Belarussian Ruble (Belarus) BYB
Belgian Franc (Belgium) BEF
Belize Dollar (Belize) BZD
Bermudian Dollar (Bermuda) BMD
Bolivar (Venezuela) VEB
Boliviano (Bolivia) BOB
Brazilian Real (Brazil) BRL
Brunei Dollar (Brunei Darussalam) BND
Bulgarian Lev (Bulgaria) BGN
Burundi Franc (Burundi) BIF
Canadian Dollar (Canada) CAD
Cape Verde Escudo (Cape Verde) CVE
Cayman Islands Dollar (Cayman Islands) KYD
Cedi (Ghana) GHC
CFA Franc BCEAO (Guinea-Bissau) XOF
CFA Franc BEAC (Central African Republic) XAF
CFP Franc (New Caledonia) XPF
Chilean Peso (Chile) CLP
Colombian Peso (Colombia) COP
Comoro Franc (Comoros) KMF
Convertible Marks (Bosnia And Herzegovina) BAM
Cordoba Oro (Nicaragua) NIO
Costa Rican Colon (Costa Rica) CRC
Cuban Peso (Cuba) CUP
Cyprus Pound (Cyprus) CYP
Czech Koruna (Czech Republic) CZK
Dalasi (Gambia) GMD
Danish Krone (Denmark) DKK
Denar (The Former Yugoslav Republic Of Macedonia) MKD
Deutsche Mark (Germany) DEM
Dirham (United Arab Emirates) AED
Djibouti Franc (Djibouti) DJ F
Dobra (Sao Tome And Principe) STD
Page 54 of 56

Dominican Peso (Dominican Republic) DOP
Dong (Vietnam) VND
Drachma (Greece) GRD
East Caribbean Dollar (Grenada) XCD
Egyptian Pound (Egypt) EGP
El Salvador Colon (El Salvador) SVC
Ethiopian Birr (Ethiopia) ETB
Euro (Europe) EUR
Falkland Islands Pound (Falkland Islands) FKP
Fiji Dollar (Fiji) FJ D
Forint (Hungary) HUF
Franc Congolais (The Democratic Republic Of Congo) CDF
French Franc (France) FRF
Gibraltar Pound (Gibraltar) GIP
Gold XAU
Gourde (Haiti) HTG
Guarani (Paraguay) PYG
Guinea Franc (Guinea) GNF
Guinea-Bissau Peso (Guinea-Bissau) GWP
Guyana Dollar (Guyana) GYD
Hong Kong Dollar (Hong Kong) HKD
Hryvnia (Ukraine) UAH
Iceland Krona (Iceland) ISK
Indian Rupee (India) INR
Iranian Rial (Islamic Republic Of Iran) IRR
Iraqi Dinar (Iraq) IQD
Irish Pound (Ireland) IEP
Italian Lira (Italy) ITL
J amaican Dollar (J amaica) J MD
J ordanian Dinar (J ordan) J OD
Kenyan Shilling (Kenya) KES
Kina (Papua New Guinea) PGK
Kip (Lao People's Democratic Republic) LAK
Kroon (Estonia) EEK
Kuna (Croatia) HRK
Kuwaiti Dinar (Kuwait) KWD
Kwacha (Malawi) MWK
Kwacha (Zambia) ZMK
Kwanza Reajustado (Angola) AOR
Kyat (Myanmar) MMK
Lari (Georgia) GEL
Latvian Lats (Latvia) LVL
Lebanese Pound (Lebanon) LBP
Lek (Albania) ALL
Lempira (Honduras) HNL
Leone (Sierra Leone) SLL
Leu (Romania) ROL
Lev (Bulgaria) BGL
Liberian Dollar (Liberia) LRD
Libyan Dinar (Libyan Arab Jamahiriya) LYD
Page 55 of 56

Lilangeni (Swaziland) SZL
Lithuanian Litas (Lithuania) LTL
Loti (Lesotho) LSL
Luxembourg Franc (Luxembourg) LUF
Malagasy Franc (Madagascar) MGF
Malaysian Ringgit (Malaysia) MYR
Maltese Lira (Malta) MTL
Manat (Turkmenistan) TMM
Markka (Finland) FIM
Mauritius Rupee (Mauritius) MUR
Metical (Mozambique) MZM
Mexican Peso (Mexico) MXN
Mexican Unidad de Inversion (Mexico) MXV
Moldovan Leu (Republic Of Moldova) MDL
Moroccan Dirham (Morocco) MAD
Mvdol (Bolivia) BOV
Naira (Nigeria) NGN
Nakfa (Eritrea) ERN
Namibia Dollar (Namibia) NAD
Nepalese Rupee (Nepal) NPR
Netherlands (Netherlands) ANG
Netherlands Guilder (Netherlands) NLG
New Dinar (Yugoslavia) YUM
New Israeli Sheqel (Israel) ILS
New Kwanza (Angola) AON
New Taiwan Dollar (Province Of China Taiwan) TWD
New Zaire (Zaire) ZRN
New Zealand Dollar (New Zealand) NZD
Ngultrum (Bhutan) BTN
North Korean Won (Democratic People's Republic Of Korea) KPW
Norwegian Krone (Norway) NOK
Nuevo Sol (Peru) PEN
Ouguiya (Mauritania) MRO
Pa'anga (Tonga) TOP
Pakistan Rupee (Pakistan) PKR
Palladium XPD
Pataca (Macau) MOP
Peso Uruguayo (Uruguay) UYU
Philippine Peso (Philippines) PHP
Platinum XPT
Portuguese Escudo (Portugal) PTE
Pound Sterling (United Kingdom) GBP
Pula (Botswana) BWP
Qatari Rial (Qatar) QAR
Quetzal (Guatemala) GTQ
Rand (Financial) (Lesotho) ZAL
Rand (South Africa) ZAR
Rial Omani (Oman) OMR
Riel (Cambodia) KHR
Rufiyaa (Maldives) MVR
Page 56 of 56

Rupiah (Indonesia) IDR
Russian Ruble (Russian Federation) RUB
Russian Ruble (Russian Federation) RUR
Rwanda Franc (Rwanda) RWF
Saudi Riyal (Saudi Arabia) SAR
Schilling (Austria) ATS
Seychelles Rupee (Seychelles) SCR
Silver XAG
Singapore Dollar (Singapore) SGD
Slovak Koruna (Slovakia) SKK
Solomon Islands Dollar (Solomon Islands) SBD
Som (Kyrgyzstan) KGS
Somali Shilling (Somalia) SOS
Spanish Peseta (Spain) ESP
Sri Lanka Rupee (Sri Lanka) LKR
St Helena Pound (St Helena) SHP
Sucre (Ecuador) ECS
Sudanese Dinar (Sudan) SDD
Surinam Guilder (Suriname) SRG
Swedish Krona (Sweden) SEK
Swiss Franc (Switzerland) CHF
Syrian Pound (Syrian Arab Republic) SYP
Tajik Ruble (Tajikistan) TJ R
Taka (Bangladesh) BDT
Tala (Samoa) WST
Tanzanian Shilling (United Republic Of Tanzania) TZS
Tenge (Kazakhstan) KZT
Timor Escudo (East Timor) TPE
Tolar (Slovenia) SIT
Trinidad and Tobago Dollar (Trinidad And Tobago) TTD
Tugrik (Mongolia) MNT
Tunisian Dinar (Tunisia) TND
Turkish Lira (Turkey) TRL
Uganda Shilling (Uganda) UGX
Unidad de Valor Constante (Ecuador) ECV
Unidades de fomento (Chile) CLF
US Dollar (Next day) (United States) USN
US Dollar (Same day) (United States) USS
US Dollar (United States) USD
Uzbekistan Sum (Uzbekistan) UZS
Vatu (Vanuatu) VUV
Won (Republic Of Korea) KRW
Yemeni Rial (Yemen) YER
Yen (J apan) J PY
Yuan Renminbi (China) CNY
Zimbabwe Dollar (Zimbabwe) ZWD
Zloty (Poland) PLN

AIM Guide Authorizenet

Uploaded by

Copyright:

Available Formats

AIM Guide Authorizenet

Uploaded by

Document Information

Original Description:

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

AIM Guide Authorizenet

Uploaded by

Copyright:

Available Formats

Advanced Integration Method (AIM)

You might also like