Merchant Integration Guide

Card Not Present Transactions

Authorize.Net Customer Support

[email protected]

Authorize.Net LLC 071708

Authorize.Net LLC (“Authorize.Net”) has made efforts to ensure the accuracy and completeness of
the information in this document. However, Authorize.Net disclaims all representations, warranties
and conditions, whether express or implied, arising by statute, operation of law, usage of trade,
course of dealing or otherwise, with respect to the information contained herein. Authorize.Net
assumes no liability to any party for any loss or damage, whether direct, indirect, incidental,
consequential, special or exemplary, with respect to (a) the information; and/or (b) the evaluation,
application or use of any product or service described herein.

Authorize.Net disclaims any and all representation that its products or services do not infringe upon
any existing or future intellectual property rights. Authorize.Net owns and retains all right, title and
interest in and to the Authorize.Net intellectual property, including without limitation, its patents,
marks, copyrights and technology associated with the Authorize.Net services. No title or ownership
of any of the foregoing is granted or otherwise transferred hereunder. Authorize.Net reserves the
right to make changes to any information herein without further notice.

Authorize.Net Trademarks:

Authorize.Net®
Authorize.Net Your Gateway to IP Transactions™
Authorize.Net Verified Merchant Seal™
Authorize.Net Where the World Transacts®
Automated Recurring Billing™
eCheck.Net®
Fraud Detection Suite™
FraudScreen.Net®

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 1
Table of Contents

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

Section 1 ........................................................................................... 5
Introduction....................................................................................... 5
Processing Requirements ................................................................................................. 5
Connection Methods ......................................................................................................... 6
Server Integration Method (SIM) .............................................................................................. 6
Advanced Integration Method (AIM) ........................................................................................ 6
Customer and Developer Support .................................................................................... 7
Section 2 ........................................................................................... 8
Submitting Transactions................................................................... 8
Credit Card Transaction Types ......................................................................................... 8
Authorization and Capture ........................................................................................................ 8
Authorization Only ..................................................................................................................... 8
Prior Authorization and Capture .............................................................................................. 9
Capture Only .............................................................................................................................. 9
Credit ......................................................................................................................................... 10
Unlinked Credit ........................................................................................................................ 10
Void ........................................................................................................................................... 11
Using the Merchant Interface .......................................................................................... 11
Unsettled Transactions ........................................................................................................... 11
Virtual Terminal ........................................................................................................................ 11
Section 3 ......................................................................................... 13
Integration Settings ........................................................................ 13
Access Settings .............................................................................................................. 13
API Login ID.............................................................................................................................. 13
Transaction Key ....................................................................................................................... 14
General Settings ............................................................................................................. 14
Test Mode ................................................................................................................................. 14
Transaction Cut-Off Time ........................................................................................................ 15
Standard Transaction Security Settings.......................................................................... 15
Address Verification Service (AVS) Filter ............................................................................. 15
Credit Card Verification (CCV) Filter ...................................................................................... 18
Password-Required Mode ....................................................................................................... 20
Server Integration Method (SIM) Settings....................................................................... 20
Form Settings ........................................................................................................................... 20
Customizing the Hosted Payment Form................................................................................ 24
Receipt page options .............................................................................................................. 26
Email Receipt ........................................................................................................................... 29
Advanced Integration Method (AIM) Settings ................................................................. 30
Direct Response....................................................................................................................... 30
Cardholder Authentication Programs.................................................................................... 31
eCheck.Net® Transactions ..................................................................................................... 31
Additional Integration Features ....................................................................................... 32
Itemized Order Information ..................................................................................................... 32

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 2
Merchant Integration Guide

Merchant-Defined Fields ......................................................................................................... 32

Section 4 ......................................................................................... 33
Transaction Response .................................................................... 33
Response Code Details .................................................................................................. 37
Response Codes ...................................................................................................................... 37
Response Reason Codes and Response Reason Text ....................................................... 37

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 3
Revision History

PUBLISH DATE UPDATES

August 2007 Release of Merchant Integration Guide
May 2008 Removal of SecureSource requirements
July 2008 KB and CS update

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 4
Section 1
Introduction

Welcome to the Merchant Integration Guide! This document is designed to be a companion guide
to the Web developer guides for connecting a Web site or business application to the Authorize.Net
Payment Gateway for processing online payments. Its purpose is to provide details about the
settings available in the Merchant Interface for configuring your connection to the payment
gateway.

The Merchant Interface at https://secure.authorize.net is a secure Web site where you can manage
your payment gateway account, submit manual transactions, monitor and review unsettled
transactions, search for and view settled transactions, view account billing statements, configure
account settings, and more. This particular guide focuses on the settings available in the Merchant
Interface for your Web site connection to the payment gateway. For help with other Merchant
Interface features and settings, see the Merchant Interface Online Help Files. These can be accessed
from any page in the Merchant Interface by clicking the Help link in the top right corner of the
page.

IMPORTANT: Please be aware that connection settings that can be configured in the Merchant
Interface may also be hard coded in your Web site code. To maintain a robust connection to the
payment gateway, it is highly recommended that you work closely with your Web developer to
identify those settings that should be hard coded in your Web site code versus those settings that
you may need to configure yourself from time to time in the Merchant Interface.

You may want to consider creating a unique user account in the Merchant Interface for your Web
developer to give them direct access and permissions to configure connection settings for your
account. This way you do not need to worry about settings yourself—you can simply communicate
requirements to your Web developer. For more information on creating user accounts, log into the
Merchant Interface at https://secure.authorize.net, click User Administration under Account in the
main menu on the left, and click the Help link in the top right corner of the page.

Note: Only Account Owners or Account Administrators have the permissions necessary to create new
account users. If the Multiple User Accounts feature is not enabled for your Merchant Interface
account, the principle owner or the person in your organization who set up your payment
gateway account will need to activate it in order for you to create user accounts. For more
information see the Multiple User Accounts Merchant Preparation Guide at
http://www.authorize.net/files/MUprepguide.pdf.

Processing Requirements
This document assumes that the following requirements for processing payments through the
Authorize.Net Payment Gateway are already in place:

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 5
 Section 1 Introduction

• You already have a U.S. based merchant bank account that allows Internet
transactions.

• You already have an e-commerce (Card Not Present) Authorize.Net Payment

Gateway account.

• You are working with a Web developer or shopping cart to connect your e-commerce
Web site or other business application to the Authorize.Net Payment Gateway.

Connection Methods
The Authorize.Net Payment Gateway provides multiple methods for connecting an e-commerce
Web site or other business application to the payment gateway via the Internet. If you or your Web
developer has not already selected an integration method, it is recommended that you discuss your
business requirements with your Web developer for help determining which connection method is
best for you. You can also review our Connection Methods Guide at
http://www.authorize.net/files/connectionmethodsguide.pdf.

Server Integration Method (SIM)

SIM is a hosted payment processing solution, which means that Authorize.Net provides the
necessary Web resources to handle all the steps in processing a transaction, including:

• Collection of customer payment information through a secure, hosted form

• Generation of a receipt to the customer
• Secure transmission to the payment processing networks for settlement
• Funding of proceeds to your bank account
• Secure storage of cardholder information

SIM is an ideal integration solution for merchants that do not want to collect, transmit or store
sensitive cardholder information to process transactions. Additionally, SIM does not require a
Secure Sockets Layer (SSL) digital certificate. This removes the complexity of securely handling
and storing cardholder information, simplifying compliance with the Payment Card Industry (PCI)
Data Security Standard. For more information about the PCI Data Security Standard, see our
Security Best Practices White Paper at http://www.authorize.net/files/securitybestpractices.pdf.

The SIM Developer Guide can be found in the Authorize.Net Integration Center at
http://developer.authorize.net/guides/SIM/default.htm.

Advanced Integration Method (AIM)

AIM is a custom payment processing solution that gives you control over all the steps in processing
a transaction, including:

• Collection of customer payment information through a custom application

• Generation of a receipt to the customer
• Secure transmission to the payment gateway for transaction processing
• Secure storage of cardholder information
• And more, depending on your business requirements

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 6
Merchant Integration Guide

AIM is an ideal integration solution for merchants that need the highest degree of customization
and control over their customers’ checkout experience. Because AIM involves the collection,
transmission, and storage of cardholder data, compliance with the PCI Data Security Standard is
required by the Card Associations. For more information, please see our Security Best Practices
White Paper at http://www.authorize.net/files/securitybestpractices.pdf.

The AIM Developer Guide can be found in the Authorize.Net Integration Center at
http://developer.authorize.net/guides/AIM/default.htm.

Customer and Developer Support

There are several resources available to help you and your Web developer successfully integrate a
merchant Web site or other business application to the Authorize.Net Payment Gateway.

• Refer to the Merchant Interface Online Help Files. Log into the Merchant Interface at
https://secure.authorize.net, click on the feature for which you need help from the main
menu or Settings menu, and then click the Help link in the top right corner of the page.

• The Authorize.Net Knowledge Base, located at http://www.authorize.net/help, provides

comprehensive answers to virtually any customer support question, as well as useful links
to demos, help files and information on contacting us. We strongly recommend using the
Knowledge Base anytime you need help.

• Customer Support is available to help you with questions regarding integration settings in
the Merchant Interface. You can contact Customer Support by emailing
[email protected], or via chat by clicking Live Help in the top right corner of the
Merchant Interface. Customer Support hours are 6:00 AM – 6:00 PM Pacific time, Monday
through Friday.

• The Integration Center at http://developer.authorize.net provides Web developers with test

