Sales and Payments

Open Store Operations > Sales & Payments to reconcile sales and payment activity for the selected store. The page requires transaction read access. Its default date range is the last 30 days.

Customer display before payment

The customer display follows the live cart, loyalty (when enabled), tip (when enabled), final order review, then payment choice. While the cashier's checkout quote or review is not ready, the live cart remains visible with Your cashier is preparing your order; it does not claim that a payment is loading or processing. Final totals and customer checkout actions remain gated by the matching server quote and review.

At Select Payment on Android registers, the Pay with Cash and Pay with Card tiles are the primary actions, each showing its applicable quoted total. Tap a tile to begin that tender's existing workflow; cash still requires collecting and confirming the cash. These actions stay visible but unavailable until the matching server quote is ready. Registers use the same payment tiles and secondary options, stacked on narrow screens and arranged side by side on wider screens. The subtotal, tax and tip breakdown follows the secondary options without repeating the tender totals.

Saved cards at the Android register

Attach the customer to the cart, select Charge, and choose Saved card at payment selection. Select the customer's masked card, review the displayed checkout total, and choose Charge saved card to confirm the payment. No card is preselected, and no separate assent checkbox or authorization step is required. The picker displays expiry and the default-card marker when available; a default card is not automatically selected. Cards originally saved online or elsewhere are eligible when they are active ordinary cards owned by this customer in the current organization and store; expired, revoked, unavailable, and differently scoped methods cannot be used.

This is a one-time customer-initiated stored-card payment, not an appointment automatic deposit/balance charge, subscription, or autopay authorization. Future automatic charges still require their separate agreement. The payment uses the register's existing ticket and exact server quote, including discounts, tax, manual prices, tip, and card pricing fee. It does not create a second virtual-terminal sale or ask the reader to simulate a card-present transaction.

Saved-card selection requires store.customers.read for the exact terminal store; payment also requires store.transactions.write. Customer ownership and the frozen ticket quote are checked separately from these operator permissions. Saved-card refunds, including gift-card funding reversals and checkout compensation, use card-not-present approval policy and the original payment identity.

If the merchant confirms that the card became unavailable before Gateway dispatch, the admitted attempt is durably closed with no payment effect so it no longer blocks the ticket. A transport failure or unknown provider response is not that proof and never authorizes another charge.

The device cannot report a saved-card approval, decline, or no-dispatch outcome: only the merchant's authenticated no-effect response or verified Gateway evidence can close that server-dispatched attempt. On completion, the receipt and customer display use this attempt's masked card and matching authorization/reference, not a previous partial tender's presentation state.

Payment coverage alone does not open a receipt: the ticket must be completed and contain its recorded transaction. If the payment is applied while sale recording is still pending, the register releases the foreground checkout without showing success; the backend finishes recording the same payment without another charge.

New terminal sales receive a positive, store-scoped transaction reference from the server when their sale header is recorded. The reference is reserved atomically, does not reset each year, and remains unchanged when the same sale is retried. Existing positive references are preserved and advance the counter so later automatically numbered sales cannot reuse them; historical records showing 0 are not renumbered automatically. The POS transaction UUID remains the canonical identity.

An uncertain payment response does not keep the register occupied or offer a charge retry. The app checks the original ticket's status at most twice, then releases that local checkout so the operator can begin another sale. The backend retains the original immutable payment identity and reconciles it without dispatching another charge.

Gift cards on Android POS

Open More → Gift cards. Sell/load a card adds the selected amount to the cart for payment. Check balance accepts a scan or a manually entered card number.

Cards needing attention appears only when a customer needs a card load completed, refund approval, or cash returned after a reversed gift card sale. View sold cards also lets you retrieve an issued card code or update delivery contact details; issued cards are not counted as unfinished work. Background reconciliation and automatic delivery are not cashier tasks. When told to return cash, give only the displayed amount and confirm after handing it to the customer. If you already returned it, confirm without paying again; if uncertain, ask a manager before giving any cash.

Find a sale or payment

