> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getdropp.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Dropp Terminals

> How a cashier operates the Dropp Terminal — a handheld device for taking orders and payments at the table or counter.

Dropp Terminal is a handheld device cashiers use to take orders and payments in person — at a table, a counter, or a QSR line. It's a native app on physical hardware, not a web page. A cashier logs in, browses the menu, builds a cart, checks out (including tapping a card on the built-in card reader), and can print a receipt over the venue's WiFi. Today it's live with 2 customers.

Every screen has the same navigation: tap the hamburger icon top right to open a slide-out drawer with Ordering, Reports, Menu, Printer jobs, and Log out.

## Logging in

The cashier enters **Terminal** (required) — the terminal's name — and **Password** (required), then taps Login. Both fields just need to be non-empty; there's no format rule.

<Note>
  Login persists. Once signed in, the terminal stays logged in across restarts — no need to log back in until the cashier explicitly logs out.
</Note>

If login fails, the cashier sees one of three messages: the server's own error, a connection message (no network / can't reach the server), or a generic fallback. The terminal never fails silently on login.

## Ordering

This is the home screen after login. The cashier browses the day's recommended menu, searches by name, description, or ingredient, filters by category, and adds items to the cart with +/- steppers. Tapping **Your Bag** goes to checkout.

There's no fee math on this screen — the cart total is a plain sum of item prices.

If the menu fails to load, the cashier sees a clear error message, not a blank screen.

## Checkout

The cashier reviews the cart and picks:

* **Fulfillment** (required) — dine-in, takeout, or delivery. Defaults to dine-in.
* **Payment method** (required) — card, transfer, or cash. Defaults to card.
* **Customer name, email, phone, discount code** (all optional) — an order can be placed with none of these filled in.

Tapping **Checkout** places the order.

<Warning>
  Card payments go through the terminal's built-in card reader. Cash and transfer skip that step entirely and place the order straight away — the terminal is trusting the cashier's word that the money changed hands, with no confirmation step.
</Warning>

For card payments, the terminal talks to the physical card reader directly. Two failure cases are handled so the cashier is never left guessing:

* If the reader doesn't respond at all, the cashier sees "No response from the card reader" instead of the order silently going through with no payment.
* If the payment step fails to even start, the cashier sees "Could not start the payment" instead of the Checkout button spinning forever.

If checkout fails for any other reason, the cashier sees a real error message, not a crash.

## Order confirmation

After checkout, the cashier sees the total charged and a **Back to Menu** button, which clears the cart and returns to Ordering.

## Menu

The cashier can view the venue's live menu and toggle any dish on or off with the eye icon — useful when something runs out, e.g. "we're out of jollof today."

<Warning>
  If the menu fails to load, or a hide/show toggle fails, the cashier sees nothing — no error message, just an empty or unchanged screen. If a dish disappears from Menu but stays visible to customers, this is why: the toggle likely failed silently. Worth checking the network connection and retrying.
</Warning>

## Reports

A read-only sales view for this terminal: total net sales (all-time and today), and a scrollable table of every order — ticket number, date, time, customer details, items, order count, amount, payment type, and fulfillment type. There's nothing to edit here.

<Warning>
  If the report data fails to load, the cashier sees an empty screen with just headers and no explanation. If Reports looks empty, it may not mean there were no sales — retry, or check the connection.
</Warning>

## Printer jobs

The terminal can print receipts to a printer on the venue's WiFi. Dropp's engine can't reach into a venue's local network directly, so it queues each receipt as a job, and the terminal — because it's physically on that WiFi — checks for waiting jobs every 15 seconds and sends them to the printer.

The Printer jobs screen shows each job with a status: **Waiting**, **Sending…**, **Sent**, or **Failed**. New jobs send automatically; the cashier can also pull to refresh or tap **Check now** to force a check right away.

<Note>
  A failed print never blocks or interrupts taking orders. The order is the money; the receipt is a convenience. A failed job just sits as "Failed" in the list — it never throws an alert or stops the cashier from working.
</Note>

If printing stops working for about 30 seconds (two failed checks in a row), a banner tells the cashier printing may be paused, and says whether it looks like a login problem (needs re-login) or a general connection problem. It doesn't warn on the very first failed check, so one dropped request doesn't cause a false alarm.

If a printer's connection changes — say from WiFi to Bluetooth — after a job was already queued for it, the terminal won't attempt to send to it. It shows as failed rather than trying and hanging.