Authorize.net API Documentation (2023)

The merchant API Login ID is provided in the Merchant Interface and must be stored securely.

The API Login ID and Transaction Key together provide the merchant authentication required for access to the payment gateway.

The merchant Transaction Key is provided in the Merchant Interface and must be stored securely.

The API Login ID and Transaction Key together provide the merchant authentication required for access to the payment gateway.

If included in the request, this value is included in the response. This feature might be especially useful for multi-threaded applications.

This is the total amount and must include tax, shipping, tips, and any other charges.

Use the ISO 4217 three-letter alphabetic code for the currency.Use the ISO 4217 three-letter alphabetic code for the currency.

Currently supported currencies are USD, CAD, GBP, DKK, NOK, PLN, SEK, EUR, AUD, and NZD.

Applies to Card Present transactions only.

Contains track data read from the customer's card.

Track data contains the full card number and expiration date by default. If you use the trackData element, do not send the creditCard element. Sending both elements may result in Response Reason Code 153.

Applies to Card Present transactions only.

Track data includes the full card number and expiration date by default. If you send the track1 element, do not send the creditCard element. Sending both elements may result in Response Reason Code 153.

Applies to Card Present transactions only.

Track data includes the full card number and expiration date by default. If you use the track2 element, do not send the creditCard element. Sending both elements may result in Response Reason Code 153.

Applies to Card Not Present transactions only.

Contains human-readable information from the customer's card.

Applies to Card Not Present transactions only.

The customer’s credit card number.

Only use cardNumber and expirationDate for Card Present transactions if the track data is unavailable. Note that using cardNumber and expirationDate in Card Present transactions may result in higher merchant rates.

Applies to Card Not Present transactions only.

The customer’s credit card expiration date.

Only use cardNumber and expirationDate for Card Present transactions if the track data is unavailable. Note that using cardNumber and expirationDate in Card Present transactions may result in higher merchant rates.

Applies to Card Not Present transactions only.

The customer’s card code.

The three- or four-digit number on the back of a credit card (on the front for American Express).

This field is required if the merchant would like to use the Card Code Verification (CCV) security feature.

Cardholder information must be stored securely and in accordance with the Payment Card Industry (PCI) Data Security Standard.

For more information about PCI, please refer to the Standards, Compliance and Security developer training video at https://developer.authorize.net/training.

If set to true, a customer profile and payment profile will be generated from the customer and payment data.

See the Solution ID Implementation Guide for details.

See the Solution ID Implementation Guide for details.

Do not use your processor's terminal ID for this field.

Worldpay RAFT 610 merchants can view the invoice number in the Worldpay Reporting Portal.

The total transaction amount must include this value.

The total transaction amount must include this value.

The total transaction amount must include this value.

If you use purchase order numbers, your solution should generate the purchase order number and send it with your transaction requests. Authorize.net does not generate purchase order numbers.

If you use customer IDs, your solution should generate the customer ID and send it with your transaction requests. Authorize.net does not generate customer IDs.

The customer’s valid email address.

Required only when using a European payment processor.

If you enable Email Receipts in the Merchant Interface, and if the email address format is valid, the customer will receive an Authorize.net generated email receipt.

If EVO is your payment processor and you submit any of the following billTo fields, you must submit all of them.

firstName
lastName
address
city
state
zip

First name associated with customer’s billing address.

Required only when using a European payment processor.

Last name associated with customer’s billing address.

Required only when using a European payment processor.

Customer’s billing address.

Required if merchant would like to use the Address Verification Service security feature.

Required when using GPN Canada or Worldpay Streamline Processing Platform.

City of customer’s billing address.

Required only when using a European payment processor.

State of customer’s billing address.

Required only when using a European payment processor.

The postal code of customer’s billing address.

Required if merchant would like to use the Address Verification Service security feature.

Required when using GPN Canada or Worldpay Streamline Processing Platform.

If EVO is your payment processor and you submit any of the following shipTo fields, you must submit all of them.

firstName
lastName
address
city
state
zip

The IPv4 address of the customer initiating the transaction. Defaults to 255.255.255.255 if not included in your request.

Required only when the merchant is using customer IP based AFDS filters.

Merchants using a third party cardholder authentication solution can submit the following authentication values with Visa and Mastercard transactions.

