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.

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.

error_outline

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

error_outline

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)

{{< notice note >}} Descriptions for Field 0047 position 5, Field 0054, and Field 0738 are explained after the following tables. {{< /notice >}}
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
Field 0723 Field 0738 Field 0047 position 5 Field 0054 Initiated by Reason COF
Established
Sale (02) F
First Payment to Establish Credential on file
Not Present Any As Entered Cardholder Unscheduled Payments
Auth Only (01) F
First Payment to Establish Credential on file
Not Present Any As Entered Cardholder Unscheduled Payments
Zero Dollar Auth Only (01) F
First Payment to Establish Credential on file
Not Present Any As Entered Cardholder Unscheduled Payments
Scenarios Using a Credential on File

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

Transaction
Type
**Field 0723 Field 0738 Field 0047 position 5 Field 0054 Initiated by Reason COF
Used
Sale (02) S
Subsequent Payment
Value from Original Transaction Response 9 01 Merchant Recurring Payments
Auth Only (01) S
Subsequent Payment
Value from Original Transaction Response 9 01 Merchant Recurring Payments

Scenario
Cardholder initiates a single purchase using the established COF.
Example
Cardholder purchases another item for delivery from the retail store.

Transaction
Type
Field 0723 Field 0738 Field 0047 position 5 Field 0054 Initiated by Reason COF
Used
Sale (02) S
= Subsequent Payment
Value from Original Transaction Response A 01 Merchant Unscheduled Payment
Auth Only (01) S
= Subsequent Payment
Value from Original Transaction Response A 01 Merchant 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.

Transaction
Type
Field 0723 Field 0738 Field 0047 position 5 Field 0054 Initiated by Reason COF
Used
Sale (02) S
Unscheduled Payment
Value from Original Transaction Response A 01 Merchant Unscheduled Payment
Auth Only (01) S
Unscheduled Payment
Value from Original Transaction Response A 01 Merchant 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.

Transaction
Type
Field 0723 Field 0738 Field 0047 position 5 Field 0054 Initiated by Reason COF
Used
Return (09) S
Unscheduled Payment
Transaction from Original Transaction Response A 01 Merchant Unscheduled Return
Return (09) U
Unscheduled Payment
Value from Original Transaction Response A 01 Cardholder 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.

Transaction
Type
Field 0723 Field 0738 Field 0047 position 5 Field 0054 Initiated by Reason COF
Used
Incremental Authorization (75) S
Subsequent Payment
Value from Original Transaction Response 4 01 Merchant 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.

Transaction
Type
Field 0723
F=First payment to Establish Credential on File
S= Subsequent Payment
U=Unscheduled Payment
Field 0738 Field 0047 position 5 Field 0054 Initiated by Reason COF
Used
Prior Authorization (07) Same as initial Authorization Only (01) Value from Original Transaction Response Same as initial Authorization Only (01) 01 Merchant 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 over charged on previous authorization transaction, a partial authorization is performed.

Transaction
Type
Field 0723
S = Subsequent Payment
U = Unscheduled Payment
Field 0738 Field 0047 position 5 Field 0054 Initiated by Reason
COF Used
Full Reversal (61), Partial Reversal (76), Void Sale (11), Void Return (17) Same as Original Value from Original Transaction Response Same as Original 01 Merchant Same as Original
{{< notice 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. {{< /notice >}}

POS Data Code - FIELD 0047 POSITION 5 Cardholder Presence

  • Cardholder present Value:

    • 0 = Cardholder present
  • Cardholder Not Present Values:

    • 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, e-Commerce
    • A = Cardholder not present, Standing Authorization - Unscheduled
    • 9 = Cardholder not present, Standing Authorization – Recurring or Installment

    POS ENTRY Mode - FIELD 0054

  • 01 = Manual/Key Entry

  • 05 = 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

{{< notice 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.

{{< /notice >}}
Field Type Descriptions
  • N: Numeric
  • A/N: 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 ptherwise limited. The data separator in a tabulated field is a semi-colon (;).

The tabulated data are described as follows:

  • Retail tabulated data field 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.

image of retail invoice