accounts, sample code, FAQs, and troubleshooting tools.

• If you or your developer can’t find what you need in the Integration Center, our Integration
Team is available to answer your questions via email at [email protected]. (Please
note that our Integration Team can only assist with support requests specific to the
Authorize.Net application programming interface (API) and/or services.)

If you have any suggestions about how we can improve or correct this guide, please email
[email protected].

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 7
Section 2
Submitting Transactions

There are two ways to submit transactions to Authorize.Net:

1. Automatically through a Web site or custom application connected to Authorize.Net using

Advanced Integration Method (AIM) or Server Integration Method (SIM).
2. Manually in the Virtual Terminal.

It’s a good idea to identify how your business plans to submit transactions so that you and/or your
Web developer can properly integrate your payment gateway account to support your business
processes.

For example, are you submitting transactions mainly through an e-commerce Web site? Are you
integrating a custom application to allow call center representatives to enter mail order/telephone
order (MOTO) transactions? Would you like the ability to verify the availability of funds on a
customer’s credit card account at the time of purchase and then charge their credit card at the time
you ship the order?

By communicating your transaction processing practices or requirements, you can help your Web
developer integrate your Web site or custom application more quickly.

Credit Card Transaction Types

The payment gateway supports the following credit card transaction types.

Authorization and Capture

This is the most common type of credit card transaction. The amount is sent for authorization, and
if approved, is automatically submitted for settlement.

Authorization Only
This transaction type is sent for authorization only. The transaction will not be sent for settlement
until the credit card transaction type Prior Authorization and Capture (see definition below) is
submitted, or the transaction is submitted for capture manually in the Merchant Interface.

If action for the Authorization Only transaction is not taken on the payment gateway within 30
days, the authorization expires and is no longer available for capture. A new Authorization Only
transaction would then have to be submitted to obtain a new authorization code.

You can submit Authorization Only transactions if you want to verify the availability of funds on
the customer’s credit card before finalizing the transaction. This transaction type can also be
submitted in the event that you do not currently have an item in stock or you want to review orders
before shipping goods.

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 8
Merchant Integration Guide

Note: If you are using SIM, the hosted payment form can be configured to submit either
Authorization and Capture or Authorization Only transactions. Please communicate to your
Web developer your preferences regarding which of these credit card transaction types
should be used for your Web site.

Prior Authorization and Capture

This transaction type is used to complete an Authorization Only transaction that was successfully
authorized through the payment gateway.

Note: An Authorization Only and a Prior Authorization and Capture together are considered one
complete transaction. Once the Prior Authorization and Capture is submitted, the transaction
will be sent for settlement.

The payment gateway accepts this transaction type and initiates settlement if the following
conditions are met:

• The original Authorization Only transaction was submitted within the previous 30 days
(Authorization Only transactions expire on the payment gateway after 30 days).

• The transaction is submitted with the valid transaction ID of an original, successfully

authorized, Authorization Only transaction.

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

• The amount being requested for capture is less than or equal to the original authorized
amount.

For this transaction type, the amount is only required in the event that a Prior Authorization and
Capture is submitted for an amount that is less than the amount of the original Authorization Only
transaction. If no amount is submitted, the payment gateway will initiate settlement for the amount
of the original authorized transaction.

Capture Only
This transaction type is used to complete a previously authorized transaction that was not originally
submitted through the payment gateway or that required voice authorization.

A Capture Only is also commonly submitted to manually accept a transaction that was declined by
the payment gateway due to Address Verification Service (AVS) and/or Card Code Verification
(CCV) filtering. For more information about AVS and CCV filter declines, see the “Standard
Transaction Security Settings” section of this guide.

The payment gateway accepts Capture Only transactions if the following conditions are met:

• The transaction is submitted with the valid authorization code issued to the merchant to
complete the transaction.

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 9
 Section 2 Submitting Transactions

• The transaction is submitted with the customer’s full credit card number and expiration
date.

Note: If you are using SIM, we strongly recommend that you only submit Capture Only
transactions through the Virtual Terminal. This transaction type requires the submission of
full sensitive customer information, which requires a greater level of compliance with the
Payment Card Industry (PCI) Data Security Standard. If your business needs the ability to
submit this transaction type from a custom application, please consider using AIM. For
more information about AIM, please see the AIM Developer Guide at
http://developer.authorize.net/guides/AIM/default.htm.

For instructions on how to perform a Capture Only transaction in the Merchant Interface, please see
the “Overriding an AVS Decline” section of this document.

Note: Please note that this transaction type may be subject to a higher discount rate. Please
contact your Merchant Service Provider for more information about submitting Capture
Only transactions.

Credit
This transaction type is used to refund a customer for a transaction that was originally processed
and successfully settled through the payment gateway.

The payment gateway accepts Credits if the following conditions are met:

• The transaction is submitted with the valid transaction ID of an original, successfully

settled transaction.

• The amount being requested for refund is less than or equal to the original settled amount.

• The sum amount of multiple Credit transactions submitted against the original transaction
is less than or equal to the original settled amount.

• At least the last four digits of the credit card number used for the original, successfully
settled transaction are submitted. An expiration date is not required.

• The transaction is submitted within 120 days of the settlement date of the original
transaction.

Unlinked Credit
This transaction type is used to issue a refund for a transaction that was not originally submitted
through the payment gateway. It also allows you to override restrictions for submitting refunds for
payment gateway transactions, for example, if you are beyond the 120-day period for submitting a
refund or you would like to refund an amount that is greater than the original transaction amount.

The ability to submit unlinked credits is not a standard payment gateway account feature. To
request the Expanded Credits Capability (ECC) feature, you must submit an application. For more
information about the ECC application, please see http://www.authorize.net/files/ecc.pdf.

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 10
Merchant Integration Guide

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

enabled for your account, and a transaction ID is submitted with the Unlinked Credit transaction,
then the payment gateway will attempt to apply the credit to an original transaction with the
transaction ID submitted.

Note: If you are using SIM, we strongly recommend that you only submit Unlinked Credit
transactions through the Virtual Terminal. This transaction type requires the submission of
full sensitive customer information, which requires a greater level of compliance with the
Payment Card Industry (PCI) Data Security Standard. If your business needs the ability to
submit this transaction type from a custom application, please consider using AIM. For
more information about AIM, please see the AIM Developer Guide at
http://developer.authorize.net/guides/AIM/default.htm.

Void
This transaction type is used to cancel an original transaction that not yet settled and prevents it
from being sent for settlement. A Void can be submitted against any other transaction type.

Note: If you are unsure of whether a transaction is settled, you can attempt to submit a Void first. If
the Void errors, the original transaction is likely settled, in which case you can submit a
Credit for the transaction.

The payment gateway accepts Voids if the following conditions are met:

• The transaction is submitted with the valid transaction ID of an original, successfully

authorized transaction.

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

Using the Merchant Interface

The Merchant Interface allows you to manage transactions, capture Authorization Only
transactions, void transactions, and issue refunds. These transaction types can also be managed
automatically via AIM or SIM if you are integrating a custom application to the payment gateway.
However, for most integrations, these transaction types can be more conveniently and easily
managed in the Merchant Interface.

Unsettled Transactions
On the Unsettled Transactions page you can select a single or multiple Authorization Only
transactions to capture. You can also void transactions from the Unsettled Transactions page. For
more information on how to submit these transaction types, click Unsettled Transactions under
Search in the Merchant Interface main menu and then click the Help link in the top right corner of
the Unsettled Transactions page.

Virtual Terminal
Refunds (Credit and Unlinked Credit) and Capture Only transactions can be submitted through the
Virtual Terminal feature of the Merchant Interface. For information on how to use the Virtual

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 11
 Section 2 Submitting Transactions

Terminal, click Virtual Terminal under Tools in the Merchant Interface main menu and then click
the Help link in the top right corner of the Virtual Terminal page.

Refunds submitted through the Virtual Terminal for original transactions processed through the
payment gateway require the Transaction ID of the original transaction. You can obtain this
information by searching for the original transaction on the Search Transactions page of the
Merchant Interface and viewing the transaction details. For information on how to search
transactions, click Transactions under Search in the Merchant Interface main menu and then click
the Help link in the top right corner of the Transaction Search page.

If ECC is enabled for your account and you would like to a submit refund through the Virtual
Terminal that is associated with a transaction that was not originally processed on the payment
gateway, a transaction ID must not be provided. If a transaction ID is submitted, the payment
gateway will attempt to apply the credit to an original payment gateway transaction.

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 12
Section 3
Integration Settings

Most integration settings in the Merchant Interface apply to both Server Integration Method (SIM)
and Advanced Integration Method (AIM). However, some are specific to the connection method
you are using. This section details all the settings you should be aware of in the Merchant Interface
that will help you achieve and maintain a strong connection to the payment gateway.

Access Settings
In order to connect a Web site or proprietary business application to the payment gateway, you
should be familiar with the API Login ID and Transaction Key. These values authenticate you as an
authorized merchant when submitting transaction requests.

API Login ID
The API Login ID is a complex value that is at least eight characters in length, includes uppercase
and lowercase letters, numbers, and/or symbols and identifies your account to the payment
gateway. It is not the same as your login ID for logging into the Merchant Interface. The two
perform two different functions. The API Login ID is a login ID that your Web site uses when
communicating with the payment gateway to submit transactions. It is only ever used for your Web
site or other business application’s connection to the payment gateway.

The API Login ID for your account is available in the Settings menu of the Merchant Interface.

