Restaurant

Transaction Types

A restaurant integration uses only a few of the many transaction types available. Below is a list of the transaction types used in our integrations.

• 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)
• Full Authorization Reversal (Type 61)
• Incremental Authorization (Type 75)

Best Practices

Handling Tips

When a customer receives their check for the purchase amount and opts to pay with a credit or debit card:

1. Authorization is obtained for the check amount by performing an Authorization Only transaction (type 01).
2. A receipt is presented to the customer to add a tip and signature.
3. Once the tip is added, the POS runs a transaction 75 to increment the original amount with the tip amount.
4. The transaction is closed with the prior Auth (07).

There are a few advantages of this workflow:

• The cardholder is present.
• Appending the tip to the original authorization ensures compliance with industry authorization tolerance.
• Meets qualifying requirements for best possible rates.

With EMV, the tip may be added on a PIN pad. In this case, send the transaction as a Sale (type 02) instead of the Authorization Only (type 01), since the tip and final amount of the transaction is known prior to sending the transaction for authorization.

Prior Authorization

Your application should identify open tickets so they are closed prior to settlement processing.

A Prior Authorized Sale (type 07) should be processed even if the final transaction amount is the same as the amount authorized (cash tip or no tip). Close the ticket and submit the Prior Authorization as soon as possible after the guest signs the check.

Prior authorizations should be generated as part of the end-of-day process or at the end of each shift.

Card Association guidelines state the following:

• The initial transaction performed as an authorization should include the final amount of food, beverage, tax, and the completion transaction (a Prior Authorization).
• The completing transaction would include the additional Tip amount processed with the Incremental Auth 75.

Adjusting Tip Amount (After Batch Close)

End-of-day Process:

Follow the steps below if a tip was entered improperly and the authorization was submitted after a batch is closed.

1. Transmit a Return (type 09) for the full authorized amount. Returns are sent to the processor at settlement time.

2. Transmit a new Sale (type 02) for the total amount plus the tip adjustment for re-authorization.

3. Transaction gets a new authorization.

Full Authorization Reversal, Void Sale and Return

If an Authorization Only (type 01) is not completed with a Prior Authorization (type 07), it is a best practice perform a Full Authorization Reversal transaction (type 61) using the original authorized amount.

This process avoids a misuse of authorization fee from the card associations, and may be required for several reasons:

• The customer requests to pay with another card or method of payment.
• The customer wants to add items to the bill, or divide the check after the initial authorization.
• The customer is owed an adjustment of their total after a coupon or management adjustment.

• Perform a Void Sale transaction (type 11) if a Prior Authorization (type 7) has been completed but not settled.
• A Void Sale (type 11) will automatically attempt a Full Authorization Reversal.
• A Return (type 09) needs to be issued if a Prior Authorization (type 07) is settled.

Bar Tabs

Following is the recommended best practice for handling bar tabs:

• Perform an Auth Only (type 01) for $0.00 to verify the card.
• Use Incremental Auth (type 75) for additional charges/rounds, as well as the tip.
• Use Prior Auth 07 to close the tab.

Other options for handling the bar tab include:

• Charge $50 up front. If the total is less than $50, issue a Full Auth Reversal (type 61), then issue a new Auth for actual total balance due.
• High dollar transactions are better addressed by authorizing each round, or closing out a charge for large purchases and then continuing with another authorization for the next round.
• The associate swipes the credit card and performs an Authorization Only (type 01) for a set dollar amount (configurable within the POS application, and should be greater than $1.00).

Account Verification

Account verification transactions ($0 authorizations) allow the POS to confirm that a card has an available balance, and that the AVS and CVV2/CVC2/CID values are correct.

Account verifications cannot be used to start a financial transaction lifecycle. If the new transaction for the full authorized amount is not swiped, a transaction fee is charged by the card associations for each $0.00 auth.

American Express and Discover

• Account verification transactions must have an amount of $1.00 or more.
• Cards that are manually keyed require billing zip code, street address, and CVV2/CVC2/CID information for approval.

Visa and MasterCard

• Cards that are manually keyed require the Billing ZIP Code for non-swiped $0.00 authorizations.
• Visa assesses a Misuse of Authorization fee for all unsettled Authorization Only transactions. Any transaction that is not settled in the defined time frame is subject to this fee.

Store and Forward

On rare occasions, Fusebox may not be able to complete transactions due to processor outage, network outages, or system maintenance. Store and Forward is the process of encrypting and storing incomplete transactions at the POS for later processing.

When Fusebox becomes available, the POS application forwards the stored transactions for authorization. Transactions are processed as if they were sent in real‐time.

Store and Forward transactions are authorized as swiped or keyed based on the original transaction data. Since the authorization data may contain a card swipe, or if manually entered, card number, AVS and CVV2 / CVC2 / CID, it is extremely important that the data be stored encrypted, following all PCI‐DSS guidelines. PCI‐DSS guidelines state specifically that card swipe data cannot be stored past the authorization. Since the authorization has not been performed it is acceptable to retain this information only in an encrypted environment and as soon as the transaction is submitted for authorization the sensitive data is removed from the POS.

Consult with your Elavon Integration Analyst for additional information before integrating Store and Forward.

Quick Serve

Quick serve restaurants get food to the customer with limited or no table service.

• Tips are not usually part of the transaction amount.
• POS applications in this environment are advised to support one-part Sale (02) transactions.

Delivery / Takeout / Catering Transactions

Transactions are accepted by the merchant where a card may or may not be present.

For example, the merchant accepts takeout orders where either there is no tip, or the gratuity is always added to the purchase amount based on a set percentage. This transaction is entered as a Sale (type 02).

Split-Tender Transactions

A bill is split between multiple forms of payment.

In the following workflow, a bill for $25.00 is split into two checks, one for $15.00, and the other for $10.00.

1. 1st split check amount of $15 uses an Authorization Only transaction (type 01) to obtain authorization.
2. Tip is added using Incremental Auth (type 75).
3. Complete sale of 1st check including tip with Prior Auth (type 07).
4. Second split check amount of $10 uses an Authorization Only transaction (type 01) to obtain authorization.
5. Tip is added using Incremental Auth (type 75).
6. Complete sale of 2nd check including tip with Prior Auth (type 07).