AstroBaaS

Pricing & promotions

Tier & Quantity Pricing

Free — GPL coresize Lplanned, not built

Generated from docs/plan/core/tier-quantity-pricing/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Core free module that ties pricing to customer account tier or product category. A VIP customer sees €8/unit instead of €10/unit on all products; or ‘shoes category gets 15% discount for VIP customers’. Prices are stored in tier pricing rules (not variant pricing), evaluated at checkout, and displayed on storefront when customer is logged in.

The problem

Many merchants want ‘member gets 10% off everything’ or ‘VIP customers see lower prices per category’. Currently, they must create separate products for each tier (SKU explosion) or manually override prices during checkout, losing professionalism. Tier pricing is a standard e-commerce primitive missing from AstroBaaS.

What it does

  • Tier definition: ‘standard’, ‘VIP’, ‘wholesale’, etc. (merchant-defined enum)
  • Tier pricing rules: per-tier, per-product or per-category, price override or percentage discount
  • Storefront display: logged-in customers see their tier price (‘your VIP price: €8’ shown below regular price)
  • Unauthenticated storefront: shows standard price (no tier)
  • Guest checkout: no tier applied
  • Checkout integration: when customer is logged in with tier=‘VIP’, apply VIP pricing automatically
  • Admin dashboard: show tier distribution, average discount per tier, revenue impact
  • Audit log: log tier price changes and which tier applied to each order

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

  • Dynamic tier assignment based on AI (paid module owns this)
  • Tier-based inventory (too complex; inventory is global)

Data model

Add customer_tiers table: { id, shop_id, tier_name, tier_order (for sorting) }. Add tier_pricing_rules table: { id, shop_id, tier_id, product_id (optional), category (optional), override_price_minor_units (optional), discount_pct (optional) }. Add customer.assigned_tier_id (foreign key to customer_tiers). Schema migration: new tables, add field to customer.

API

  • POST /admin/tiers — create tier
  • GET /admin/tiers — list tiers
  • POST /admin/tiers/:id/pricing-rules — add pricing rule to tier
  • GET /products/:id?tier_id=VIP — get product price for specific tier (admin only)
  • PUT /account/tier — read customer’s current tier (authenticated only)

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Add ‘Customer Tiers’ in Commerce > Customers or Pricing. Tier list: name, price rules count, customer count. Click tier to manage pricing rules: table of rules (product/category, price or discount %). ‘Add rule’ form. Customer admin: field ‘Assigned tier’ with dropdown. Show analytics: ‘VIP: 100 customers, avg €8 price vs €10 standard, revenue impact: +5%’.

The seam — why this is core

Core owns tier pricing rule storage and checkout integration. Merchants manually assign tiers to customers. Paid modules own tier recommendation (auto-assign based on spend or behavior).

Currently requires PRODUCT_PRICE hook. This is a price-rule-engine feature. Table stakes for wholesale, membership, and subscription-adjacent markets.

Dependencies

  • Customer system (must have assigned_tier_id field)
  • Checkout flow (to apply tier pricing when customer is logged in)
  • Product system (tier rules reference products/categories)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

  • Merchant creates tier ‘VIP’ and rule: product shoe-001 override price €8 (vs standard €10)
  • Customer assigned tier=‘VIP’, adds shoe-001 to cart → price displays €8
  • Unauthenticated customer sees shoe-001 price as €10 (no tier)
  • Checkout calculates order total using VIP price €8 when customer is logged in
  • Audit log: ‘VIP pricing applied to order #12345, saved customer €2 per shoe’

Risks

If tier pricing is evaluated client-side, fraud is easy (customer edits JS to fake tier). If tier price is a percentage discount without a floor (VIP = 90% off), merchant loses money (validate discount doesn’t exceed reasonable margin threshold). If tier assignment is permanent without review, customer can’t be demoted even if conditions no longer apply.

Commercial context

Suggested priceFree; core for B2B-friendly shops
Rival anchorMagento Open Source tier pricing; free

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.


Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.