IMPORTANT: The API Login ID is a sensitive piece of account information and should only be
shared on a need-to-know basis, for example with your Web developer. Be sure to store it securely.

To obtain your API Login ID:

1. Log into the Merchant Interface at https://secure.authorize.net

2. Select Settings under Account in the main menu on the left
3. Click API Login ID and Transaction Key in the Security Settings section
4. If you have not already obtained an API Login ID and Transaction Key for your account, you
will need to enter the secret answer to the secret question you configured at account
activation.
5. Click Submit.

The API Login ID for your account is displayed on the API Login ID and Transaction Key page.

It is highly recommended that you reset your API Login ID regularly, such as every six months, to
strengthen the security of your payment gateway account. To reset your API Login ID you will
need to contact Authorize.Net Customer Support. You will then need to communicate the new API
Login ID to your Web developer immediately to update your Web site integration code. Failure to
do so will result in a disruption in transaction processing.

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 13
 Section 3 Integration Settings

Note: The above directions apply when Multiple User Accounts is activated for your account. If
this feature is not enabled for your account, you will need to activate it in order to generate
and view the API Login ID in the Merchant Interface. Otherwise your current login ID is
the same as the API Login ID for your account.

Transaction Key
The Transaction Key is a 16-character alphanumeric value that is randomly generated in the
Merchant Interface and works in conjunction with your API Login ID to authenticate you as an
authorized user of the Authorize.Net Payment Gateway when submitting transactions from your
Web site.

Like the API Login ID, the Transaction Key is a sensitive piece of account information that should
only be shared on a need-to-know basis.

To obtain a Transaction Key:

1. Log into the Merchant Interface at https://secure.authorize.net

2. Select Settings under Account in the main menu on the left
3. Click API Login ID and Transaction Key in the Security Settings section
4. Enter the secret answer to the secret question you configured when you activated your user
account
5. Click Submit

The Transaction Key for your account is displayed on a confirmation page.

IMPORTANT: Be sure to record your Transaction Key immediately in a secure manner or copy it
immediately to a file in a secure location as it is not always visible in the Merchant Interface like
the API Login ID. Once you navigate away from the confirmation page there will be no other way
to access the Transaction Key in the Merchant Interface. You would have to generate a new
Transaction Key.

It is highly recommended that you create a new Transaction Key regularly, such as every six
months, to strengthen the security of your payment gateway account. You will then need to
communicate the new Transaction Key to your Web developer immediately to update your Web
site integration code. Failure to do so will result in a disruption in transaction processing.

General Settings
The following settings are important for all connections to the Authorize.Net Payment Gateway and
should be configured for your account to achieve optimal performance and security. You may need
to contact your Web developer to be sure that your Web site is coded to interact properly with these
settings.

Test Mode
Test Mode allows you to test your Web site connection to the payment gateway without actually
processing live transactions. Once activated, your account is already in Test Mode by default.
While in Test Mode, the payment gateway will accept test transactions as a simulation of how
actual transactions would be accepted or declined, but payment data will not actually be

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 14
Merchant Integration Guide

submitted for processing. Test transactions will not be stored and cannot be retrieved from the
payment gateway.

IMPORTANT: Please contact your Web developer for help with submitting test transactions.

It is important that you leave your account in Test Mode until your connection to the payment
gateway is successfully tested and it is ready to process live transactions. You may place your
account in Test Mode at anytime to test updates to your Web site connection or in the event that
you need to quickly turn off transaction processing.

To turn Test Mode off or on:

1. Log into the Merchant Interface at https://secure.authorize.net

2. Select Settings under Account in the main menu on the left
3. Click Test Mode in the Security Settings section
4. Click Turn Test OFF to take your account out of Test Mode. Click Turn Test ON to place
your account in Test Mode

Transaction Cut-Off Time

The Transaction-Cut-Off Time is the time of day that your transactions are batched and submitted
by the payment gateway to the processing network for settlement. You can specify the time that
your batch should be submitted for settlement each day. The default Transaction Cut-Off Time for
your account is 3:00 PM Pacific time. Transactions submitted after your Transaction Cut-Off Time
will be included with the next day’s batch. You may want to contact your Merchant Service
Provider for their recommendation on what time is best for your account’s Transaction Cut-Off
Time to optimize the settlement timeframe for your transactions.

To configure the transaction cut-off time for your account:

1. Log into the Merchant Interface at https://secure.authorize.net

2. Select Settings under Account in the main menu on the left
3. Select Transaction Cut-Off Time in the Business Settings section
4. Select the desired cut-off time from the drop-down lists
5. Click Submit

Standard Transaction Security Settings

The following standard transaction security settings are recommended for all payment gateway
accounts as a general way to identify and prevent suspicious transactions.

Address Verification Service (AVS) Filter

Bankcard processors implemented the Address Verification Service (AVS) to aid merchants in the
detection of suspicious transaction activity. The payment processing network compares the billing
address provided in the transaction with the cardholder’s address on file at the credit card issuing
bank. The processing network returns an AVS response code that indicates the results of this
comparison to the payment gateway. You can configure your account to reject certain transactions
based on the AVS code returned. For example, the AVS code “A” indicates that the street address
matched, but the first five digits of the ZIP Code did not.

The following result codes are possible.

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 15
 Section 3 Integration Settings

AVS CODE DESCRIPTION

A The street address matches, but the 5-digit ZIP code does not
Address information was not submitted in the transaction
B information, so AVS check could not be performed
The AVS data provided is invalid, or AVS is not allowed for the
E card type submitted
The credit card issuing bank is of non-U.S. origin and does not
G support AVS
Neither the street address nor the 5-digit ZIP code matches the
N address and ZIP code on file for the card
P AVS is not applicable for this transaction
AVS was unavailable at the time the transaction was processed.
R Retry transaction
S The U.S. card issuing bank does not support AVS
U Address information is not available for the customer's credit card
The 9-digit ZIP code matches, but the street address does not
W match
The street address and the first 5 digits of the ZIP code match
Y perfectly
The first 5 digits of the ZIP code matches, but the street address
Z does not match

Note: AVS responses B, E, R, G, U, S and N are the default payment gateway AVS transaction
rejection settings, meaning that when these codes are returned, transactions are
automatically rejected by the payment gateway. These default settings can be modified in
the Merchant Interface.

To configure transaction rejection settings based on the AVS response code:

1. Log into the Merchant Interface at https://secure.authorize.net

2. Select Settings under Account in the main menu on the left
3. Click Address Verification Service in the Security Settings section
4. Click to select the check box(es) next to the AVS codes for which the payment gateway
should reject transactions
5. Click Submit

Transactions will be processed against your rejection criteria immediately.

Note: In order to use the AVS filter, you need to require the billing address and ZIP code fields
when collecting payment information from your customers. Please communicate these
requirements to your Web developer.

Tips for using AVS:

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 16
Merchant Integration Guide

• AVS response code N (neither the street address nor the ZIP code matches the address and
ZIP code on file for the card) is the most fundamental AVS check. Select N to implement
the most basic AVS protection from suspicious transaction activity.
• If you choose not to select N, then there is no need to select the following response codes:
B, E, R, G, U, and S. These codes indicate that the address could not be verified by the
card issuer. If transactions are NOT being rejected when they are returned with an N
response, then it is unnecessary to reject transactions that could not be verified with the
issuer.
• To avoid errors when accepting gift credit cards (stored-value cards with a Visa,
MasterCard, Discover or American Express logo), you will need to deselect the U response
code. For this type of transaction, the customer’s billing address will most likely not be
associated with the gift card, or will not exist on file at the issuing bank.
• Not all banks outside the United States will return the G, U and S response codes.
Therefore, this code is not absolutely effective for limiting suspicious transactions from
outside of the United States.
• If you want to accept International payments, you must deselect the G, U and S response
codes.
• The desired response code in most cases is Y (the street address and the first 5 digits of the
ZIP code match perfectly). Select this response code for rejecting transactions only after
very careful consideration, as legitimate matches may be rejected when Y is selected.

The AVS filter is designed to provide a basic level of protection from suspicious transactions.
However, the AVS filter is not intended for use as an absolute protection nor is it intended for use
in all processing scenarios as there are many reasons why an address and ZIP code may not match.
You are not required to reject a transaction due to an AVS mismatch, but it is recommended that
you enable some level of address verification. However, most banks and Merchant Service
Providers require use of the AVS system in order to avoid non-qualified transaction surcharges
(typically an additional 1%). For this reason, it is recommended that you enable some level of
address verification to avoid non-qualified transaction surcharges. Please note, however, that you
are responsible for applicable transaction fees incurred for transactions declined due to an AVS
mismatch (as with any other declined transaction).

If your business has a low risk factor, or potentially paying a non-qualified discount rate will not
adversely affect your business, you may consider being lenient in your application of the AVS
filter. Conversely, if you anticipate a high frequency of suspicious transaction activity or if you are
incurring abnormally high discount rate charges, the AVS filter may be an appropriate method of
protection.

Overriding an AVS Decline

In the event that you would like to accept a transaction that was declined by the payment gateway
due to AVS filtering, you may submit a Capture Only transaction in the Virtual Terminal. This is
possible because the transaction was declined by the payment gateway after the transaction was
successfully authorized and the funds placed on hold at the credit card issuing bank. As such, an
Authorization Code was issued for the transaction and can be obtained in the Merchant Interface.

Note: The Authorization Code is required for submitting a Capture Only transaction.

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 17
 Section 3 Integration Settings

To obtain the transaction’s Authorization Code:

