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.

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.

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)

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

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

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.