1. Confirm the selected store.
2. Set From and To to the period you need.
3. If you have a reference, enter the exact transaction number, processor reference, POS ID, or Gateway ID in Transaction or payment reference.
4. Optionally choose one or more Channels. Select Clear to remove the channel filter.
5. Review the result columns:
   • Date and Txn # identify the record;
   • Source identifies its channel and transaction type;
   • Lifecycle shows the transaction state;
   • Payment shows the method and any displayed fee;
   • Amount shows the transaction total;
   • Sync shows whether the payment record is connected to the corresponding sale; and
   • Identifiers shows the available POS or payment reference.
6. Use Previous and Next when the result spans more than one page.

If a banner says some payment data is temporarily unavailable, the page is showing in-store transactions only. Treat that result as incomplete and retry before declaring the period reconciled.

Inspect transaction details

Select a row to open Transaction Details. Compare the following sections with the receipt or processor reference you are investigating:

• Payment Summary: method, reference, subtotal, tax, tip, fee, discount, total, tender amounts, and change when available;
• Line Items: product, quantity, unit price, and line total;
• Receipt Preview: store, date, totals, processor reference, and the customer-facing receipt or item detail;
• Card Authorization: card type, masked last four digits, authorization code, and entry method when supplied;
• Settlement: batch status and linked batch identifiers for card payments; and
• Customer and Compliance Checks when those records exist and your role can view them.

Select a linked batch identifier to open its record in Settlement Batches. Select Open hosted receipt when a hosted version is available. Transaction readers can also use Email Receipt or SMS Receipt to resend the receipt to a destination they enter.

For checkout-ticket sales, the cart, checkout, customer display, and receipt created at checkout use frozen server prices and discount allocations, not current product settings. Discount names disclose coupon and promotion allocations; allocations on several products can belong to one basket-wide coupon. A 10% basket coupon is not limited to the item used to open the adjustment dialog. Applying a one-shot coupon continues to replace automatic promotions rather than stack with them.

Dual pricing means two prices, not a fee or a cash discount. Live item rows show card unit prices and quantity-based gross amounts. The merchant summary shows Total for cash and Card Total for card; payment buttons show the amount for that tender, alongside Split Payment when enabled. Discounts and tax are quoted separately for each price basis. Deposits are identical for cash and card, and tips stay separate from item prices. EBT FOOD uses eligible merchandise's cash price without SNAP tax; EBT Cash uses the cash price with applicable tax.

Receipts created at checkout show cash item prices and totals for Cash or Gift Card, and card item prices and totals for Card. Cash/card split receipts show the card-priced order as Card total, the actual tender amounts, and Amount paid. Gift-plus-Cash stays on its cash-price basis. SNAP-funded portions use their frozen cash prices and tax exemption; partially funded items may omit a unit price rather than invent one. Genuine coupon, promotion, and loyalty discounts remain visible, but no dual-pricing fee or cash-discount line is printed on these checkout receipts.

History reprints keep the existing recorded-transaction presentation; this change does not reconstruct past receipts from checkout quotes. Refund and return calculations are unchanged: fees use the existing proportional allocation, so individual lines can have cent-level rounding differences while the refund total remains exact. Existing EBT return restrictions continue to apply.

Itemized POS refunds persist the signed gross merchandise subtotal and the signed discount from the accepted refund lines, including their frozen loyalty allocation, without changing the payout. Transaction CSV, Excel, and PDF exports include a separate Discounts column; subtract it from subtotal, then add tax, tip, and fee to reconcile the total. For refunds, both subtotal and the stored discount are negative.

A synced payment can appear before its POS transaction detail is available. If the portal asks you to select the owning store, switch to that store before reopening the detail.

Understand viewing and action access

Transaction read access opens the list and detail. Capture, refund, return, tip-adjustment, and void controls use the server's current action availability as well as your role's permissions. If availability cannot be verified, payment-changing controls remain unavailable; the browser does not infer permission to proceed from tender or status.

