Search Developer Site

Payment Transactions

The Authorize.Net API provides robust features for processing transactions through the Authorize.Net gateway. The API comes in XML and JSON flavors. This page provides a high-level overview of how the API works. For detailed API reference information, see our API Reference Guide.

While credit cards remain the primary method of payment, the Authorize.Net API increasingly supports new and exciting payment types. For more information on payment types and API features, see the API Features page.

Credit Card Process

Connecting a web site or software application to the payment processing networks is exceptionally difficult and typically beyond the expertise and technical resources of most online merchants. Instead, merchants can connect to the Authorize.Net Payment Gateway, which provides the complex infrastructure and security necessary to ensure fast, reliable, and secure transmission of transaction data.

The API referred to in this page was formerly known as AIM XML, now referred to simply as our payment API.

Typically, the actors in an online credit card transaction are:

  • Consumer—buys the product from the merchant’s web site using a credit card from an issuing bank.
  • Issuing bank—provides a credit card to the consumer. Represents the consumer in the event of a dispute.
  • Acquirer—usually a bank, underwrites the merchant’s ability to accept credit cards. Represents the merchant in the event of a dispute.
  • Merchant—sells a product or service to the consumer from their website, using an Authorize.Net payment API.

For more information on how Authorize.Net fits into the payment network, See our credit card processing diagram. For API field descriptions and sample code, see the API Reference Guide.

Life of a Transaction

An online payment transaction goes through various phases, shown below.

Authorize

An authorization places a hold on the transaction amount in the customer’s issuing bank. No money actually changes hands yet. For example, let’s say that the merchant is going to ship a physical product from their website. First they authorize the amount of the transaction. Then they ship the product. Only after the product is shipped does the merchant capture the transaction.

Capture

A capture essentially marks a transaction for settlement. As soon as the product is shipped, the merchant can capture an amount up to the amount of the authorization. Usually the full amount is captured. An example of a situation in which the whole amount is not captured might be if the customer ordered multiple items and one of them is unavailable. It’s important to note that a single authorization can be captured only once. If you capture only part of an authorization amount, a new authorization will be required in order to capture more.

Settle

Within 24 hours, Authorize.Net settles the transaction. The merchant’s acquirer then deposits the funds into the merchant’s bank account.

Voids and Credits

A void occurs after authorization, but before settlement. No money is exchanged; the authorization is simply cancelled.

A credit occurs after settlement. For example, the merchant ships the item, and the transaction is settled, but for some reason the customer becomes unsatisfied with the product. In such a case, the merchant may decide to refund (credit) the money. A credit is a new and distinct transaction from the original charge with its own unique transaction ID.

Creating a Transaction

The createTransactionRequest function is used to submit any type of one-time payment transaction. Transaction types are described below.

Authorization and Capture

This transaction is the most common type of credit card transaction and is the default payment gateway transaction type. The amount is sent for authorization and if it is approved, it is automatically submitted for settlement. The unique value for an Authorization and Capture transaction is: authCaptureTransaction.

Authorization Only

This transaction type is sent for authorization only. The transaction will not be sent for settlement until the credit card transaction type Prior Authorization and Capture (see definition below) is submitted, or the transaction is submitted for capture manually in the Merchant Interface. If no action is taken within 30 days, the authorization expires and is no longer available for capture. A new Authorization Only transaction has to be submitted to obtain a new authorization code. The unique value for an Authorization Only transaction is authOnlyTransaction.

Prior Authorization and Capture

This transaction type is used to complete an Authorization Only transaction that was successfully authorized through the payment gateway. Together, an Authorization Only transaction and a Prior Authorization and Capture transaction are considered one complete transaction. When the Prior Authorization and Capture is submitted, the transaction is sent for settlement.

