Orders separates taking the order from taking the money, which is exactly how counter service works: the customer orders ahead, and pays when they pick up.
Recording a payment
Open the order on your dashboard and use the payment form: choose Cash or Card (external terminal) — the terminal you already own — enter the amount (it defaults to the balance due), and record it. The order flips to Paid, and the customer's tracking page shows it too.
Choosing the right payment method
The payment form is intentionally simple, but the method you select matters for downstream reporting. Cash payments are logged as tendered currency and feed directly into your end-of-day cash drawer reconciliation. Card (external terminal) is the right choice whenever a customer taps, swipes, or inserts a card on a terminal you already operate outside of NOWAITN — this keeps your existing processor relationship and rates intact while still giving you a unified record inside the platform. There's no need to re-key card numbers or connect a separate payment gateway; the system simply logs that a card transaction occurred and ties it to the order.
If a customer pays with a mix of methods — say, part cash and part card — you can record each portion separately against the same order. Enter the cash amount first, record it, and the balance due will automatically update to reflect what's still owed before you log the card portion. This keeps a clean, itemized record of exactly how each dollar was collected, which is especially useful for businesses that reconcile cash drawers independently from card batch totals.
Working from any device at the counter
Because the payment form lives on your dashboard, staff can record payments from a phone, tablet, or desktop at any workstation — there's no dependency on a single fixed point-of-sale terminal. This is particularly useful for walk-up counters, food trucks, or pop-up service windows where staff move between a register and a mobile device throughout a shift. As long as a team member is logged in with the appropriate permissions, they can pull up the order, confirm the amount, and mark it paid in a few taps.
Correcting a payment entry
Mistakes happen — a staff member might select the wrong method or mistype an amount. Rather than leaving an inaccurate record in place, void or adjust the payment entry directly on the order before closing it out. Keeping corrections tied to the original order (rather than creating a separate adjustment later) preserves a clear timeline for anyone reviewing the transaction afterward, including during shift reconciliation or a customer dispute.
Best practices for front-counter staff
- Confirm the balance before recording — the form defaults to the amount due, but always double-check against what the customer is actually handing over, especially on orders with recent modifications.
- Record immediately, not in batches — logging payments in real time, order by order, prevents end-of-shift guesswork and reduces the chance of an order being marked paid twice or missed entirely.
- Use consistent terminology with your team — make sure every staff member understands the difference between "Cash" and "Card (external terminal)" so reporting stays accurate across shifts and locations.
- Train new hires on the tracking page update — customers often glance at their phone the moment they pay, so staff should know that the status change is instant and visible, which helps answer "did that go through?" questions on the spot.
Getting this first step right sets up everything downstream — from tip allocation and split payments to the audit trail your bookkeeper relies on at month end — so it's worth building a habit of precise, real-time entry at the counter.
Balances, tips, and splits
Every order carries a running balance: partial payments are fine, several payments can settle one order (two people splitting, a deposit then the rest), and any tip the customer added at ordering is already in the total. Staff need the payment permission on their seat to record money — order-taking and payment-taking are separate capabilities.
How running balances work in practice
Each order's balance updates in real time as payments land against it, regardless of channel. A customer might place a deposit online when booking, add an item at the counter, and then pay the remainder with a card at pickup — all three events post to the same running total. Staff never need to do mental math to figure out what's owed; the balance due is always visible on the order screen, and it automatically nets out tips, discounts, and any adjustments applied earlier in the order lifecycle.
This matters most for businesses that take deposits or partial prepayments — catering orders, large group reservations, or custom jobs. Instead of tracking a separate spreadsheet of "who owes what," the order itself becomes the single source of truth for balance status, which reduces the chance of double-charging or accidentally letting an order go out unpaid.
Handling tips correctly
Tips added during the ordering process — whether through a self-service kiosk, an online checkout flow, or a staff-assisted prompt — are folded directly into the order total before any payment is recorded. This means front-counter staff should never manually add a tip amount on top of the displayed balance; doing so risks double-counting. If a customer wants to add or adjust a tip after the fact (for example, increasing it on a card payment at pickup), that adjustment should be made as an edit to the order itself, not as a separate line item at the time of payment. Keeping tips inside the order record also ensures they flow correctly into reporting and any downstream payroll or tip-pooling calculations.
Splitting payments across multiple people or methods
Splits are common in dine-in, group ordering, and family billing scenarios, and the platform supports them without requiring staff to create duplicate orders. A few patterns worth knowing:
- Even splits: Divide the total balance evenly across a known number of payers — useful for groups who agree to split the bill equally.
- Custom splits: Apply different amounts per payer when guests are only covering their own items or contributing unequal shares.
- Mixed-method splits: One portion of the balance can be paid by card while another is settled in cash, and each payment is logged as its own entry against the same order.
Because each split payment is recorded as a discrete transaction, the audit trail stays granular — if a dispute arises later, staff can see exactly which payment method covered which portion of the bill, rather than one lump-sum entry that obscures the details.
Permissions: separating order-taking from payment-taking
Not every staff member who can build or modify an order should necessarily be able to take money against it. The platform treats these as distinct seat-level permissions, which supports a few practical use cases:
- Trainees or front-of-house staff can take orders and manage splits without being granted payment authority, reducing risk during onboarding.
- Shift leads or cashiers can be granted payment permission specifically for the register or counter they're working, limiting exposure if a seat is shared across stations.
- Managers can audit who recorded which payment, since the permission model ties every transaction to an individual staff identity rather than a generic terminal login.
Setting this up correctly during staff onboarding — rather than granting blanket payment access to every seat — is one of the simplest ways to tighten financial controls at the counter without slowing down service.
Paying by card online
Card payment through your own Stripe account is available today for orders placed through the API — developers can request a hosted payment link or embed the payment step directly. Card checkout on the hosted ordering page is rolling out next; until then the page is deliberately pay-at-pickup, which also means zero payment setup before you can start taking orders.
How the Stripe integration works
Because the integration connects directly to your own Stripe account, funds settle to you on Stripe's standard payout schedule rather than passing through a third-party holding account. This matters for cash flow planning and for reconciliation, since the money movement you see in Stripe should match the orders recorded in NOWAITN one-to-one. When an order is created through the API with a payment request attached, NOWAITN generates a payment intent in Stripe, tracks its status (pending, succeeded, failed, or refunded), and updates the order's payment state automatically as Stripe sends webhook confirmations. There's no manual step required to mark an online card order as paid — the system does this the moment Stripe confirms the charge.
Hosted payment links vs. embedded checkout
Developers integrating card payments have two implementation paths, and the right choice depends on how much control you want over the customer experience:
- Hosted payment link: NOWAITN generates a Stripe-hosted checkout URL that you can send via SMS, email, or display as a QR code. This is the fastest path to production since Stripe handles the entire payment UI, including card validation, 3D Secure authentication, and mobile wallet support like Apple Pay and Google Pay — all with no custom frontend work required.
- Embedded payment step: For businesses that want the payment form to live inside their own app or ordering flow, the payment step can be embedded directly using Stripe Elements. This keeps customers inside your branded experience from browsing to checkout, but requires more frontend implementation and ongoing maintenance as Stripe's SDK evolves.
Most teams starting out choose the hosted link for speed, then migrate to embedded checkout once order volume justifies the engineering investment.
Security and PCI compliance
Both implementation paths keep raw card data off your servers entirely. Stripe's hosted checkout and Stripe Elements are built to keep you in the simplest PCI compliance tier (SAQ A), since card numbers are tokenized in the customer's browser before ever reaching your infrastructure. This is a meaningful advantage over building a custom card form, which would pull your business into much stricter compliance requirements. If your team is evaluating card payments for the first time, this is worth flagging to whoever owns compliance — it significantly reduces the audit burden compared to a self-built solution.
Preparing for hosted-page card checkout
While the hosted ordering page remains pay-at-pickup for now, businesses planning ahead should still connect and verify their Stripe account today. Doing so early means there's no setup delay once card checkout becomes available on the hosted page — the account, bank details, and tax settings will already be in place. It's also a good opportunity to test the API-based payment flow on a subset of orders (for example, catering or large group orders placed by phone) so staff are already familiar with how online payments appear in the order and audit trail before the feature rolls out more broadly.
Reconciling online and counter payments together
Once card payments start flowing in through the API alongside counter payments, reconciliation needs to account for both sources. Online card orders will appear in the same audit trail as counter transactions, tagged with their payment method and Stripe transaction reference, so end-of-shift reconciliation doesn't require cross-referencing a separate system. Front-counter staff should still check for any online orders awaiting pickup at the start of a shift, since these are already paid and simply need fulfillment rather than payment collection at the register.
The audit trail
Every payment records who took it, when, by what method, and against which order — so end-of-day reconciliation is reading a list, not reconstructing one.
What gets logged automatically
Each transaction captures a consistent set of fields the moment it's recorded, with no extra steps required from staff:
- Staff member on shift — the login or PIN used to record the payment, not just whoever happens to be at the counter
- Timestamp — down to the second, which matters when you're investigating a discrepancy against a specific till session
- Payment method — cash, card, online, or split, including the specific processor or terminal reference for card transactions
- Order reference — linking the payment back to the original job, ticket, or invoice so there's never an orphaned transaction
- Amount and tip breakdown — the base total, any tip, and the final amount collected, recorded separately rather than as a single lump sum
Because this data is captured at the point of transaction rather than entered retrospectively, it removes the usual gap between what actually happened at the counter and what gets written down later in a spreadsheet or notebook.
Reconciling at the end of a shift
Instead of counting a cash drawer against a handwritten log and hoping the numbers match, a shift close becomes a side-by-side comparison: the system's recorded totals against what's physically in the drawer or showing on the card terminal batch report. Discrepancies surface immediately, by shift and by staff member, rather than days later when it's nearly impossible to remember which transaction was off.
This is particularly useful in businesses with multiple staff taking payments across a single day. Rather than one shared till log that blurs together, each team member's transactions are separated automatically, so you can see at a glance whether a shortfall is a one-off counting error or a pattern tied to a specific shift.
Why this matters for disputes and refunds
When a customer disputes a charge or a card payment gets queried by their bank, having an exact record of when the payment was taken, by whom, and against which order gives you something concrete to respond with — rather than relying on memory or a search through paper receipts. The same applies internally: if a tip is reported as missing or a split payment doesn't seem to add up, the audit trail shows exactly how the amount was divided and recorded at the time, not reconstructed after the fact.
Best practices for keeping the trail clean
- Require individual staff logins or PINs rather than a shared counter account, so every entry in the trail points to an actual person
- Record payments at the moment they're taken rather than batching them in at the end of a shift — this keeps timestamps accurate and reduces the risk of a payment being recorded against the wrong order
- Review flagged discrepancies the same day they occur, while the relevant staff member and transaction details are still fresh
- Export audit logs periodically for your accounting records, rather than relying solely on in-app history, particularly if you're preparing for a tax filing or external audit
Supporting compliance and accounting
Beyond day-to-day reconciliation, a consistent audit trail simplifies work at tax time and during any external review. Bookkeepers and accountants can pull a clean, timestamped record of revenue by method and by day, rather than asking your team to recreate historical totals from memory or fragmented paperwork. For businesses that undergo periodic financial reviews or need to demonstrate PCI-related handling of card data, having payment records tied to specific staff actions and terminals also provides a straightforward paper trail to point to, rather than scrambling to assemble one under time pressure.