Store settings and dashboard
Every setting key the store reads, what each one changes, the three display switches that are wired to nothing, and how the admin dashboard is scoped.
The store has eight settings. Five of them do something. Three are drawn on the screen, saved to the database, and read by no code at all.
They live at Admin → E-commerce → Settings (/admin/ecommerce/settings),
in two tabs — General and Display.
How saving works
The screen writes to core's platform settings endpoint, not to an E-commerce route of its own. Three consequences:
- The permission is
edit.settings, the general platform settings permission. Someone with every E-commerce permission and not that one cannot change a tax rate. - Only changed keys are submitted. Fields you did not touch are not rewritten, so two admins editing different tabs do not overwrite each other.
- No E-commerce key is Super-Admin-protected, unlike core's withdrawal and
broker settings. Any admin holding
edit.settingscan change all of them.
The platform settings table holds every value as text. The backend compares
against the literal string "true" when it reads a switch, so a value that is
empty, missing or anything other than "true" is off.
If a switch you turned on appears to do nothing, check the stored value before you look anywhere else — this is a real class of bug on this platform, not a theoretical one.
General → Tax
Tax is applied to the discounted subtotal — after any discount, before shipping. It applies to every product, including downloadable ones, in the product's own currency.
There are no tax zones, no per-country rates, no VAT/GST distinction, no tax-exempt products and no reverse-charge handling. Every customer everywhere pays the same percentage.
If your obligations differ by jurisdiction, this setting cannot express that. Decide before you launch whether a single blended rate is defensible for you, or whether you need to price tax into the products and leave this off.
The collected tax is credited to the platform wallet as a pass-through, recorded separately from store revenue and explicitly not counted as profit — you owe it onward. Cancelling an order reverses the pass-through along with the refund.
General → Shipping
Charged once per checkout, never on digital-only carts, and waived entirely by
a FREE_SHIPPING discount code. No zones, weights, bands or thresholds. The
full behaviour is on Shipping.
Display → Layout
This one works. The product listing reads it and re-paginates. Valid values are 1–100; anything much above 24 makes the catalogue page heavy on mobile.
Display → the three that do nothing
ecommerceShowProductRatings, ecommerceShowRelatedProducts and
ecommerceShowFeaturedProducts are declared in the settings screen, rendered
as switches, and saved to the database. No storefront code reads any of
them.
Turning "Show Product Ratings" off does not hide ratings. Turning "Show Featured Products" off does not remove the landing page section. Do not spend an afternoon proving that to yourself — the values simply have no consumer.
If you need those sections gone, they have to be removed from the storefront components. There is no configuration path.
| Key | Shown as | Actually read by |
|---|---|---|
ecommerceTaxEnabled |
Enable Tax | Both order endpoints |
ecommerceDefaultTaxRate |
Default Tax Rate | Both order endpoints, cart and checkout quoting |
ecommerceShippingEnabled |
Enable Shipping | Both order endpoints, cart and checkout quoting |
ecommerceDefaultShippingCost |
Default Shipping Cost | Both order endpoints, cart and checkout quoting |
ecommerceProductsPerPage |
Products Per Page | Product listing |
ecommerceShowProductRatings |
Show Product Ratings | — nothing |
ecommerceShowRelatedProducts |
Show Related Products | — nothing |
ecommerceShowFeaturedProducts |
Show Featured Products | — nothing |
Changing tax or shipping on a live store
The storefront quotes tax and shipping in the browser from these settings, and the backend recomputes them from the same settings when it charges. A customer who loaded the cart page before you changed a rate is looking at a stale quote, and will be charged the new one.
Order rows record what was charged at the time, so historic orders, receipts and refunds are unaffected. Only carts in flight are exposed, and only until they reload.
Change rates when the store is quiet, and never mid-promotion.
The dashboard
Admin → E-commerce → Dashboard (/admin/ecommerce), gated on
access.ecommerce.dashboard.
- Date range. Defaults to the last 7 days. Pick your own start and end.
- Chart metric. Revenue, orders or customers.
- Comparison. Every headline figure is compared against the immediately preceding window of the same length, so a 7-day view compares to the 7 days before it. Change the range and the comparison moves with it.
- Recent orders with the buyer attached.
The recent-orders payload carries the buyer's email twice — once on the derived customer object and once on the raw user include — and both are masked. If you run a demo instance, that is why the dashboard shows redacted addresses while the orders table does not.
The dashboard reads orders directly rather than any cached aggregate, so it is always current and always agrees with the orders table. If a figure looks wrong, it is the underlying orders that are wrong.
Related settings elsewhere in the platform
Three things that shape the store are not in the store's own settings screen:
- KYC. The
order_ecommercefeature (Marketplace Purchases in the level builder) gates checkout. Set it in CRM → KYC → Levels. - Notification templates.
OrderConfirmationandOrderStatusUpdateare edited under System → Notification templates, along with the rest of the platform's mail. - Affiliate rewards. Two seeded conditions of type
ECOMMERCE_PURCHASE— a 5% shopping cashback and a 3% referral commission, the second seeded disabled — live in the affiliate settings, not here.
Back to Orders, or on to the API and permissions reference.