A retail integration uses only a few of the many transaction types available. Below is a list of the transactions used by most retail POS applications.

Transaction Type Description
Authorization Only (Type 01) Credit only transaction type. It places a hold on the open-to-buy on a cardholder’s credit account. AVS and/or CVV requests can be performed. The transaction qualifier (Elavon Gateway API Field 0115) must equal 010.
Sale (Type 02) Recommended authorization transaction type for both credit and debit.
Prior Authorization (Type 07) Changes an existing Auth Only (Type 01) to a Prior-Auth (Type 07) for settlement. Prior authorizations can also be performed on Forced / Voice Auth Only (Type 01) transactions.
Return (Type 09) Debit transactions should follow the standard online PIN process.
Void Sale (Type 11) Changes an existing Sale (Type 02) or Prior-Auth (Type 07) to a voided transaction. Usually it is not settled, but it may be included in a batch.
Void Return (Type 17) It voids an existing Return (Type 09) transaction and changes the status of the return transaction to a voided transaction.
Transaction Inquiry (Type 22) Performs transaction status inquiry.
Incremental Authorization (Type 75) Used to secure additional authorization for an on-going, previously authorized transaction. Type 75 is limited to certain industries and card types.

Sale Transactions

A typical retail sale transaction occurs in the following circumstances:

  • Cardholder is present

  • Final amount is known

  • Goods or services are delivered at the time of the sale

  • The final amount can increase after using the Authorizaton Only (transaction 01) if, for example, a customer wants to add additional goods to the order. In such a case, the Incremental Authorization (transaction 75) is used. This is considered a two-part transaction.


Elavon does not recommend padding the Reference Number (Field 0007) with leading zeros. Should you choose to do so, be sure to store the value in your system as a String instead of an Integer. This will eliminate any potential discrepancies in how this field is presented in two-part transactions, and the chance of downgrades or fees is greatly reduced.

One-part Transaction

Electronic Authorization is obtained for the final amount (e.g., $50.00) by performing a Sale transaction (type 02). The transaction is closed.

Two-part Transaction

In a two-part transaction, authorization is obtained for the original known amount (e.g., $50.00) by performing an Authorization Only transaction (type 01).

The customer adds additional merchandise and the POS runs an Incremental Authorization transaction (type 75) to adjust the original amount (e.g., $25.00). The transaction is closed with Prior Authorization (type 07) and the new Final Amount of $75.00.

The advantages of this type of transaction include the authorization of an additional amount before closing the transaction, ideal interchange qualifications, ideal aurhorization-related chargeback protection, and the ability to use a Token. Additionally, only one transaction posts to the cardholder statement, and the transaction fees are economical.

The drawbacks include the potential for a transaction fee assessment, the Authorization Only and Prior Authorization must match exactly in order to be funded, and if for some reason the Prior Authorization is not processed, the Authorization Only will eventually expire, and the merchant will not be funded for the transaction. Additionally, it may be considered an Additional Authorization for some cards and regions.


If the approval was obtained from a voice authorization center, the sale request must be resubmitted with the approval code to the Fusebox application with the Force Flag (Field 0012) set to 1. The other option is to submit a Prior Auth without the Force Flag, but with the approval code in Field 0006.

Retail COF and Related transaction Scenarios

Retail credential file transactions are indicated by Fields 0738, 0054, and 0723.

Scenarios Establishing a Credential on File

Scenario Field 0738 Value Field 0054 Value Field 0723 Value
Retail Transaction Card Present API Request - Not Present
API Response – Compliance Data Value (Merchant POS must retain for COF transactions)
Entry Mode of the Card Present Transaction
01 = Manual Entry
05 = EMV
07 = Contactless Chip Card
80 EMV fall back to swipe
90 = Magnetic Stripe
91 - Contactless Mag Stripe
F = First Payment (Establishes Credential on File)

Scenarios Using a Credential on File

Scenario Field 0738 Value Field 0054 Value Field 0723 Value
Scheduled Retail Transaction with Token API Request - Compliance Data Value retained from field 0738 of the Original Authorization Transaction Response
API Response - Not Present
01 - Manual Entry S = Subsequent Payment Using Credentials on File
Unscheduled Retail Transactions with Token API Request - Compliance Data Value retained from field 0738 of the Original Authorization Transaction Response
API Response - Not Present
01 - Manual Entry U = Unscheduled Payment/Purchase Using Credentials on File

Retail Invoice

The image below shows how the required receipt information can be incorporated into a standard retail invoice.

image of retail invoice