Invalid combinations of card type, authenticationIndicator, and cardholderAuthenticationValue will result in Response Reason Code 118.

Important: This field is deprecated and should not be used.

The Electronic Commerce Indicator (ECI) value for a Visa transaction, or the Universal Cardholder Authentication Field indicator (UCAF) for a Mastercard transaction. The cardholder authentication process generates the ECI or UCAF value prior to submitting the transaction.

Required only for authorizationOnlyTransaction and authCaptureTransaction requests processed through 3D Secure cardholder authentication programs, such as Visa Secure or Mastercard Identity Check. When submitted with other values for transactionValue, this element is ignored.

Invalid values of authenticationIndicator will result in Response Reason Code 116.

This field is currently supported through Chase Paymentech, FDMS Nashville, Global Payments and TSYS.

Important: This field is deprecated and should not be used.

The Cardholder Authentication Verification Value (CAVV) for a Visa transaction, or Accountholder Authentication Value (AVV)/ Universal Cardholder Authentication Field indicator (UCAF) for a Mastercard transaction. The cardholder authentication process generates the CAVV, AAV, or UCAF value prior to submitting the transaction.

Required only for authorizationOnlyTransaction and authCaptureTransaction requests processed through 3D Secure cardholder authentication programs, such as Visa Secure or Mastercard Identity Check. When submitted with other values for transactionValue, this element is ignored.

Invalid values of cardholderAuthenticationValue will result in Response Reason Code 117.

This field is currently supported through Chase Paymentech, FDMS Nashville, Global Payments and TSYS.

This element is required if you submit the retail element.

This element is required if you submit the retail element.

This field is required for the EVO processor, and is supported on the TSYS processor.

For a list of valid settingName values and their uses, please see the Transaction Settings section of the Payment Transactions page.

For a list of permitted settingValue formats, please see the Transaction Settings section of the Payment Transactions page.

Do not use these fields to pass through sensitive details as doing so may be a violation of the PCI Data Security Standard.

Worldpay RAFT 610 merchants can view the first two userField elements in the Worldpay Reporting Portal.

Up to 20 userField elements may be submitted per request.

User reference field provided for the merchant’s use. The merchant will receive this field in the response, exactly as it was submitted in the request. Authorize.net will not store this value.

User reference field provided for the merchant’s use. The merchant will receive this field in the response, exactly as it was submitted in the request. Authorize.net will not store this value.

Currently supported for TSYS merchants.

For details on surcharge rules, please see Visa's merchant regulations and fees.

Currently supported for TSYS merchants.

For details on surcharge rules, please see Visa's merchant regulations and fees.

Currently supported for TSYS merchants.

For details on surcharge rules, please see Visa's merchant regulations and fees.

The total transaction amount must include this value.

Required if the merchant stores card-on-file payment information.

Required if the merchant stores card-on-file payment information.

Set recurringBilling to true if you set isFirstRecurringPayment.

Required if the merchant stores card-on-file payment information.

Use in these situations:

• - When resubmitting declined transactions;
• - When resubmitting a transaction with an expired authorization;
• - When submitting delayed charges after completing the original payments;
• - When charging customer penalties for reservation no-shows; or
• - When processing an unscheduled card-on-file transaction.

Required if the merchant stores card-on-file payment information.

Required if the merchant stores card-on-file payment information.

Required if the merchant stores card-on-file payment information.

Store the networkTransId value received in the original card-on-file transaction response. Set the originalNetworkTransId to the original networkTransId value for all subsequent authorizations against the same card-on-file.

Use resubmission for resubmitting the original charge if declined, and if the customer has already received goods or services.

Use delayedCharge if there are supplemental charges after the original charge was submitted and the customer has received the goods or services.

Use reauthorization for new transactions submitted after the original transaction, for example, for split or delayed shipments of goods, or for extended services beyond those originally requested.

Use noShow for penalties after cancellation of services, for example, when a customer does not appear after making a reservation.

Store the amount of the original card-on-file transaction response. Set the originalAuthAmount to the original amount value for all subsequent authorizations against the same card-on-file.

Applicable to Mastercard only. Use pre for initial authorizations, for example, prior to tips. Use final for final authorizations, for example, including tips.