Orders and transactions

Find the right order

Select the location, then use the relevant order date, customer or order reference to identify the record. Specify whether you are looking for the latest order or a particular one.

Order placement, payment time and scheduled fulfillment time can differ. Use the date that matches the question you are trying to answer.

Order state and payment state

An order describes what was ordered and how it is being fulfilled. Its payment records describe money received, refunded or otherwise handled.

Do not treat an order’s existence or value as proof of payment. Likewise, payment state does not, by itself, tell you whether the food was delivered or collected.

Read the details

Review the line items, selected variations and modifiers, customer details and relevant transaction records together. Historical names and choices can differ from today’s menu.

For refunds or disputes, use the linked records and their status rather than inferring the outcome from an order total.

Keep test and live activity separate

Check the selected mode when comparing orders and transactions. A missing record may be outside the selected location, dates or mode.

Use the application’s order and payment workflows for operational changes. Asking Gordon to inspect a record does not itself change the order.

Orders are not transactions

Carts, orders, item lines, payment transactions, refunds, fees and settlement entries represent different events. Order workflow status is not payment status. A paid order is not necessarily one transaction: an order can have multiple payments, and transaction counts count payment records.

Order counts and paid-sales rankings can include different activity. To inspect the latest order or payment, open its individual record rather than relying only on a sales summary.

What order details contain

Recorded details can include items, modifiers, size choices, customer information, payment details, notes and activity. Missing fields mean the information was not recorded. A partial page of activity is not a complete history, and order totals do not establish payment settlement.

Dates and follow-up questions

Order placement, payment, scheduled fulfillment and service-day dates are distinct. Use the requested basis in the location's timezone. Within a conversation, a follow-up such as “is delivery most popular?” after “this week?” retains the same relevant period. An explicitly named location overrides the currently selected one for that request.

Cancellation, voids and refunds

A cancellation, void and refund should not be treated as equivalent merely because a status label changed. Check the resulting payment, order and stock records separately. Cancelling an order does not confirm that inventory was restored; a refund request still needs a completed payment-provider status.

Checkout attempts and genuine transactions

Opening card checkout creates a recoverable payment attempt, not a merchant transaction. An abandoned, declined or unconfirmed card attempt has no recorded merchant transaction. Successful payment creates the transaction; later confirmation can record it once without duplicating or changing its original recording time.

A submitted cash order is recorded with cash due. Opening card checkout and closing the browser is different from submitting a cash order. Retrying a declined payment and then succeeding should produce one successful transaction, not a transaction for each attempt.

Refunds and disputes retain the original transaction. Dashboard/POS transaction lists, details, customer transaction history and Gordon's transaction reporting use recorded transactions. Recoverable checkout attempts remain separate from those customer-facing transaction totals.