The payment gateway accepts this transaction type and initiates settlement when the following conditions are met:

  • The original Authorization Only transaction was submitted within the previous 30 days (Authorization Only transactions expire on the payment gateway after 30 days).
  • The transaction is submitted with the valid transaction ID (refTransId) of an original, successfully authorized Authorization Only transaction.
  • The original transaction was successful and is not yet captured.
  • The amount being requested for capture is less than or equal to the original authorized amount. Only a single Prior Authorization and Capture transaction can be submitted against an Authorization Only.

The unique element values for a Prior Authorization and Capture transaction are:

<transactionType>priorAuthCaptureTransaction</transactionType>

In addition, the transaction ID of the original transaction needs to be specified in the <refTransId>element:</refTransId>

<refTransId>123456</refTransId>

For this transaction type, the <amount> field is required only if a Prior Authorization and Capture is submitted for an amount that is less than the amount of the original Authorization Only transaction. If no amount is submitted, the payment gateway will initiate settlement for the amount of the original authorized transaction.

Capture Only

This transaction type is used to complete a previously authorized transaction that was not originally submitted through the payment gateway or that required voice authorization.

The payment gateway accepts this transaction type and initiates settlement if the transaction is submitted with the valid authorization code issued to the merchant.

The unique element values for a Capture Only transaction are:

<transactionType>captureOnlyTransaction</transactionType><authCode>authorization code here</authCode>

Market Type and Device Type

By default, transactions are considered to be E-Commerce (card not present). If the card is present, the transaction is considered to be a retail transaction. For retail transactions, you must specify a market type with a value of 2 and a device type, as shown below. Track Data can only be submitted in conjunction with these parameters.

<retail> <marketType>2</marketType> <deviceType>5</deviceType> </retail>

Available parameters for deviceType are:

  • 1=Unknown
  • 2=Unattended Terminal
  • 3=Self Service Terminal
  • 4=Electronic Cash Register
  • 5=Personal Computer- Based Terminal
  • 7=Wireless POS
  • 8=Website
  • 9=Dial Terminal
  • 10=Virtual Terminal

Partial Authorization

A partial authorization, also known as a split-tender order, is an order in which two or more transactions comprise the total amount of the order. This type of transaction allows a customer to pay for one transaction with multiple payment types.

Setting <allowPartialAuth>true</allowPartialAuth> in the request indicates that the merchant's system can accommodate partial authorizations. Without this flag, the transaction would be processed as any other and would be either fully authorized or declined due to lack of funds on the card.

If the first transaction is successfully approved for a partial amount of the total order, a split-tender ID is generated and returned to the merchant in the response. This ID must be passed back with each of the remaining transactions of the group, using <splitTenderId> value </splitTenderId>

If you include both a split-tender ID and a transaction ID on the same request, an error results.

All transactions in the group are held until the final transaction of the group is successfully authorized.

If the merchant needs to release the group of transactions before the final transaction is approved (if the balance is paid by cash, for example), send a updateSplitTenderGroupRequest request and include the split-tender ID instead of a transaction ID. In this case, you would also submit the splitTenderStatus field with a value of completed.

If the merchant needs to void the group before completion, send a void request, using the split-tender ID instead of a transaction ID. This action will void all the transactions in the group.

The transaction is not submitted for settlement until either the merchant submits payments adding up to the full requested amount or until the merchant indicates that the transaction is complete (when all or part of the remaining balance is paid in cash).

Unique elements that apply to Partial Authorization transactions are:

  • <allowPartialAuth>true</allowPartialAuth> (input, optional) The default value is set in the Merchant Interface; you can use this parameter to authorize individual transactions if the option is set to False in the Merchant Interface. Including this field in the transaction request overrides the merchant's account configuration.
  • <balanceOnCard> (output) this is the authorized amount remaining on the card.
  • requestedAmount this is the amount requested.
  • <splitTenderId> (output) this is the split-tender ID provided when the first partial authorization transaction was issued. Use this ID when submitting subsequent transactions related to the same group order.
  • <splitTenderStatus> (output) indicates whether or not the transaction is complete.