Gateway evidence uses the explicit location when present; legacy transactions without a location use their recorded merchant authority. An explicit different location is never overridden by a matching merchant identifier, and missing authority keeps actions unavailable.

Funded gift-card availability uses request-local advisory evidence shared by void and refund, with each distinct issued card fetched once for the page. Transaction and issued-card inquiries share bounded concurrency. Unavailable evidence disables the affected actions without hiding persisted history; mutations still re-read and lock current funding authority rather than trusting the displayed snapshot.

Internal payment review scans persisted history without fetching action availability for unrelated rows. It retains the same store, organization, terminal, and lifecycle filters and consults Gateway only for actual review candidates; locally recorded review reasons do not require a provider inquiry. Public transaction lists and details still return canonical action availability.

When a sale combines goods with issued gift-card value, a used issued card does not necessarily prevent refunding the verified remaining non-gift portion. The server reports only that admissible allowance; returning issued-card value still requires the full-return and unused-card policy. Pending issuance or unavailable card authority never supplies a guessed allowance.

• Capture requires store.transactions.write, an eligible authorized transaction, and a known stored goods/gift-funding purpose. Unknown-purpose authorizations require review before capture.
• Refund is shown to roles with store.refunds.write; its mutation endpoint also enforces store.transactions.write and store.transactions.admin for the selected store.
• Tip Adjust and Void Transaction require both store.transactions.write and store.transactions.admin.
• Return Items requires store.refunds.write and selected-store store.transactions.admin. The server must find a remaining returnable product allocation after prior refunds and active return reservations, not merely a product line on the receipt.
• Export requires store.reports.read.

A card transaction cannot be voided after its batch has closed. An uncaptured authorization is evidence that goods have not been fulfilled: its reserved inventory is restored only when the server finds an unreversed sale debit and no meaningful return or preparation effect. A completed sale is not proof of unfulfilled goods, so a caller's restock preference cannot authorize a void inventory adjustment. Active, completed, prepared, or unknown return evidence prevents a second restoration, including during webhook delivery or server retries.

Only a versioned current-writer failed merchant return with no linked refund/reservation/credit note, preparation audit, inventory ledger effect, or deposit redemption effect is treated as an unprepared no-effect attempt. The stored restock selection is operator intent, not evidence that preparation ran. A failed status alone—including an unversioned legacy failure—is not proof that stock was never returned.

Any payment containing positive stored accepted cash cannot start a generic payment void, even when its method is labeled split or card; use the cash return workflow. A split payment with zero accepted cash retains card-only eligibility. Already admitted Gateway void requests remain recoverable, but a completed or released cash-containing sale cannot use that recovery path to start another generic void. Dedicated checkout compensation remains a separate server workflow. A refundable tip balance does not imply that any product units remain returnable.

Heavy discounts can round a single-unit refund to zero while a larger quantity still has a valid positive refund. Return availability considers eligible remaining quantities within the refundable balance; it does not assume one unit or require the entire remaining quantity to fit.

A promotion can allocate a product zero paid value while its physical quantity remains returnable. The server may offer that zero-money return even when no financial refund is available, provided the same ownership and remaining-quantity rules admit it. It prepares the physical return without a refund/provider call; any positive refund still requires financial and Gateway eligibility.

When the original card leg is fully refunded and only a known cash balance remains, that cash refund does not depend on another Gateway confirmation. An outstanding card balance still requires verified Gateway refund eligibility.

Previously persisted inventory-reversal intents remain durable recovery authority. The new admission policy applies to new attempts, not a retroactive reinterpretation of already admitted requests; later return evidence still prevents a duplicate inventory restoration.

The remote transaction's admitted inventory marker remains authoritative even if the local request-key record was rolled back or is unavailable. A caller's new key or changed restock preference cannot erase that admitted intent, and a new completed-sale attempt without such a marker cannot create one.

An accepted void can remain Void Requested while Gateway confirms the payment reversal. This is pending, not “Transaction voided”; only the authoritative Voided lifecycle confirms completion. Each explicit new operator attempt has a fresh request identity. A delivery replay of the same unresolved request must retain that request's identity, not invent another payment operation.

