Skip to main content

Customers, Households, and Online Orders

These Store Operations entries use different scopes:

  • Customers is a store-scoped entry and requires store.customers.read.
  • Households is organization-scoped and requires org.customers.read.
  • Online Orders is store-scoped and requires store.transactions.read.

Confirm the selected organization and store before using links from a customer to an invoice or from an order to a sale.

Customers​

Open Store Operations > Customers to find and maintain customer records.

Find and review a customer​

  1. Use Search customers to find a record.
  2. Use All Statuses, Payment profile active, or Needs payment profile to filter payment-profile readiness.
  3. Review the list's name, email, phone, billing summary, loyalty points, and payment-profile status.
  4. Select a row to open Customer Details.
  5. Review:
    • contact details and date of birth when recorded;
    • loyalty points and the existing card, barcode, or external ID;
    • tax ID, payment terms, currency, and billing address;
    • whether a saved customer payment profile is available; and
    • the link to household management.
  6. Use View loyalty, Open Invoices, or Create invoice for the related workflow when your role can open it.

Active means the saved customer payment profile is available. Needs setup means it is not yet available; it does not mean the customer record is missing.

Find a customer at the Android POS​

At checkout, open Customer, enter a first name, last name, full name, email, or phone number, and select Search. Partial matches are case-insensitive: nicole, robinson, and Nicole Robinson can find the same customer. Review the matching customers and select the intended record to attach it to the sale.

You can still enter a loyalty ID or scan a loyalty member barcode for an exact lookup. Customer search is available only when the cashier has customer-read permission for the selected store or organization. Search requires a connection; a search error appears in the customer sheet and does not prevent dismissing it and continuing the sale without a customer.

The POS uses its selected store for authorization and customer changes. Searching by name, email, phone, or loyalty barcode finds customers throughout the organization so chain customers can visit any store. Browsing without a search stays limited to the selected store's customers. A cashier with that store's customer read/write grants does not need organization-wide customer or loyalty administration permissions to attach or create a customer, attach loyalty, or earn points during checkout. Redeeming points requires customer-write access at that store. Those grants do not authorize acting on behalf of another store or accessing another organization.

API failures use plain instructions rather than technical error codes or HTTP statuses. A support reference may appear so support can find the request without exposing server details.

Customer details, identifiers, custom fields, assets, and saved-card customer identity belong to the organization, even when the customer's home store differs from the cashier's selected store. Hosted card entry and invoice card-save recovery use that same organization-owned identity; the selected or original invoice store still determines the Gateway location and saved receipt scope. The selected store also determines the cashier's permission and the store-specific analytics shown.

Nonzero opening points (including imported balances) are recorded against the active loyalty program applicable to the attributed store. If none applies, the customer is still created with zero points and the message Points not added: this store has no loyalty program; imports include a warning for each affected row in the warning total. Retrying an import preserves that original skipped outcome even if a program is added later. Manual points adjustments at a store without a program are refused with the same plain message.

Add, edit, import, or delete customer records​

If your role is authorized for the corresponding change:

  • Select Add Customer, enter at least the first and last name, add the applicable contact, loyalty, tax, and billing details, then save.
  • Select Edit to correct an existing record.
  • If a customer profile is being merged into another record, edits to that source profile are refused until the merge completes. The surviving profile remains editable. If the merge needs review, resolve its Action Inbox item before retrying the source edit.
  • Checkout continues normally while a merge waits for an in-flight payment. The merge waits at most 15 minutes from its admission for an open checkout, including an abandoned quote; it never expires or cancels checkout. If checkout remains open or immutable payment records require the profiles to stay separate, Action Inbox shows Customer profiles kept separate — review needed. Support must reconcile any Gateway identity change; completing that item does not restart the merge automatically.
  • A kept-separate decision made before any Gateway merge releases the surviving profile for synchronization and other queued merges, while the source profile remains protected from edits. Dispatch evidence is committed before contacting Gateway and retained across retries. If Gateway already merged the identities or a dispatched request has an unknown outcome, the survivor remains fenced until support manually reconciles the remote and local records.
  • Inbound Gateway customer updates recheck merge admission while holding the target customer locks, so a webhook cannot change a staged source profile's identity fields during a merge.
  • If an imported customer's Gateway identity merges while its binding command is pending, reconciliation follows the survivor only after inbound sync has moved that same POS customer and Gateway management verifies the survivor's organization and POS reference. The original binding command then completes without repeated review.
  • Hosted card entry, emailed setup links, and payment-profile setup sessions hold durable customer-resolution admission through the creating call. A pending merge blocks replacement references. Stored setup email is validated before admission. An explicit Gateway HOSTED_SETUP_NOT_CONFIGURED refusal releases admission because it precedes customer resolution; other dispatched failures retain non-creating reconciliation. Created links return without a directory scan: prepared known bindings complete locally, while unbound customers reconcile in the background.
  • Select Import CSV, download the provided template, populate it without changing its expected structure, and upload it. Review the import result before relying on the new records.
  • Select Delete only after confirming that the record is the correct customer and that your organization no longer needs it.