Basic Fraud Settings

AVS

The Address Verification Service (AVS) is a system designed by bankcard processors to help detect suspicious credit card transaction activity. AVS matches billing address information provided by the cardholder with the cardholder's billing address on file at the credit card issuing bank. The processing network then sends an AVS response code indicating the results of the match to the payment gateway. The AVS response code can be found in the payment gateway transaction response as well as on the Transaction Detail page in the Merchant Interface. Based on the merchant's AVS rejection settings, the transaction is accepted or rejected. Rejected transactions display a transaction status of Declined (AVS Mismatch) on the Transaction Detail page. It is important to note that the merchant cannot retrieve address information from the issuing bank; the bank provides only match or no-match information.

To implement AVS, the merchant must require the Address and ZIP Code fields on their payment form. To manage AVS rejection settings, log in to the Merchant Interface and choose Account > Settings > Security Settings > Basic Fraud Settings > AVS.

Card Code Verification (CCV)

This feature enables merchants to compare the card code submitted by the customer for the transaction with the card code on file at the card issuing bank. Filter settings in the Merchant Interface allow the merchant to reject transactions based on the CCV response received. To implement CCV, the merchant must require the Card Code field on their payment form.

To manage rejection settings, log in to the Merchant Interface and choose Account > Settings > Security Settings > Basic Fraud Settings > CCV.

Different card companies use different terminologies to refer to card codes:

CVV2 = Visa

CVC2 = MasterCard

CID = American Express and Discover

For security reasons, we cannot store the CVV data. Consequently, when you configure a fraud or velocity rule with the action ‘Do not Authorize and Hold for review’, the card code of the transactions flagged by this rule cannot be validated when you approve the transaction later.

Daily Velocity Filter

The Daily Velocity Filter enables merchants to specify a threshold for the number of transactions allowed per day. All transactions exceeding the threshold for that day are flagged and processed according to the selected filter action. This filter is helpful in preventing certain types of fraudulent activity on the merchant's account.

Choose Account > Settings > Security Settings > Basic Fraud Settings > Daily Velocity.

Retrieving, Approving, and Declining Held Transactions

The Authorize.Net Merchant Interface provides access to the Advanced Fraud Detection Suite for merchants who sign up. Some of the functions there can be used from the API. Suspicious transactions that are being held for review can be retrieved, approved, or declined by using simple API requests. To see the reference information for those requests, see the API Reference Guide.

Compliance

The Payment Card Industry Data Security Standard (PCI DSS) is a set of requirements designed to ensure that ALL companies that process, store or transmit credit card information maintain a secure environment. For more information, see the PCI Security standards page and Authorize.Net 's PCI Compliance page.

In the following video, you can learn about important payment industry security standards which are a critical step in assuring that your clients have a solid foundation for accepting secure payments.

Customer Transaction Receipts

With the payment gateway you can send customer transaction receipts for an approved transaction.  The method works for transactions that were approved, were not voided, and are not expired.

The email is not sent if a merchant does not have a "receipt reply to" address set up in their account.

sendCustomerTransactionReceiptRequest

Element Value Format
merchantAuthentication Contains the merchant’s payment gateway account authentication information.
name The merchant’s unique API login ID. 20-character maximum.
transactionKey The merchant’s unique transaction key. 16 characters.
refId Merchant-assigned reference ID for the request. 20-character maximum.
transId The payment gateway-assigned identification number for the transaction. When testRequest is set to a positive response, or when Test Mode is enabled on the payment gateway, this value will be 0.
customerEmail The customer’s valid email address. 255-character maximum. For example, janedoe@customer.com
emailSettings Contains one or more setting element.
setting Contains settingName and settingValue elements.

settingName

Merchant-created name of the desired setting. String

settingValue

Value of the setting. See code example below. String

Example sendCustomerTransactionRequest