For an ordinary card-only void, a definitive Gateway answer is recorded in POS during the original request using the same idempotent completion as the webhook. A confirmed refusal preserves the original payment and reports its reason; it is not a successful reversal. A lost or ambiguous response stays pending. Status reads inquire only the original Gateway transaction and never send another void, change the admitted inventory choice, or postpone its recovery deadline. When the screen is closed, the existing five-minute card recovery job also observes pending ordinary voids; cash, gift, mixed-tender, invoice, and checkout-compensation owners keep their separate workflows.

If a refused void has already revoked gift cards issued by the sale, POS retains Void Requested for review rather than presenting a charged sale with unusable cards as unchanged. Background inquiry rotates durably across candidates without changing their financial admission timestamps. Interrupted confirmed-void effects remain eligible until their inventory, deposit, and customer-effect transaction commits, without an expiring recovery window. Visible Android history likewise rotates its bounded original-transaction inquiries so later pending rows are not excluded.

While a transaction detail is open with Void Requested or Refund Requested, the portal automatically refreshes its detail and the list while waiting for the authoritative outcome. Refreshes back off from two seconds to at most once every fifteen seconds, run for at most two minutes, and stop when the outcome settles or you close the detail, select another transaction, or leave the page. A temporary read failure leaves the pending status in place and retries without submitting another payment operation.

Closing and reopening an unresolved void confirmation, switching selected transactions, or receiving an unsuccessful replay response does not start a new attempt: the portal retains the original identity. Malformed or nonterminal responses remain unresolved. Only a complete, matching authoritative terminal response releases that identity.

An unresolved refund likewise retains its original request identity. A matching replay can return the original refund child with Refund Failed after the server confirms rejection; this is a failed outcome, not refund completion, and does not dispatch another payment operation. Only Refunded confirms success. A confirmed failed outcome permits a separately explicit new attempt; an unavailable or mismatched outcome does not.

After the portal accepts a pending refund, it also checks that refund's saved request identity and refreshes the open original sale, even if the sale still shows Completed while the refund is preparing. When the refund attempt becomes terminal, attempt polling stops; the sale is refreshed immediately and once more two seconds later, within the same two-minute limit, to catch its separate reconciliation. Closing only the refund dialog does not stop this refresh; closing or changing the original transaction detail does. The sale's lifecycle always comes from its own refreshed detail, never from copying the refund child's status or predicting full versus partial refund completion.

For a terminal-reported device void, the server confirms the Gateway outcome and completes funded gift-card revocation before recording finality. A used card or uncertain revocation leaves the request unresolved for recovery rather than leaving a returned funding payment with a spendable issued card. Definitive responses, scoped status inquiry, webhook delivery, and the lost-webhook sweep converge through the same idempotent completion, including collected bottle deposits; confirmation replay retains the original attempt identity even after an unsuccessful replay response.

Tip adjustment submits the replacement tip only. The server computes the new total from the stored sale total less its previous tip plus the replacement tip, and requires POS/Gateway accounting agreement before dispatch. Tip adjustment also requires verified open, unbatched settlement. A Gateway tip flag cannot override settled, settling, or unknown settlement evidence. The tip control also requires the stored POS total and previous tip to agree with the exact Gateway transaction evidence. If payment status cannot be confirmed, refresh the transaction or contact support; never provide a replacement total.

On Android, History uses the same server action availability: the refund control appears when either refund or return is available, and settlement banners do not independently override these flags. Tip approval binds the sale, attempt identity, and replacement tip—not a client-calculated total. Gift-card cash-return approval and dispatch share one fresh attempt identity; transport redelivery retains that identity. An unavailable void confirmation remains pending until the server proves the original reversal or a definitive refusal. Visible detail uses two quick status reads followed by a quiet fifteen-second cadence; visible History also checks a bounded set of pending originals without reopening the confirmation. These reads do not create replacement request identities, repeat the void, or let an old refusal override an already confirmed Voided state.

