Implementing Tipping

[gohanman]

I'm spinning this off as separate functionality:

The other issue that comes up is tipping of staff. Currently we limit people to cash tips but are constantly being asked to accept credit card tips. Since we use integrated card processing, cc tips would need to be added to the transaction so we are considering an open PLU. However this has the disadvantage of forcing customers to specify a tip amount (and potentially do some math in their heads) while under the steely gaze of their cashier!! Not a huge problem but thought I'd mention it here in case there are some clever solutions...

While the focus of this will be technical there's probably a non-technical side too. I imagine accepting tips via credit card will require some kind of conversation with the store's merchant services provider to make sure the tipping functionality is enabled on the account and/or to avoid setting off alarm bells at the MSP. But I don't have the experience to do more than speculate.

I think the optimal workflow would be to:

• Charge the customer's card for the purchase amount
• Give the customer a paper signature slip with a tip line
• Do an adjustment in POS to increase the original authorization so it includes the tip

I'm sure there are some clever solutions for digital only processes but for a first attempt at this I think it's easiest to stick closely to common conventions.

On the front end side we'd need:

• An interface to pull up existing authorizations and add adjustments
• I think the adjustment would end up being its own transaction with a sale to a dedicated tips department and tender as credit
• The UI should give the option to enter either an adjusted total or the tip amount so there's no extra math if the customer only partially filled out the receipt
• Some kind of login-based filtering controlling which cashiers can adjust which transactions
• Possibly some kind of item/department based configuration so a tip line only appears on a receipt if it's appropriate for that transaction (essentially distinguish between grocery purchases and restaurant purchases)

On the back end side we'd need:

• Reporting on tips. I'd guess both by employee and by hour depending how the store divides tips among employees.
• Special handling for "tip transactions" consisting of the tip amount and additional tender

I think it's ultimately easier to have these as separate transactions as opposed to suspending it and then resuming to add the tip. It's likely necessary to have tip transactions separate in the event that the original is finalized by mistake so aiming for consistency with all tips seems like the right choice. But the tip transactions will need to be curated out of aggregate reports. A purchase plus a tip is still logically only one transaction. This would apply to Paycards, too. We'd have a record for the original authorization and another record for the successful adjustment where as the processor likely reports that as a single authorization.

[otc-narendra]

We would love to see some progress on this. A digital only process would be super lovely but the more traditional paper receipt route would certainly be an excellent start. I assume two copies of each receipt with a tip line need to be printed so that the customer can keep one copy just like at a restaurant. Since vanilla grocery transactions don't involve tipping, I assume the cashier would have to specify that a particular transaction is potentially "tippable" so that the POS prints the paper slip with a tip line?

[gohanman]

Theoretically:

1. Cashier selects EMV w/ Tipping instead of EMV Credit/Debit
2. Terminal asks if customer wants to enter a tipe
3. Terminal accepts tip entry
4. Transactions runs & authorizes
5. POS adds open ring for tip amount
6. POS adds tender line for total authorization including tip

A digital only process actually seems easier to me. Going this route would be least disruptive to cashier or POS's existing behavior. There's one interaction to collect the payment, which may or may not include a tip, and then the transaction's done. A more traditional paper setup would require more steps to somehow go back into the transaction after the initial payment and reauth the card for the tip.

[otc-narendra]

A digital process would be far better than paper! Thank you! I look forward to testing the functionality.