Customers with retained records cannot be deleted, including customers whose appointments were cancelled. A blocked deletion identifies the kinds of records that retain the customer; the customer and their history remain unchanged. Do not retry deletion to remove that history.

Customer write controls do not change household membership. Use Households for shared relationships.

Customer creation has a durable request identity. If a connection drops after saving, resume the saved request rather than entering the same customer again: the server returns the original customer for the same request and unchanged details. A missing search result does not mean that the save failed, because search results are paginated. Server contact deduplication still selects the canonical customer; a separate new customer request does not require resolving an unrelated saved request first.

In the retail customer page and document customer dialog, reopening an unresolved create restores the original saved details. Use Recover Customer (or Recover Customer & Continue) to look up that exact operation and, only when unknown, safely submit the same request identity and payload. Editing is locked during recovery; Cancel returns to ordinary customer search and selection without discarding the recovery record. Recovery is scoped to the organization, store, and creation surface; it does not lock unrelated documents or customer lookup. Durable browser storage must be available before submission. Android POS customer review also retains its immutable creation request on the terminal across screen recreation, and acknowledges it only after the saved customer is consumed.

Changing the selected organization or store closes the previous create form and releases that page's busy state. The previous operation remains recoverable in its original scope. Its eventual success or failure cannot replace a new scope's form, restore old customer details there, or release a different in-flight request. An explicitly submitted customer in the new scope receives its own request identity.

On Android POS customer review and checkout quick-add, use Start separate customer to keep an earlier unresolved request available while entering a different customer with a fresh request identity. Customer review lists previous attempts under Other saved customer drafts, with Open saved draft: [customer name] explicitly replacing the editor's fields with that draft's immutable details; quick-add uses Recover & Link for its saved attempt. A fresh permission denial (HTTP 403) retires only the denied attempt, leaves the entered fields available, and reports the permission problem. It does not promote another saved draft into recovery. An unknown outcome keeps the same request identity and original details; a later permission denial during recovery cannot disprove that earlier outcome. Ordinary terminal customer creation and scanned-ID creation use the merchant-owned durable command, not a terminal-local decision that a missing customer means the earlier request failed. Switching employees, stores, or terminals cannot view or dispatch another operator's saved attempt.

Browser recovery also belongs to the authenticated operator. Another account using the same organization and store cannot restore or dispatch those saved requests. Each open form retains the key of the request it displays; starting a separate customer in another tab does not change that recovery identity.

In Peak Mobile Android, a fresh server validation rejection restores the entered name, email, phone, and address for correction before acknowledging that invalid attempt. Authentication failures and uncertain retries retain the original request and key for recovery in their original operator scope; they do not silently discard the captured customer details.

Households​

Households group customers across the organization for relationship management, combined loyalty balances, shared-address grouping, and marketing groups. Changing the selected store does not narrow this page.

Review a household​

  1. Open Store Operations > Households.
  2. Search by household information.
  3. Review Household, Grouping, Members, Combined Points, and Shared address.
  4. Select a row to open the household.
  5. Confirm the member list, each member's points, the combined points, grouping source, and shared address.

Create or adjust a household​

When your role is authorized to change customer relationships:

  • Create: select Create Household, enter a display name and optional shared address, search for customers, add the intended members, then select Create. At least one member or a shared address is required.
  • Add a member: open the household, search by name, email, phone, or loyalty ID, and select Add Member.
  • Remove a member: select Remove next to the member. This removes the relationship; it does not delete the customer.
  • Combine households: choose another household under the combine control, confirm that it is the intended group, and select Combine households.
  • Split a household: enter the new display name, select the members to move, and select Move selected members.

Review the member count and combined points after every merge or split. Household changes apply to the organization, not just the store that happened to be selected.

Online Orders​

Open Store Operations > Online Orders to review delivery and takeout platform orders for the selected store.

Users with order-write permission can accept an eligible Received order when the portal enables the action for a connected storefront. All other fulfillment actions remain provider-managed.

To review orders:

  1. Confirm the selected store.
  2. Choose Active or History (last 30 days), then filter by status, fulfillment, external order ID, or dates.
  3. Review the provider, selected store, customer, external order reference, items and modifiers, amounts and currency, normalized status, raw provider status, and timestamps.
  4. For an eligible order, select Accept order. If acceptance cannot be confirmed, refresh the order before retrying; an error does not prove that Uber rejected the request.
  5. Use the provider's supported workflow for all other fulfillment actions. Users without order-write permission can review orders but cannot accept them.

These orders do not create Peak sales, transactions, KDS tickets, or accounting entries. Receipt and fulfillment remain valid without a linked Peak transaction.

If a delivery connection is unavailable or its state cannot be verified, historical orders can remain visible but acceptance is unavailable. Contact Peak Support for connection problems; acceptance also requires provider approval and the nominated order-manager application.

If an order appears in the wrong store or is missing, capture the organization, selected store, external order reference, time, and exact message before following Troubleshooting.