1. Log into the Merchant Interface at https://secure.authorize.net

2. Click Transactions under Search in the main menu on the left
3. Enter the applicable search criteria to look up the transaction, for example, the payment
gateway settlement date or customer name. If you have the Transaction ID, simply enter
that value in the Transaction ID field
4. Click Search at the bottom of the page
5. Click on the Transaction ID for the declined transaction to view the details
6. The Authorization Code is located in the Authorization Information section of the
Transaction Detail page

To perform a Capture Only transaction:

1. Log into the Merchant Interface at https://secure.authorize.net

2. Click Tools from the tool bar at the top of the page
3. Select Capture Only from the Select Transaction Type section of the Virtual Terminal
page
4. Enter the required transaction information (indicated with an asterisk) including the
Authorization Code
5. Click Submit

Note: Because a Capture Only transaction requires the customer’s full credit card number and
expiration date, you may need to contact the customer to collect this information. In
addition, your transaction processing rates for Capture Only transactions may be
downgraded (increased). Please contact your Merchant Service Provider for more
information.

In the event that you would like to void the authorization for the transaction so that the customer’s
funds can be released back to their card, you will need to call the credit card issuing bank as the
payment gateway does not allow a Void transaction for a decline. You must have the Authorization
Code for this request and you must know the credit card type that was used, and your Merchant
Number associated with that Card Association (for example, Visa). If you don’t know your
Merchant Number, please call your Merchant Service Provider.

Credit Card Verification (CCV) Filter

The Credit Card Verification Code, or Card Code, is a three- or four-digit security code that is
printed on the back of credit cards (or on the front for American Express cards) in reverse italics in
the card’s signature panel.

Figure 1. Finding the card code on a credit card

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 18
Merchant Integration Guide

You can opt to collect this information from the customer and submit the data to the payment
gateway as another method for authenticating credit card transactions submitted through your
account. The payment gateway will pass this information to the credit card issuer along with the
credit card number. The credit card issuer will determine if the value matches the value on file for
the customer’s credit card and return a code to the payment gateway indicating whether the code
matched, in addition to indicating whether the card was authorized. You can configure the payment
gateway to reject transactions based on the code returned.

CARD CODE DESCRIPTION

RESPONSE
N The Card Code does not match
P The Card Code was not processed
S The Card Code was not indicated
U Card Code is not supported by the card issuer

Note: There are no default payment gateway settings for the Card Code filter. To use this feature,
you will need to configure the appropriate rejection settings.

To configure transaction rejection settings based on the Card Code response:

1. Log into the Merchant Interface at https://secure.authorize.net

2. Select Settings under Account in the main menu on the left
3. Click Card Code Verification in the Security Settings section
4. Click to select the check box(es) next to the Card Code responses for which the payment
gateway should reject transactions
5. Click Submit

Note: In order to use the CCV filter, you need to require the Card Code field either on the
payment gateway hosted payment form or your own custom payment form. Please
communicate these requirements to your Web developer.

Overriding a CCV Decline

In the event that you would like to accept a transaction that was declined by the payment gateway
due to CCV filtering, you may submit a Capture Only transaction in the Virtual Terminal. This is
possible because the transaction was declined by the payment gateway after the transaction was
successfully authorized and the funds placed on hold at the credit card issuing bank. As such, an
Authorization Code was issued for the transaction and can be obtained in the Merchant Interface.

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 19
 Section 3 Integration Settings

Note: The Authorization Code is required for submitting a Capture Only transaction.

For more information on how to obtain the Authorization Code for a CCV decline and submit a
Capture Only transaction, see the section of this document titled “Overriding an AVS Decline.”

Password-Required Mode
Password-Required Mode is a security setting that requires the account Transaction Key to be
submitted with all transactions for authentication purposes. This setting is enabled for all payment
gateway accounts by default and should always be on for SIM and AIM merchants.

To verify that Password-Required Mode is enabled for your account:

1. Log into the Merchant Interface at https://secure.authorize.net

2. Click Settings under Account in the main menu on the left
3. Click Password-Required Mode in the Security Settings section
4. If it is unchecked, click to select the check box labeled Require Password for ALL
Transactions
5. Click Submit

Server Integration Method (SIM) Settings

If you are connecting to the payment gateway using SIM, this section describes the integration
settings you will need to understand in order to configure them properly in the Merchant Interface.

IMPORTANT: Please be aware that connection settings that can be configured in the Merchant
Interface may also be hard coded in your Web site code. To maintain a robust connection to the
payment gateway, it is highly recommended that you work closely with your Web developer or
third-party solution to identify those settings that should be hard coded in your Web site code
versus those settings that you may need to configure yourself from time to time in the Merchant
Interface.

Form Settings
SIM merchants use the payment gateway hosted payment form for collecting and submitting
customer payment information. You can customize the hosted payment form to include additional
transaction fields and to match the look and feel of your Web site.

Fields on the Payment Form

By default, the payment gateway hosted page will always display the fields required to post a
transaction, which are:

For credit card transactions:

• Amount
• Credit Card Number
• Expiration Date

For eCheck.Net® transactions:

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 20
Merchant Integration Guide

• Amount
• ABA Routing Number
• Bank Account Number
• Bank Account Type
• Bank Name
• Bank Account Name

Note: eCheck.Net® fields only appear on the hosted payment form in the event that the
eCheck.Net service is enabled for your payment gateway account. eCheck.Net® is
Authorize.Net’s exclusive electronic check processing solution. For more information on
how eCheck.Net can help you potentially increase sales and how to sign up, visit
http://www.authorize.net/echeck.

To configure additional fields that you would like to appear on your payment form:

1. Log into the Merchant Interface at https://secure.authorize.net

2. Click Settings under Account in the main menu on the left
3. Click Payment Form in the Transaction Format Settings section
4. Click Form Fields
5. Click to select the checkbox(es) in the View column next to the fields you would like to
display on your payment form
6. For each field you are adding, click to select the check boxes in the Edit and Required
columns if you would also like to configure either or both of these attributes for the field

• View – The customer can view but not edit the information. For example, if you would
like to display an invoice number. Information that is View only should be submitted
with the transaction information to the payment gateway. Contact your Web developer
for more information.

• Edit – The customer can view and/or edit the information but the field is not required
to submit the transaction. For example, if you would like to collect but not require the
customer’s email address, configuring the field as View and Edit allows the customer
to provide this information with the transaction.

• Required – The customer must provide the information in order to submit the
transaction. For example, if you would like to require the customer’s card code. When
requiring this field, the View, Edit and Required attributes must be configured.

7. Click Submit

Be sure to test your payment form anytime you update fields and their attributes to be sure that it
meets your requirements.

IMPORTANT: If you choose to use the Address Verification Service (AVS) and Card Code
Verification (CCV) transaction security features, you must collect billing address and Card Code
information from the customer on the payment gateway hosted payment form.

The following table lists the additional payment form fields you can configure for the hosted
payment form in the Merchant Interface.

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 21
 Section 3 Integration Settings

Note: Payment form field settings may also be submitted to the payment gateway as a part of
your Web site’s integration code. To be sure that payment form settings included in your
Web site integration code do not conflict with payment form settings you configure in the
Merchant Interface, it is recommended that you discuss your payment form field
requirements with your Web developer.

FIELD VALUE NOTES

PAYMENT INFORMATION
Recurring Billing The recurring billing status Indicates whether the transaction is a recurring
Transaction billing transaction.
Card Code The customer’s card code The three- or four-digit number on the back of a
credit card (on the front for American Express).

This field is required if you would like to use the

Card Code Verification (CCV) security feature.
eCheck Type The type of eCheck.Net Applicable only when eCheck.Net is enabled for
transaction the payment gateway account. For more
information about eCheck.Net, visit
http://www.authorize.net/echeck.

Indicates the type of eCheck.Net payment

request.
FIELD VALUE NOTES

ORDER INFORMATION
Invoice Number The merchant assigned invoice The invoice number must be created dynamically
number for the transaction on the merchant server or provided on a per-
transaction basis. The payment gateway does not
perform this function.

Also, in order to be included on the hosted

payment form, the attribute View must be
configured for this field in the Merchant Interface
payment form settings.
Description The transaction description The description must be created dynamically on
the merchant server or provided on a per-
transaction basis. The payment gateway does not
perform this function.

Also, in order to be displayed, the attribute View

must be configured for this field in the Merchant
Interface payment form settings.

FIELD VALUE NOTES

BILLING INFORMATION
First Name The first name associated with
the customer’s billing address
Last Name The last name associated with
the customer’s billing address

Company The company associated with

the customer’s billing address

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 22
Merchant Integration Guide

Address The customer’s billing address Required if the merchant would like to use the
Address Verification Service filter.
City The city of the customer’s billing
address
State The state of the customer’s
billing address
ZIP Code The ZIP code of the customer’s Required if the merchant would like to use the
billing address Address Verification Service filter.

Country The country of the customer’s

billing address
Phone The phone number associated
with the customer’s billing
address
FAX The fax number associated with
the customer’s billing address
Email The customer’s valid email The email address to which the customer’s email
address receipt is sent. The email is sent to the customer
only if the email address format is valid.

Customer ID The merchant assigned The unique identifier to represent the customer
customer ID associated with the transaction.

Also, in order to be displayed, the attribute View

must be configured for this field in the Merchant
Interface payment form settings.

FIELD VALUE NOTES