<?xml version="1.0" encoding="UTF-8"?> <sendCustomerTransactionReceiptRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"> <merchantAuthentication> <name>MyLoginName</name> <transactionKey>MyTransKey</transactionKey> </merchantAuthentication> <refId>123456</refId> <transId>1234567890</transId> <customerEmail>somebody@somewhere.com</customerEmail> <emailSettings> <setting> <settingName>headerEmailReceipt</settingName> <settingValue><![CDATA[<html><head></head><body>some HEADER stuff</body></html>\]\]></settingValue> </setting> <setting> <settingName>footerEmailReceipt</settingName> <settingValue><![CDATA[<html><head></head><body>some FOOTER stuff</body></html>\]\]></settingValue> </setting> </emailSettings> </sendCustomerTransactionReceiptRequest>

Payment Processors

Authorize.Net supports the following payment processors.

North American Payment Processors

Payment Processors Accepted Card Types Accepted Currencies
Chase Paymentech Tampa
  • American Express
  • Diners Club
  • Discover
  • JCB
  • Mastercard
  • Visa
  • United States Dollar (USD)
  • Canadian Dollar (CAD)
Elavon
  • American Express
  • Diners Club
  • Discover
  • JCB
  • Mastercard
  • Visa
  • United States Dollar (USD)
  • Canadian Dollar (CAD)
EVO Payments
  • American Express
  • Discover
  • JCB
  • Mastercard
  • Visa
  • United States Dollar (USD)
First Data Merchant Services (FDMS) Omaha, Nashville, and EFSNet
  • American Express
  • Diners Club
  • Discover
  • JCB
  • Mastercard
  • Visa
  • United States Dollar (USD)
  • Canadian Dollar (CAD)
Global Payments
  • American Express
  • Diners Club
  • Discover
  • JCB
  • Mastercard
  • Visa
  • United States Dollar (USD)
  • Canadian Dollar (CAD)
Heartland Payment Systems
  • American Express
  • Diners Club
  • Discover
  • JCB
  • Mastercard
  • Visa
  • United States Dollar (USD)
TSYS Acquiring Solutions
  • American Express
  • Diners Club
  • Discover
  • JCB
  • Mastercard
  • Visa
  • United States Dollar (USD)
WorldPay Atlanta
  • American Express
  • Diners Club
  • Discover
  • JCB
  • Mastercard
  • Visa
  • United States Dollar (USD)

European Payment Processors

Payment Processors Accepted Card Types Accepted Currencies
AIB Merchant Services
  • Mastercard
  • Visa
  • United Kingdom Pound (GBP)
  • Euro (EUR)
  • Unites States Dollar (USD)
Barclaycard
  • JCB
  • Mastercard
  • Visa
  • United Kingdom Pound (GBP)
  • Euro (EUR)
First Data Merchant Solutions (MSIP Platform)
  • Mastercard
  • Visa
  • United Kingdom Pound (GBP)
HSBC Merchant Services
  • Mastercard
  • Visa
  • United Kingdom Pound (GBP)
  • Euro (EUR)
  • United States Dollar (USD)
Lloyds Bank Cardnet
  • Mastercard
  • Visa
  • United Kingdom Pound (GBP)
Streamline
  • JCB
  • Mastercard
  • Visa
  • United Kingdom Pound (GBP)
  • Euro (EUR)
  • United States Dollar (USD)

Asia-Pacific Payment Processors

Payment Processors Accepted Card Types Accepted Currencies
FDI Australia
  • Mastercard
  • Visa
  • Australian Dollar (AUD)
  • New Zealand Dollar (NZD)
  • United States Dollar (USD)
Westpac
  • Mastercard
  • Visa
  • Australian Dollar (AUD)

EVOSnap

There are multiple EVOSnap processing platforms. EVOSnap U.S. suporrts only US Dollar (USD). All currencies, including U.S. Dollar, are supported on EVOSnap International.

