I am building a menu for a multi-chain sandwich shop in Chicago, and one of the issues the customer has is the modifier page layouts. With the current conversational modifier options, you can either have all mod groups on one page or have them broken out into a page per modifier group. 

With this format, and knowing they will be using a smaller screen, there are too many options on the page and the user would have to scroll down to see all options available for menu items such as this that have many choices.

With this format, there are too many areas that need to be clicked into with the division of pages. Ideally, the customer wants the size. hot/cold choice, and bread choice on one page while the cheese options, toppings, and extras appear on the second page.

Could we please have more control over the modifier screen control?

Had a merchant on old receipt display there refund policy for example:

We want you to be completely satisfied with your purchase! 

If you change your mind or are not satisfied, we offer exchanges or store credit only (no refunds) within 14 calendar days of purchase. Please note, items must be unworn and unwashed, with all tags attached, in order to exchange an item or receive store credit. All clearance items are final sale (no refunds, exchanges, or store credit).

Thank you,

Currently there is a character limit and doesn't allow the full length of a custom message to be entered on the receipt.

There needs to be an easier way to make mass changes in the UI without having to export the data:

1. When you search for a modifier (or modifier group) and then select ‘Edit’ from the results, after making the edits and updating, the system DOES NOT return to the search results screen. When you perform the same operation on a product or item, the system saves the search results.
2. Search and Search Results - The search function should allow users to create a search and save it, or at the very least, retain the search conditions and results until the user clears the search. This works similarly for products and items, but not for modifiers and modifier groups. Without this, the user must continually re-enter the search. Additionally, search results should be able to be sorted and filtered by column (attribute)

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.

In the new Back Office Theme, the Employee based payroll report shows large empty spaces when fields are hidden from the report. In the old back office they could save their preferences, in the new UI it resets to default each time they pull the report.

We have a customer using the Apple terminal who requires the payment method to be printed on the receipt. Could you please prioritize making this option available at your earliest convenience?

We have a merchant that recently switched to using the new backoffice UI. They are requesting the ability to save the custom column selections when they pull a report instead of it reverting back to default each time. They said the old UI did save their custom selections.

When a customer presents a Visa card and the available balance is less than the purchase total, the card issuer may return a unique response code along with a partial amount approved. Currently on the POS, Linga lacks a clear notification for the merchant.

We would like to see a prompt or notification on the POS screen when a partial authorization is received. The notification should:

Clearly alert the merchant that only a partial amount was approved.

Display the approved amount and remaining balance.

Offer the merchant the option to either accept the partial payment and request an additional form of payment (split-tender), or decline the transaction altogether, based on the return code.

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)