Developer FAQs

Please visit our documentation for more information on how to integrate e-commerce, mail order/telephone order (MOTO), retail, and mobile applications to the Authorize.Net Payment Gateway.

The recommended method of integration for all Card Not Present (CNP) merchant business models is Advanced Integration Method (AIM). AIM offers the most flexible integration, allowing merchants to host their own secure payment form and send transactions to the payment gateway using an end to end Secure Sockets Layer (SSL) connection.

If you, or your merchant, do not have an SSL certificate, we recommend Server Integration Method (SIM). SIM uses scripting techniques to authenticate transactions with a unique transaction fingerprint. SIM also provides a customizable and secure payment gateway hosted payment form to make integration easy for Web merchants that do not have an SSL certificate. The Authorize.Net Payment Gateway can handle all the steps in the secure transaction process; payment data collection, data submission and the response to the customer.

For Card Present (CP), or retail business models, Authorize.Net also provides a CP integration method designed for developers and providers of point-of-sale (POS) systems and retail payment solutions. Retail and mobile merchants would then simply purchase a ready-to-install POS solution or device.

For additional guidelines on how to choose the integration method that will best meet the needs of the merchant, and for detailed information about AIM, SIM and CP, please see the Implementation Guides.

In order to submit transactions to the Authorize.Net Payment Gateway, you must be able to emulate an HTML form POST using SSL. The transaction response can either be a delimited string or XML.

For more information about how to format transaction data, see our Implementation Guides.

With Authorize.Net, it doesn't matter what platform or development language you use as long as you have a live Internet connection and can emulate an HTML form POST using Secure Sockets Layer (SSL). Most development languages provide libraries or objects that allow you to do this.

Authorize.Net provides sample code in a number of different development languages. Please use our sample code request form, which will automatically e-mail the requested code to you.

Authorize.Net supports any card swipe device that is used in conjunction with our point-of-sale (POS) partners' premier retail and mobile payment processing systems or solutions. To view a list of our certified POS partners, please visit our POS Solutions Directory.

Please use the Test Account Application form to request a test account.

For more information about certifying your shopping cart with Authorize.Net, visit our Certified Solution Program.

In order to be able to support all types of merchants on the Authorize.Net Payment Gateway, the Shopping Cart Certification (SCC) program requires shopping carts to support all Authorize.Net API fields, products, and services; including eCheck.Net® transactions.

Please use the Partner and Developer Inquiry form to request help with your integration project.

The card associations do not currently require payment applications to be PCI certified. However, Visa does provide many useful guidelines and best practices for payment applications that help to provide strengthened security for merchants. Visit Visa's Cardholder Information Security Program (CISP) for more information.

Authorize.Net is fully PCI certified, and dedicates many resources to maintaining our certification with Visa.

Yes. Merchants can submit transactions to the payment gateway on behalf of non-U.S. customers. To do so, the merchant's bank account must be with a financial institution located in the United States, and the merchant must be configured to accept the customer's card type: Visa, MasterCard, American Express, Discover, JCB, Diner's Club, or EnRoute. The payment gateway will submit the amount of the transaction to the customer's card issuer, who will then handle all currency conversion to U.S. dollars. Since default Address Verification Service (AVS) settings may cause foreign transactions to be declined, merchants who plan to regularly accept international transactions should make sure that their AVS settings are configured to meet their business needs.

The payment gateway generated transaction key is a complex value that uniquely identifies a merchant's payment gateway account, and is similar to an account password. Transaction keys are used to authenticate requests submitted to the payment gateway, and can be obtained in the Merchant Interface.

Please follow these steps to obtain a transaction key:

1. Log into the merchant's Authorize.Net account at: https://secure.authorize.net.
2. Click on Settings under Account in the main menu on the left.
3. From the Security Settings section, click API Login ID and Transaction Key.
4. Enter the Secret Answer to your account's Secret Question.
5. Click Submit.

A transaction fingerprint is a hash generated using the HMAC-MD5 hashing algorithm on a set of merchant- and transaction-specific fields, including the merchant's transaction key. A unique, single use transaction fingerprint is required for each transaction sent to the payment gateway using SIM. If the transaction fingerprint cannot be validated by Authorize.Net, the transaction request will be rejected.

No, however, the transaction response will be returned to you in a specific order. For more information about transaction fields and transaction response field order, see our Implementation Guides.

Yes, you can create and submit merchant-defined fields. To do this, simply send your own name value pairs. Authorize.Net will return the value in the transaction response as well as include the value on the merchant e-mail receipt (if your account is configured for merchant e-mail receipts). However, merchant-defined fields are not stored in our database.

