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.

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.

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.

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.

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. Both webhook delivery and the lost-webhook sweep compensate collected bottle deposits; confirmation replay retains the same 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 unresolved until the server reports Voided.

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.