Bar Tabs and Credit Cards: The Mixology for POS Developers

Transcription

1 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 Mercury Page 1 of 9

2 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 preauthorizations 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 Mercury Page 2 of 9

3 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 Mercury Page 3 of 9

4 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 Mercury Page 4 of 9

5 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 MToken TM 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 9

6 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 Mercury Page 6 of 9

7 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 $ The tab is opened by sending a PreAuth for $ 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 $ 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 $ 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 $ The POS uses token/recordno "A" from the first PreAuth to send a second preauthorization (now called PreAuthByRecordNo) for the second $ 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 Mercury Page 7 of 9

8 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 MToken TM 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 magstripes. 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 Mercury Page 8 of 9

9 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 Mercury Page 9 of 9