The Authorize.Net hosted payment form allows you to customize background and text color, header and footer, as well as the actual information that is displayed on the payment form. The header and footer fields support up to 255 characters, whether passed in the appropriate post string fields or configured in the Merchant Interface. These fields allow you to reference logo images and also support the use of style sheets (.css).

For more information about customizing the Authorize.Net hosted payment form and instructions on how to upload logo images to the Authorize.Net servers, see our Implementation Guides.

If you are using SIM, you have the option of using the Authorize.Net hosted receipt page, or using relay response to send the results of the transaction to a receipt generating script on your Web site.

If you choose to use relay response, your receipt generating script must be able to parse the results of the transaction and print the response to the screen. With relay response, you have more options for using the transaction response, including updating a database, writing to log files, sending customer receipt e-mails, etc.

For more information about relay response, see the SIM Implementation Guide.

Note: Authorize.Net does not return sensitive transaction data such as credit card or bank account information.

Yes. Each Authorize.Net implementation guide includes a detailed listing of all response, or error, codes and the reasons why they would be received. Please refer to our Implementation Guides for more information.

You can also troubleshoot certain errors by using our Response Code Tools.

Yes, there is a Visa error test credit card number. The payment gateway has been designed so that this special test credit card number can be used to generate specific response codes or errors from Authorize.Net so that you may test your working code.

To cause the payment gateway to respond with a specific response code, send a transaction with the Visa error test credit card number (x_card_num) 4222222222222 and an amount (x_amount) equal to the response code you want the payment gateway to return.

For example, if a transaction is sent in Test Mode with the credit card number 4222222222222 and an amount of 12 dollars, the payment gateway will respond with response code 12, "Authorization Code is required but is not present."

Response code 103 can be received in the event that the Authorize.Net Payment Gateway account is configured for Expanded Credits Capabilities (ECC), and the account password is being submitted with transactions. To resolve this issue, submit the account transaction key in place of the password.

For information about how to obtain a transaction key, see our Implementation Guides.

You can also troubleshoot certain errors by using our Response Code Tools.

This response indicates that the payment gateway account is in Test Mode. There are three indicators that an account is in Test Mode:

1. Test Mode is turned ON in the Merchant Interface
2. x_test_request is submitted in the transaction string as TRUE
3. The POST URL is set to our certification environment: https://test.authorize.net/gateway/transact.dll

Transactions that are submitted while the account is in Test Mode are not actually submitted to the credit card and electronic check processing networks, and credit card or bank accounts are not actually charged. Therefore they do not have a valid transaction ID.

Once you have finished testing your integration project, you will need to turn Test Mode OFF and change the POST URL to https://secure.authorize.net/gateway/transact.dll. You can turn Test Mode OFF by clicking Settings under Account in the main menu on the left. Then click Test Mode from the Security Settings section. Then click Turn Test OFF. You can also turn test mode off by submitting x_test_request = FALSE.

In the transaction response string from Authorize.Net, this value is the six-digit authorization code returned by the card issuing bank, and indicates that the transaction was approved.

Typically, the only time the x_auth_code field is used is in the event that the merchant previously submitted an Authorization Only (AUTH_ONLY) transaction via a processing system or payment gateway other than Authorize.Net, and wanted to capture the transaction using Authorize.Net. To do this, the transaction method (x_method) must be submitted with the value of "CAPTURE_ONLY," and the authorization code (x_auth_code) issued for the original AUTH_ONLY must be submitted in the transaction request string to Authorize.Net.

For more information about the authorization code, see our Implementation Guides.

When Authorize.Net sends a transaction response to your server, the payment gateway waits 10 seconds for a response. If Authorize.Net does not receive a response from your server in 10 seconds, the payment gateway server will time out and display an error page. The first thing you need to check is the order that your script executes. It is very important that something prints to the screen before any other process is started. If your script prints to the screen first, Authorize.Net will recognize that you are receiving the information. The most effective method would be to PRINT the headers, and a line of text such as "Processing, please wait."

To resolve relay response time outs:

• Verify your script permissions and the ability to accept an HTML POST.
• Check that the script is not completing other functions before writing to the screen, such as writing to a database or sending e-mails.
• See if there are different processes that are used in your script for approvals, declines or errors. Check each process to be sure that they will write to the screen before any other functions.
• Check if your script is using redirects immediately upon receipt of the response from our servers. Redirects are discouraged because they can potentially interfere with the process.

