dmeeker

Bar Tab Rage

Blog Post created by dmeeker on Aug 30, 2017

Bar Tab Transaction Flows

dsiEMVUS

 

Bar tabs can be a tricky thing to figure out how to handle from a transaction flow perspective. In this article we will explore some different scenarios that may arise when dealing with bar tabs using Datacap NETePay with dsiEMVUS and hopefully untangle the process a bit and make it clear, simple, and easy to understand.

 

Tab handling is complex and the technology doesn't always solve for the best scenario as there are many different user experiences to  consider.  As an integrator feel free to share how you currently manage bar tabs in the comments below.

 

Act 1:Scene 1

This gentleman finds himself at a bar and would like to open a tab.

The Bartender requests the gentleman’s credit card and opens a tab by sending an EMVZeroAuth

transaction to verify that the card is active.

                     *The EMVZeroAuth also returns a Token, which can be stored for later use*

 

    1. The transaction request is sent from the POS to the dsiEMVUS client control

    2. dsiEMVUS sends the request to the PIN Pad to prompt for card entry

    3. The EMV chip card is inserted into the card reader and the card data is immediately read and encrypted

    4. The secure card data is included into the transaction and forwarded to the NETePay service

    5. NETePay sends the transaction request to the Vantiv host

    6. The Vantiv host decrypts the card data and sends it to the issuing bank for approval

    7. The issuing bank sends the response back to Vantiv

    8. Vantiv takes the clear card data and converts it into a secure token

    9. The response is sent from Vantiv to NETePay, to the PIN Pad, and finally through dsiEMVUS back to the POS

  10. The POS takes the token and stores it for later use

 

*The transaction having been approved, the Bartender hands the card back to the Gentleman

         

 

       

*The transaction having been declined, the Bartender requests a different form of payment           

 

 

Act 1:Scene 2

                              The Gentleman has eaten and drank to his heart’s content (and his wallet’s chagrin) and is now

                              ready to checkout.

 

 

 

 

Scenario 1) While an uncommon situation for a diner, since it is the best thing for the merchant from a processing standpoint the Bartender prints out the check and requests the Gentleman’s card again.

The Bartender closes the check and runs a new EMVSale (which follows the same path as an EMVZeroAuth) for the full amount including the tip and the Sale is approved.

 

 

Scenario 2) Since the POS has the token from the initial EMVZeroAuth a new SaleByRecordNo can be sent for approval.

     *Ideally the Bartender prints off a receipt with a tip line and processes the entire transaction with the tip, but this is

       not as important with a SaleByRecordNo as it would be with an EMVSale

 

 

     1. The transaction request is sent from the POS to the dsiEMVUS™ client control.

     2. dsiEMVUS sends the request directly to NETePay

     3. NETePay sends the transaction request to the Vantiv host

     4. The Vantiv host detokenizes the card data and sends it to the issuing bank for approval

     5. The host bank sends the response back to Vantiv

     6. Vantiv takes the clear card data and converts it into a brand new secure token

     7. The response is sent from Vantiv to NETePay and through dsiEMVUS back to the POS

     8. The POS replaces the old token with the new one and stores it for later use

 

*The transaction having been approved, the Bartender hands the card back to the Gentleman

 

 

 

*The transaction having been declined (Since the EMVZeroAuth did not verify any funds on the card), the Bartender requests a different form of payment

 

Or

                   

 

He sends the Gentleman to the kitchen to wash dishes

 

 

Scenario 3) Finally, what if the transaction did not have a tip added on the initial transaction, but needed to be added after the fact? As a follow up to the SaleByRecordNo an AdjustByRecordNo is sent to change the initial transaction to now include a tip.

 

 

     1. The transaction request is sent from the POS to the dsiEMVUS™ client control.

     2. dsiEMVUS sends the request directly to NETePay

     3. NETePay™ sends the transaction request to the Vantiv host where it will live until the batch is closed and sent to

         the bank for settlement

     4. The Vantiv host receives the request to adjust the transaction and makes the adjustment

     5. Vantiv refreshes the token and replaces it with a brand new secure token

     6. The response is sent from Vantiv back to NETePay™ and through dsiEMVUS™ back to the POS

     7. The POS replaces the old token with the new one and stores it for later use

 

 

Act 2:Scene 1

 

While there are dozens of different scenarios that can be explored, let’s look at just one more:

 

 

What if the Gentleman looked at his credit card statement a few days later and

                                                        realized that the total amount was incorrect?

 

 

          He calls the merchant and explains the situation and finds out that the tip was entered incorrectly.

 

         
      The merchant can partially refund the transaction in the amount that was incorrectly charged.

      The merchant recalls the previous transaction and using the Token sends a ReturnByRecordNo

      transaction, which follows the same transaction flow as a SaleByRecordNo.

 

Final Bow

 

These are different ways to handle bar tabs with the current latest versions of Datacap's NETePay™ (5.06.11) and dsiEMVUS (1.16). In the future there may be a different and even better way to handle bar tabs and once available we will explore that method and its various nuances as well. I hope this article has been both informative and fun to read.

 

Thank you for reading!

Outcomes