Orders
| Field | Value |
|---|---|
| Audience | public |
| Page type | reference |
| Area | sg-admin |
| Updated | 2026-05-14 |
The SG-Admin Orders module — transaction records, status, refunds, payment linkage.
The Orders module in the admin is the per-site surface where store checkout transactions land as records. Each order carries the line items, customer info, payment-method linkage (via Payment Gateways integration), and lifecycle status. This page is the Reference definition.
What is this for?
Read this page when you want the structural definition of the Orders module — what records it administers, the order lifecycle, and the relationship to Products and Payment Gateways.
Good use cases
- You are scoping store fulfillment workflows.
- You are explaining to a stakeholder how SGEN handles transaction records.
- You hit a "where do I refund this?" question and want the model laid out.
What NOT to use this for
- Step-by-step procedures — open the relevant Guide.
- Product administration — open Products Reference.
- Per-release shipped change — open What's New or Changelog.
How this connects to other features
- SG-Admin Overview — parent surface.
- Products — the records orders reference.
- Coupons — discounts applied to orders.
- Payment Gateways — the providers that authorized each order's payment.
Where to find it
Open SG-Admin for the active site. Orders is in the sidebar under the store management group (alongside Products and Coupons). Tab-filtered views (All / Paid / Pending / Refunded / Fulfilled) are available within the module. Editor and Admin access can view and act on orders.
Definition
The Orders module administers transaction records for the store. Each order carries identifying metadata (order number, timestamp), customer metadata (name, email, shipping address), line items (products + variants + quantities + per-line price), payment metadata (gateway, payment state), and lifecycle status (pending, paid, fulfilled, refunded, cancelled).
The defining property is transaction-shaped. Orders are the receiving end of the buy flow — once an Add-to-cart and checkout sequence completes, the order record lands here.
Purpose
The purpose of this page is to define the Orders module as a Reference layer.
Scope
This page covers Orders at the Reference level.
The page covers:
- The order record model.
- The order lifecycle.
- Refund and cancellation handling.
- Linkage to Products, Coupons, Payment Gateways.
- Per-step procedures — Guides.
- Per-release shipped change — What's New or Changelog.
- Custom fulfillment integrations — out of scope.
The order record model
Each order carries:
- Order number — unique identifier.
- Timestamp — when the order was placed.
- Customer — name, email, addresses.
- Line items — product + variant + quantity + per-line price for each item.
- Subtotal / discount / tax / total — financial breakdown.
- Payment — gateway used, payment state.
- Status — pending / paid / fulfilled / refunded / cancelled.
- Notes — operator-side notes.
Site · SG-Admin · Orders
Recent transactions
| Order | Customer | Items | Total | Payment | Status |
|---|---|---|---|---|---|
| #1247 | Visitor A | 2 items | USD 138.00 | Visa ···· 4242 | Paid |
| #1246 | Visitor B | 1 item | USD 49.00 | Visa ···· 9876 | Paid |
| #1245 | Visitor C | 3 items | USD 207.00 | Bank transfer | Pending |
| #1244 | Visitor D | 1 item | USD 89.00 | Visa ···· 4321 | Refunded |
Order lifecycle
Pending (checkout submitted, payment not yet authorized) → Paid (payment authorized) → Fulfilled (operator marked shipped/delivered) → Refunded (where applicable) or Cancelled (where applicable).
Refunds run through the linked Payment Gateway; the order state updates to reflect the refund.
Linkage
- Products: line items reference product records (and variants where applicable). Inventory decrements on Paid status.
- Coupons: applied discount references the coupon record (for audit + analytics).
- Payment Gateways: payment metadata references the gateway that authorized the transaction.
Constraints and boundaries
Orders is a Reference area for the transaction record model.
Use this Reference for:
- Understanding the order record and lifecycle.
- Confirming the linkage to Products / Coupons / Payment Gateways.
- Per-step fulfillment procedures — Guides.
- Custom shipping integrations — out of scope.
- Per-release shipped change — What's New or Changelog.
Public boundary
This page is intentionally public-safe.
Examples
Example 1 — Customer checkout produces a paid order
Customer adds 2 products, applies coupon, checks out via Visa. Payment Gateway authorizes; order lands in Orders module as Paid; inventory decrements; operator marks fulfilled after shipping.
Example 2 — Operator refunds an order
Operator opens order, clicks Refund. Payment Gateway processes the refund; order state updates to Refunded; inventory restocks if configured.
Example 3 — Pending order awaits bank transfer
Customer chose bank transfer at checkout. Order state is Pending until the transfer clears; once cleared, state moves to Paid.
Documentation guidance
Use this page as the structural definition for the Orders module.
Reading order
Open this page when scoping fulfillment or refund workflows. Pair with Products for the line-item context and Payment Gateways for the payment processing layer.
Related reading
- SG-Admin Overview — parent surface.
- Products — line-item records.
- Coupons — discounts applied.
- Payment Gateways — payment processors.
Vocabulary cross-reference
- Order is one transaction record.
- Line item is one product+variant+quantity entry on an order.
- Payment state is the gateway-side status (authorized, captured, refunded).
- Order status is the operator-side lifecycle state.
Maintenance discipline
When the Orders module changes across releases (new status, new line-item field, new refund flow), update this Reference and log the change in Changelog.
Related reading
| Topic |
|---|
| SG-Admin |
| Products |
| Coupons |
| Payment Gateways |