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.

Summary:
Allow items on the POS system to be restricted not only by time and day, but also by service type (e.g., Dine-In, Takeout, Delivery).

Use Case:
A merchant has a "Wing Wednesday" special that is already configured to be available only on Wednesdays. However, they want to further restrict the item to specific service types—namely, Dine-In, Table Service, and Bar Tab. The item should not be available for QSR, To-Go or Delivery orders.

Proposed Functionality:

• Add a configuration option at the item level to enable or disable availability by service type.

• Allow merchants to select one or more service types where the item is eligible.

• The system should enforce this restriction at the time of order creation, ensuring the item cannot be added if the current order’s service type is not allowed.

Benefits:

• Greater control over promotional item availability.

• Prevents misuse or accidental application of specials to unintended order types.

• Supports complex pricing or availability strategies based on business operations.

Example Scenario:

• Item: Wing Wednesday Special

• Availability: Wednesdays only

• Allowed Service Types: For Here, Table Service, Bar Tab

• Result: The item will not appear or be allowed on Takeout or Delivery orders, even on Wednesdays.

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)

Partner is asking for a change to be made to the formatting of the "Pay by CC" line when using cash discount. Merchants/customers are getting confused as this wording would not apply if using a debit card and not a credit card as this technically would be causing a violation. Partner is requesting for the wording to be changed to "card pricing".

Partners have mentioned customers wanting the following integrations added to the Integration Hub since some of the current options do not work for them.

• MarginEdge
• Tip Haus

Fatte Albert's Pizza requested the following feature to be implemented to Linga POS:

• To be able to close the shift without performing the close day
• To be able to collect reports for different shifts

There is currently no way to show balance from an EBT card on the front end receipt. This can cause possible issue for SNAP states that required this information.