Retail
Transaction Types
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.
- Authorization Only (Type 01)
- Sale (Type 02)
- Prior-Authorized Sale (Type 07)
- Return (Type 09)
- Void Sale (Type 11)
- Void Return (Type 17)
- Transaction Inquiry (Type 22)
- Incremental Authorization (Type 75) [/magic-link]
- Partial Authorization Reversal (Type 76)
Types of Retail Transactions
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 Authorization 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.
important
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 authorization-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.
note
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.
Credential on File Transactions
Credential on file transactions occur when a cardholder gives express permission to the merchant to store their payment credentials for use on a future purchase.
The COF transaction category introduces two transaction types:
- Scheduled COF
- Unscheduled COF
These types of transactions also update card brand rules, including merchant disclosure requirements.
The stored credential transaction category covers all COF transactions, including:
- Cardholder-initiated stored credential transactions - no fixed schedule
- Industry Specific (delayed, no-show, incremental)
note
Descriptions for Field 0047 position 5, Field 0054, and Field 0738 are explained after the following tables.
Scenarios Establishing a Credential on File
Scenarios
Cardholder and Merchant agree to establish a Credential on File at a Retail Business and perform the initial sale or authorization transaction. The COF may be used for future transactions initiated by the cardholder or merchant for payment of goods or services.
Example
- Cardholder makes a purchase and agrees to place their card on file with the merchant for future use.
Transaction Type (Sale 02)
- Field 723 (F) = First Payment to Establish Credential on file
- Field 0738 = Not Present
- Field 0047, position 5 = Any
- Field 0054 = As Entered
- Initiated by (Reason COF Established) = Cardholder
Transaction Type (Auth Only 01)
- Field 723 (F) = First Payment to Establish Credential on file
- Field 0738 = Not Present
- Field 0047, position 5 = Any
- Field 0054 = As Entered
- Initiated by (Reason COF Established) = Cardholder
Zero-dollar Auth Only (01)
- Field 723 (F) = First Payment to Establish Credential on file
- Field 0738 = Not Present
- Field 0047, position 5 = Any
- Field 0054 = As Entered
- Initiated by (Reason COF Established) = Cardholder
Scenarios Using a Credential on File
Scenarios
Merchant initiates a recurring payment for goods or services using the established COF based on a standing arrangement with the Cardholder.
Example
Merchant performs a transaction for monthly gym membership fees.
Sale (02)
- Field 723 = (S) Subsequent Payment
- Field 0738 = Value from Original Transaction
- Field 0047, position 5 = 9
- Field 0054 = 01
- Initiated by (Reason COF Used) = Merchant
Auth Only (01)
- Field 723 = (S) Subsequent Payment
- Field 0738 = Value from Original Transaction
- Field 0047, position 5 = 9
- Field 0054 = 01
- Initiated by (Reason COF Used) = Merchant
Scenario
Cardholder initiates a single purchase using the established COF.
Example
Cardholder purchases another item for delivery from the retail store.
Sale (02)
- Field 723 (U) = Unscheduled Payment
- Field 0738 = Value from Original Transaction Response
- Field 0047, position 5 = A
- Field 0054 = 01
- Initiated by (Reason COF Used) = Cardholder
- Reason COF Used = Unscheduled Payment
Auth Only (01)
- Field 723 = (U) Unscheduled Payment
- Field 0738 = Value from Original Transaction Response
- Field 0047, position 5 = A
- Field 0054 = 01
- Initiated by (Reason COF Used) = Cardholder
- Reason COF Used = Unscheduled Payment
Scenario
Merchant initiates a Transaction using the established COF based on an arrangement with the cardholder.
Example
Merchant delivers a single product that was ordered or provides a onetime service.
Sale (02)
- Field 723 = (U) Unscheduled Payment
- Field 0738 = Value from Original Transaction Response
- Field 0047, position 5 = A
- Field 0054 = 01
- Initiated by (Reason COF Used) = Merchant
- Reason COF Used = Unscheduled Payment
Auth Only (01)
- Field 723 = (U) Unscheduled Payment
- Field 0738 = Value from Original Transaction Response
- Field 0047, position 5** = A
- Field 0054 = 01
- Initiated by = Merchant
- Reason COF Used = Unscheduled Payment
Scenario
Cardholder or Merchant initiates a Return Transaction using the established COF
Example
Cardholder returns a product to the store for a refund. Merchant has overcharged for previous goods purchased or service provided.
Return (09)
- Field 723 = (U) Unscheduled Payment
- Field 0738 = Transaction from Original Transaction Response
- Field 0047, position 5 = A
- Field 0054 = 01
- Initiated by = Merchant
- Reason COF Used = Unscheduled Return
Return (09)
- Field 723 = (U) Unscheduled Payment
- Field 0738 = Value from Original Transaction Response
- Field 0047, position 5 = A
- Field 0054 = 01
- Initiated by = Cardholder
- Reason COF Used = Unscheduled Return
Scenario
Merchant initiates an incremental Authorization
Example
Merchant requires an additional authorization amount for service provided, an incremental authorization is performed using the COF.
- Incremental Authorization (75)
- Field 723 = (S) Subsequent Payment
- Field 0738 = Value from Original Transaction Response
- Field 0047, position 5 = 4
- Field 0054 = 01
- Initiated by = Merchant
- Reason COF Used = Unscheduled Additional Authorization
Scenario
Merchant initiates a Prior Authorization to complete a previous COF authorization only transaction.
Example
Merchant needs to submit a prior authorization for a COF transaction as part of their End of Day process and initiate settlement.
- Prior Authorization (07)
- Field 723 = Same as initial Authorization Only (01)
- Field 0738 = Value from Original Transaction Response
- Field 0047, position 5 = Same as Initial Authorization
- Field 0054 = 01
- Initiated by = Merchant
- Reason COF Used = Same as Initial Authorization only (01)
Scenario
Merchant initiates a Reversal or Void of a previous COF transaction
Examples
Merchant needs to cancel a previous transaction - a void or full reversal is performed.
Merchant has overcharged on previous authorization transaction a partial authorization is performed.
Full Reversal (61), Partial Reversal (76), Void Sale (11), Void Return (17)
- Field 723 = Same as Original
- Field 0738 = Value from Original Transaction Response
- Field 0047, position 5 = Same as Original
- Field 0054 = 01
- Initiated by = Merchant
- Reason COF Used = Same as Original
note
While Credential on File integrations are not third party processor specific, if a merchant changes third party processor with already established Credentials on File, it is advised that the merchant re-establish those Credentials on File with the new third party processor.
POS Data Code - Field 0047 Position 5 Cardholder Present
- Cardholder present Value 0: Cardholder present
Cardholder Not Present Values
Values and Descriptions:
1: Cardholder not present (reason not specified)
2: Cardholder not present, mail order
3: Cardholder not present, telephone order
4: Cardholder not present, Industry Practice
5: Cardholder not present, eCommerce
A: Cardholder not present, Standing Authorization - Unscheduled
9: Cardholder not present, Standing Authorization – Recurring or Installment
POS Enty Mode - Field 0054
01: Manual/Key Entry
005: EMV
07: Contactless Chip Card
80: EMV fall back to swipe
90: Magnetic Stripe
91: Contactless Mag Stripe
Compliance Data Value - Field 0738
This field contains the compliance data required to process Credential on File transactions. The value is returned in the API response of the transaction that established the COF. This value must be retained by the merchant POS.
The stored value must be provided on in the API request by the POS on all transactions using the COF.
When Establishing a COF
- API Request – Not Present
- API Response: Compliance Data Value - Merchant POS must retain for all transactions using a COF
When Using a COF
API Request:
- Compliance Data Value retained from field 0738 of the Original Authorization Transaction Response when the COF was Established
API Response:
- Compliance Data Value – Possibly a different value from the request – merchant does not need to store this value
important
When attempting to establish a COF, if a value is not returned in response field 0738, the COF was not established. The merchant must treat this and any future transactions for this card as non COF transactions. In this case, do not send 723 and 738 on those future transactions.
Field Type Descriptions
- N: Numeric
- AN: Alphanumeric
- C: Dollar/cents amount, including decimal point (for example 1.00). Dollar amounts less than $1.00 must be prefixed with a leading zero.
In, Out, and Store Descriptions
Input (In): The actual fields presented in the Input Request.
Output (Out): The actual fields returned in the Output Response are dependent on the Third Party Processor Interface module being used. If the interface requires the data and the processor returns the information, it is returned in the format required by the processor.
Store: Elavon strongly recommends that your application retain the fields noted with a check mark under the Store column until completion or settlement of the transaction. Any other fields can be stored at the discretion of the integrator.
Tabulated Data
Tabulated Data is an API field type that supports multiple values in a single input API field. It was developed to better address data that can be grouped together. This field allows API expansion to an area of the API (Retail, Direct Marketing, etc.) where available API fields are otherwise limited. The data separator in a tabulated field is a semi-colon (;).
Tabulated data includes:
- Retail tabulated data fields: 0412, 0413, 0414, 0415, and 0416
- SubField 1 Item code describing the type of product purchased [max size 16, type N]
- SubField 2 Item quantity [max size 3, type N]
- SubField 3 Item amount [max size 13, type C]
- Format NNNN;NNN;NNNNNNNNNN.NN
Overall total size = 4 + ; 16 + ; 3 + ; 10 + 2 = 35 total
In this example, API Field 0412 includes all subfields, item code, quantity and amount.
- 0412,23;1;13.42
In this example, API Field 0412 is being used to pass only the Item Quantity and Amount and the Item Code field has been left blank.
- 0412,;2;2.35
In this example, API Field 0412 is being used as the item code only. It’s an example of Legacy use.
- 0412,453
AMEX Level III increased subfield 1 from 4 to 16 to accommodate SKUs as well as item codes.
Retail Invoice
The image below shows how the required receipt information can be incorporated into a standard retail invoice.