Authorize.Net Gateway Guide
Services and Compatibility
- Payment Gateway Company Name:
- Services that work with Spreedly:
- Supported operations:
- Purchase, Authorize, Capture, Refund, Void, Verify, Store, General Credit
- Supported payment types:
- Credit Card, Bank Account, Apple Pay, Google Pay
- Spreedly 3DS2 Global Supported
- Gateway Specific 3DS2 Supported
- Populate MIT GSF Support
- Europe, North America
- API endpoint URL:
Authentication and Security
- Specific names for credentials:
- API Login ID, Transaction Key
Onboarding Merchants in:
Reversals for Authorize.Net ACH transactions should be processed via General Credit, not Refund.
This gateway supports Level 2 transaction processing via Spreedly. If you are interested in Level 2 transaction support, please contact the gateway to confirm that your account is enabled for this processing type. Please let us know if there are any specific parameters you would like to have enabled.
Adding an Authorize.Net gateway
To add an Authorize.Net gateway you just need to supply your Authorize.net API login ID and your Authorize.net transaction key:
Creating Third Party Tokens
Authorize.Net allows for storing of payment methods. You can transfer these tokens to Spreedly to use in future transactions. When doing so, provide the
customerPaymentProfileId as the
reference. You will then need to supply the
customerProfileId in subsequent transactions calls by providing it as the gateway specific field
Stored credential gateway specific fields
An Authorize.Net gateway supports our standardized Stored Credential Data fields. In some cases, Authorize.net may require a
reason to be passed for a merchant-initiated transaction; you may pass the
stored_credential_reason_type_override field to populate the
reason to Authorize.net. Note that the accepted values for this field are distinct from the reason codes supported in Spreedly’s standardized
stored_credential_reason_type field. See the Authorize.Net Card on File documentation for further details.
Gateway specific fields
When interacting with a Authorize.Net gateway to run transactions, there are many gateway specific fields you can specify when making a call. These fields can be sent like so:
verify_amount gateway specific field allows you to set a custom value for the verify transaction, allowing a $0 authorize for supported brands and acquirers. Please Note Authorize.net also requires the
zip fields to be present in the
billing_address to perform a $0 authorize.
By default, the
recurringBilling flag will only be automatically sent as
recurring in the transaction if the payment method is not a credit card or a third party token. If you wish to override this behavior, you can set the
recurring gateway specific field to
false to not send the
recurringBilling field, or to
true to ensure that it is sent as
When storing a credit card with Authorize.Net CIM using third party vaulting, you can specify a
customer_profile_id if you’d like to add the card onto an existing customer in your Authorize.Net account:
If you have already created a token with Authorize.Net and choose to store it with Spreedly by creating a third party token, you will need to provide the
customerPaymentProfileID as the reference in the Create Third Party Token request and pass the associated customerProfileId in the gateway specific field
customer_profile_id for each transaction using that token.
Requiring Billing Address
For some European customers, billing addresses are required for refund transactions. If Authorize.Net rejects refunds due to missing or incomplete billing address information, try calling refund with
require_billing_address set to
Response Code 4: Held for Review
<responseCode>4</responseCode> received from ANET indicates that the transaction was held for review. This community article indicates these responses are related to an anti-fraud tool:
Response code 4 relates to transactions held by the Advanced Fraud Detection Suite (response reason codes 252 and 253) and are only applicable to merchants using that service. These transactions require a manual review by the merchant in their online interface before they will be completed.
With these response codes, it is not possible for you, as the developer, to know whether the merchant will ultimately decide to accept or reject the transaction. Therefore, it is important to present a somewhat ambiguous response to the customer when these response codes occur.
These transactions are marked as succeeded, since they are received to be processed. However, they are flagged as
fraud_review:true so they may indeed fail after review.
We’ve mapped the Spreedly response statuses based on Authorize.net’s docs:
Response Code - indicates the overall status of the transaction with possible values of Approved, Declined, Errored or Held for Review:
4: Action Required (typically used for AFDS transactions that are held for review)
Spreedly does not do any callbacks once we receive a response from the gateway, so it is up to the merchant to determine the ultimate status of transactions showing
Please refer to using a payment method for more information on how to send GSFs
Gateway specific response fields
A response from Authorize.net may contain a
You can find this information in
gateway_specific_response_fields. For example, a transaction
could have something like this:
<transaction> <token>LgpTNGjsWQs9DwdxcbreUVz0R8p</token> <transaction_type>Purchase</transaction_type> <gateway_specific_response_fields> <authorize_net> <full_response_code>I00001</full_response_code> <response_reason_code>252</response_reason_code> <authorization_code>IJK2DZ</authorization_code> </authorize_net> </gateway_specific_response_fields> </transaction>
Authorize.net offers response reason code lookup tool which may help you discern why a transaction is failing. This can be especially helpful when you initially setup your Authorize.net gateway and run a real transaction to verify your credentials are correct.
If you’d like to request any
gateway_specific_response_fields, please contact Support with your request and the gateway documentation for the fields of interest.