SHIPPING INFORMATION
First Name The first name associated with
the customer’s shipping address
Last Name The last name associated with
the customer’s shipping address
Company The company associated with
the customer’s shipping address
Address The customer’s shipping address

City The city of the customer’s

shipping address
State The state of the customer’s
shipping address
ZIP Code The ZIP code of the customer’s
shipping address
Country The country of the customer’s
shipping address

FIELD VALUE NOTES

ADDITIONAL SHIPPING INFORMATION (Level 2 Data)

Tax The valid tax amount The tax amount charged.

When configured in the integration code, this field

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 23
 Section 3 Integration Settings

can also include a tax item name and description.

Contact your Web developer for more information.

The total amount of the transaction must include

this amount.
Freight The valid freight amount The freight amount charged.

When configured in the integration code, this field

can also include a freight item name and
description. Contact your Web developer for more
information.

The total amount of the transaction must include

this amount.
Duty The valid duty amount OR The duty amount charged.
delimited duty information
When configured in the integration code, this field
can also include a duty item name and
description. Contact your Web developer for more
information.

The total amount of the transaction must include

this amount.
Tax Exempt The tax exempt status Indicates whether the transaction is tax exempt.
Purchase Order The merchant assigned The purchase order number must be created
Number purchase order number dynamically on the merchant server or provided
on a per-transaction basis. The payment gateway
does not perform this function.

Also, in order to be displayed, the attribute View

must be configured for this field in the Merchant
Interface payment form settings.

Note: The hosted payment form can be configured to submit either Authorization and Capture or
Authorization Only transactions. Please communicate any preferences regarding which of
these credit card transaction types should be used for your Web site transactions to your
Web developer.

Customizing the Hosted Payment Form

When using the payment gateway hosted payment form, you can also configure the following
settings to match the look of your Web site:

• The color of the text

• The color of link text
• The background color
• The header text (this can include HTML)
• The footer text (this can include HTML)

To configure the look of the payment gateway hosted payment form:

1. Log into the Merchant Interface at https://secure.authorize.net

2. Click Settings under Account in the main menu on the left
3. Click Payment Form in the Transaction Submission section

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 24
Merchant Integration Guide

4. Click on any of the provided links to configure the different elements of the payment form

For specific instructions, click the Help link at the top right corner of each Merchant Interface page.

Basic HTML guide

When customizing headers and/or footers for your hosted payment form and receipt page, you can
use the following basic hypertext markup language (HTML) tags and codes to specify font and
paragraph formatting and create hyperlinks. Simply use the following tags around your text, as
shown in the examples.

FORMAT HTML TAGS OR CODES EXAMPLE RENDERING

Opening tag: <b> <b>Your text here</b> Your text here
Bold
Closing tag: </b>
Opening tag: <i> <i>Your text here</i>
Italic Your text here
Closing tag: </i>
Opening tags: <b><i> <b><i>Your text
Bold Italic Your text here
Closing tags: </i></b> here</i></b>
Opening tag: <br> Your<br>text<br>here Your
Line Break
Closing tag: Not needed text
here
Opening tag: <hr> Your<hr>text<hr>here Your
Horizontal
Rule Closing tag: Not needed
text

here
Opening tag: <p> Your<p>paragraphs</p> Your
Paragraph
Closing tag: </p> <p>here</p> paragraphs
here
Hyperlink Opening tag: <a <a href= Link text here
href=”URL here”> ”http://www.yourURL.co
Closing tag: </a> m”> Link text here</a>
Email Link Opening tag: <a href= <a href=”mailto:your@ [email protected]
”mailto:email emailaddress.com”>your
address here”> @emailaddress.com</a>
Closing tag: </a>
Single Left single quote: &lsquo;Your text ‘Your text here’
Quote &lsquo; here&rsquo;
Right single quote:
&rsquo;
Double Left double quote: &ldquo;Your text “Your text here”
Quote &ldquo; here&rdquo;
Right double quote:
&rdquo;

There are many ways to use HTML code in the payment form and receipt page headers and footers.
You might choose to reference a cascading style sheet (CSS). A CSS is a separate HTML document
that defines formatting styles such as font and text color and size. Please contact your Web
developer with any questions you have about using HTML tags and codes, or about using a CSS in
your form headers and footers.

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 25
 Section 3 Integration Settings

Logos and background images

If you would like to use a logo and/or background image on the hosted payment form, image files
must be uploaded to the payment gateway server in order to be displayed properly. The location of
the logo and background images on the payment gateway server must be referenced in the header or
footer.

To upload a logo or background image to the payment gateway:

1. Save the file in any of the following formats: .gif, .jpg, .png, or .swf (other file formats will
not be accepted).
2. If needed, rename the logo or background image according to the following Authorize.Net
naming convention:

• Only use letters, numbers and/or the underscore character

• Do not use spaces
• You must include your merchant ID and one of the following prefixes for identification
purposes: logo_, background_, header_, footer. (If you do not know your merchant ID,
refer to the Merchant Profile page in the Account menu of the Merchant Interface.)

Good Examples: Bad Examples:

logo_merchantIDhere.jpg logo.jpg
background_merchantIDhere.png background.jpg
header_merchantIDhere.swf online forms.png
footer_merchantIDhere.gif

3. Send the logo and/or background file in an email to [email protected] with the subject
line “Payment Form Image Upload.” The images are then uploaded to a secure payment
gateway server.

4. To reference the logo or background image, add the following HTML to the payment form
and/or receipt page header or footer:

<img src="https://secure.authorize.net/mgraphics/filename.ext">

Note: The maximum character length allowed when configuring header or footer text in
the Merchant Interface is 255. If you are including a lot of text, links or graphics,
you will need to arrange with your Web developer to include the header
information as part of the integration code. There is no character limit when
configuring payment form header text in the integration code.

If you are not comfortable uploading an image to the payment gateway or adding HTML to the
form header or footer yourself, you can ask your Web developer for help.

Receipt page options

In addition to the secure hosted payment form, SIM also provides two options for communicating
the transaction results to the customer: the payment gateway hosted receipt page OR Relay
Response.

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 26
Merchant Integration Guide

• The hosted receipt page is a brief transaction summary that is displayed in the customer’s
Web browser from the secure payment gateway server. It can be configured to match the
look and feel of your Web site.

• The Relay Response feature of SIM allows you to create a custom receipt page using
transaction results information returned by the payment gateway. The custom receipt page
is then relayed by the payment gateway to the customer’s Web browser.

Note: Only one receipt page option should be implemented. Implementing both options can cause
integration errors. Please contact your Web developer for help deciding which receipt
option best meets your business needs.

Hosted Receipt Page

The formatting of the hosted receipt page is similar to the formatting configured for the hosted
payment form. For example, the text and link color and background color will be the same.
However, the following settings are unique to the hosted receipt page.

• The receipt link (the URL or Web address included on the hosted receipt page that will
return customers to your Web site)
• The receipt method (the link method, for example, a regular link or a button)

Note: Please contact your Web developer before changing the receipt method setting, as
it may depend on how your Web site is integrated to the payment gateway.

• Receipt link text (the text that should be displayed for the link back to your Web site)
• The header text (this can include HTML)
• The footer text (this can include HTML)

To configure the payment gateway hosted receipt page:

1. Log into the Merchant Interface at https://secure.authorize.net

2. Select Settings under Account in the main menu on the left
3. Click Receipt Page in the Transaction Response section
4. Click on any of the provided links to configure the different elements of the receipt page

For specific instructions, click the Help link at the top right corner of each Merchant Interface page.

Relay Response
A Relay Response configuration indicates to the payment gateway that you would like to receive
the transaction response and use it to create a custom receipt page for display to the customer.

To configure Relay Response for your transactions:

1. Log into the Merchant Interface at https://secure.authorize.net

2. Click Settings under Account in the main menu on the left
3. Click Relay Response in the Transaction Format Settings section

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 27
 Section 3 Integration Settings

4. Enter the URL to which the payment gateway should post the transaction response for
custom receipt page formatting
5. Click Submit

Configuring this URL in effect enables Relay Response for your payment gateway account.

Note: The Relay Response URL should only be configured if a Relay Response is desired.
Configuring both the hosted receipt page and a Relay Response can result in a failed
implementation. You may want to contact your Web developer to verify that only one
of the hosted receipt page and Relay Response options are configured for your
integration.

Silent Post URL

If you would like to use transaction response information for purposes other than creating a custom
receipt page, such as integration with proprietary business processes or applications, a Silent Post
URL can also be configured in the Merchant Interface. The Silent Post URL is a location on your
Web server where the payment gateway can “carbon copy” the transaction response. This allows
you to use transaction response information for other purposes separately without affecting the
amount of time it takes to respond to the payment gateway with a custom receipt page from the
Relay Response URL.

To configure the Silent Post URL:

1. Log into the Merchant Interface at https://secure.authorize.net

2. Click Settings under Account in the main menu on the left
3. Click Silent Post URL in the Transaction Format Settings section
4. Enter the secondary URL to which you would like the payment gateway to copy the
transaction response
5. Click Submit

MD5 Hash
The MD5 Hash feature allows you to authenticate that transaction responses are securely received
from Authorize.Net. The payment gateway creates the MD5 hash using the following pieces of
account and transaction information as input:

• MD5 Hash value

• API Login ID
• Transaction ID
• Transaction Amount

The MD5 Hash value is a random value that you configure in the Merchant Interface.

To configure an MD5 Hash value for your account:

1. Log into the Merchant Interface at https://secure.authorize.net

