Below is a list of the most commonly asked questions from developers integrating to the Authorize.Net Payment Gateway. For questions about our mobile SDKs, please visit the Mobile FAQs.
- Where can I find documentation for the Authorize.Net application programming interface (API)?
- Which integration method should I use?
- What transaction data formats does Authorize.Net accept?
- What programming languages can I use to integrate to Authorize.Net?
- Does Authorize.Net provide any code samples?
- What card swipe devices do you support?
- How do I obtain a test account?
- How do I obtain Authorize.Net shopping cart certification?
- Why do I have to support eCheck.Net® transactions to certify my shopping cart?
- Who do I contact for integration support?
- Does my solution have to be Payment Card Industry (PCI) Data Security Standard certified?
- Does Authorize.Net support international transactions?
- What is a transaction key?
- How do I obtain a transaction key?
- What is a transaction fingerprint?
- Do I need to submit transaction fields in a specific order?
- Does the Authorize.Net API support custom fields?
- How can I customize the Authorize.Net hosted payment form?
- What is a relay response?
- Is there a document that lists transaction response codes or error messages and their possible causes?
- Is there a way to produce specific response codes or errors?
- Why am I receiving response code 103 when trying to issue a Credit?
- Why am I receiving a transaction ID value of zero?
- What is x_auth_code?
- What are the causes of a relay response time out?
- What is the MD5 Hash security feature and how am I supposed to use it?
- What if settings in the Merchant Interface conflict with my integration code?
- What is the difference between x_delim_char and x_encap_char?
- What is the difference between a linked and unlinked Credit?
- What is AVS?
- If I want to test the AVS response in live mode, are transactions actually processed and the credit card charged?
- What is CCV?
- What tools are available for controlling fraudulent transactions?
- How are transactions batched?
- I get an Error 13 "The merchant API login ID is invalid or the account is inactive."
- I need sample code in a different programming language than what is available on http://developer.authorize.net/samplecode/.
- I am not familiar with programming—can you help me connect my Web site to Authorize.Net?
- Are test credit card numbers available?
If you, or your merchant, do not have an SSL certificate, we recommend Direct Post Method (DPM). DPM is a hosted payment option that allows the user optimal site customization while still relying on Authorize.Net for help with PCI DSS compliance. DPM uses a unique fingerprint to authenticate transactions. Developers can customize a secure, hosted payment form without an SSL certificate (Please note: an SSL certificate is still highly recommended in order to display "https" in the browser URL and promote customer confidence). The Authorize.Net Payment Gateway handles all of the steps in the secure transaction process—payment data collection, data submission and the response to the customer—while keeping Authorize.Net virtually transparent.
Also recommended is Server Integration Method (SIM). SIM uses scripting techniques to authenticate transactions with a unique transaction fingerprint. SIM also provides a customizable and secure 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.
For more information about how to format transaction data, see our Implementation Guides.
Authorize.Net is fully PCI certified, and dedicates many resources to maintaining our certification with Visa.
- Log into the merchant's Authorize.Net account at: https://secure.authorize.net.
- Click on Settings under Account in the main menu on the left.
- From the Security Settings section, click API Login ID and Transaction Key.
- Enter the Secret Answer to your account's Secret Question.
- Click Submit.
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 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.
You can also troubleshoot certain errors by using our Response Code Tools.
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."
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.
- Test Mode is turned ON in the Merchant Interface
- x_test_request is submitted in the transaction string as TRUE
- 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.
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.
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.
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.
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.
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.
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.
For more information about AVS, please see the Merchant Interface Help Files.
- American Express Test Card 370000000000002
- Discover Test Card 6011000000000012
- Visa Test Card 4007000000027 or 4012888818888
- JCB 3088000000000017
- Diners Club/ Carte Blanche 38000000000006
- MasterCard 5424000000000015