• Narendra Varma

  ---

  From: Andy Theuninck notifications@github.com Sent: Friday, July 27, 2018 2:07 PM To: CORE-POS/IS4C Cc: Narendra Varma; Comment Subject: Re: [CORE-POS/IS4C] Implementing Tipping (#885)

Theoretically:

1. Cashier selects EMV w/ Tipping instead of EMV Credit/Debit
2. Terminal asks if customer wants to enter a tipe
3. Terminal accepts tip entry
4. Transactions runs & authorizes
5. POS adds open ring for tip amount
6. POS adds tender line for total authorization including tip

A digital only process actually seems easier to me. Going this route would be least disruptive to cashier or POS's existing behavior. There's one interaction to collect the payment, which may or may not include a tip, and then the transaction's done. A more traditional paper setup would require more steps to somehow go back into the transaction after the initial payment and reauth the card for the tip.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCORE-POS%2FIS4C%2Fissues%2F885%23issuecomment-408538866&data=02%7C01%7C%7C14ea11dcc93a4fc2cabd08d5f404fa2d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636683224581193442&sdata=1yIYbtOvpSPH7TXt3AU0M%2F8%2Fw%2FlG4A9RDAqzj67t350%3D&reserved=0, or mute the threadhttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAcTaNnjZYMKA6n3cb0CAi-qcY3q_pBydks5uK4DtgaJpZM4OaWdf&data=02%7C01%7C%7C14ea11dcc93a4fc2cabd08d5f404fa2d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636683224581193442&sdata=bi6%2BixbnBhF3R0tbQOKTsajNMb3pxr5Z70jTXj8jJOc%3D&reserved=0.

[otc-narendra]

I just installed the master version of the paycard plugin on my v2.7 lane and with tipping disabled, when I enter a transaction and then enter DATACAP to charge available card, I get a blue box saying "process card transaction". At this point, I cannot enter anything and have to use the browser back button. Same behavior with tipping enabled.

[gohanman]

That sounds like some kind of javascript error that's not necessarily tipping related. Clearing the browser cache might help.

[otc-narendra]

I believe it's related to issue #976 since I don't have the autoloader changes yet. I'll wait to try this once we upgrade to v2.9+

[gohanman]

This is in 2.10 although still entirely untested

[otc-narendra]

@gohanman Just installed 2.10 on the lane, built a new NewMagellan driver and got EMV and swipe transactions running properly using our new Verifone VX-805. Thanks to Joel for his help. However, selecting the EMV with tip option after DATACAP command seems to do nothing at all. Used the EMV test app to verify that the tipping functionality works as expected on the VX805. Any thoughts?

[gohanman]

What does the direct command DATACAPEMVTIP do, if anything?

[otc-narendra]

Direct command DATACAPEMVTIP seemed to work and I was able to follow the prompts on the terminal to add a tip and run the card (message on terminal was APPROVED). However, the POS gave an error saying "An unknown error occurred at the gateway". Once I cleared the error, POS came back to the dialog asking me to confirm that I want to "tender $xxx as EMVTIP?". POS definitely thinks the transaction was not completed but I checked with Vantiv and the transaction was successfully charged.

[gohanman]

That's unfortunately the "something went horribly wrong" generic error. The debug_lane.log might shed light on what happened.

[otc-narendra]

Ok, wierdly enough it now works partially. After the transaction was approved on the terminal (with tip) the POS came back with: "Partial Approval" and the amount paid is the total including tip with Change of the tip amount! I checked my lane settings and Tender CC is mapped to COREPOS-pos-lib-Tenders-CreditCardTender. I would expect that the tip amount would be added to the transaction as an open ring in the TIPS department specified in the paycard plugin settings and not booked as change.

PS: Nothing of value in the debug_lane log

[gohanman]

Yes it should be adding the tip amount as an open ring in the specified departments. Is it configured as literally "TIPS" or is it that department's number? If it's the name instead of the number that's probably the issue.

The current setup does just blindly trust the open ring will succeed. I suppose it'd be better to have a fallback option to record the tip some other way if the open ring fails. There'd be some potential back office headaches if tips aren't recorded in two different ways but prompting the cashier to give change is a more immediate and acute problem.

[otc-narendra]

It's configured as a department number (54 in our case). Agree that having some graceful fallback option to record the tip in the transaction rather than prompting the cashier to give change is better. I was under the impression that the CC tender didn't allow change at all...

[otc-narendra]

I found the problem - typo of PaycardTipDepartment in MercuryDC.php and missing case 'EMVTIP': in PaycardEmvMenu.php. I have fixed both and checked them into the Our Table Gitlab v2.10 repo.

It all works now but of course having some "smarts" to ensure that the open ring succeeds and if not, a fallback would be great. I am happy to test this in a high-volume production setting on Friday and give more feedback...

[gohanman]

Whoops. Something in the commit message auto-closed the issue.

Nice find BTW, thanks.