2. Click Settings under Account in the main menu on the left
3. Click MD5-Hash in the Security Settings section
4. Enter any random value to use for your MD5 Hash Value. Enter the value again to confirm
5. Click Submit

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 28
Merchant Integration Guide

Please note that the MD5 Hash value is not displayed on the screen once submitted. You will need
to store the value securely and update your Web developer any time you change the value.

Email Receipt
In addition to the hosted payment form and receipt page, the payment gateway also provides an
email receipt. You may opt to send an email receipt to any customer who provides their email
address. The email receipt includes a summary and results of the transaction. To the customer, this
email appears to be sent from the merchant email address that is configured as the Email Sender in
the User Profile settings of the Merchant Interface.

To opt to send an email receipt to your customers:

1. Log into the Merchant Interface at https://secure.authorize.net

2. Click Settings under Account in the main menu on the left
3. Click Email Receipt in the Transaction Format Settings section
4. Click to select the check box labeled Email transaction receipt to customer
5. Click Submit to save changes

This setting also allows you to customize text for the email receipt header and footer. Add the
header and footer text you would like to use for your email receipts in the appropriate text fields.

To verify or configure the Email Sender for your account:

1. Log into the Merchant Interface at https://secure.authorize.net

2. Click User Profile under Account in the main menu on the left OR if this option is not
available for your account, click Settings in the Account section
3. Click Edit Profile Information OR if you are in the Settings menu, click Manage
Contacts in the Business Settings section and click Edit next to the account contact that
should be configured as the Email Sender
4. Click to select the check box labeled Use this email address as sender in the Specify
Email Sender section
5. Click Submit to save changes

You may also opt to receive a confirmation email from the payment gateway at the completion of
each transaction, which includes the results of the transaction and order information.

To receive confirmation emails:

1. Log into the Merchant Interface at https://secure.authorize.net

2. Click User Profile under Account in the main menu on the left OR if this option is not
available for your account, click Settings in the Account section
3. Click Edit Profile Information OR if you are in the Settings menu, click Manage
Contacts in the Business Settings section and click Edit next to the account contact that
should receive confirmation emails
4. Click to select the check box labeled Transaction Receipt in the Transaction Emails
section
5. Click Submit to save changes

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 29
 Section 3 Integration Settings

If you are an Account Owner or Account Administrator, you can configure these settings for other
users as well on the User Administration page in the Account menu.

1. Click User Administration under account in the Merchant Interface main menu
2. Click on the name of the user who you would like to receive the confirmation email
3. Click Edit Profile Information
4. Click to select the check box labeled Transaction Receipt in the Transaction Emails
section
5. Click Submit to save changes

Advanced Integration Method (AIM) Settings

If you are connecting to the payment gateway using AIM, the following sections describe the
integration settings you will need to understand in order to configure them properly in the Merchant
Interface.

Please be aware that connection settings that can be configured in the Merchant Interface may also
be hard coded in your Web site code. To maintain a robust connection to the payment gateway, it is
highly recommended that you work closely with your Web developer to identify those settings that
should be hard coded in your Web site code versus those settings that you may need to configure
yourself from time to time in the Merchant Interface.

Please keep in mind that AIM involves the collection, transmission, and storage of cardholder data
on your Web server. As such, compliance with the PCI Data Security Standard is required by the
Card Associations. For more information, please see our Security Best Practices White Paper at
http://www.authorize.net/files/securitybestpractices.pdf and Developer Best Practices White Paper
at http://www.authorize.net/files/developerbestpractices.pdf.

Direct Response
For AIM, the payment gateway communicates transaction response information to the merchant
Web server directly and securely with a delimited text string. Delimited means that each piece of
information in the string is separated by a distinct character indicating to computer programs where
one piece of information ends and the next begins.

Though the payment gateway formats this information using a default field separating character (a
comma), you can configure this and additional settings to ensure that information is communicated
between the merchant Web server and payment gateway correctly at all times.

In addition to the field separator, you can configure an encapsulation character. An encapsulation
character works similarly to the field separator and is really only necessary in the event that the
field separator could potentially be included in an actual field value. For example, if the default
field separator is a comma, but a piece of information in the transaction response includes a comma
as part of a value, (street address or company name, etc.), it will cause an error for computer
programs trying to extract information from the string. As an additional protection from this type of
error, the encapsulation character wraps around each piece of information to further differentiate it
from the other values. In the example below, the comma is the field separator and the quotation
marks are the encapsulation character.

“AUTH_CAPTURE”,”12-98790”,”Jane”,”Doe”,”Jane’s, Inc.”,”201 Center St.”,

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 30
Merchant Integration Guide

Depending on the computer programs that will be using the information, you may need to configure
custom field separator and encapsulation characters for your transaction responses from the
payment gateway. It is recommended that you use characters that are uncommon in transaction
information values, for example, the pipe (|).

To configure direct response:

1. Log into the Merchant Interface at https://secure.authorize.net

2. Click Settings under Account in the main menu on the left
3. Click Direct Response in the Transaction Format Settings section
4. Click to select the radio button labeled Yes next to Delimited Response
5. Select the character you would like to use from the Field Separator drop-down list
6. Select the character you would like to use from the Field Encapsulation Character drop-
down list
7. Click Submit

Note: Check with your Web developer before changing field separator and encapsulation
characters as it may affect the integration of transaction response information with other
computer programs.

Cardholder Authentication Programs

The Authorize.Net Payment Gateway provides support for cardholder authentication information
passed from third party solutions for Verified by Visa and MasterCard® SecureCode®. If you use
such a service in conjunction with your Web site transactions, additional integration is required for
your Web site. Contact your Web developer and refer them to the “Cardholder Authentication”
section of the Advanced Integration Method (AIM) Developer Guide at
http://developer.authorize.net/guides/AIM/default.htm.

Note: Cardholder authentication is currently supported for AIM transactions only through the
Chase Paymentech, FDMS Nashville, Global Payments and TSYS processors for Visa and
MasterCard transactions. If cardholder authentication information is submitted for
transactions processed through any other processor, it will be ignored.

eCheck.Net® Transactions
If you are signed up for eCheck.Net®, you are required to submit the following information for
electronic check transactions:

• ABA Routing Number

• Bank Account Number
• Bank Account Type
• Bank Name
• Bank Account Name
• eCheck.Net Type

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 31
 Section 3 Integration Settings

As such, additional integration is required for your Web site. Contact your Web developer and refer
them to the eCheck.Net® Developer Guide at http://developer.authorize.net/guides/eCheck.pdf for
more information. For more information about the eCheck.Net service, see
http://www.authorize.net/echeck.

Additional Integration Features

The following sections provide information about integration features that don’t involve settings in
the Merchant Interface, but that do provide additional capabilities for your integration to the
payment gateway and transaction processing.

Itemized Order Information

Based on your unique business requirements, you may choose to submit itemized order, or line
item, information with each transaction. Itemized order information is not submitted to the
processor and is not currently returned with the transaction response. However, this information is
displayed on the Transaction Detail page and in the QuickBooks® download file reports in the
Merchant Interface. For more information about these features, please see the Merchant Interface
Online Help Files (after logging into the Merchant Interface, click the Help link in the top right
corner of the page).

Unlike most other integration settings for your account, this feature is not configured in the
Merchant Interface. Please contact your Web developer for more information on how to submit
detailed order information with transactions to the payment gateway.

Merchant-Defined Fields
You may also choose to submit merchant-defined fields to further customize the information that is
included with a transaction. Merchant-defined fields are any fields that are not recognized by the
payment gateway as standard application programming interface (API) payment form fields. For
example, you may want to provide a field in your checkout process where customers may provide
specific shipping instructions or product color information.

Merchant-defined fields are included with the transaction response and in the merchant
confirmation email for the merchant’s records. However, they are not provided on the Transaction
Detail page in the Merchant Interface. Contact your Web developer for more information on how to
submit merchant-defined fields with transactions to the payment gateway.

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 32
Section 4
Transaction Response

The payment gateway will return transaction results for all Advanced Integration Method (AIM)
transactions and Server Integration Method (SIM) with Relay Response transactions. The
transaction response indicates whether the transaction was accepted or declined and includes
information about the transaction.

Fields included in the payment gateway response are provided in the table below.

ORDER FIELD NAME VALUE FORMAT NOTES

1 Response Code The overall status of 1 = Approved
the transaction 2 = Declined
3 = Error
4 = Held for Review
2 Response Subcode A code used by the
payment gateway
for internal
transaction tracking
3 Response Reason A code that Numeric See the “Response Codes
Code represents more Details” section of this
details about the document for a listing of
result of the response reason codes.
transaction
4 Response Reason A brief description Text
Text of the result, which
corresponds with
the response
reason code
5 Authorization Code The authorization or 6 characters
approval code
6 AVS Response The Address A = Address (Street) Indicates the result of the
Verification Service matches, ZIP does not AVS filter.
(AVS) response B = Address information
code not provided for AVS See the “Address
check Verification Service (AVS)
E = AVS error Filter” section of this
G = Non-U.S. Card document for more
Issuing Bank information.
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

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 33
 Section 4 Transaction Response

