Bar Tabs and Credit Cards: The Mixology for POS Developers
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Bar Tabs and Credit Cards:
The Mixology for POS Developers
Point of sale (POS) systems used in bars and nightclubs have features to support running tabs for
customers who order multiple rounds of drinks and pay by credit card—referred to as “bar tabs.” It is a
challenge for POS developers to keep the payment process simple for employees and customers while
adhering to processing regulations and requirements. Additionally, different merchants have different
levels of risk tolerance. For example, a bar in a public airport with unknown customers, where the risk of
fraud could be high, may decide that certain penalty fees are worth paying, whereas a local
neighborhood bar with a known clientele and lower risk of fraud may not.
Such considerations are the “ingredients” that go into the credit card cocktail—the “mixology” for POS
developers. In this paper, we examine each ingredient to help POS developers create a perfect balance
between their merchants’ risk tolerance and their needs for customer service, fraud protection, and
maintaining compliant authorization practices.
Bar Tab Basics
POS systems designed for food and beverage (F&B) establishments should have easily implemented
procedures to open, maintain and close a customer's tab. What are the basics?
1. Be able to open a new customer's tab by name, seat number or simple identifier. Tabs are
customer/guest specific and should be able to "move" with the customer.
2. Be able to add multiple "rounds" of items to the running tab, incrementing the total amount due
with each round.
3. When the customer is ready, present a printed, itemized check. This check informs the customer of
the total amount due and initiates the payment process.
4. If the customer presents a credit card:
Swipe and process the card for the total amount. The most common way for processing a
payment when a tip modification is involved uses a two-step process: PreAuth followed by a
corresponding PreAuthCapture.
Manually entered transactions should be discouraged. The need for a manual transaction
could indicate fraud. If allowed, enforce a rule that all manually entered transactions require an
accompanying manual imprint of the card.
With an approved authorization, print and present the itemized sales draft plus two additional
copies—the merchant and customer receipt copy—to the cardholder. Include lines for gratuity
and customer signature on both copies.
Retrieve and confirm the signed merchant copy of the check. Modify the final amount to
include the cardholder's added gratuity and then close the tab.
© 2014 Mercury Page 1 of 9Credit Card Acceptance Procedures When Supporting Bar Tabs
Bar Tab Mixology
Balancing merchant and cardholder fraud controls and card brand regulations
Merchants need to protect themselves, especially in the F&B industry, from increasing fraudulent card
activity, authorization limits, and "dine and dash" customers who purposely find ways to walk out on
open tabs. To minimize these risks, POS systems need to offer merchants a way of verifying that credit
cards are valid, not reported lost or stolen, and have available funds.
Some businesses require a credit card authorization just to open a tab; some use incrementing pre-
authorizations to make sure the card has sufficient funds available; others hold a card or driver's license
until the customer requests the final bill.
To protect cardholders from excessive frozen funds due to multiple pre-authorizations, the card brands
have adopted regulations and penalties that aim at reducing a "misuse" of their authorization networks.
POS systems are required to process the transactions in a manner that complies with the card brand
regulations in order to avoid unnecessary fees.
Mixology Ingredients I
Card Brand Regulations—Misuse and Zero Floor
The Visa® Misuse of Authorization Network and Zero Floor Limit regulations outlined below were put in
place to discourage merchants and the POS systems they use from improperly handling transactions.
Misuse of Authorization Network
The Misuse of Authorization regulation applies to credit card authorizations that are not followed by a
matching settled transaction, or in the case of a cancelled or timed out authorization, not properly
reversed. Note that the regulations specify "properly reversed." This means that systems that have
relied on "standard" VoidSales in the past must now add functionality to send a Reversal-VoidSale
including additional process and acquirer reference data.
Currently this penalty fee is 4.5 cents per transaction. The penalty applies if a merchant obtains an
authorization and does not use it. This penalty was implemented to reduce the occurrence of such
authorizations as they can adversely affect a cardholder’s available balance, leading to additional
declines.
Although higher processing fees or downgrades may begin after 24 hours, settlement must occur
within 10 days of authorization. There is an exception for travel and entertainment merchant
categories, which must finalize transactions within 20 days of authorization.
"Status check" transactions may not be used in F&B environments. A status check transaction uses a
fixed, small dollar amount to confirm a card is valid and that it has not been reported lost or stolen.
It may only be used within limited markets such as automated fuel dispensers and certain lodging
merchants.
Zero Floor Limit Fee
The Zero Floor Limit regulation applies to settled transactions that cannot be matched to a previously
approved or partially approved authorization.
Currently this fee is 10 cents per transaction.
This fee applies to settlement transactions submitted without proper authorization, regardless of
cause.
© 2014 Mercury Page 2 of 9Credit Card Acceptance Procedures When Supporting Bar Tabs
Mixology Ingredients II
PreAuths and PreAuthCaptures
The combination of PreAuth and PreAuthCapture is a mainstay of F&B transaction processing. POS
developers need to pay particular attention to correctly build these to take advantage of their intended
use and avoid any unintended misuse.
Whereas the PreAuth communicates with the card issuer to confirm, reserve, and set the originating
conditions of the transaction, the PreAuthCapture communicates with the processor to compare,
complete and fund the transaction. The card brands enforce this matching requirement. It is the basis
for the regulations outlined above.
The PreAuth must match the PreAuthCapture in AuthCode, AcqRefData (Acquirer Reference Data),
original purchase and authorization amounts to maintain its best qualifying processing rate—otherwise
the transaction reclassifies as a "downgrade" and will have a higher processing rate attached to it.
What is a PreAuth? How is it regulated?
The PreAuth hold funds on the available balance of a cardholder's credit card.
When an issuing bank approves a PreAuth, it reserves the amount requested plus an additional
"cushion" of 20%.
Over-authorizing a PreAuth for an amount greater than the actual purchase amount, and estimating
a PreAuth amount, are not allowed.
PreAuths must be finalized using a corresponding PreAuthCapture.
Although authorized with an AuthCode, PreAuths do not receive a response reference number
(RefNo) and are not included in the merchant's batch totals until captured.
Because it is not referenced in the merchant's batch, a PreAuth cannot be voided using a standard
VoidSale. However, it can be "reversed" using a Reversal-VoidSale.
A Reversal is a void request routed directly to the issuer.
Why are reversals (Reversal-VoidSales) so important?
Reversals (also referred to as “Reversal-VoidSale”) cancel a PreAuth transaction by sending the
cancellation request directly to the card issuer. The issuing bank can then clear the cardholder's
available open to buy within hours instead of days.
Before the adoption of reversals, the only option available to POS systems was to use a standard
VoidSale, which could remain "pending" on the cardholder's account for five to seven business days.
Because Reversals may possibly decline, the card brands mandate support for both Reversal-
VoidSales and standard VoidSales.
© 2014 Mercury Page 3 of 9Credit Card Acceptance Procedures When Supporting Bar Tabs
Mixology Ingredients III
Card Brand PrePaid Cards and Partial Approvals
Accepting card branded prepaid cards can offer additional challenges for F&B tab handling procedures
and tip policies. Card brand prepaid cards can be activated like gift cards with a fixed value that
decreases with use. They are unique hybrids that look and are accepted like credit cards, use fixed
values like gift cards, and have real-time debit behavior.
These cards look like standard credit cards. Merchant card acceptance agreements require that the
prepaid cards be accepted wherever the card brand is accepted.
Card brand prepaids are not registered to a cardholder. If lost or stolen, there is no recourse and
the card can be used as cash by whoever has possession of it.
Because they are not associated with a cardholder, there is no way to match them to a customer. If
a customer rings up a large tab, the risk of potential fraud also increases should the customer
present the card for payment and then bails on the balance due.
Card brand prepaids have a real-time balance that decreases with use. This can present challenges
for routine POS functions if the available balance is less than or even equal to the purchase amount.
Balance inquiries on prepaid cards are currently supported only by MasterCard® and Discover®.
Prepaid cards that have a partial amount available pose a similar challenge for tip modification. For
example, cardholders present their prepaid card for the tab purchase total amount due of $50:
1. If the balance on the card is less than the total check amount, the card issuer will partially
authorize the card for only the available balance. The POS handles the balance due. The
verbiage “PARTIAL AP” appears in the authorization text response and the authorized amount
will be less than the requested purchase amount.
2. Whenever a “PARTIAL AP” appears on the PreAuth portion of the transaction, this means there
are no funds remaining on the card. The following steps should be taken:
a. Immediately request a second form of payment to complete purchase.
b. Capture both the prepaid partial amount and the second form of payment amount.
c. If the second form of payment is a credit card, then present two separate sales drafts for the
customer’s signature.
d. The server should write on the partially approved check that the balance on the prepaid
card is 0.00 (so no tip is allowed) and to only accept the gratuity on the second form of
payment.
Card brand rules protect restaurants up to 20 percent of the original authorization for the tip
amount. Risk over 20 percent lies with the F&B establishment—this is true for credit cards as
well as card brand prepaids. Therefore, if the balance on the card is good, but the cardholder
leaves a tip greater than 20 percent, the restaurant is still potentially liable for the amount over
20 percent in a chargeback dispute.
If the balance on the card is the same as the initial check total and the cardholder then leaves
an additional gratuity, the issuing bank will reject this final overage at the time of the batch
settlement. This is because the initial authorization request is sent to the issuer but the final
capture is not sent until settlement.
© 2014 Mercury Page 4 of 9Credit Card Acceptance Procedures When Supporting Bar Tabs
Bar Tab Mixology
Best Practices
Handling bar tabs requires balancing the merchant’s need for greater fraud protection with the need to
satisfy card brand regulations. For the cardholder, transparency and clarity are key. The very best
practice is to have the server request and physically hold on to the customer's credit card (or driver's
license) and then swipe the card when the customer requests the final amount.
Implement your bar tabs in clearly defined steps so that any transaction authorization impact is clearly
apparent to the cardholder and their account. For example:
To open the tab, swipe the card, running a PreAuth based on the amount of the first order.
Use this approval response to confirm the card's validity.
Hold the card through the completion of the final sale.
Use Mercury's MTokenTM secure tokenization technology to store card data for subsequent use.
Mercury's tokens are unique, dynamically-generated, alpha-numeric values, used to securely replace
sensitive card data. They may be stored for subsequent use or used in card-on-file programs. The
use of tokenization reduces the risk and complexity of credit card processing. Mercury is the sole
holder, generator and custodian of the process that generates and then unlocks a token.
When the customer is ready to close the check, if additional items were ordered, first process a
PreAuth Reversal-VoidSale using the token as described above to reverse the initial PreAuth.
Resubmit a second swiped PreAuth for the final amount before returning the card and the itemized
final sales drafts to the customer for adding gratuity and signature.
☞ Important Chargeback Information Per card brand regulations, for merchants to have any recourse
against chargebacks by a cardholder, it is important that the PreAuth of the final sale is always swiped
and a signature obtained by the cardholder.
Bar Tab Mixology
A thumbs up or thumbs down approach
The following outlines four ways of handling credit card payments when implementing bar tabs.
Although each option uses Mercury's tokenization in the PreAuth and PreAuthCapture transaction
sequence, they differ in terms of potential cardholder and card brand impacts.
The overall best practice is to
minimize the number of authorizations on the cardholder's account
maximize the merchant's protection to prevent fraud
stay compliant with the intent of the card brand regulations
© 2014 Mercury Page 5 of 9Credit Card Acceptance Procedures When Supporting Bar Tabs
1. PreAuth—PreAuthCapture at the close of the tab
This approach requires a single authorization on the cardholder’s account and complies with all card
brand regulations.
The server opens a new tab without a status check or card swipe validation.
When the customer is ready to close the tab, the server swipes the customer's card and runs a
PreAuth transaction to obtain a single issuer authorization and a unique Mercury
token/RecordNo. The POS stores the token/RecordNo.
The server presents the customer with the itemized bill, along with customer and merchant
copies of the receipt. The customer adds a gratuity and a signature to the merchant copy.
The server then closes the tab for the purchase plus gratuity amount, using the stored token
from PreAuth response to send the final PreAuthCaptureByRecordNo for capture.
☞ Note A valid signature on a final sales draft that was initially a card-present swiped PreAuth
transaction will significantly improve a merchant's ability to dispute a chargeback case.
2. PreAuth "Status Check" to confirm if card is lost or stolen.
This method requires two authorizations on the cardholder's account. The first validates that the card
has not been reported lost or stolen, and the second authorizes the final transaction amount. The first
authorization could lead to a Misuse of Authorization Network penalty fee if incorrectly implemented.
First authorization – validate the card:
The server obtains the customer's credit card to open a new tab. The server swipes the card to
process a small PreAuth, such as $1.00. The merchant determines the amount.
This PreAuth "status check" is used to confirm that the card is in good standing; the
authorization response returns an issuer AuthCode and a unique Mercury token/RecordNo.
If approved, the POS should use the token/RecordNo to send a PreAuth Reversal-VoidSale.
☞ Note If this step is not completed and the PreAuth is left to “fall off,” the transaction is
assessed a Misuse of Authorization Network penalty fee and the merchant will be charged
an additional 4.5 cents per transaction on that card.
Second authorization – complete the transaction:
When the customer is ready to pay the tab, the server swipes the customer's card a second time
and runs a PreAuth transaction for the final amount to obtain the authorization and a new
Mercury token/RecordNo. The POS stores this token/RecordNo.
The server presents the customer with the itemized bill, along with customer and merchant
copies of the receipt. The customer adds a gratuity and a signature to the merchant copy.
The server then closes the tab for the purchase plus gratuity amount, using the stored token
from the PreAuth response to send the final PreAuthCaptureByRecordNo for capture.
© 2014 Mercury Page 6 of 9Credit Card Acceptance Procedures When Supporting Bar Tabs
3. Incremental PreAuths followed by PreAuth Reversal-VoidSale of tab totals
This method requires multiple authorizations on the cardholder's account and will impact his/her
available balance. This could be considered a Misuse of Authorization Network if incorrectly
implemented.
To open a new tab, the server swipes the customer's credit card for the initial tab amount. Example:
The customer orders two drinks totaling $14.00. The tab is opened by sending a PreAuth for $14.00.
Mercury passes back a unique token/RecordNo "A" to the POS. The POS stores the token/RecordNo.
The customer orders a second round of drinks. The POS programmatically sends a PreAuth Reversal-
VoidSale using token/RecordNo "A" to reverse the initial $14.00.
The server swipes the customer's card a second time, sending a second authorization request for
$28.00 (the total of the two rounds). Mercury passes back a unique token/RecordNo "B" to the POS.
The POS stores the token/RecordNo.
When the customer is ready to close out the tab, the server presents the customer with the
itemized bill, along with customer and merchant copies of the receipt. The customer adds a gratuity
and a signature to the merchant copy.
The server then closes the tab for the purchase plus gratuity amount using the stored token "B"
from PreAuth response to send the final PreAuthCaptureByRecordNo for capture.
☞ Note When a token/RecordNo is used to send a transaction "ByRecordNo," the associated card
data is decrypted as AcctNo and ExpDate only and will be treated like a manually entered
transaction.
4. Incremental PreAuths using estimated amounts
This method uses a predetermined, "estimated" amount that increments by that amount each time the
customer reaches the previous estimated amount until the final tab is closed. It requires multiple
authorization holds on the cardholder’s account. Using estimated dollar amounts is a Misuse of
Authorization Network. Merchant locations may decide that the nature of their business requires this
approach regardless of additional penalties imposed by the Misuse of Authorization Network.
To open a new tab, the server swipes the customer's credit card for an estimated fixed amount
(controlled by the merchant) instead of the actual amount for the first round. For example, the
customer orders a beer for $6, but the first PreAuth is for $20.00. Mercury returns token/RecordNo
"A" to the POS, which stores the token.
Customer orders additional rounds and the amount on the tab exceeds $20. At this point, the server
charges the customer’s card again with another $20.00. The POS uses token/RecordNo "A" from the
first PreAuth to send a second preauthorization (now called PreAuthByRecordNo) for the second
$20.00. This second PreAuth will return a new token/RecordNo "B", which the POS stores. The total
preauthorization hold on the customer's card is now $40, ($20 for the first and $20 on the second)
held by two separate authorizations.
The customer is ready to close the tab. For our example, the actual total is $36. The POS system first
sends a Reversal-VoidSale for each of the two $20 PreAuths, which avoids the penalty fee for Misuse
of Auth Network.
© 2014 Mercury Page 7 of 9Credit Card Acceptance Procedures When Supporting Bar Tabs
Note If this step is not completed and the two PreAuths are left to “fall off,” the merchant
will be assessed an additional 4.5 cents penalty fee per transaction for Misuse of Authorization
Network.
The server then swipes the cardholder's credit card again, which generates a third
preauthorization on the card for the actual total amount of $36. The third PreAuth will return
token/RecordNo "C." The POS stores this for the final PreAuthCaptureByRecordNo.
The server returns the card to the customer and presents the customer with the itemized bill,
along with customer and merchant copies of the receipt. The customer adds a gratuity and a
signature to the merchant copy.
Using token/RecordNo "C," the server closes the tab by sending a final capture (now referred to
as PreAuthCaptureByRecordNo) that includes the total purchase plus gratuity.
☞ Important Notes
A valid signature on the final sales draft that was a card-present, swiped transaction will
significantly improve a merchant's ability to dispute a chargeback.
Use caution if you choose to use this method. Systems that pre-authorize tabs by running a fixed
dollar amount, do so at the risk of causing additional transaction costs and penalties to the
merchant. The benefit of this procedure may or may not outweigh the cost to the business.
Bar Tab Mixology
Final Considerations
1. Always use Mercury's MTokenTM to reduce PCI scope and minimize exposure to card data.
2. Protect against disputes and chargebacks:
Ensure the final transaction is swiped to confirm that the card and cardholder are present.
Never manually enter card numbers unless there is a strict policy to obtain a manual imprint of
the card. Fraudulent cards often have incomplete mag-stripes or purposely damaged mag-
stripes. Without transmitting the card's mag-stripe data, there is no way to prove that the card
was present at the time of sale other than by having a physical imprint of the card.
Validate the cardholder's signature (it should match both the name on the card and the
signature panel on the back of the card).
Ensure your POS received a valid approval code. Set policies and restrictions on “forced” (also
called VoiceAuth) authorization functions to prevent invalid (made up or typo) approvals from
being submitted.
Set policies for monitoring risk associated with tips that exceed the card brand 20 percent
allowance. The merchant is responsible for excessive tips in the event of a dispute.
Settle the batch of transactions in a timely manner—settlement should happen at the end of
each business day.
3. Consider pay as you go, treating cards like cash.
4. When opening a tab, consider holding a secondary form of identification, such as the driver's
license, until the tab is closed.
In high volume establishments, holding the license prevents a customer from opening multiple
tabs with different bartenders or bar stations.
© 2014 Mercury Page 8 of 9Credit Card Acceptance Procedures When Supporting Bar Tabs
Holding the license with an open tab is often the easiest method. While cardholders may report
their credit card lost or stolen to abandon a tab, they are less likely to leave their driver's license
behind.
Merchants will have more recourse to pursue those who walk out without payment.
Make sure to obtain a signed sales receipt. Failure to obtain a signature results in exposure to
chargebacks for missing signature or transaction not authorized. If cardholders leaves without
closing their tab, leaving their license behind, be sure to attach the sales receipt for signature
when they return to get their license.
In conclusion, when all is said and done, there is no easy answer – each situation is different. We hope
that the information provided here helps you to make informed decisions when implementing your own
approach to the credit card payments portion of handling bar tabs.
© 2014 Mercury Page 9 of 9You can also read
