Commerce Wiki
A precise reference for every term that matters in modern commerce — from SKU to CRDT — with specific explanations of how QuantumOS X3 implements each concept across its 9 pillars.
Use this as shared vocabulary across engineering, merchandising, finance, and marketing.
Commerce Fundamentals
14 termsSKU
fundamentalsStock Keeping Unit — a unique alphanumeric identifier assigned to a single sellable variant. Every distinct size, color, or configuration gets its own SKU. It is the atomic unit of inventory management and fulfilment.
In X3: X3 auto-generates SKUs using a configurable pattern (prefix + attribute hash) and enforces global uniqueness across tenants in the shared PIM; manual overrides are validated at import time.
Variant
fundamentalsA specific, purchasable form of a configurable product — for example, 'Blue / XL / Cotton'. Variants share a parent product record but each have independent inventory, pricing, images, and weight. A product with three sizes and four colours yields twelve variants.
In X3: X3 stores variants in qos_product_variants with a JSONB attributes column; variant matrices are built at query time via a Postgres lateral join, keeping schema migrations rare.
Bundle
fundamentalsA fixed set of two or more products sold as one line item. Bundles often carry a discount relative to buying constituent items separately. Inventory may be tracked at the bundle level or dynamically deducted from component SKUs at order placement.
In X3: X3 supports both static (pre-packaged) and dynamic (assemble-on-order) bundles; component reservation happens atomically inside a Postgres transaction during checkout to prevent oversell.
Configurable Product
fundamentalsA product that the shopper customises by selecting one or more attribute axes — size, colour, material — before adding to cart. The selection resolves to a specific variant. Configurable products exist as a UI concept; the actual inventory belongs to the resolved variant.
In X3: X3's storefront PDP fetches all in-stock variant combinations in a single pgvector-accelerated query so the attribute selector disables unavailable combinations in real time.
Virtual Product
fundamentalsA product that has no physical form and therefore requires no shipping or inventory tracking — consultations, gift cards, SaaS licences. Payment is captured but no fulfilment workflow is triggered.
In X3: X3 sets requires_shipping = false and routes virtual line items through a lightweight fulfilment stub that emits a 'delivered' event immediately after payment settlement.
Downloadable Product
fundamentalsA digital asset — PDF, software, audio — sold as a file download. Requires access-controlled, time-limited download links to prevent link sharing. May allow multiple downloads up to a configured limit.
In X3: X3 signs download URLs with a 72-hour expiry HMAC token stored in qos_digital_entitlements; download counts are enforced at the edge function layer without touching the primary database.
Subscription
fundamentalsA recurring purchase agreement where the merchant charges the customer on a defined cadence — weekly, monthly, annually. Subscription commerce requires dunning logic, upgrade/downgrade flows, pause/resume, and cohort-level churn analysis.
In X3: X3 manages subscription state in qos_subscriptions with a cron-driven billing engine; Kynetra AI scores churn probability 14 days before renewal so teams can trigger win-back journeys proactively.
AOV
fundamentalsAverage Order Value — total revenue divided by total number of orders over a period. AOV is a primary lever in growth: lifting it 10% on the same traffic compounds across every channel. Tactics include upsells, cross-sells, free-shipping thresholds, and bundle discounts.
In X3: X3's analytics dashboard surfaces per-segment AOV with cohort breakdowns and flags orders below tenant-configured thresholds for upsell prompt insertion.
LTV
fundamentalsCustomer Lifetime Value — the projected total revenue a customer generates over their entire relationship with the merchant. LTV drives acquisition spend decisions: a customer with a 3-year LTV of 24,000 justifies a much higher CAC than one with 2,000.
In X3: X3 calculates historical LTV per customer via a Postgres window function and projects forward using an exponential smoothing model run nightly inside the analytics engine.
CAC
fundamentalsCustomer Acquisition Cost — total marketing and sales spend divided by the number of new customers acquired in a period. The LTV:CAC ratio is the canonical unit-economics health check; a ratio below 3:1 typically indicates unsustainable growth.
In X3: X3 imports ad spend from Meta, Google, and affiliate networks via webhook and computes CAC per channel, per campaign, and per attribution window — visible in the Growth Intelligence dashboard.
GMV
fundamentalsGross Merchandise Value — the total face value of all orders placed through the platform, before any deductions. GMV is a marketplace or platform-wide metric; it overstates true revenue because it includes seller payouts, refunds, and discounts.
In X3: X3 separates GMV from net revenue at the data model level: qos_orders.subtotal holds GMV while qos_ledger_entries tracks settled amounts post-fees and post-refund.
NMV
fundamentalsNet Merchandise Value — GMV after subtracting cancellations, refunds, and fulfilment failures. NMV is the more honest revenue proxy for marketplace operators.
In X3: X3 surfaces NMV in the Command Center overview alongside GMV so operators can see return rates without needing a separate BI query.
Take Rate
fundamentalsThe percentage of GMV that a marketplace operator retains as revenue — typically covering payment processing, platform fees, and fulfilment services. A take rate of 12% on 1 Cr GMV yields 12 L platform revenue.
In X3: X3 supports per-category, per-seller, and tiered take-rate schedules; fees are calculated at order confirmation and recorded in qos_commission_splits before funds settle to seller wallets.
Commission
fundamentalsA seller-specific or category-specific percentage or flat fee charged against each completed sale. Commissions may be stacked — a base platform commission plus a payment gateway fee, for example.
In X3: X3 resolves commission stacks at checkout using a priority-ordered rule engine; split disbursements to seller bank accounts are batched nightly via the payment gateway payout API.
Inventory & Fulfilment
18 termsReservation
inventoryA temporary hold placed on inventory at the moment a customer adds an item to their cart or initiates checkout, preventing another buyer from purchasing the same unit. Reservations must have TTL-based expiry to avoid permanently locking stock that is never purchased.
In X3: X3 uses Postgres advisory locks scoped to (tenant_id, sku_id) pairs; reservations expire after a configurable TTL (default 15 minutes) and are released by a cron-driven cleanup job.
Oversell
inventoryAccepting more orders than available inventory — a failure mode that results in cancellations, disappointed customers, and operational scramble. Oversell typically occurs when inventory checks and order writes are not atomic.
In X3: X3 prevents oversell via a CHECK constraint on qos_inventory.available_qty >= 0 enforced at the Postgres level, making it structurally impossible regardless of application-layer race conditions.
Backorder
inventoryAn order placed against zero or negative inventory, with an explicit expectation that the item will be fulfilled once stock arrives. Backorders require ETA communication, prioritised receiving workflows, and proactive status updates.
In X3: X3 gates backorder acceptance per SKU via a backorder_allowed flag; backordered line items are held in a separate allocation queue that auto-releases when a purchase order is received into the WMS.
Preorder
inventoryAn order placed before a product is available for sale — typically for upcoming launches. Preorders often require partial or full payment upfront with a promised fulfilment date. They differ from backorders in that no prior stock existed.
In X3: X3 models preorders with a release_date on the variant; the storefront renders a 'Ships on [date]' badge and the OMS holds the order in PREORDER status until the WMS signals receiving.
Wave Picking
inventoryA warehouse fulfilment strategy where orders are grouped into 'waves' — time-based batches — and all picks for that wave are executed simultaneously. Waves are sized to match staff capacity and despatch cut-off times.
In X3: X3's WMS scheduler emits waves every 30 minutes by default; wave size and cut-off cadence are configurable per warehouse and auto-adjusted by Kynetra AI based on historical pick-rate telemetry.
Batch Picking
inventoryA method where a single picker collects items for multiple orders simultaneously, visiting each bin location once per walk. Reduces travel time compared to order-by-order picking — effective for high-SKU, low-volume-per-order operations.
In X3: X3 generates batch pick lists sorted by bin location using a nearest-neighbour path optimisation; the WMS mobile app on the Capacitor shell displays the sequenced bin list with scan-to-confirm.
Cluster Picking
inventoryA variant of batch picking where the picker uses a cart with labelled compartments — one per order — and sorts items into the correct compartment at the point of pick. Eliminates a separate consolidation sort step.
In X3: X3 assigns cluster totes dynamically at wave release; the WMS mobile scanner confirms tote-to-order mapping and flags exceptions if a barcode does not match the expected SKU.
FEFO
inventoryFirst Expired, First Out — a picking rule that mandates items with the earliest expiry date are picked and despatched first. Critical for food, pharmaceuticals, and cosmetics where selling expired goods creates liability.
In X3: X3 enforces FEFO at the lot level; lot expiry dates are captured at goods receipt and the pick suggestion engine ranks available lots ascending by expires_at before presenting pick instructions.
FIFO
inventoryFirst In, First Out — inventory received earliest is despatched first. The default strategy for non-expiring goods; FIFO prevents old stock from being permanently buried by newer deliveries.
In X3: X3 defaults to FIFO on all non-tracked SKUs using a received_at ordering; configurable to LIFO or FEFO per product category in warehouse settings.
LIFO
inventoryLast In, First Out — most recently received inventory is picked first. Uncommon in physical commerce (creates old-stock risk) but relevant in certain accounting jurisdictions for cost valuation.
In X3: X3 supports LIFO as a pick-strategy override at the category level and computes LIFO-adjusted cost of goods sold separately in the financial export module.
Lot Tracking
inventoryAssociating received inventory with a manufacturer lot number, enabling recall traceability. If a lot is recalled, the system can instantly identify all affected units: still in warehouse, in transit, or delivered to customers.
In X3: X3 stores lot numbers in qos_inventory_lots linked to both the purchase order line and every outbound order line; a recall search returns the full affected order list in under 200ms.
Serial Tracking
inventoryAssigning a unique serial number to every individual unit of a product — used for high-value electronics, medical devices, and warranty-critical items. Serial tracking enables precise unit-level traceability from manufacturer to end customer.
In X3: X3 scans and records serial numbers at goods receipt and again at despatch; the customer-facing order confirmation includes the serial number for self-service warranty registration.
Expiry Tracking
inventoryRecording the expiry or best-before date of perishable inventory at the SKU or lot level. Enables FEFO picking, near-expiry alerts, and automatic write-down workflows before stock becomes unsellable.
In X3: X3 surfaces near-expiry stock in a WMS dashboard alert when remaining shelf life drops below a configurable threshold (default 30 days); Kynetra can trigger an automatic markdown campaign.
3PL
inventoryThird-Party Logistics — outsourcing warehousing, pick-pack, and shipping to a specialist provider. The merchant retains ownership of inventory but delegates physical operations. Integration requires real-time inventory sync, order push, and tracking number pull-back.
In X3: X3 connects to 3PL partners via a standardised webhook contract; the 3PL adapter layer translates X3 fulfilment events into partner-specific API calls without requiring per-integration code changes.
Dropship
inventoryA model where the merchant takes the order and payment but forwards fulfilment to the supplier, who ships directly to the customer. The merchant never holds stock. Margin is the difference between retail price and supplier cost.
In X3: X3 routes dropship line items to supplier inboxes via email or EDI automatically on order confirmation; the OMS tracks supplier shipping confirmations and propagates tracking to the customer.
Ship-from-Store
inventoryFulfilling an online order from a retail store's inventory rather than a dedicated warehouse. Increases inventory utilisation and reduces last-mile delivery distance for nearby customers, often improving delivery speed.
In X3: X3's OMS scores each store's suitability for ship-from-store based on distance to the delivery address, current pick capacity, and real-time stock availability before assigning the order.
BOPIS
inventoryBuy Online, Pick Up In Store — the customer purchases on the web and collects from a physical location. Requires real-time store inventory visibility, a 'ready for pickup' notification workflow, and a check-in handoff process.
In X3: X3 reserves BOPIS inventory at the store level; the store associate receives a push notification on the POS, marks the order ready, and the customer receives an SMS with a QR pickup code.
Endless Aisle
inventoryA retail strategy where store associates can offer customers the full online catalogue — including items not stocked in-store — by placing orders on a tablet or POS terminal for home delivery or store pickup. Eliminates lost sales from local stockouts.
In X3: X3 surfaces the full catalogue on the POS in 'endless aisle' mode; orders placed from store are tagged with the originating store ID for associate commission attribution and inventory reporting.
Orders & Payments
11 termsOrder Lifecycle
ordersThe sequence of states an order transitions through from placement to completion: PENDING (captured, not yet confirmed) → CONFIRMED (payment authorised, inventory reserved) → FULFILLED (all line items shipped or delivered) → COMPLETE (customer accepted, return window closed) → REFUNDED (partial or full refund issued). Each state triggers downstream events.
In X3: X3 implements the order lifecycle as a Postgres-backed state machine with transition guards; invalid transitions are rejected at the database level, and each transition publishes a typed event to the Kynetra event bus.
Payment Capture vs Authorisation
ordersAuthorisation places a hold on the customer's funds without moving money. Capture is the subsequent step that actually moves the funds to the merchant. Many merchants authorise at order placement and capture only when the order ships, reducing disputes on cancelled orders.
In X3: X3 supports both immediate and deferred capture; deferred capture automatically fires when the WMS marks the shipment as despatched, with a configurable timeout after which it falls back to void-and-recapture.
Settlement
ordersThe final transfer of funds from the payment gateway's holding pool to the merchant's bank account. Settlement timing varies by gateway: same-day, T+1, or T+2. Marketplace platforms must split settlements between the platform and multiple sellers.
In X3: X3 reconciles gateway settlement reports against qos_ledger_entries nightly; discrepancies above a configurable threshold raise an alert in the finance inbox for manual review.
Chargeback
ordersA payment reversal initiated by the cardholder's bank, typically following a dispute. Chargebacks carry fees and damage merchant health scores with payment networks. Merchants have a limited window to submit evidence contesting fraudulent chargebacks.
In X3: X3 receives chargeback webhooks from payment gateways and surfaces them in a dispute dashboard with pre-assembled evidence packets (order data, delivery confirmation, device fingerprint) to accelerate rebuttal.
Fraud Signals
ordersData points used to assess whether an order is likely fraudulent: velocity (too many orders from one IP), address mismatch, device fingerprint, BIN country vs billing country, and behavioural anomalies. High-risk orders may be auto-cancelled or routed for manual review.
In X3: X3 scores every order through a Kynetra fraud regent that aggregates 40+ signals and returns a risk score 0-100; orders above the tenant-configured threshold are held in REVIEW status before confirmation.
COD
ordersCash on Delivery — payment is collected by the courier at the moment of delivery. Dominant in markets with low credit card penetration (India, MENA, Southeast Asia). COD orders carry higher return rates and operational cost but enable broader market reach.
In X3: X3 gates COD availability by pin code, order value ceiling, and customer risk band; COD remittances from logistics partners are auto-reconciled against the expected settlement via the 3PL webhook contract.
NET Terms
ordersA payment arrangement common in B2B commerce where the buyer pays within a defined number of days after invoice — NET 30 means payment is due 30 days after the invoice date. Requires credit risk assessment and dunning workflows for late payments.
In X3: X3 stores approved NET terms per buyer account in qos_b2b_credit_terms and auto-generates invoices with due dates; overdue invoices trigger a Kynetra-driven dunning sequence via email.
PO Checkout
ordersA checkout flow where the buyer submits a Purchase Order number rather than paying immediately. The seller fulfils against the PO and invoices later. Standard in public sector and large enterprise procurement workflows.
In X3: X3's B2B checkout supports PO number capture with optional file attachment; PO-gated products are only visible to buyer accounts that have an approved PO template on file.
Quote
ordersA formal price proposal presented to a buyer before they commit to purchasing. Quotes may include custom pricing, volume discounts, or special terms. A quote-to-order flow converts an accepted quote into a confirmed order without re-entering line items.
In X3: X3 generates PDF quotes from the admin and tracks quote status (draft, sent, accepted, expired); accepted quotes auto-generate a linked order with quote pricing locked in regardless of subsequent catalogue price changes.
RMA
ordersReturn Merchandise Authorisation — a formal approval allowing a customer to return a product. RMAs include a reference number, return window, condition requirements, and instructions for the courier label. They prevent unauthorised or fraudulent returns.
In X3: X3's customer portal lets shoppers self-serve RMA requests; each RMA triggers a Kynetra regent to assess return reason, customer LTV, and policy eligibility before auto-approving or escalating to a human agent.
Return Authorisation
ordersSynonymous with RMA — the explicit approval that a return is accepted. Distinct from refund, which is the financial step that may follow a return. Returns may be inspected before a refund decision is made.
In X3: X3 models return authorisations separately from refunds; a returned item enters a QC-holding inventory state in the WMS before being restocked, written off, or redirected to a liquidation channel.
Customer & Loyalty
14 termsCustomer 360
customerA unified view of a customer aggregating data from every touchpoint: browsing history, purchase history, support tickets, loyalty status, email engagement, and in-store visits. The 360 view enables personalised experiences and informed agent interactions.
In X3: X3's Customer 360 panel aggregates all touchpoint events in real time; the panel is accessible inside the admin, the POS, and the AI Copilot so every team member has the same context.
LTV Bands
customerSegmentation of the customer base into groups by Lifetime Value — for example, the top 5% by LTV vs the bottom 50%. LTV bands inform acquisition spend, retention priority, support SLAs, and personalised reward structures.
In X3: X3 recalculates LTV bands nightly and exposes them as a first-class segment attribute for journey automation triggers, loyalty tier assignments, and personalisation rules.
Cohort
customerA group of customers who share a common acquisition attribute — typically the month they made their first purchase. Cohort analysis tracks how different acquisition cohorts retain, spend, and churn over time.
In X3: X3's analytics engine materialises cohort retention tables as Postgres views; the admin dashboard visualises cohort curves with a configurable metric (AOV, order frequency, LTV).
Segment
customerA dynamic or static group of customers matching a defined set of criteria — 'customers in Chennai who purchased in the last 30 days with an AOV above 2,000'. Segments power targeted campaigns, pricing rules, and loyalty experiences.
In X3: X3 evaluates segment membership using a JSON rule engine that combines RFM scores, product affinities, geography, and custom attributes; segments recompute automatically on each relevant data change.
CDP
customerCustomer Data Platform — a system that collects, unifies, and activates customer data across channels. A CDP stitches together anonymous and identified profiles and makes unified data available to downstream tools like email, ads, and personalisation.
In X3: X3 acts as an embedded CDP for connected tenants; cross-channel identity resolution uses a deterministic match on email/phone and a probabilistic match on device fingerprint plus behavioural signals.
RFM Analysis
customerRecency-Frequency-Monetary scoring — ranking customers on three axes: how recently they purchased, how often they purchase, and how much they spend. RFM produces a score like '5,5,5' (best customer) that powers segmentation without predictive modelling.
In X3: X3 computes RFM scores nightly in Postgres using decile-based binning; scores are stored on the customer record and exposed as a segment filter for campaign targeting.
Tier
customerA named loyalty level that a customer achieves by meeting a spend or points threshold — Bronze, Silver, Gold, Platinum. Tiers typically carry escalating benefits: higher earn rates, free shipping, priority support.
In X3: X3 evaluates tier eligibility on every qualifying transaction; tier upgrades and downgrades are immediate and trigger a Kynetra-composed notification email celebrating the change.
Points
customerA loyalty currency earned on purchases and redeemable for discounts or rewards. Points are a proven retention mechanism but require careful design of earn rate, redemption rate, and expiry policy to avoid liability runaway.
In X3: X3 tracks points in an append-only ledger in qos_loyalty_ledger; balance is computed as a sum of earn and burn entries — making it auditable and reversible without UPDATE statements.
Cashback
customerA loyalty variant where a percentage of spend is returned to the customer as real monetary credit applicable to future purchases. Cashback feels more tangible than points and has higher perceived value, but creates a direct P&L liability.
In X3: X3 stores cashback as a wallet balance in the same ledger as points; cashback can be configured as instant, next-order, or milestone-triggered with a minimum order value gate.
Earn Event
customerAn action that grants loyalty points or cashback — a purchase, a product review, a referral, a birthday, a social share. Earn events are defined per tenant with configurable multipliers.
In X3: X3 processes earn events through a Kynetra loyalty regent that resolves applicable multipliers (tier, product category, campaign) and writes atomic ledger entries in under 50ms.
Burn Event
customerThe redemption of loyalty currency — applying points or cashback against an order total. Burn events reduce the loyalty liability and must be consistent even if the order is subsequently cancelled or refunded.
In X3: X3 handles burn reversals automatically on refund: if an order that used points is refunded, a compensating earn entry restores the burnt balance minus a configurable retention percentage.
Dunning
customerThe process of communicating with customers about failed or overdue payments — subscription renewals, invoice settlements, instalment plans. Effective dunning sequences retry payments on a smart schedule and graduate from soft to firm messaging.
In X3: X3's dunning engine retries failed subscription payments on days 1, 3, 7, and 14 with exponential jitter; Kynetra personalises the email copy based on customer tier and historical responsiveness.
Churn Prediction
customerUsing historical purchase patterns to forecast which customers are likely to stop buying. A customer who previously ordered monthly but has not ordered in 60 days is a churn candidate. Early identification allows intervention before the customer is lost.
In X3: X3's Kynetra churn regent scores every customer weekly using a gradient-boosted model trained on tenant-specific order history; customers crossing the churn threshold are surfaced in a retention action queue.
Win-back
customerA campaign targeting lapsed customers who have not purchased in a defined window. Win-back messaging typically includes an incentive — discount, free shipping, or a personalised offer — to re-engage.
In X3: X3 ships a pre-built win-back journey template: Kynetra selects the incentive based on predicted LTV and sends a series of three touchpoints (email + optional WhatsApp) across 14 days.
Marketing & Growth
12 termsFunnel
marketingThe sequential stages a prospective customer moves through from first awareness to purchase — Awareness, Interest, Consideration, Intent, Purchase, Retention. Each stage has an associated conversion rate; the product of all stage rates is the end-to-end funnel conversion.
In X3: X3's Growth Intelligence dashboard visualises funnel stages as annotated step-drop charts with daily and weekly breakdowns, session replays linked per stage, and A/B test overlays.
Conversion Rate
marketingThe percentage of visitors who complete a desired action — adding to cart, initiating checkout, placing an order. Measured at each funnel stage. Lifting checkout conversion from 60% to 65% adds 8.3% revenue on the same traffic.
In X3: X3 captures conversion events at the edge via a first-party pixel stored in Postgres; conversion rates are available per page, per device, per segment, and per A/B test variant.
Cart Abandonment
marketingWhen a customer adds items to their cart but leaves without completing checkout. Industry average abandonment is 70-80%. Recovery emails sent within one hour can recapture 5-15% of abandoned revenue.
In X3: X3 persists cart state server-side and triggers a Kynetra-composed recovery sequence after a configurable delay (default 1 hour); the email includes the exact cart items with live pricing and stock status.
Journey Automation
marketingA series of timed, conditional marketing touchpoints triggered by customer behaviour or lifecycle events. Journeys replace one-size-fits-all blasts with personalised sequences: new customer onboarding, post-purchase follow-up, re-engagement.
In X3: X3's Journey Builder executes automation via a cron-driven journey-tick engine; nodes support email (via Mailgrid), SMS, webhook, and loyalty actions, all connected by conditional branch logic.
Triggered Campaign
marketingA message or sequence that fires automatically in response to a specific customer action or event — browse abandonment, low loyalty balance, a birthday, or a product review. Triggered campaigns have far higher open and conversion rates than batch sends.
In X3: X3 ships 27 built-in trigger events; operators can add custom triggers via the event webhook API without deploying code.
A/B Test
marketingA controlled experiment where two or more variants of a page, message, or price are shown to randomly assigned user groups. Statistical significance is reached when the observed difference is unlikely to be due to chance.
In X3: X3's native A/B framework assigns visitors to variants at the edge using a deterministic hash on session ID; results are computed using a Bayesian posterior that reports probability-to-beat rather than p-values.
Holdout Group
marketingA control group deliberately excluded from a campaign or experiment to provide a clean baseline. Holdouts measure the true incremental lift of a campaign — what would have happened without any intervention.
In X3: X3 supports configurable holdout percentages (default 10%) per campaign; holdout members are permanently excluded for the campaign duration and their revenue is tracked separately for lift calculation.
Attribution
marketingThe process of assigning credit to marketing touchpoints that preceded a conversion. Models include last-click (simple), first-click (awareness-focused), linear (equal credit), time-decay (recency-weighted), and data-driven (ML-based).
In X3: X3 stores the full touchpoint sequence in qos_attribution_events and supports switching between attribution models in the UI without re-processing historical data.
ROAS
marketingReturn on Ad Spend — revenue generated per unit of ad spend. A ROAS of 4x means every rupee spent returns 4 in revenue. ROAS is the primary efficiency metric for performance marketing teams.
In X3: X3 imports spend data from connected ad platforms and computes ROAS per campaign, per SKU promoted, and per customer segment — visible alongside CAC in the Growth Intelligence dashboard.
CPM
marketingCost per Mille — the cost to serve 1,000 ad impressions. A CPM pricing model is used for awareness campaigns where brand exposure is the goal rather than immediate conversion.
In X3: X3 records CPM costs from ad platform imports and uses them to compute reach-efficiency ratios in the marketing analytics module.
CPC
marketingCost per Click — the cost of each click generated by an ad. CPC is used in search and social advertising where the advertiser pays only when a user clicks through.
In X3: X3 reconciles CPC data from Google Ads and Meta ad accounts to build a unified cost-per-click view across channels, normalised by campaign objective.
CPA
marketingCost per Acquisition — the total ad spend divided by the number of conversions (orders, sign-ups, etc.). CPA is a direct measure of performance-channel efficiency and is the natural complement to CAC.
In X3: X3 computes CPA at the campaign level using first-order attribution by default, with the option to switch to 30-day attributed windows for subscription products.
Platform & Technical
13 termsISR
platformIncremental Static Regeneration — a Next.js rendering strategy that pre-renders pages at build time and re-generates them in the background on demand without taking the page offline. ISR combines the performance of static HTML with the freshness of server rendering.
In X3: X3's storefront uses ISR with a 60-second revalidation window on category and product pages; the revalidation is triggered on-demand via webhook when PIM data changes, keeping latency below 40ms p95.
Edge Function
platformA serverless function deployed to a CDN edge network and executed close to the end user — often 10-50ms from the browser. Edge functions are ideal for personalisation, A/B routing, authentication checks, and geo-based redirects.
In X3: X3 deploys storefront middleware as Cloudflare Workers edge functions; tenant routing, feature flags, and fraud pre-screening all execute at the edge before the request reaches the origin.
CDN
platformContent Delivery Network — a globally distributed network of servers that cache and serve static assets (images, CSS, JS) from locations close to the user, drastically reducing time-to-first-byte.
In X3: X3 uses Cloudflare as its CDN layer; product images are served via Cloudflare Images with automatic WebP conversion and responsive resizing, reducing image payload by 60-80% vs raw uploads.
Webhook
platformAn HTTP callback that one system sends to another when an event occurs — an order is placed, a shipment is despatched, a payment fails. Webhooks enable real-time integrations without polling.
In X3: X3 publishes typed, versioned webhook events with HMAC-SHA256 signatures; the delivery engine retries with exponential back-off up to 72 hours and surfaces delivery failures in the developer dashboard.
Idempotency
platformThe property of an operation that can be applied multiple times without changing the result beyond the first application. Critical in payments and order APIs — a network retry should not result in a duplicate charge.
In X3: X3 requires an Idempotency-Key header on all write API endpoints; keys are stored with a 24-hour TTL and return the cached response for duplicate requests without re-executing the operation.
Event Sourcing
platformAn architectural pattern where state changes are stored as an immutable, append-only sequence of events rather than as mutable row updates. The current state is derived by replaying events. Provides a full audit trail and enables temporal queries.
In X3: X3's order state machine and loyalty ledger use event sourcing; the event log is the system of record, and the qos_orders aggregate table is a materialised projection rebuilt by replaying events.
CQRS
platformCommand Query Responsibility Segregation — separating the write model (commands that change state) from the read model (queries that return data). Allows each side to be optimised independently: writes for consistency, reads for speed.
In X3: X3 applies CQRS on the OMS: order placement writes go through a command handler with full validation, while order list queries hit a denormalised Postgres view optimised for pagination at high cardinality.
Saga Pattern
platformA distributed transaction pattern where a multi-step operation — place order, reserve inventory, charge payment, create shipment — is managed as a sequence of local transactions, each with a compensating action on failure. Avoids distributed locks across services.
In X3: X3 implements checkout as a choreography-based saga; each step publishes a typed event, and compensating events (release reservation, void payment) fire automatically if any downstream step fails.
CRDT
platformConflict-free Replicated Data Type — a data structure that can be updated concurrently on multiple nodes and merged without conflicts. CRDTs are foundational for offline-first applications where local state must sync after reconnecting.
In X3: X3's POS uses CRDT-based cart and inventory state so sales associates can continue transacting during the 72-hour offline window; sync on reconnect applies a merge strategy without manual conflict resolution.
RLS
platformRow-Level Security — a Postgres feature that enforces data access policies at the database layer by filtering rows based on the executing user's context. RLS provides a structural guarantee of tenant isolation even if application-layer bugs bypass normal query scoping.
In X3: X3's admin-web sets a app.tenant_id GUC before each query via tenantProcedure; RLS policies on all customer-data tables use this GUC to restrict row visibility, making cross-tenant data leaks structurally impossible.
OAuth Scopes
platformFine-grained permissions declared during an OAuth flow that limit what an authorised application can access. A 'read:orders' scope grants order read access without write access or customer data access.
In X3: X3's partner API uses Kynetra Auth to issue scoped JWT tokens; the tRPC API layer validates required scopes per procedure, and scope violations return a structured 403 before any database round-trip.
tRPC
platformA TypeScript-first RPC framework that generates end-to-end type-safe API contracts without a schema file or code generation step. The client infers types directly from server procedure definitions, making breaking changes a compile-time error.
In X3: X3's admin-web is built entirely on tRPC with 39 sub-lambdas for hot routes; shared input validators (Zod schemas) are co-located with procedure definitions and reused on the client for form validation.
pgvector
platformA Postgres extension that adds vector similarity search — cosine, L2, and inner product — to standard Postgres tables. Enables semantic search, product recommendations, and embedding-based retrieval without a separate vector database.
In X3: X3 stores product and customer embeddings in qos_embeddings using pgvector; semantic search on the storefront and the 'customers like this segment' feature both use HNSW index scans in under 20ms.
International Commerce
12 termsMarket
internationalA configured selling destination defined by a combination of country, currency, language, tax region, and shipping rules. A merchant selling to India, UAE, and UK is operating three markets, each with distinct pricing, tax, and content requirements.
In X3: X3 models markets in qos_markets with per-market price lists, tax configs, and storefront locale mappings; the storefront resolves the correct market at the edge based on the incoming x-geo-country header.
Locale
internationalA combination of language and region code — en-IN, ta-IN, ar-AE — that drives storefront language, date formatting, number formatting, and right-to-left text rendering.
In X3: X3 uses next-intl with CLDR-compliant number and date formatters; 10 locales are supported out of the box with a content fallback chain so partially translated content degrades gracefully.
Currency
internationalThe monetary unit in which prices are displayed and charged. Multi-currency storefronts must handle display currency (for the shopper) vs settlement currency (for the merchant's bank) and FX conversion between them.
In X3: X3 supports display-only currency conversion (FX rate applied on the fly) and natively charged currency (the gateway charges the shopper in their currency and settles in the merchant's base currency).
FX Rate
internationalThe exchange rate between two currencies at a given time. FX rates fluctuate continuously; merchants must decide whether to lock in rates (predictable margins, FX risk for merchant) or float them (accurate pricing, potential shopper confusion from price changes).
In X3: X3 fetches FX rates every 6 hours from an exchange rate API and stores them in qos_fx_rates with a valid_from timestamp; price display uses the latest rate while settled invoices are locked at order-time rate.
CLDR
internationalCommon Locale Data Repository — the Unicode consortium's authoritative data set for locale-specific formatting rules: number separators, date patterns, plural forms, measurement units, and calendar systems.
In X3: X3 bundles CLDR data for all supported locales and uses it to format prices, dates, and quantities without client-side JS — formatting happens in server components so SSR output is locale-correct.
hreflang
internationalAn HTML attribute that tells search engines which version of a page is intended for which language and region. Proper hreflang implementation prevents duplicate content penalties and ensures the correct locale ranks in each market's search results.
In X3: X3 generates hreflang tags automatically for all localised storefront pages using the market configuration; the sitemap.xml includes the full hreflang alternates block for each market.
Tax Region
internationalA geographic jurisdiction with its own tax rules — rates, exemptions, and filing requirements. Tax regions may be country-level (India GST), state-level (US sales tax), or category-level (UK zero-rated food).
In X3: X3 resolves applicable tax region at checkout using the delivery address; tax rate tables in qos_tax_rules are merchant-maintained and applied after all discounts are deducted from the taxable base.
VAT
internationalValue Added Tax — a consumption tax applied at each stage of the supply chain, with businesses reclaiming VAT on their purchases. The end consumer bears the full VAT cost. Dominant in Europe, India (as GST), and the Middle East.
In X3: X3 stores tax-inclusive and tax-exclusive prices separately; storefront display respects the market's tax-inclusive convention while invoices show the tax breakdown for VAT-registered business buyers.
GST
internationalGoods and Services Tax — India's unified indirect tax replacing the prior VAT/service tax patchwork. GST has four rates (5%, 12%, 18%, 28%), product-level HSN code classification, and requires monthly GSTR filings.
In X3: X3 maps products to HSN codes in the PIM; GST rate is resolved at checkout from the HSN-rate table; GSTR-compatible export in the finance module generates B2B (with GSTIN) and B2C line items in the prescribed JSON format.
HSN Code
internationalHarmonised System of Nomenclature code — an internationally standardised product classification code used in India's GST system to determine the applicable tax rate. 6-digit codes cover broad categories; 8-digit codes are more specific.
In X3: X3 stores HSN codes per product in qos_products.hsn_code and validates them against the GST council's master list; incorrect codes are flagged during PIM import.
Customs HS Code
internationalThe Harmonised System code used in international trade customs declarations. Required on commercial invoices for cross-border shipments to determine import duties and eligibility for trade agreement preferences.
In X3: X3 stores HS codes for cross-border selling and includes them in commercial invoice PDFs generated for international shipments.
DDP vs DDU
internationalDelivered Duty Paid (DDP) means the seller pays all import duties and taxes — the buyer receives the package with no surprise charges. Delivered Duty Unpaid (DDU) means the buyer is responsible for clearing customs and paying import duties.
In X3: X3 supports both shipping incoterms; DDP shipping calculates estimated duties at checkout and collects them from the buyer, remitting to the logistics partner for pre-clearance.
B2B Commerce
8 termsBuyer Group
b2bA named classification applied to B2B buyer accounts that controls which catalogues, price lists, and payment terms they can access. A hospital buyer group might see medical supply pricing; a retail buyer group sees standard wholesale pricing.
In X3: X3 assigns buyer groups in qos_b2b_buyer_groups; the storefront and checkout resolve catalogue visibility, price lists, and payment options by joining the authenticated session's buyer account to its assigned group.
Price List
b2bA defined set of prices applied to a specific customer segment, buyer group, or geographic market — potentially overriding the base catalogue price. A single product may have dozens of active price lists simultaneously.
In X3: X3 resolves the applicable price list at checkout using a priority-ordered rule: buyer-account-specific list, then buyer-group list, then market list, then base price — all evaluated in a single Postgres CTE.
PO
b2bPurchase Order — a formal document issued by a buyer authorising a supplier to deliver goods or services at a specified price. POs define quantity, unit price, delivery terms, and payment terms. They create a binding commercial obligation.
In X3: X3 stores POs in qos_purchase_orders linked to the buyer account and seller; PO-to-invoice matching is automated — discrepancies above a configurable tolerance are flagged for finance review.
Quote-to-Order
b2bThe workflow converting a sales quote into a confirmed purchase order. Once a buyer accepts a quote, the agreed pricing, quantities, and terms are locked in and a binding order is created without re-entering data.
In X3: X3's quote-to-order conversion is a single API call that creates the order from the quote snapshot, locking in quoted prices even if the catalogue price subsequently changes.
Credit Limit
b2bThe maximum outstanding balance a buyer can carry before further orders require prepayment. Credit limits are typically set by the seller's finance team based on payment history and creditworthiness.
In X3: X3 checks available credit in real time at checkout by comparing the buyer's credit limit against the sum of unpaid invoices; orders exceeding the limit are held for finance approval.
Approval Workflow
b2bA structured review process where orders above a threshold — by value, by product type, or by customer — require explicit sign-off from a designated approver before proceeding. Common in enterprise procurement to enforce spend controls.
In X3: X3's approval workflow routes orders to configured approvers via email with one-click approve/reject links; approvers can leave a comment and the originating buyer is notified of the decision via the portal.
Company Account
b2bA B2B entity representing an organisation rather than an individual — with a business name, tax ID, credit terms, and multiple authorised buyer contacts underneath it. Company accounts separate personal and business identity.
In X3: X3 models company accounts in qos_b2b_companies with a one-to-many relationship to qos_b2b_contacts; order history, credit balance, and price lists are scoped to the company, not the individual buyer contact.
Buyer Contact
b2bAn individual user who belongs to a B2B company account and can place orders on behalf of that company. Buyer contacts may have role-based permissions — some can place orders, others can only view invoices.
In X3: X3 supports per-contact permission sets within a company account; a buyer contact with view-only access sees order history but cannot proceed past the cart confirmation step.
Every structural advantage X3 has over Shopify Plus, Magento, and Commercetools — explained with specifics.
Read moats →The 9 pillars — Storefront, POS, OMS, WMS, Marketplace, Loyalty, AI Copilot, Bridge, and Conversational Commerce.
Explore features →334 regents powering intelligent behaviour in X3 — from churn prediction to fraud scoring to content generation.
Learn about Kynetra →QuantumOS Dispatch
Weekly insights for commerce operators
100 competitive moats, real operator stories, platform updates. No fluff. Every Tuesday.
No spam. Unsubscribe any time. 60k+ readers.
Ready to build on a platform that implements all of this correctly, by default?