To signup for an Authorize.Net account, please visit Authorize.Net.
Authorize.Net works with merchant accounts in the US only, but can work with customers/consumers in the following areas:
- All countries
- Product prices are in USD
- Customers purchasing in other currencies will be charged in their local currency at the exchange rate in effect at the time of the transaction
API LOGIN ID AND TRANSACTION KEY
Advanced Billing requires your API Login ID and Transaction Key in order to communicate with your Authorize.Net account. Within your Authorize.Net account, navigate to the following: Account –> Settings –> API Credentials & Keys –> API Login ID
Once you have obtained your credentials, please enter them into your Advanced Billing site by navigating to your payment gateway settings.
REQUIREMENTS
-
Customer Information Manager (CIM) option must be turned on.
-
You do NOT need the Automatic Recurring Billing (ARB) feature.
-
You will also need a merchant account with a compatible bank. If you need an Authorize.Net account and a merchant account, please contact one of Advanced Billing’s partners who will help get you setup with everything you need.
-
Avoid making settings “required” under “Payment Form”. The default setting for most of these checkboxes is OFF, and they should remain on the defaults.
-
Please do not change the Authorize.Net “Direct Response Delimiter” settings. By default, the Default Field Separator is a comma (
,) and no Field Encapsulation Character is specified. Do not change it to pipe (|). -
DO NOT set “Card Code” to “Required” under Settings → Payment Form → Form Fields (setting this to Required here effectively rejects any transaction where the CVV is NOT provided, which will cause recurring transactions to fail!). Instead, mark the CVV as required in Advanced Billing: Settings → Fields → Check the “Required?” box for “CVV”.
-
Relax your AVS Settings in Authorize.Net in Settings -> Address Verification Service -> Under General AVS Responses, uncheck G, U, and S. These settings must be unchecked if you wish to accept international payments.
CURRENCIES & MERCHANT LOCATION
Authorize.Net handles one currency per gateway account. Please contact them directly to open the accounts needed for each currency.
For full information on currency and merchant location support, please view our payment gateway overview page.
DATA PORTABILITY POLICY
- There is no cost associated with exporting solely customer profile/CIM data, but exporting other data may incur fees.
- Exports only occur on Wednesdays and Fridays.
- For the most up-to-date information, please contact migrations@authorize.net.
Authorize.Net Account Updater
If you receive the following error for a renewal transaction in your Site: Customer Profile ID or Customer Payment Profile ID not found., we recommend the following troubleshooting steps/questions:
- Did you, as the merchant, recently enable Authorize.Net’s new Account Updater Service?
- If so, we request that you inquire with your Authorize.Net representative if the payment profiles in question received an ACL or CCH response when attempting to update the card.
If any of these are true, please use the following steps to correct the error:
-
Create a new payment profile for the subscription. Please choose one of the following methods:
- Add a new card
- Email the subscriber a link to update their payment method by sending them their Self-Service Page URL.
- Select Email customer to request payment update from the subscription’s payment details
If you wish to view a report in your Authorize.Net account of updated cards, please follow the instructions below:
- Log in to your account
- Select “Reports” from the main toolbar.
- Select “Account Updater Reports” from the menu on the left.
- Select the month you would like to view.
- Click Run Report
If results are found, the first 100 records will be displayed on the dashboard. To view more than the first 100 records, you will need to use the Download to File option. Select the record corresponding to the month you wish to review and click Run Report
Check the report for the customers who you are experiencing this error with. Search the report to see if they have one of these statuses:
- CCH: Contact Card Holder - A change has occurred, contact card holder for updates.
- ACL: Account Closed - The account has been closed, contact card holder for new card.
Source: Authorize.Net’s Account Updater documentation
Authorize.Net Disabled Payment Profiles
Advanced Billing will now check for the Customer Profile ID error as listed above and automatically disable the payment profile should this situation occur. Disabled payment profiles can only be deleted, and cannot be the active payment profile on a subscription. In addition, a user notification will be generated which will inform you of the impacted subscription and payment profile.
Disabled payment profiles can also occur if the stored Advanced Billing information does not correspond to any information on the gateway side (from an errant credit card information import for example).
Authorize.Net eCheck/ACH
For more information on Authorize.Net’s eCheck/ACH feature, please see our documentation here. The linked article provides a comprehensive overview of how eCheck/ACH functions within your Advanced Billing and Authorize.Net accounts.
Authorize.Net Response Reason Codes
In most cases, when a transaction can’t be processed - Authorize.Net will respond with a number of fields that can help you diagnose the issue. The important fields to look at in the gateway output log, are response_code, response_reason_code and response_subcode. The first two (response_code and response_reason_code) are very useful at diagnosing an issue, as there is a publically accessable site that you can view here (Response Code Descriptions) which details the various combinations and the possible description of the issue. However, there are a number of combinations that don’t have any descriptive text at all, and those are:
| Response Code | Response Reason Code |
| 1 | 1 |
| 2 | 2 |
| 2 | 3 |
| 2 | 4 |
Need to understand an Authorize.Net response code? Here is a link to Authorize.Net’s current response codes.
In these cases, the error is usually (not guaranteed) that the merchant isn’t “white listed” for that customers card. In this case, they will need to call their issuing provider and ask about the decline. In most cases, the issues can be resolved. In these cases, the customer will most likely have to call their issuing provider to solve the potential issue.
Authorize.Net AVS & Anti-Fraud Settings
Authorize.Net has a comprehensive article that explains all of the AVS settings. It’s worth reviewing to familiarize yourself with the AVS codes. This is especially helpful when examining transaction responses from Authorize.Net.
Authorize.Net Response Delimiter Setttings
Due to a recently discovered issue, Advanced Billing currently requires that you not change the Authorize.Net Direct Response Delimiter Settings. If you do, some transactions that rely on AVS may fail. Additionally, if these settings are changed, some successful transactions may refuse to allow refunds, generating the error “The credit card number is invalid”.
You can restore your default settings by following this guide:
-
Log In to your Authorize.Net control panel and click on “Settings”
-
From the Settings screen, select “Direct Response”
-
Make the following selections under Direct Response Delimiter. (Note: These are the defaults)
-
Delimited Response: Yes
-
Default Field Separator: , (comma)
-
Field Encapsulation Character: (none)
We will soon be fixing this problem so that your settings do not affect our ability to parse certain responses from Authorize.Net. If you have been affected by this problem, in particular if you receive the error “The credit card number is invalid” when attempting to issue a refund, contact us and we can usually help you fix the issue.
Authorize.Net Transactions failures
If your transactions fail with “The transaction was unsuccessful” or “{field} is required, you will have to investigate which settings are causing this to happen within the Authorize.Net interface.
One reason is that your Authorize.Net configuration might be “requiring” certain fields that are a part of the Authorize.Net Payment Form settings. These settings actually affect API transactions as well, and all should be unchecked.