Note: On occasion, timeouts will occur that are outside of the control of your script or our servers. Typical reasons for these timeouts are Internet traffic, merchant server overload or malfunctions, or Internet routing issues. Depending upon your server location and what route is used to send data, it is possible that you may occasionally receive a time out message.

The MD5 Hash is an optional security feature and can be used on the merchant side to verify that a transaction response was actually sent by Authorize.Net. This feature is intended to be used when a relay response is configured for SIM, and is not necessary for use with AIM.

To effectively use this feature, you will need to provide a MD5 input value in the Merchant Interface, develop a process to generate your own hash, and determine if that value matches the hash provided in the transaction response.

For more information about the MD5 hash security feature, see our Implementation Guides.

Transaction or account settings submitted in the transaction request string will always override settings in the Merchant Interface.

For the most part, merchants rarely change Merchant Interface settings that might impact their integration. However, merchants may change settings in the Merchant Interface that could affect values in the transaction response, or the way that information is returned in the transaction response. As a result, you may notice behavior with the transaction response that you had not anticipated or you may not be able to parse the transaction response correctly.

To prevent this, it is a good idea to set fields in the transaction request string that format the transaction response in the transaction request string on a per-transaction basis. Examples of such fields are x_test_request, x_delim_data, x_delim_char, x_encap_char, x_relay_response, x_duplicate_window, and x_response_format.

Both fields provide information about how data in the transaction response string received from the Authorize.Net Payment Gateway should be formatted. The delimiting character (x_delim_char) separates each field or piece of data that is included in the transaction response, delineating where one field ends and the next begins.

The encapsulation character (x_encap_char) encloses the field on both sides. In the following example, the comma (,) is the delimiting character and the double quotation (") is the encapsulation character:

"loginID","transactionkey","amount", . . .

An encapsulation character is really only needed when the possibility exists that the delimiting character may be included in an actual field value, which could cause an error when the data is parsed. For example, if you submit an address that you would like to include on the receipt page, and the address text includes a comma, the encapsulation character will ensure that data in the transaction response is parsed correctly by the merchant's Web server. This is also a good example of why common characters, such as a comma, are not the best delimiting characters. If you use an uncommon delimiter, (i.e., |), you do not necessarily need to configure or use an encapsulation character.

Note: If you request an XML transaction response, you do not need to use the delimiting or encapsulation characters.

A linked Credit is a Credit transaction submitted against a Charge transaction that was originally processed through Authorize.Net. By default, all payment gateway accounts require that Credit transactions be submitted with the transaction ID (x_trans_id) of the original Charge transaction, be less than the original Charge amount, and that the original transaction be less than 120 days old.

An unlinked credit is not linked to a previous Charge transaction processed through Authorize.Net, and has no date or amount restrictions. In order to process unlinked Credits, merchants must apply for Expanded Credit Capabilities (ECC) by completing and submitting the ECC Application to Authorize.Net.

AVS stands for Address Verification Service. This service allows merchants to compare the billing address provided with a transaction with the billing address on file at the customer's issuing bank and to use that information to determine whether to accept a transaction. Use of this service is included with each standard Authorize.Net CNP Payment Gateway account and is highly recommended for all e-commerce and MOTO transactions.

For more information about AVS, please see the Merchant Interface Help Files.

Yes. In order to test AVS you must submit either a live AUTH_ONLY or AUTH_CAPTURE transaction with valid address information. If the transaction is approved or declined (i.e., not errored) you will be billed for a single transaction by Authorize.Net and your processor.

CCV stands for Card Code Verification. The Card Code value is a three-digit security code that is printed in reverse italics at the top of the signature panel on the back of credit cards (on the front for American Express). This value can be submitted to the payment gateway and verified by the card issuing bank to provide merchants with an extra measure of security against credit card fraud.

For general protection from fraudulent transactions, AVS and CCV are highly recommended. However, for advanced prevention, Authorize.Net offers the Fraud Detection Suite (FDS), a set of transaction filters and Internet Protocol (IP) address tools designed to help with the detection and prevention of suspicious transactions. Unlike other solutions, FDS was designed to address the types of fraud experienced by merchants that process transactions online. Based on extensive research and transaction behavior analysis, this set of fraud filters was built to help merchants implement a flexible, rules-based fraud prevention solution customized to meet unique transaction processing needs. Using these filters proactively can significantly enhance day-to-day efforts to identify and control potentially fraudulent transactions.

Authorize.Net will automatically batch all transactions that are marked for settlement once a day based on the batch cut off time configured for the merchant's account. To view or change the batch cut-off time configured for the merchant's account, log into the Merchant Interface, click Settings under Account in the main menu on the left, and click Transaction Cut-Off Time from the Business Settings section.