ORDER FIELD NAME VALUE FORMAT NOTES

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 The payment This value must be used for
gateway assigned Credit, Prior Authorization
identification and Capture and Void
number for the transactions.
transaction
8 Invoice Number The merchant Up to 20 characters (no
assigned invoice symbols)
number for the
transaction
9 Description The transaction Up to 255 characters (no
description symbols)
10 Amount The amount of the Up to 15 digits
transaction
11 Method The payment CC or ECHECK
method
12 Transaction Type The type of credit AUTH_CAPTURE,
card transaction AUTH_ONLY,
CAPTURE_ONLY,
CREDIT, PRIOR_
AUTH_CAPTURE, VOID
13 Customer ID The merchant Up to 20 characters (no
assigned customer symbols)
ID
14 First Name The first name Up to 50 characters (no
associated with the symbols)
customer’s billing
address
15 Last Name The last name Up to 50 characters (no
associated with the symbols)
customer’s billing
address
16 Company The company Up to 50 characters (no
associated with the symbols)
customer’s billing
address
17 Address The customer’s Up to 60 characters (no
billing address symbols)
18 City The city of the Up to 40 characters (no
customer’s billing symbols)
address
19 State The state of the Up to 40 characters (no
customer’s billing symbols) or a valid two-
address character state code
20 ZIP Code The ZIP code of the Up to 20 characters (no
customer’s billing symbols)
address

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 34
Merchant Integration Guide

ORDER FIELD NAME VALUE FORMAT NOTES

21 Country The country of the Up to 60 characters (no
customer’s billing symbols)
address
22 Phone The phone number Up to 25 digits (no letters)
associated with the
customer’s billing Ex. (123)123-1234
address
23 Fax The fax number Up to 25 digits (no letters)
associated with the
customer’s billing Ex. (123)123-1234
address
24 Email Address The customer’s Up to 255 characters
valid email address
25 Ship To First Name The first name Up to 50 characters (no
associated with the symbols)
customer’s shipping
address
26 Ship To Last Name The last name Up to 50 characters (no
associated with the symbols)
customer’s shipping
address
27 Ship To Company The company Up to 50 characters (no
associated with the symbols)
customer’s shipping
address
28 Ship To Address The customer’s Up to 60 characters (no
shipping address symbols)
29 Ship To City The city of the Up to 40 characters (no
customer’s shipping symbols)
address
30 Ship To State The state of the Up to 40 characters (no
customer’s shipping symbols) or a valid two-
address character state code
31 Ship To ZIP Code The ZIP code of the Up to 20 characters (no
customer’s shipping symbols)
address
32 Ship To Country The country of the Up to 60 characters (no
customer’s shipping symbols)
address
33 Tax The tax amount Numeric Delimited tax information is
charged not included in the
transaction response.
34 Duty The duty amount Numeric Delimited duty information
charged is not included in the
transaction response.
35 Freight The freight amount Numeric Delimited freight information
charged is not included in the
transaction response.
36 Tax Exempt The tax exempt TRUE, FALSE,
status T, F,
YES, NO,
Y, N,
1, 0

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 35
 Section 4 Transaction Response

ORDER FIELD NAME VALUE FORMAT NOTES

37 Purchase Order The merchant Up to 25 characters (no
Number assigned purchase symbols)
order number
38 MD5 Hash The payment See the “MD5 Hash”
gateway generated section of this document for
MD5 hash value more information.
that may be used to
authenticate the This feature is not
transaction necessary for AIM.
response.
39 Card Code The card code M = Match Indicates the result of the
Response verification (CCV) N = No Match CCV filter.
response code P = Not Processed
S = Should have been See the “Card Code
present Verification (CCV) Filter”
U = Issuer unable to section of this document for
process request more information.
40 Cardholder The cardholder Blank or not present =
Authentication authentication CAVV not validated
Verification verification 0 = CAVV not validated
Response response code 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)
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

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 36
Merchant Integration Guide

Response Code Details

The following tables describe the response codes and response reason texts that are returned for
each transaction.

• Response Code indicates the overall status of the transaction with possible values of
approved, declined, errored held for review.

• Response Reason Code is a numeric representation of a more specific reason for the
transaction status

• Response Reason Text details the specific reason for the transaction status. This
information can be returned to you and/or the customer to provide more information about
the status of their transaction.

Response Codes
RESPONSE CODE DESCRIPTION
1 This transaction has been approved.
2 This transaction has been declined.
3 There has been an error processing this transaction.
4 This transaction is being held for review.

Response Reason Codes and Response Reason Text

RESPONSE RESPONSE RESPONSE REASON TEXT NOTES
CODE REASON
CODE
1 1 This transaction has been approved.
2 2 This transaction has been declined.
2 3 This transaction has been declined.
2 4 This transaction has been declined. The code returned from the processor
indicating that the card used needs to
be picked up.
3 5 A valid amount is required. The value submitted in the amount
field did not pass validation for a
number.
3 6 The credit card number is invalid.
3 7 The credit card expiration date is invalid. The format of the date submitted was
incorrect.
3 8 The credit card has expired.
3 9 The ABA code is invalid. The value submitted in the
x_bank_aba_code field did not pass
validation or was not for a valid
financial institution.
3 10 The account number is invalid. The value submitted in the
x_bank_acct_num field did not pass
validation.
3 11 A duplicate transaction has been A transaction with identical amount
submitted. and credit card information was
submitted two minutes prior.
3 12 An authorization code is required but not A transaction that required
present. x_auth_code to be present was
submitted without a value.
3 13 The merchant API Login ID is invalid or

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 37
 Section 4 Transaction Response

RESPONSE RESPONSE RESPONSE REASON TEXT NOTES

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

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 38
Merchant Integration Guide

RESPONSE RESPONSE RESPONSE REASON TEXT NOTES

CODE REASON
CODE
Merchant Service Provider.
3 40 This transaction must be encrypted.
2 41 This transaction has been declined. Only merchants set up for the
FraudScreen.Net service would
receive this decline. This code will be
returned if a given transaction’s fraud
score is higher than the threshold set
by the merchant.
3 43 The merchant was incorrectly set up at The merchant was incorrectly set up at
the processor. Call your Merchant the processor.
Service Provider.
2 44 This transaction has been declined. The card code submitted with the
transaction did not match the card
code on file at the card issuing bank
and the transaction was declined.
2 45 This transaction has been declined. This error would be returned if the
transaction received a code from the
processor that matched the rejection
criteria set by the merchant for both
the AVS and Card Code filters.
3 46 Your session has expired or does not
exist. You must log in to continue
working.
3 47 The amount requested for settlement This occurs if the merchant tries to
may not be greater than the original capture funds greater than the amount
amount authorized. of the original authorization-only
transaction.
3 48 This processor does not accept partial The merchant attempted to settle for
reversals. less than the originally authorized
amount.
3 49 A transaction amount greater than The transaction amount submitted was
$[amount] will not be accepted. greater than the maximum amount
allowed.
3 50 This transaction is awaiting settlement Credits or refunds may only be
and cannot be refunded. performed against settled transactions.
The transaction against which the
credit/refund was submitted has not
been settled, so a credit cannot be
issued.
3 51 The sum of all credits against this
transaction is greater than the original
transaction amount.
3 52 The transaction was authorized, but the
client could not be notified; the
transaction will not be settled.
3 53 The transaction type was invalid for If x_method = ECHECK, x_type cannot
ACH transactions. be set to CAPTURE_ONLY.
3 54 The referenced transaction does not
meet the criteria for issuing a credit.
3 55 The sum of credits against the The transaction is rejected if the sum
referenced transaction would exceed the of this credit and prior credits exceeds
original debit amount. the original debit amount.
3 56 This merchant accepts ACH The merchant processes eCheck.Net
transactions only; no credit card transactions only and does not accept
transactions are accepted. credit cards.

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 39
 Section 4 Transaction Response

RESPONSE RESPONSE RESPONSE REASON TEXT NOTES

CODE REASON
CODE
3 57 - 63 An error occurred in processing. Please
try again in 5 minutes.
2 65 This transaction has been declined. The transaction was declined because
the merchant configured their account
through the Merchant Interface to
reject transactions with certain values
for a Card Code mismatch.
3 66 This transaction cannot be accepted for The transaction did not meet gateway
processing. security guidelines.
3 68 The version parameter is invalid. The value submitted in x_version was
invalid.
3 69 The transaction type is invalid. The value submitted in x_type was
invalid.
3 70 The transaction method is invalid. The value submitted in x_method was
invalid.
3 71 The bank account type is invalid. The value submitted in
x_bank_acct_type was invalid.
3 72 The authorization code is invalid. The value submitted in x_auth_code
was more than six characters in length.
3 73 The driver’s license date of birth is The format of the value submitted in
invalid. x_drivers_license_dob was invalid.
3 74 The duty amount is invalid. The value submitted in x_duty failed
format validation.
3 75 The freight amount is invalid. The value submitted in x_freight failed
format validation.
3 76 The tax amount is invalid. The value submitted in x_tax failed
format validation.
3 77 The SSN or tax ID is invalid. The value submitted in
x_customer_tax_id failed validation.
3 78 The Card Code (CVV2/CVC2/CID) is The value submitted in x_card_code
invalid. failed format validation.
3 79 The driver’s license number is invalid. The value submitted in
x_drivers_license_num failed format
validation.
3 80 The driver’s license state is invalid. The value submitted in
x_drivers_license_state failed format
validation.
3 81 The requested form type is invalid. The merchant requested an integration
method not compatible with the AIM
API.
3 82 Scripts are only supported in version The system no longer supports version
2.5. 2.5; requests cannot be posted to
scripts.
3 83 The requested script is either invalid or The system no longer supports version
no longer supported. 2.5; requests cannot be posted to
scripts.
3 84 - 90 This reason code is reserved or not
applicable to this API.
3 91 Version 2.5 is no longer supported.
3 92 The gateway no longer supports the
requested method of integration.
3 97 This transaction cannot be accepted. Applicable only to SIM API.
Fingerprints are only valid for a short
period of time. This code indicates that

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 40
Merchant Integration Guide