In Android History, scan the receipt QR code rather than a product barcode. Signed receipt links are verified before the transaction opens. Older receipt codes still work when they contain the full POS transaction UUID, either directly or in the receipt link. A product barcode, processor reference, or malformed code shows That's not a receipt code locally without requesting transaction details; scan the receipt QR or find the sale in History instead.

Unavailable-action guidance is shown as written by the server, including cash-return instructions and refresh/support advice. Missing guidance uses a neutral unavailable-action message; the app does not interpret that prose as financial diagnostic codes.

Android displays uncertain settlement diagnostics as Payment status unconfirmed or Batch status unconfirmed, with the server's refresh/support guidance. The original diagnostic state and batch identifiers remain stored for support; these display labels do not change action availability.

Android's refund editor offers explicit Full refund and Partial refund choices. Full refund requests the whole remaining paid amount, including refundable tips and fees, through the existing monetary refund workflow. Inventory is unchanged; use Partial refund's item quantities and restock control for an item return. Refund [amount] uses the server-reported remaining balance; tapping it requests a quote once and continues through normal approval/submission only when its exact amount and currency match the displayed choice. A changed amount or currency requires one confirmation of the actual quote. Partial items show Refund selected items and an exact quoted confirmation. Selection changes never create quotes or reservations. Refund status updates automatically, and the screen can be closed while processing continues. The reason is optional. Item controls still require the server's returnAvailable flag, and saved request review does not grant fresh return availability.

For a pure-cash sale, an amount-only refund follows the dedicated cash-money quote and refund workflow, not the physical item-return workflow. Manager cash approval, quote, and dispatch share the same attempt key; the server controls cash refund eligibility and drawer accounting. No item quantities or inventory-restocking instruction accompany that money-only request. An uncertain response retains the admitted request for status review rather than paying cash again.

Ordinary money-only cash admission requires stored positive cash tender with no card or gift-card tender, an exact-cent requested amount, and CASH_RETURN approval for the original transaction, store, operator, terminal, and attempt key. A card or split-return approval cannot authorize this cash request. Known gift funding or issued-card claims remain in the dedicated funded gift-card workflow. The admitted amount, reason, approval, operator, terminal, and cash operation remain frozen on replay.

Cash-money quote and admission use the same cash-capacity calculation as final physical return admission. Pending or unknown cash refund children, active physical reservations, completed cash returns, and durably accepted split cash consume capacity; a financial child and its linked return cash are counted only once. Final physical admission rechecks capacity under the shared parent lock, so an earlier plan cannot spend cash already refunded by another request. Failed unaccepted work can release capacity; accepted cash does not disappear because a card leg later fails or its reservation expires.

Review cash refund request remains available for that saved uncertain cash request even if the original sale is now fully refunded and new actions are unavailable. Review reads the saved request's status and amount; it does not issue another refund or create an item-return reservation.

If an existing return's completion acknowledgement is lost, Android exposes Review return request separately from new Refund/Return controls. It restores only the saved reservation identity; if that identity is missing or mismatched, review cannot fall back to creating another return.

Export the reviewed period

If your role has report read access:

1. Set the selected store and date range.
2. Open Export.
3. Choose CSV, Excel, or PDF.
4. Save the generated file and confirm that it represents the same store and dates you reviewed.

The export uses the selected transaction date range for the selected store. It is separate from the organization-wide invoice receivables export.

Finish reconciliation

A review is complete when you have confirmed:

• the correct store and date range;
• the expected transaction lifecycle and sync status;
• payment method, amount, reference, and receipt details;
• refund or return outcomes, if any;
• the linked settlement batch for card activity, when assigned; and
• any degraded-data warning has cleared or is accounted for.

Use Returns and Settlement Batches to audit return records and Gateway batch history. If a duplicate charge, failed refund, missing payment detail, or unsettled batch remains unexplained, follow Troubleshooting and provide Peak Support with the store, transaction or Gateway reference, time, amount, and exact message shown.