Search Developer Site

Understanding 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.

Because the Authorize.Net API is a payment processing API, it is important to know a few things about payment transactions. Before integrating the API into your system, read this page to understand the processes that the API enables.

For detailed API reference information, see our API Reference Guide.

If you are new to the Authorize.Net payment API, we recommend that you begin with our credit card payment tutorial. Many of the core concepts in the tutorial apply to other payment types, which makes it a good place to start. You should also sign up for a sandbox account and use our testing guide for your initial tests.

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

If you are designing software that will be used by multiple merchants, you should consider registering as a partner and obtaining a solution ID. A solution ID allows the source of transactions to easily be identified by the merchant in their online reporting or through reporting API methods.

When you develop your payment application and its integration with the Authorize.Net, you must consider the Payment Card Industry Data Security Standard (PCI-DSS). For more information, see our Understanding PCI Compliance page.

Understanding the Credit Card Payment Network

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.

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.

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 element value for a Authorization and Capture transaction is:

<transactionType>authCaptureTransaction</transactionType>

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 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 element value for a Authorization Only transaction is:

<transactionType>authOnlyTransaction</transactionType>

Prior Authorization Capture

Authorize.Net 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 Capture transaction can be submitted against an Authorization Only.

The unique element value for a Prior Authorization Capture transaction is:

<transactionType>priorAuthCaptureTransaction</transactionType>

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

<refTransId>9876543210</refTransId>

For this transaction type, the amount field is required only if a Prior Authorization 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 value for a Capture Only transaction is:

<transactionType>captureOnlyTransaction</transactionType>

In addition, the previously obtained authorization code needs to be specified in the authCode element:

<authCode>SAMPLE</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 is a type of transaction which allows split-tender orders, so that a customer may pay for one order with more than one payment card.

In the request, setting allowPartialAuth to true indicates that the merchant's system can process partial authorizations. Without allowPartialAuth the transaction will 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:

<splitTenderId>SAMPLE</splitTenderId>

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

All transactions are grouped under a split-tender ID, and all transactions in a 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 (request, 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 (response) The available credit remaining on the card.
  • requestedAmount (response) The originally requested amount of the order.
  • splitTenderId (response) The split-tender ID provided in the response to the first partial authorization transaction. Use this ID when submitting subsequent transactions related to the same order.
  • splitTenderStatus (response) The status of the split-tender order as a whole. Possible values are: completed, held, or voided.

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.

Visa refers to card codes as CVV2; MasterCard uses CVC2; and Discover and American Express use CID.

For security reasons, we cannot store the card code 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.

Log in to the merchant interface and 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.

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
  • China Union Pay
  • Diners Club
  • Discover
  • JCB
  • Mastercard
  • Visa
  • United States Dollar (USD)
  • Canadian Dollar (CAD)
Elavon
  • American Express
  • China Union Pay
  • Diners Club
  • Discover
  • JCB
  • Mastercard
  • Visa
  • United States Dollar (USD)
  • Canadian Dollar (CAD)
EVO Payments
  • American Express
  • China Union Pay
  • Discover
  • JCB
  • Mastercard
  • Visa
  • United States Dollar (USD)
First Data Merchant Services (FDMS) Omaha, Nashville, and EFSNet
  • American Express
  • China Union Pay
  • Diners Club
  • Discover
  • JCB
  • Mastercard
  • Visa
  • United States Dollar (USD)
  • Canadian Dollar (CAD)
Global Payments
  • American Express
  • China Union Pay
  • Diners Club
  • Discover
  • JCB
  • Mastercard
  • Visa
  • United States Dollar (USD)
  • Canadian Dollar (CAD)
Heartland Payment Systems
  • American Express
  • China Union Pay
  • Diners Club
  • Discover
  • JCB
  • Mastercard
  • Visa
  • United States Dollar (USD)
TSYS Acquiring Solutions
  • American Express
  • China Union Pay
  • 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. supports 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

Card Code (CVV2/CVC2/CID)

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

To enable card code:

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.