Add a text box for entering in a reason for the discount. The description should only appear if the toggle is enabled on the discount in the back office. 

If I have a tab named Bob and a tab named Tom.  Try to transfer a beer from Bob's tab to Tom's tab it shows up with check number rather than bar tab name.  So it will say 01-001 Bar Tab, etc.  Check number not listed under bar tab have to go into the order and remember check number.  I'm suggesting on the item transfer page replacing "Bar Tab" with customer name (ex 01-001 Bob). All of my customers who use tabs have made this suggestion the 1st time they try to transfer from one tab to another.

We have three restaurant locations (same ownerhip) that is requesting a role security switch that would prevent staff from adding gratuity to a check. This is a very common functionality in most POS system software in the restaurant industry. If the switch is in the off position the Gratuity button under Options in the order screen would be disabled for a user assigned to a role with that restriction. Please see attached images and let me know if there are any other details needed.

The option to remove seat print should be available for ALL service types. 

Not all table service restaurants like to use the seat option. 

They will often split by seat at the end of the transaction but many do not enter the order by seat and many do not want the seats printed in the kitchen.

When a split payment takes place, the seats that have already been paid for still show and don’t disappear or get marked as paid, which confuses the merchant who has to go over each ticket to see the items listed.
The least we can do, if you can’t make the paid seats disappear from the list like other systems, is to highlight them in a different color and have a PAID text overlay on the items.

Currently, the system only allows us to either void the entire check or issue a refund for a specific item once payment has been completed. However, there are situations where it would be more efficient and appropriate to void or refund a single item from a paid check, without having to void the entire check or process a full refund.

When a delivery order & driver is marked as arrived and is unpaid the only payment option that pops up is cash. Please add the ability to include other payment methods like Side CC and Others for restaurants that accept checks or other payment on delivery options can be logged when the driver arrives back at the restaurant. 

At the moment the restaurant has to open the order in check status, mark the payment type and then go back to delivery tab to arrive and close the order. 

Please add the delivery fee driver compensation to the driver/cashier report so restaurants can cash out tips and compensation at the end of a shift from the POS rather than having to log into the back office to pull the driver report.

A merchant has requested that we should have the ability to sell E gift card from the POS. The E gift card number or code can be shown on a receipt or part of the sales receipt. 

Currently, Linga POS allows merchants to configure a Debit payment type; however, selecting this payment type does not result in a true debit transaction being initiated on the payment device. Instead, selecting Debit simply adjusts surcharge calculations but still sends the transaction to the device and processor as a standard credit transaction.

The key issue is that Linga POS does not currently send any instruction or indicator to the integrated payment device to initiate debit transaction logic. As a result, while the cardholder may be prompted to enter a PIN, the transaction is still processed as credit at the device and processor level.

Business Need:

For solutions like ours, the ability for the POS to correctly initiate debit vs credit at the device level is essential. Most payment devices expect a specific transaction type to be initiated to handle debit properly:

• Initiating debit triggers the device to handle routing, PIN entry, network logic, and correct processing with the processor.

• Initiating credit bypasses debit networks entirely, even if a PIN is entered.

Without Linga sending the correct transaction type to the payment device, debit-capable cards are always routed as credit, resulting in:

• Incorrect interchange qualification.

• Missed cost savings for merchants who intend to process true PIN-debit.

• Inability to comply with some processor requirements or merchant agreements.

• Confusion at the merchant level when "Debit" is selected but does not function as expected.

Requested Enhancement:
We are requesting that Linga POS implement proper debit support by:

1. Allowing the POS system to distinguish between credit and debit when communicating with the integrated payment device.

2. Sending the appropriate transaction type instruction to the device when the Debit tender type is selected in Linga.

3. Ensuring that when Debit is selected:

   • The device initiates a debit transaction flow.

   • The device controls PIN entry, routing, and processing in accordance with the card brand and processor requirements.

4. Maintaining the existing surcharge logic as applicable.

Why This is Critical:

• The current behavior prevents merchants from leveraging true PIN debit.

• Payment processors and devices rely on POS software to properly identify the intended transaction type.

• Proper debit support is already expected and standard across many other POS platforms.

• Linga already handles EBT properly, which shows device-level transaction type control is possible.

Reference Ticket:
Case #206888 (Joshua Fox, Partner Support)