Accepted Authorization/Settlement Currencies

  • USD—U.S. Dollar

  • CAD—Canada Dollar

  • CHF—Switzerland Franc

  • DKK—Denmark Krone

  • EUR—Euro

  • GBP—United Kingdom Pound

  • NOK—Norway Krone

  • PLN—Poland złoty (MasterCard Only)

  • SEK—Sweden Krona

  • ZAR—South Africa Rand

Accepted Billing Currencies

  • USD—U.S. Dollar

  • AUD—Australian Dollar

  • GBP—United Kingdom Pound

Accepted Card Types

  • Visa

  • MasterCard

  • American Express

  • JCB

  • Diners Club - U.S. only

Unsupported Services

Apple Pay and soft descriptors are not supported by EVOSnap.

EVOSnap Supported Services

U.S. Services

Service E-Commerce MOTO Retail
Transaction Types
X X X X
X X X X
X X X X
X X X X
X X X X
Features
X X X X
X X X X
X
X X X X
X X X X
Supported card types:
  • Visa
  • MasterCard
  • American Express
  • Discover
  • JCB
  • Diners Club
X X X

Duplication Rules

EVO platform always checks for duplicate transactions based on:

  • Same Terminal ID
  • Same Card Number
  • Same Dollar Amount

Duplicates are flagged when they occur within an hour of each other.

Magstripe

Track 2 data is supported only for card-present transactions.

Level 2 Support

PO# is required when any level 2 data is submitted. Level 2 data includes tax, duty, and freight information.

Billing Address

When any billing fields are submitted, all must be submitted.

  • First name
  • Last name
  • Address
  • City
  • State/province (required only if country is US or Canada)
  • Country
  • ZIP/postal code

Other Field Requirements

The employeeId field is required; however, if a value is not passed with the field, Authorize.Net sends a default value of 0000 to the processor.

Consolidated Accounts

The Consolidated Accounts feature is not supported on the EVOSnap platform. Multiples market types require multiple accounts.

Automated Recurring Billing

Merchants using Automated Recurring Billing must be approved by their merchant service provider, also known as their acquirer.

International Services

Service MOTO E-Commerce Authorize X X Authorize and Capture X X Capture X X Void X X Credit X X AVS—Visa and American Express only. X X CVV2/CVC2/CID X X 3DS

Not Supported

  • Retail
  • Level 2 data
  • Soft descriptors
  • Partial authorization
  • Consolidated accounts (MOTO/E-Commerce)—separate accounts are required.
  • Automated recurring billing and customer information manager

CVV

EVOSnap requires CVV for all international transactions. CVV must be enabled in the Authorize.Net merchant interface’s Virtual Terminal settings.

To enable CVV:

Step 1. Navigate to the Authorize.Net merchant interface. Step 2. Choose Accounts > Settings > Transaction Format Settings > Virtual Terminal. Step 3. Check the View box for Card Code. Step 4. Click Submit.

Other EVOSnap Considerations

International AVS Behavior

Transactions are declined if the submitted address data does not match. Merchants can override this behavior on a per-transaction basis, if permitted by EVOSnap. Merchant accounts are configured to either use or not use AVS processing when they are boarded. If the account is configured to not use AVS processing, AVS is not performed, even if the data is included. If the merchant account is configured to use AVS every transaction must include AVS data, unless the merchant is authorized by EVOSnap to override the AVS processing.

API

Customer code is required. If not present, customer code is populated with 0000. Country code must be in ISO format. For example, GBR, CHE, AUS.

Error Codes

  • RTC 350 Description—EVOSnap: country must be a valid three-character value if specified. Message—country must be a valid three-character value if specified.
  • RTC 351 Description—EVOSnap: employee ID cannot be more than 6 characters in length, 4 for a retail transaction. Message—employee ID must be 1 to %x characters in length. Note—the %x is replaced with a 6 for E-Commerce and MOTO transaction types and 4 for retail transaction types.

Billing Information

When any billing information is submitted, all billing fields must be provided.