RESPONSE RESPONSE RESPONSE REASON TEXT NOTES

CODE REASON
CODE
the transaction fingerprint has expired.
3 98 This transaction cannot be accepted. Applicable only to SIM API. The
transaction fingerprint has already
been used.
3 99 This transaction cannot be accepted. Applicable only to SIM API. The
server-generated fingerprint does not
match the merchant-specified
fingerprint in the x_fp_hash field.
3 100 The eCheck.Net type is invalid. Applicable only to eCheck.Net. The
value specified in the x_echeck_type
field is invalid.
3 101 The given name on the account and/or Applicable only to eCheck.Net. The
the account type does not match the specified name on the account and/or
actual account. the account type do not match the
NOC record for this account.
3 102 This request cannot be accepted. A password or Transaction Key was
submitted with this WebLink request.
This is a high security risk.
3 103 This transaction cannot be accepted. A valid fingerprint, Transaction Key, or
password is required for this
transaction.
3 104 This transaction is currently under Applicable only to eCheck.Net. The
review. value submitted for country failed
validation.
3 105 This transaction is currently under Applicable only to eCheck.Net. The
review. values submitted for city and country
failed validation.
3 106 This transaction is currently under Applicable only to eCheck.Net. The
review. value submitted for company failed
validation.
3 107 This transaction is currently under Applicable only to eCheck.Net. The
review. value submitted for bank account
name failed validation.
3 108 This transaction is currently under Applicable only to eCheck.Net. The
review. values submitted for first name and
last name failed validation.
3 109 This transaction is currently under Applicable only to eCheck.Net. The
review. values submitted for first name and
last name failed validation.
3 110 This transaction is currently under Applicable only to eCheck.Net. The
review. value submitted for bank account
name does not contain valid
characters.
3 116 The authentication indicator is invalid. This error is only applicable to Verified
by Visa and MasterCard SecureCode
transactions. The ECI value for a Visa
transaction; or the UCAF indicator for a
MasterCard transaction submitted in
the x_authentication_indicator field is
invalid.
3 117 The cardholder authentication value is This error is only applicable to Verified
invalid. by Visa and MasterCard SecureCode
transactions. The CAVV for a Visa
transaction; or the AVV/UCAF for a
MasterCard transaction is invalid.

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 41
 Section 4 Transaction Response

RESPONSE RESPONSE RESPONSE REASON TEXT NOTES

CODE REASON
CODE
3 118 The combination of authentication This error is only applicable to Verified
indicator and cardholder authentication by Visa and MasterCard SecureCode
value is invalid. transactions. The combination of
authentication indicator and cardholder
authentication value for a Visa or
MasterCard transaction is invalid.

For more information, see the

“Cardholder Authentication” section of
this document.
3 119 Transactions having cardholder This error is only applicable to Verified
authentication values cannot be marked by Visa and MasterCard SecureCode
as recurring. transactions. Transactions submitted
with a value in
x_authentication_indicator and
x_recurring_billing=YES will be
rejected.
3 120 An error occurred during processing. The system-generated void for the
Please try again. original timed-out transaction failed.
(The original transaction timed out
while waiting for a response from the
authorizer.)
3 121 An error occurred during processing. The system-generated void for the
Please try again. original errored transaction failed. (The
original transaction experienced a
database error.)
3 122 An error occurred during processing. The system-generated void for the
Please try again. original errored transaction failed. (The
original transaction experienced a
processing error.)
3 123 This account has not been given the The transaction request must include
permission(s) required for this request. the API Login ID associated with the
payment gateway account.
2 127 The transaction resulted in an AVS The system-generated void for the
mismatch. The address provided does original AVS-rejected transaction
not match billing address of cardholder. failed.
3 128 This transaction cannot be processed. The customer’s financial institution
does not currently allow transactions
for this account.
3 130 This payment gateway account has IFT: The payment gateway account
been closed. status is Blacklisted.
3 131 This transaction cannot be accepted at IFT: The payment gateway account
this time. status is Suspended-STA.
3 132 This transaction cannot be accepted at IFT: The payment gateway account
this time. status is Suspended-Blacklist.
2 141 This transaction has been declined. The system-generated void for the
original FraudScreen-rejected
transaction failed.
2 145 This transaction has been declined. The system-generated void for the
original card code-rejected and AVS-
rejected transaction failed.
3 152 The transaction was authorized, but the The system-generated void for the
client could not be notified; the original transaction failed. The
transaction will not be settled. response for the original transaction
could not be communicated to the
client.

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 42
Merchant Integration Guide

RESPONSE RESPONSE RESPONSE REASON TEXT NOTES

CODE REASON
CODE
2 165 This transaction has been declined. The system-generated void for the
original card code-rejected transaction
failed.
3 170 An error occurred during processing. Concord EFS – Provisioning at the
Please contact the merchant. processor has not been completed.
3 171 An error occurred during processing. Concord EFS – This request is invalid.
Please contact the merchant.
3 172 An error occurred during processing. Concord EFS – The store ID is invalid.
Please contact the merchant.
3 173 An error occurred during processing. Concord EFS – The store key is
Please contact the merchant. invalid.
3 174 The transaction type is invalid. Please Concord EFS – This transaction type is
contact the merchant. not accepted by the processor.
3 175 The processor does not allow voiding of Concord EFS – This transaction is not
credits. allowed. The Concord EFS processing
platform does not support voiding
credit transactions. Please debit the
credit card instead of voiding the
credit.
3 180 An error occurred during processing. The processor response format is
Please try again. invalid.
3 181 An error occurred during processing. The system-generated void for the
Please try again. original invalid transaction failed. (The
original transaction included an invalid
processor response format.)
3 185 This reason code is reserved or not
applicable to this API.
4 193 The transaction is currently under The transaction was placed under
review. review by the risk management
system.
2 200 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. The credit
card number is invalid.
2 201 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. The
expiration date is invalid.
2 202 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. The
transaction type is invalid.
2 203 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. The value
submitted in the amount field is invalid.
2 204 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. The
department code is invalid.
2 205 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. The value
submitted in the merchant number field
is invalid.
2 206 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. The
merchant is not on file.
2 207 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. The
merchant account is closed.

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 43
 Section 4 Transaction Response

RESPONSE RESPONSE RESPONSE REASON TEXT NOTES

CODE REASON
CODE
2 208 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. The
merchant is not on file.
2 209 This transaction has been declined. This error code applies only to
merchants on FDC Omaha.
Communication with the processor
could not be established.
2 210 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. The
merchant type is incorrect.
2 211 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. The
cardholder is not on file.
2 212 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. The bank
configuration is not on file.
2 213 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. The
merchant assessment code is
incorrect.
2 214 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. This
function is currently unavailable.
2 215 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. The
encrypted PIN field format is invalid.
2 216 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. The ATM
term ID is invalid.
2 217 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. This
transaction experienced a general
message format problem.
2 218 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. The PIN
block format or PIN availability value is
invalid.
2 219 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. The ETC
void is unmatched.
2 220 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. The
primary CPU is not available.
2 221 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. The SE
number is invalid.
2 222 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. Duplicate
auth request (from INAS).
2 223 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. This
transaction experienced an unspecified
error.
2 224 This transaction has been declined. This error code applies only to
merchants on FDC Omaha. Please re-

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 44
Merchant Integration Guide

RESPONSE RESPONSE RESPONSE REASON TEXT NOTES

CODE REASON
CODE
enter the transaction.
3 243 Recurring billing is not allowed for this The combination of values submitted
eCheck.Net type. for x_recurring_billing and
x_echeck_type is not allowed.
3 244 This eCheck.Net type is not allowed for The combination of values submitted
this Bank Account Type. for x_bank_acct_type and
x_echeck_type is not allowed.
3 245 This eCheck.Net type is not allowed The value submitted for
when using the payment gateway x_echeck_type is not allowed when
hosted payment form. using the payment gateway hosted
payment form.
3 246 This eCheck.Net type is not allowed. The merchant’s payment gateway
account is not enabled to submit the
eCheck.Net type.
3 247 This eCheck.Net type is not allowed. The combination of values submitted
for x_type and x_echeck_type is not
allowed.
2 250 This transaction has been declined. This transaction was submitted from a
blocked IP address.

2 251 This transaction has been declined. The transaction was declined as a
result of triggering a Fraud Detection
Suite filter.
4 252 Your order has been received. Thank The transaction was accepted, but is
you for your business! being held for merchant review. The
merchant may customize the customer
response in the Merchant Interface.
4 253 Your order has been received. Thank The transaction was accepted and was
you for your business! authorized, but is being held for
merchant review. The merchant may
customize the customer response in
the Merchant Interface.
2 254 Your transaction has been declined. The transaction was declined after
manual review.
3 261 An error occurred during processing. The transaction experienced an error
Please try again. during sensitive data encryption and
was not processed. Please try again.
3 270 The line item [item number] is invalid. A value submitted in x_line_item for
the item referenced is invalid.
3 271 The number of line items submitted is The number of line items submitted
not allowed. A maximum of 30 line items exceeds the allowed maximum of 30.
can be submitted.

Note: A very helpful tool for troubleshooting errors is available in our Integration Center at
http://developer.authorize.net/tools/responsereasoncode.

Last revised: 7/17/2008

Copyright © 1998 - 2008 Authorize.Net, a CyberSource solution 45