Tender screen and split payments

Every sale in Bitta Retail POS is paid through the tender screen: a touch overlay with a button per tender method, a keypad, quick cash buttons, and a large remaining/change readout. This page covers the tender screen itself and split payments. Card specifics live on Card payments at the register, charging to a customer account on On-account sales, and how each tender settles into your accounts on Per-tender settlement.

How a sale gets paid

A sale carries one payment line per tender applied to it - cash, card, voucher, or on account. The payment lines are the single source of truth for how the sale was paid: the sale's paid amount sums them, the shift's expected cash and card totals sum them, and end-of-day posting reads them.

A sale completes only when the applied payments exactly equal the payable total - there is no slack tolerance. Cash handed over above the total becomes change, never part of the applied amount. Once the sale completes, its payment lines are frozen; they can only be edited while the sale is still open.

Each payment line permanently records the tender method it was taken with, so receipts and reports always show the tender exactly as it was at sale time, even if an administrator later renames or reconfigures the method.

Opening the tender screen

Build the cart, then tap the register's tender/checkout button.
The overlay shows Total Due, Remaining, the tender method buttons for this terminal, and any payments already added to the sale.
Add one or more payments (see below) until Remaining reaches zero, then confirm. The sale completes, change due is shown, the receipt prints if auto-print is on, and the register moves to a fresh sale.

Cancelling the overlay changes nothing - no payment is recorded until you confirm.

NOTE

Every number on the tender screen is re-validated on the server when you confirm. If the sale was changed or completed from another session in the meantime, the screen refuses with a friendly error instead of recording money twice.

Taking cash

Denomination buttons: tap bill buttons to build the tendered amount - customer hands a 20 and a 5, tap 20, tap 5. The amounts come from a denomination set configured on the cash tender method (a USD set of 1/5/10/20/50/100 is seeded by default).
Exact cash: methods flagged with an exact-cash button show a one-tap button that takes exactly the remaining balance.
Change: anything tendered above the remaining balance becomes change automatically. Change is only ever computed on cash tenders - a card line never produces cash change.
Overpayment guard: a directly typed applied amount that would overpay the sale is refused with guidance to put the excess in the tendered amount instead. This keeps applied payments exactly equal to the total while still letting customers pay with round bills.

At completion the total change due is stamped on the sale, shown on screen, and printed on the receipt.

Split payments

Split tender is just multiple payment lines - for example 20.00 cash plus the rest on card:

Tap Cash, enter 20.00, Add.
Tap Card (or press Pay card for an integrated reader - see Card payments at the register), Add.
The readout counts Remaining down and flips to Change Due once the sale is covered. Confirm to complete.

TIP

Tapping Add with an empty amount takes the whole remainder for that method - one-tap completion works for every tender, including On Account.

Payments captured by an integrated card reader are locked in the overlay: money the processor has already taken cannot be removed by editing the tender screen. You can still add further payments (cash, on account) to cover any remaining balance.

Tender methods and per-terminal availability

The buttons a register offers come from the tender method catalog. Administrators find it by opening Tell Me (Alt+Q) and searching "POS Tender Methods". Each method defines its behavior class (Cash, Card, Voucher, Other, On Account), its button caption, its sort order, whether it opens the cash drawer, its denomination set, and its exact-cash button. Typical seeded methods are CASH, CARD ("Card (external card terminal)"), VOUCHER, and ONACCT.

A plain Card method with no integration deliberately represents a standalone external card machine: the cashier keys the amount into the machine and records the tender in Bitta Retail POS. The integrated reader flow is separate - see Stripe Terminal setup.

Which methods appear on a given terminal can be refined per store and terminal from the POS Terminal List's Tender Overrides action. While a terminal has no override rows it offers every active method in catalog order; the first override row added makes the override list authoritative for that terminal - only rows marked Visible show, in the override's order.

NOTE

Deactivating a method hides it from every register but keeps its history. Completed sales always keep the tender identity they were paid with.

The back-office tender dialog

The POS Sales Card has a keyboard-first twin of the register overlay: Process -> Tender and Complete. If the sale has no payments yet, it suggests one cash line prefilled with the full remaining amount, so an exact-cash checkout is a single OK. The two surfaces share the same completion logic and can be mixed - lines typed in one appear in the other.

Card payments at the register - integrated reader flow and the external terminal fallback.
On-account sales - charging to a customer account with credit policy checks.
Dual pricing and surcharges - when a price mode is active, the tender screen also shows cash/card totals and the disclosure line.
Per-tender settlement - where each tender's money lands at end of day.