Authorize.net provides payment gateway services that provides online credit card and e-Check payment processing. This gateway is pre-integrated with Zuora and is both easy to configure and use.
To set up Authorize.net as your gateway, enter your Authorize.net credentials in the Z-Payments Settings > Setup Payment Gateway page. When selecting a Gateway Type, choose Authorize.net.
There are some common fields you must complete for every gateway configuration. We recommend reviewing our Setup Payment Gateway documentation for information on these common fields:
If you enable Use Gateway Test Environment, you must use developer account credentials, and not the merchant credentials. If you are using the production gateway (test or non-test environment), you must use the merchant credentials.
In addition to the common fields, every gateway has unique requirements and information (such as credentials and certain rules) that you must provide to configure the gateway in Zuora.
Your credentials will be obtained from Authorize.net and configured in Zuora.
To configure the Authorize.net payment gateway in Zuora, you must enter your API Login ID and Transaction Key in the Setup Payment Gateway page. See Authorize.net's Access Settings document for help determining your API Login ID and Transaction Key, or if you need to obtain a new Transaction Key.
We recommend testing your Authorize.net payment gateway using both your payment gateway's test and production (live) environments. Once you have completed testing in the gateway's test environment, it is recommended that you perform a test in your live production environment with a real credit card. If there are any differences in the configuration of your testing and production accounts, testing in production ensures your production merchant account is set up properly and can successfully connect to the production environment.
Some payment gateways provide separate credentials for merchants to access their testing (or certification) environment, some gateways use the same credentials for testing as for the production (live) environment but direct test transactions to a different URL, and other gateways do a little of both. Authorize.net provides you the ability to both test your transactions using a developer's test account as well as testing your transactions in your live account in test mode. Testing in both your developer's account and live account in test mode are recommended by Authorize.net in their article on Test Information. We recommend reviewing this article before you begin testing.
You can sign up for a test account on the Authorize.net Developer website. Once you have signed up, you will receive an email with your account information as well as a list of frequently asked questions and answers.
When configuring the Authorize.net payment gateway in Zuora, you can indicate whether you would like to use the Authorize.net test environment or the Authorize.net production environment.
If you do not select Use Gateway Test Environment, Zuora will direct payment transactions to your Authorize.net production environment at
We recommend contacting your Authorize.net to request a set of test credit cards and testing scenarios. When you establish an Authorize.net Developer Test Account, you will receive an email containing your test credentials and some test credit card numbers. Here are some additional test card numbers to get you started:
Authorize.net has online documentation on testing, test credit cards, and testing scenarios. Here are some documents to review before you begin testing:
If you receive an error message when adding credit cards, you may need to change or remove the encapsulation setting from your merchant account. Access your merchant account, click Settings, then click Direct Response > Transaction Response Settings. Remove the single quote setting in the Encapsulation Character field and click Save.
In general, gateway testing environments are intended to give merchants the opportunity to test their gateway and integrations to their gateway, in order to work out any bugs before going to the production environment. Some gateway test environments are shared amongst multiple merchants, and other gateways provide unique testing environments for each merchant. Additionally, gateway test environments (also referred to as certification or sandbox environments) do not have the same high availability or performance capability as production environments. As such, they are not intended for load testing. Merchants performing high volumes of load testing that puts a stress on a shared test environment may receive a warning from the gateway or have their access to the testing environment suspended.
For failed payments processed using the Authorize.net payment gateway, Z-Payments will provide the gateway Response Reason Code (for example, 44) and Response Reason Text (for example, This transaction has been declined).
To view the current status of the Authorize.net gateway, go to this location: https://status.authorize.net/.
To find more information on Authorize.net payment gateway errors:
We recommend that you check the payment in Zuora to see how many times the same payment method has been retried for payment and failed. If there have been several retries, check the error messages from the beginning with the first failure and the more recent failures to determine if the error message is the same. If a merchant tries to process a payment against the same credit card too many times despite receiving errors, this could trigger warnings to the card issuing bank. The card issuing bank may place an alert on the account and not allow any further transactions from the merchant using that payment method. When a mechant has been flagged, the error received on the payment may be not state the reason why, instead it might be a generic error such as 2 - Declined. In this case, the merchant (Zuora customer) should work with their merchant acquirer/processor to see if they can identify the problem with the payment method. If the processor does not know, then the merchant and/or the card holder can try calling their card issuing bank to look into the issue
General credit card decline errors from Authorize.net may have a Response Reason Code "2" and Response Reason Text "This transaction has been declined." General declines are fairly common, but a high rate of decline with this error is worth investigating further with your payment gateway and processor to rule out any issues with your merchant account. If you notice the declines happening with a specific card issuing bank, you may want to contact that bank to find out more information.
Reasons for a general decline include:
If you experience a very high number of transactions with this error, contact your merchant services provider to review your account configuration and status of the account. Since Authorize.net receives the decline from the processor who receives it from the card issuing bank, Authorize.net may refer you to your processor or merchant services provider for assistance.
If your company offers a limited free trial where you obtain and authorize credit cards in advance, but charge for payment on a future date (such as tomorrow, a week, or a month later) there's a risk that the credit card may no longer be valid when the future payment is collected (in gateway terminology, this is sometimes referred to as capturing a payment). The status/validity of a credit card can change easily and frequently. A customer's credit card can have sufficient funds today, but the customer makes a large purchase tomorrow that results in their account being low in funds. If you happen to charge their card when their account has insufficient funds, you will get a credit card decline. The same customer can pay off their credit card debt tomorrow, and their card will once again be valid with sufficient funds. For this reason, we recommend configuring your payment retry rules to retry credit cards (for example, you can retry a card once every 24 hours, up to a maximum of 3 attempts).There are many benefits to offering limited free trials, but its important to understand how a credit card can be valid one day and be declined the next. Again, if you feel these types of declines are occurring at a high rate, please contact your payment gateway and processor immediately to investigate the issue.
Both Authorize.net and Zuora have email notifications that can be configured to send out payment receipts when a payment has been processed. See Authorize.net Email Receipt documentation for information on how to configure the email notification in your gateway. Zuora passes along the customer's email address to Authorize.net with the payment transaction so if you have this notification enabled, your customer will receive the below Customer Receipt/Purchase Confirmation.
The following is a sample of the email from Authorize.net:
From: "JOHN DOE" <firstname.lastname@example.org> To: "Jan Smith" <email@example.com> Sent: Thursday, January 12, 2012 at 11:02 AM Subject: ABC Company Customer Receipt/Purchase ConfirmationThank you for your order! Order Information Merchant: ABC Company Description: null Invoice Number: INV00000295 Customer ID: ABC00000100 ------------------------------ Billing Information Jan Smith United States firstname.lastname@example.org ------------------------------ Shipping Information Total: US $99.00 American Express Date/Time:12-Jan-2012 11:02:22 AM PT Transaction ID: 3084961236 ------------------------------ Regards, John Doe Billing Manager, ABC Company