Ecommerce
How SGEN handles products, orders, coupons, and the work of running a small store
Ecommerce in SGEN is the set of surfaces that decide what you sell, how it is presented, what happens when a visitor checks out, and how the resulting order is tracked, paid, and fulfilled. The four sub-areas — configuration, products, orders, and coupons — each own a slice of the work. This page is the entry point: what each sub-area is for, how they connect, and which doc to open next.
The shape of SGEN ecommerce is operator-first. The platform ships the surfaces a small team needs to run a real store without bolting on extra software, and treats every commerce object — product, attribute, category, coupon, order, refund — as a first-class admin record with its own list, edit, and bulk-action surfaces.
What is this for?
Use this page when you need to understand the ecommerce surface of your SGEN site at a glance, decide which sub-area to open, and know how the four sub-areas talk to each other. Read it before opening Configuration, Products, Orders, or Coupons so you know which surface owns which job.
The four pillars on this page are: configuration (the store-wide settings — checkout, payment, shipping, taxes), products (the catalog — products, variants, attributes, categories, customers), orders (the transaction record — list, view, refund, export, status), and coupons (the promotional surface — coupon codes, validation, application).
Good use cases
- Setting up a new store from a fresh install.
- Adding a product with variants (size, color) and a sale price.
- Reviewing today's orders and refunding one that came in by mistake.
- Issuing a coupon code for a seasonal campaign.
- Exporting the last 30 days of orders for an accountant.
- Walking a new team member through how the store is wired.
What NOT to use this for
- Replacing a finance system. SGEN tracks orders and payments at the order level; reconciliation, payouts, and accounting integration belong in your finance stack.
- Treating the product list as a content management system. Products are commerce objects, not articles. Use Pages or Posts for narrative content about a product.
- Running an inventory operation that needs a warehouse system. The product surface tracks stock at a level appropriate for a small store; a multi-warehouse operation needs a dedicated inventory system.
How this connects to other features
- Ecommerce Configuration — store-wide settings that every other sub-area depends on. Set this up first.
- Products — the catalog. Every order references one or more products from this list.
- Orders — the record of every transaction. Reads from Products, writes to Customers.
- Coupons — the promotional layer that adjusts prices at checkout.
- Security — the user accounts that hold roles like Customer (assigned at checkout-time account creation) live here.
- UX — the visual presentation of product pages, the shopping cart popup, and the checkout flow.
Before you start
You need an admin account on the site with the role Site Owner or Administrator. Editor and Customer roles cannot reach the ecommerce admin surfaces.
If you are reading this on a fresh install, open Ecommerce → Configuration first and walk through the General, Checkout, Payment, Shipping, and Taxes panels. Each panel ships with placeholder values that need to be replaced before the first real order. Everything below assumes those configuration panels are populated.
Where to find it
Ecommerce in the SGEN admin is grouped under the Ecommerce parent in the left navigation. The shortcut paths are:
- Configuration:
/sg-admin/ecommerce_configuration/general(and the sibling tabs: checkout, payment, shipping, taxes, layout_seo, product_tabs, purchase_flow) - Products:
/sg-admin/ecommerce_products/ - Orders:
/sg-admin/ecommerce_orders/ - Coupons:
/sg-admin/ecommerce_coupons/
Steps
1. Configure the store
Open Ecommerce → Configuration. Walk through the panels in order: General (store name, address, currency), Checkout (the steps a buyer goes through), Payment (the methods you accept), Shipping (the rates and zones), Taxes (the tax rates by region). Save each panel before moving to the next.
A reasonable order is: General first (so currency is set), then Taxes (so prices can be entered in the correct context), then Payment and Shipping (so the buyer can complete checkout), then Checkout (which depends on the others being in place).
2. Add a product
Open Products → Add New. Fill in the product name, description, price, and at least one image. If the product has variants (different sizes, colors, formats), create the variants under the Attributes panel and assign them to the product. Save. The product appears in the public store listing under its category.
3. Process an order
Open Orders. The list shows every order placed on the store with status (Pending / Processing / Completed / Refunded), customer, total, and date. Click a row to open the order detail. From the detail, you can change the status, add an internal note, refund the order, or export it.
The status flow most stores use is: Pending (order placed, payment captured) → Processing (fulfillment in progress) → Completed (shipped or delivered). A refund moves the order to Refunded and writes a refund record against the original payment.
4. Issue a coupon
Open Coupons → Add New Coupon. Enter the coupon code, the discount type (percentage or fixed amount), the discount value, and any constraints (minimum order, valid date range, per-customer limit, applicable products or categories). Save. The coupon is live the moment it saves.
The buyer enters the code at checkout. The coupon validation runs server-side before the discount applies — invalid codes return a clear error rather than silently being dropped.
5. Export orders for the finance team
In Orders, click Export Orders. The export form lets you pick a date range and the columns you want in the export file. Click Export. The file downloads as a CSV. Hand it to the finance team for reconciliation.
What success looks like
A clean ecommerce posture on an SGEN site reads like this:
- The Configuration panels are filled out and saved (no placeholder values).
- Every product in the public store has a real image, a real price, and a real description.
- Orders are flowing through the status pipeline from Pending to Completed without manual intervention beyond fulfillment.
- Coupons that were created for a campaign are deactivated or removed once the campaign ends.
- The order export reconciles cleanly with the payment provider's report at the end of the month.
What to do if it does not work
Symptom: A buyer cannot complete checkout.
Open Configuration → Payment and confirm at least one payment method is enabled. Open Configuration → Shipping and confirm the buyer's region matches a configured shipping zone. If both are correct, place a test order yourself with a real card to see the failure mode.
Symptom: A coupon code is rejected at checkout.
Open Coupons, find the code, and check the constraints. Most rejections come from the date range (the campaign window expired), the minimum order (the buyer's cart is below the threshold), or the per-customer limit (the buyer has already used the code).
Symptom: An order shows as Pending but the payment did go through.
Open the order detail. The payment record at the bottom shows the payment status from the provider. If the payment is captured but the order is Pending, change the order status to Processing. If the payment is not captured, the order is correctly Pending — wait for the payment to confirm or refund it.
Symptom: A product variant does not appear in the dropdown on the public product page.
Open the product edit, scroll to the Attributes panel, and confirm the variant is both created and assigned to this product. Save again. Reload the public page with cache disabled.
Symptom: A refund did not return funds to the buyer.
The refund in SGEN writes the refund record on the order and signals the payment provider. The actual return of funds happens on the provider's side and follows the provider's timeline (typically 3-10 business days for card refunds). If the timeline has passed and funds are still not returned, contact the payment provider directly with the refund record's reference.
Examples
Example 1: Setting up your business' first product.
your business is launching their store. The Site Owner opens Configuration and walks the panels in order. They set currency to USD, add their address, configure Stripe under Payment, set a flat shipping rate of $5 under Shipping for US-domestic orders, and add a sales tax rate for their state under Taxes. They open Products → Add New, add Canvas Tote Bag at $30 with a single image, and save. The product appears at /store/canvas-tote-bag ten seconds after save.
Example 2: Issuing a launch coupon.
The same team wants a launch coupon for the first 100 customers. They open Coupons → Add New Coupon, enter the code LAUNCH25, set the discount type to percentage, the value to 25, the per-customer limit to 1, and the maximum total uses to 100. Save. The next 100 buyers who enter LAUNCH25 at checkout get 25% off their order. The 101st buyer to try the code sees a clear "this coupon has been fully used" message.
Example 3: Refunding an order placed by mistake.
A customer placed two of the same order by accident and emails to ask for a refund on the duplicate. The Site Owner opens Orders, finds the duplicate by order number, clicks Refund Order, enters the full amount, adds an internal note ("duplicate, refunded per customer email 2026-04-29"), and confirms. The order moves to Refunded status. The customer gets a refund confirmation from the payment provider within the provider's standard window.
click order #
action menu
full or partial
audit-logged
Notes on the four sub-areas
The four sub-areas talk to each other in a specific direction. Understanding the direction helps when something goes wrong.
- Configuration → everywhere. The store-wide settings cascade into Products (which currency the price is in), Orders (which payment methods are valid), and Coupons (which currency the discount is denominated in). A change to Configuration can affect every existing record downstream.
- Products → Orders. Every order line item references a product and (if applicable) a variant. Deleting a product after an order has referenced it does not delete the order — the order keeps a snapshot of the product at the time of purchase.
- Coupons → Orders. A coupon applies at checkout and is recorded on the order's line items. The coupon record itself is reference data; the application is on the order.
- Customers → Orders. A registered customer's order history is the union of every order with their email or account ID. Guest orders carry the email but no account.
Related reading
- Ecommerce Configuration — full configuration walkthrough.
- Products — catalog management.
- Orders — order processing and refunds.
- Coupons — promotional layer.
- Security — Customer role and account-creation surface.
- UX — visual presentation of the store on the public site.
From Actual Feature Content Corpus (2026-04-27 export, page #12)
Group: SG-Modules
Route seed: /ecommerce
Audience visibility: Client-facing default; internal transactional details require tighter visibility control.
This section preserves the original landing-page framing. It records the documentation boundary for ecommerce material on the public docs site.
Documentation boundary
Ecommerce documents the commerce-related surface exposed within SGEN for product, transaction, and purchase-flow operations. The page presents Ecommerce as a governed transaction surface rather than a generic feature bucket. Commerce objects carry pricing, order, customer, compliance, and reporting implications, which is why the documentation must remain exact.
What this page covers
- Commerce-related objects and operational surfaces within SGEN.
- Configuration, products, orders, and coupons as the four sub-areas.
- Relationship to security (customer accounts), UX (storefront presentation), and analytics (order reporting).
- Client-facing boundaries for transactional detail.
What this page does not claim
- It does not promise specific payment-provider integrations beyond what the live Configuration → Payment panel exposes.
- It does not promise multi-warehouse inventory or fulfillment automation.
- It does not promise tax-jurisdiction automation beyond the rates an admin enters in the Taxes panel.
- It does not promise a specific accounting-system integration.
- It does not name any internal infrastructure component, vendor, or service.
Validation notes
The behaviors documented above are evidenced from the live admin on the QA staging site. Surface names (Configuration tabs, Products list, Orders list, Coupons list, Refund flow, Export CSV) match the surfaces live in the SGEN admin as of the 2026-04-21 surveyor pass. Specific provider names and integration details are intentionally absent from this landing page — those live in the per-sub-area docs where they are scoped to a real configured surface.
Related surfaces in the SGEN admin
Ecommerce Configuration (General, Checkout, Payment, Shipping, Taxes, Layout & SEO, Product Tabs, Purchase Flow), Ecommerce Products (with Attributes, Categories, Customers, Scan Orders sub-pages), Ecommerce Orders (with Order View, Guest Orders, Orders Export sub-pages), Ecommerce Coupons.
A note on operating rhythm
A small store running on SGEN tends to settle into a weekly rhythm: a morning sweep through Orders to confirm yesterday's orders are flowing through the status pipeline, a weekly review of Coupons to deactivate any that have run their course, a monthly export of Orders for the finance team, and a quarterly walk through Configuration to confirm the store-wide settings still match the business. The four sub-areas are designed for this rhythm. If the operation feels heavier than this, the question is usually a missing surface (an automation that should exist but does not) rather than a misuse of the existing one — file the gap with the SGEN team rather than building around it.
When the store outgrows the surface
Two signals suggest the store has outgrown what the SGEN ecommerce surface ships:
- The catalog has more than a few hundred products with deep attribute trees that the visual editor cannot navigate quickly.
- The order volume is high enough that fulfillment needs an external warehouse system and the order list cannot drive the workflow.
A few patterns worth knowing
Three patterns recur across stores running on SGEN. They are worth knowing before you hit them.
Pattern: Sale price vs regular price.
Every product carries a regular price. A sale price is optional. When both are set, the public product page shows the regular price struck through and the sale price next to it, and the cart total reflects the sale price. To end a sale, clear the sale price field on the product edit and save. The regular price reasserts on the next public page load.
Pattern: Variants that share a base product.
A product like a t-shirt with three sizes and four colors does not need 12 separate product records. Create the t-shirt as one product, define the size and color attributes, and assign all 12 variants to the same product. The public product page shows two dropdowns; the cart records the specific variant chosen. Inventory tracks per variant if you opt into per-variant stock.
Pattern: Guest checkout vs account checkout.
A buyer can check out without creating an account. The order is recorded with the buyer's email but no account ID. Guest orders appear under the Guest Orders sub-page rather than under a customer's account history. If the same email later creates an account, the guest orders do not automatically link to the new account; the link is manual and lives in the account merge surface.
Configuration as the foundation
The Configuration sub-area deserves its own paragraph because every other sub-area depends on it. The order in which the panels matter is:
- General. Currency, store name, store address. Currency is set here and cannot be changed per-product later. Pick deliberately.
- Taxes. Tax rates by region. Set this before adding products if you want product prices entered tax-exclusive; the panel toggles between tax-inclusive and tax-exclusive entry.
- Payment. The methods you accept. At least one method must be enabled before the first order can be placed.
- Shipping. The rates and zones. A buyer outside any configured zone cannot complete checkout, so make sure your live zones cover the regions you intend to sell to.
- Checkout. The checkout flow itself — fields shown, steps in the flow, post-checkout behavior.
A short tour of the order list
The Orders list is the most-visited surface in a working store. Six things to know about it:
- The status pills at the top of the list filter by status. The count next to each pill is the live count for that status.
- The search input matches order number, customer name, and customer email.
- The bulk-action dropdown can change status across many orders at once — useful for moving a batch of Processing orders to Completed after a shipping run.
- The export action respects the current filter; export the list filtered to a date range to get only that range in the file.
- Each row is clickable to the order detail; the row also exposes inline status change for fast updates.
- The Guest Orders sub-page is a separate filtered view of orders without an account ID. It is the place to look for orders that did not link to a known customer.
Coupons that hold up under use
A coupon that ships with no constraints is a coupon that gets shared, abused, and burned through within a day. The coupon panel exposes the constraints that make a coupon match its intent:
- Date range. Start and end the coupon. Set both. A coupon with no end date will outlive the campaign.
- Per-customer limit. Cap how many times a single customer can use the code. Set this to 1 for one-shot promos.
- Maximum total uses. Cap the total number of redemptions across all customers. Useful for "first 100 buyers" style campaigns.
- Minimum order. Require a minimum cart total before the coupon applies. Useful for nudging average order value.
- Applicable products or categories. Restrict the coupon to a specific subset of the catalog. Useful for product-launch coupons.
Closing thought
The four sub-areas — Configuration, Products, Orders, Coupons — cover the work of running a small store. The work is real, the surfaces are real, the records are real. Open the per-sub-area docs for the details. Use this page as the map.
Where to go from here
Three reading paths from this page, depending on where you are:
- Setting up a new store. Start at Configuration → General. Walk every panel in the order described above. Open the per-panel docs for the panels that need more depth.
- Adding a new product line. Start at Products. The product list shows the current catalog; the Add New flow walks you through a new record. Read the Attributes doc if the new line has variants.
- Operating an existing store. Start at Orders for the morning sweep, then Coupons for any active campaign review. Configuration is the surface you visit quarterly, not weekly.
The store is yours. The records are yours. The export is yours. Treat the surface that way and the day-to-day stays small.
Run the morning sweep, keep the configuration current, and the operation runs itself most weeks.
Related reading
| Topic | |
|---|---|
| Security | |
| UX | |
| What this covers | |
| --- | |
| What is this for? | |
| Good use cases | |
| What NOT to use this for | |
| How this connects to other features | |
| Before you start | |
| Where to find it | |
| Steps | |
| What success looks like | |
| What to do if it does not work | |
| Examples | |
| Property | Value |
| --- | --- |
| title | Ecommerce |
| audience | public |
| classification | PUBLIC |
| audit_at | 2026-05-14 |