VALUECOMBO Marketplace Engine

All Markets, One Place — multi-seller marketplace operating blueprint.

Marketplace Finance, Cashflow & Profitability Intelligence Engine

Validated Orders/Settlements → Revenue → Fees & Costs → Adjustments → Contribution Profit → Cash Inflow/Outflow → Working Capital → Reconciliation → Finance Insights

Coverage: seller economics, marketplace service fees, shipping revenue/cost, payment and packaging costs, returns/RTO, promotion spend, settlement payable/available, contribution profit/margin and cashflow signals.

Controls: every financial record should reference its source, entity, order and period where applicable. Calculations should use a defined basis, consistent periods, no double counting, and reconciliation against actual payment/settlement records.

Finance principle: contribution profit and cashflow outputs are estimates until reconciled with actual marketplace, payment, accounting and bank records. No invented financial results or guaranteed profit/cash claims.

Implementation status: finance/profitability data foundation is ready. Live accounting feeds, payment/bank feeds, real-time cashflow, tax/accounting integration and automated reconciliation require connected finance/accounting backend services.

Marketplace Accounting & Reconciliation Engine

Marketplace Event/Transaction → Source Record → Accounting Mapping → Amount Validation → Reconciliation → Difference Review → Approval → Close → Audit

Coverage: orders, marketplace service fees, seller settlements, refunds, returns/RTO adjustments, shipping/payment adjustments, promotion spend and other authorized financial movements.

Controls: every reconciliation should reference the source system, source reference, accounting period and underlying marketplace entity. Differences should be recorded and reviewed rather than silently overwritten.

Reconciliation principle: Shopify/order records, settlement records, payment/accounting records and external provider data should be treated as separate sources until matched and validated. No financial amount should be invented to force a match.

Status flow: Open → Matched → Difference Found → Under Review → Approved Adjustment → Reconciled → Closed.

Implementation status: accounting/reconciliation data foundation is ready. Live accounting feeds, bank/payment-provider matching, automated journal mapping, tax/accounting integrations and automatic reconciliation require connected finance/accounting backend services.

Marketplace Treasury & Cash Management Engine

Validated Cash Events → Opening Position → Inflows → Settlement/Refund/Operating Outflows → Reserves → Available Cash → Reconciliation → Treasury Review

Coverage: customer cash inflows, seller settlement obligations, refunds, shipping/payment outflows, promotion spend, operating movements, reserved cash and available cash signals.

Controls: cash movements should reference validated transactions and accounting/reconciliation records. Settlement and refund obligations should be tracked separately from available cash, and reserves should not be treated as freely spendable funds.

Cash principle: treasury balances are not inferred from incomplete data. External bank/payment-provider balances remain authoritative until imported and reconciled.

Status flow: Cash Event → Validated → Classified → Reserved/Available → Reconciled → Reviewed.

Implementation status: treasury data foundation is ready. Live bank/payment balances, automated cash sweeps, reserve calculations, treasury alerts and real-time cash position require connected finance/payment backend services.

Risk-Based Financial Reserve Engine

Validated Risk Exposure → Reserve Basis → Reserve Calculation → Approval → Reserved Funds → Actual Event → Adjustment/Release → Reconciliation → Audit

Coverage: documented exposure from returns/RTO, customer refunds, disputes, settlement exceptions and other approved financial risks.

Controls: every reserve must identify its risk type, evidence/source, calculation basis, effective period, approval status and reconciliation reference. Reserve rates or amounts should be configured from documented marketplace rules and validated data.

Protection principle: a reserve is a financial risk-management mechanism, not a conclusion that a loss will occur. Unused or released reserves must remain separately traceable and should not be treated as available profit until reconciled.

Status flow: Proposed → Under Review → Approved → Reserved → Partially Released/Adjusted → Released → Reconciled.

Implementation status: reserve data/workflow foundation is ready. Live risk-based reserve calculation, payment/settlement holds, automatic releases and accounting reconciliation require connected finance/risk backend services.

Seller Credit & Payout Risk Engine

Validated Seller/Order Data → Settlement Exposure → Holds/Reserves → Risk Review → Payout Eligibility → Authorized Release → Reconciliation

Coverage: eligible and pending settlements, held amounts, reserves, refund/RTO and dispute exposure, payout exposure and any separately approved seller credit or advance request.

Controls: payout decisions should reference validated settlement, return, dispute and reserve records. Holds must have a documented reason, status and review path; credit eligibility must use defined criteria and authorized approval.

Protection principle: payout timing, credit eligibility or advance availability is not guaranteed. Risk signals are review inputs, not proof of seller wrongdoing or inability to pay.

Status flow: Exposure Identified → Risk Review → Hold/Reserve if Authorized → Eligibility Review → Approval → Payout/Release → Reconciliation.

Implementation status: seller credit/payout-risk data foundation is ready. Live risk calculation, automated holds, credit underwriting, payout controls and payment-provider execution require connected finance/risk backend services.

Working Capital & Settlement Forecast Engine

Validated Historical/Current Data → Cash & Settlement Assumptions → Scenario Forecast → Expected Inflows/Outflows → Working Capital Gap → Liquidity Signal → Review → Reconciliation

Coverage: expected customer inflows, seller settlement outflows, refunds, operating/promotion outflows, expected closing cash, settlement payable/available and working-capital gaps.

Scenario planning: baseline, higher-demand and lower-demand cases can be recorded separately with assumptions and confidence status. Forecasts should use validated historical/current data and clearly state the period used.

Controls: forecast assumptions, source periods, data quality and reconciliation references must be recorded. Forecasts are estimates, not guaranteed cash positions, settlement dates, sales or profits.

Status flow: Draft → Data Validated → Forecasted → Reviewed → Reconciled/Updated.

Implementation status: working-capital/settlement forecast data foundation is ready. Live cash feeds, settlement timing models, scenario automation, liquidity alerts and treasury execution require connected finance/payment backend services.

Financial Reporting & Management Dashboard Engine

Validated Marketplace Data → Period Reporting → KPI Calculation → Comparison/Trend → Insight → Management Action → Reconciliation

Coverage: sales, Marketplace Service Fee, gross/contribution margin, operating costs, returns/RTO, promotion spend, seller settlements, cash inflow/outflow and working-capital signals.

Management views: marketplace summary, seller economics, product/category performance, cash & settlement position, cost drivers, returns/RTO exposure and promotion efficiency where validated data is available.

Controls: every KPI must have a defined period, source reference and calculation basis. Comparisons should use consistent periods and dimensions; incomplete data should be marked rather than silently estimated.

Decision support: reports can surface trends, exceptions and recommended actions, but management decisions should use the underlying validated records rather than dashboard summaries alone.

Status flow: Data Collected → Validated → Calculated → Reported → Reviewed → Reconciled.

Implementation status: financial reporting data foundation is ready. Live dashboards, automatic KPI aggregation, real-time data refresh, accounting integration and management-alert automation require connected analytics/finance backend services.

Tax Accounting & GST Reconciliation Engine

Validated Order/Seller Tax Context → Tax Rule → Tax Components → Refund/Credit Adjustments → Accounting Match → Difference Review → Reconciliation → Audit

Coverage: seller GST/registration status, seller and customer state context, supply type, tax category, taxable value, configured tax rate/components, refunds/credits and accounting tax amounts.

Controls: tax records must reference the underlying seller/order/product context, source evidence, filing period and rule version. CGST/SGST/IGST/cess amounts should be reconciled with the applicable configured rule and accounting source; unresolved conflicts should be reviewed rather than guessed.

Compliance principle: this engine organizes and reconciles tax data; it does not issue GST registrations or government enrolment IDs and does not replace professional tax advice or the requirements of applicable law.

Status flow: Tax Context Captured → Rule Applied → Components Recorded → Accounting Compared → Difference Review → Reconciled → Closed.

Implementation status: tax-accounting reconciliation data foundation is ready. Live GST/tax verification, invoice/tax automation, filing preparation, accounting-provider integration and automatic reconciliation require connected tax/finance backend services.

Invoice & Document Automation Engine

Validated Order/Seller/Tax Data → Document Type → Calculation Validation → Document Number/Version → Approval → Issue → Store/Deliver → Amend/Void → Audit

Document coverage: invoices, credit notes, debit notes, refund/adjustment documents and defined operational documents linked to marketplace orders and seller records.

Controls: every document should reference its underlying order/seller/tax records, source reference, document version and validation status. Corrections should create a traceable amendment/version rather than silently changing an issued document.

Financial integrity: document totals, discounts, shipping, tax and adjustments must reconcile with the underlying transaction and tax records before issue. Document generation should not invent customer, seller, tax or payment information.

Status flow: Draft → Validating → Approved → Issued → Delivered/Stored → Amended/Void if authorized.

Implementation status: invoice/document data foundation is ready. Live invoice generation, numbering controls, PDF delivery, e-invoice/e-way-bill integrations, tax-provider connections and automatic customer/seller delivery require connected commerce/finance backend services.

Vendor & Supplier Procurement Engine

Supplier Discovery → Vendor Approval → Product/SKU Mapping → Purchase Planning → Purchase Order → Supplier Confirmation → Receiving → Quality/Cost Validation → Inventory → Supplier Performance → Reorder

Coverage: supplier onboarding, vendor status, product/SKU sourcing, purchase quantities, purchase orders, unit cost, shipping/procurement costs, landed cost, expected/actual receipt and supplier performance.

Controls: procurement records should preserve supplier, product/SKU, purchase-order and reconciliation references. Requested, approved and received quantities should remain distinguishable; landed cost should use documented cost components.

Quality & sourcing: received quantity and quality status should be validated before inventory is treated as sellable. Supplier performance can consider delivery, quality, fill rate, cost consistency and exception history when sufficient validated data exists.

Status flow: Vendor Lead → Under Review → Approved → Product/SKU Mapping → PO Draft → PO Approved → Confirmed → Receiving → QC/Cost Validation → Inventory → Reconciled.

Implementation status: procurement data foundation is ready. Live supplier discovery, purchase-order communication, receiving scans, supplier payments, inventory posting and automated reorder execution require connected procurement/inventory backend services.

Purchase Order & Goods Receiving Engine

Purchase Plan → PO Draft → Approval → Supplier Confirmation → Dispatch → Goods Receipt → Quantity/Quality Inspection → Cost Validation → Inventory Posting → Payment/Reconciliation

Coverage: purchase-order quantities, supplier confirmation, expected receipt, actual receipt, accepted/rejected quantities, unit and landed cost, quantity/cost variance, inspection and inventory posting.

Controls: ordered, confirmed, received and accepted quantities remain separate. Variances must be recorded and reviewed; inventory should not be treated as received/sellable until the applicable receiving and quality checks are completed.

Exception flow: Quantity Short/Excess → Quality Issue → Cost Variance → Supplier Review → Corrective Action → Reconciliation.

Status flow: Draft → Approved → Supplier Confirmed → In Transit → Receiving → Inspection → Accepted/Exception → Inventory Posted → Reconciled.

Implementation status: PO/receiving data foundation is ready. Live supplier communication, barcode/scanner receiving, warehouse inventory posting, automated payment and procurement reconciliation require connected procurement/inventory backend services.

Warehouse & Inventory Operations Engine

Warehouse/Location → Receive → Put Away → Reserve → Pick → Pack → Dispatch → Stock Adjustment/Cycle Count → Reconciliation

Coverage: warehouse locations, inventory movements, received stock, reservations, available stock, damaged stock, order-linked picking/packing, purchase-order receiving and cycle counts.

Controls: every stock movement should reference a product/SKU and movement reason. Quantity before/after, reserved and available quantities should remain traceable. Manual adjustments require an operator/reason reference and reconciliation.

Stock integrity: damaged, reserved and available stock must not be silently combined. Cycle-count differences should create an exception and be reviewed before the system treats the adjusted quantity as authoritative.

Status flow: Received → Put Away → Available → Reserved → Picked → Packed → Dispatched; exceptions → Count/Review → Adjustment → Reconciled.

Implementation status: warehouse/inventory operations data foundation is ready. Live warehouse scanning, location-level stock mutation, pick/pack workflows, cycle-count automation and real-time inventory synchronization require connected WMS/inventory backend services.

Order Fulfilment & Pick-Pack Optimization Engine

Order → Seller/Warehouse Allocation → Pick Wave → Picking → Packing → Package Validation → Dispatch Readiness → Carrier Handoff → Reconciliation

Coverage: fulfilment planning, seller/warehouse allocation, pick waves, pick priority, packing status, package references, package counts, dispatch readiness and carrier service level.

Controls: allocation should use approved seller/product and inventory records. Picked and packed quantities must be traceable to order lines; package and dispatch records should not be marked complete without the required validation.

Optimization: fulfilment plans may consider seller/warehouse location, inventory availability, package consolidation, service level and dispatch timing where validated data supports the decision. Optimization signals are recommendations, not guaranteed delivery outcomes.

Status flow: Allocated → Pick Wave Created → Picking → Picked → Packing → Packed → Dispatch Ready → Carrier Handoff → Reconciled.

Implementation status: fulfilment/pick-pack data foundation is ready. Live allocation, warehouse task assignment, barcode scanning, package generation, carrier booking and real-time optimization require connected fulfilment/WMS/logistics backend services.

Customer Delivery Experience & ETA Engine

Validated Shipment Events → Delivery Milestones → ETA Signal → Customer Updates → Exception Handling → Delivery → Experience Record

Coverage: promised/estimated delivery dates, carrier/service level, pickup and delivery context, shipment milestones, tracking events, delivery attempts, exceptions and customer notification status.

ETA principle: ETA should be derived only from validated logistics/tracking data and clearly identified as an estimate. If tracking data is stale or unavailable, the system should show the data limitation rather than invent an ETA.

Customer experience flow: Order Confirmed → Pickup → In Transit → Out for Delivery → Delivered; exceptions such as delay, failed attempt or RTO should trigger the appropriate review/communication workflow.

Controls: shipment identity must remain linked to the correct order/seller/fulfilment record. Customer notifications should use consented supported channels and preserve delivery-event history.

Implementation status: delivery-experience/ETA data foundation is ready. Live carrier tracking, ETA calculation, customer notifications, exception automation and real-time delivery updates require connected logistics/communication backend services.

Customer Returns & Refund Experience Engine

Customer Request → Eligibility → Approval → Reverse Pickup → Receipt → Inspection → Inventory Decision → Refund → Seller Adjustment → Customer Notification → Resolution

Coverage: return reason, request type, eligibility, approval, pickup, reverse tracking, receipt, inspection, inventory disposition, refund amount/status and seller adjustment reference.

Customer experience: every return/refund case should have a clear status, responsible workflow and communication record. The customer-facing status should reflect validated backend events rather than assumptions.

Controls: refund decisions and amounts must be linked to the underlying order/line item and authorized eligibility decision. Seller adjustments remain traceable to the corresponding return/refund case.

Status flow: Requested → Eligibility Review → Approved/Rejected → Pickup → Received → Inspection → Refund Processing → Refunded → Resolved; exceptions → Support Review.

Implementation status: returns/refund experience data foundation is ready. Live return authorization, reverse pickup, inspection updates, payment refunds, seller adjustments and customer notifications require connected commerce/logistics/payment backend services.

Customer Support & Omnichannel Service Engine

Customer Contact → Case Creation → Order/Product Identification → Priority/SLA → Routing → Response → Resolution → Refund/Return/Adjustment if Applicable → Customer Update → Closure

Coverage: order help, product questions, delivery issues, returns/RTO, payment/refund issues, seller-related cases and general marketplace support across supported contact channels.

Omnichannel model: supported conversations can be linked to one case reference so customer history, responses, escalations and resolutions remain traceable across channels.

Controls: sensitive credentials, OTPs, passwords, full payment-card or bank credentials should never be requested through the support workflow. Financial/refund actions require authorized validation against the underlying order and applicable policy.

Status flow: New → Routed → Assigned → First Response → In Progress → Escalated if needed → Resolved → Closed.

Implementation status: customer-support data foundation is ready. Live WhatsApp/SMS/email integrations, unified inbox, agent routing, SLA timers, conversation history and automated refund/return actions require connected support/communication backend services.

Seller Support & Communication Engine

Seller Request → Seller/Order/Product Identification → Priority/SLA → Routing → Response → Evidence → Resolution → Financial/Inventory Reconciliation → Seller Update → Closure

Coverage: onboarding/KYC, product submission, listing/compliance, orders, pickup/shipment, returns/RTO, settlements, promotions, inventory, disputes and general seller support.

Communication model: each support interaction should retain a case and communication reference so seller history remains traceable across supported channels.

Controls: seller financial or inventory impacts require documented evidence and authorized decisions. Support communication must not request passwords, OTPs, full payment-card details or other sensitive credentials.

Status flow: New → Routed → Assigned → First Response → In Progress → Escalated if needed → Resolved → Reconciled → Closed.

Implementation status: seller-support data foundation is ready. Live unified inbox, WhatsApp/SMS/email integrations, agent routing, SLA timers, seller notifications and automated financial/inventory actions require connected support/communication backend services.

Seller Education & Knowledge Engine

Seller Need → Knowledge Topic → Verified Content → Learning → Assessment/Confirmation → Next Topic → Policy Update → Knowledge Review

Coverage: seller onboarding, KYC/GST guidance, product listing, pricing, inventory, fulfilment, returns/RTO, settlements, promotions, customer service, compliance and marketplace best practices.

Knowledge controls: operational guidance should reference an approved source or current VALUECOMBO policy version. Time-sensitive or regulatory content should be reviewed when rules change; outdated content should not remain presented as current.

Learning model: sellers can follow structured topics, mark completion, use assessments where appropriate and receive a recommended next topic based on their onboarding/support needs.

Status flow: Draft → Review → Published → Seller Access → Learning → Completion/Assessment → Update → Re-review.

Implementation status: education/knowledge data foundation is ready. Live learning portal, progress tracking, assessments, personalized recommendations, notifications and content-version automation require connected knowledge/learning backend services.

Seller Certification & Verification Engine

Eligibility → Evidence → Knowledge Completion → Assessment → Verification → Certification → Validity → Re-verification/Expiry → Audit

Coverage: VALUECOMBO seller training/certification milestones, verification evidence, assessment status, issue/validity dates, expiry, suspension and re-verification.

Certification principle: VALUECOMBO certification represents marketplace-defined requirements only. It does not replace government registration, statutory licences, regulatory approvals or third-party certifications where those are legally required.

Controls: certification should be issued only after the defined eligibility, evidence and assessment requirements are validated. Expired or suspended certifications should not continue to display as active.

Status flow: Eligible → Evidence Submitted → Under Verification → Assessment Complete → Certified → Active → Re-verification Due/Expired/Suspended.

Implementation status: certification/verification data foundation is ready. Live evidence verification, assessments, certification badges, expiry automation and seller-access controls require connected verification/learning backend services.

Seller Identity & KYC Verification Engine

Seller Application → Identity/Business Evidence → PAN/Business Proof → GST or Applicable Enrolment Status → Bank/Payout Verification → Risk Review → Authorized Approval → Re-verification → Audit

Coverage: seller identity, business/shop proof, PAN status, GST status where applicable, permitted government enrolment/registration reference, bank and payout verification, evidence and approval history.

Compliance principle: VALUECOMBO does not issue GST registrations or government enrolment IDs. Government registration/enrolment status must be obtained from the applicable authority and verified according to the marketplace's compliance process.

Controls: missing, inconsistent or expired evidence can place an application on hold for review. Sensitive credentials such as passwords, OTPs and full banking authentication details must not be stored as ordinary support data.

Status flow: Submitted → Evidence Check → Verification → Risk Review → Approved/Hold/Rejected → Active → Re-verification Due → Re-verified/Suspended.

Implementation status: KYC/identity data foundation is ready. Live government verification, document OCR, bank-account verification, automated risk checks and secure KYC provider integrations require connected compliance/KYC backend services.

Seller Account & Access Control Engine

Approved Seller → Account Mapping → Authentication → Role → Permission Check → Portal Access → Activity → Review → Suspend/Revoke → Audit

Coverage: seller login identity, portal roles, product/order/settlement/promotion/support permissions, authentication and authorization status, account security status and access reviews.

Access principle: authentication proves the account identity; authorization determines what that seller is permitted to access. Seller data must be isolated by approved seller identity and role.

Controls: pending/rejected/suspended sellers should not receive active seller permissions. Access changes should be traceable to an authorized decision and audit reference.

Status flow: Pending → Approved → Active → Access Review → Restricted/Suspended → Reinstated or Revoked.

Implementation status: account/access data foundation is ready. True seller-specific data isolation, secure authentication/session controls, permission enforcement, account recovery and automatic suspension/revocation require connected marketplace backend/authentication services.

Seller Wallet & Earnings Engine

Delivered Order → Earnings Calculation → Fees/Adjustments → Pending Balance → Eligibility → Available Balance → Withdrawal/Payout → Reconciliation

Coverage: seller gross earnings, Marketplace Service Fee, shipping/payment adjustments, returns/RTO adjustments, other authorized adjustments, net earnings, pending/available balance and withdrawal records.

Balance principle: Pending earnings remain separate from available earnings until the applicable settlement/hold conditions are satisfied. Every financial movement should reference its underlying order or settlement record.

Controls: duplicate transactions and payouts must be prevented through unique references/idempotency. Holds and adjustments require a documented reason and reconciliation trail.

Status flow: Pending → Eligibility Review → Available → Withdrawal Requested → Processing → Paid → Reconciled, with Hold/Exception paths where required.

Implementation status: wallet/earnings data foundation is ready. Live seller balances, automated calculations, withdrawal processing, payment-provider payouts and real-time reconciliation require connected financial backend services.

Seller Withdrawal & Payout Engine

Withdrawal Request → Balance/Settlement Eligibility → Amount Validation → Approval → Payout Execution → Provider Confirmation → Seller Update → Reconciliation

Coverage: seller withdrawal requests, eligible/approved amounts, payout method, payout account reference, provider reference, payment status, failures, holds and reconciliation.

Controls: requested amount must not exceed validated eligible funds. Each payout uses a unique idempotency reference to prevent duplicate execution. Failed or held payouts move to review rather than being silently completed.

Status flow: Requested → Eligibility Check → Approved → Processing → Provider Submitted → Paid → Reconciled, with Hold/Failed/Retry/Review paths.

Security: payout account references should use secure provider/account identifiers; never store passwords, OTPs, PINs or full banking authentication credentials in ordinary marketplace records.

Implementation status: withdrawal/payout data foundation is ready. Live payment-provider execution, bank validation, automated retries, webhook confirmation and real-time payout reconciliation require connected payment/payout backend services.

Seller Billing & Invoice Engine

Validated Marketplace Activity → Billing Period → Order/Settlement Matching → Service Fee & Adjustments → Tax Validation → Statement/Invoice → Approval → Delivery → Reconciliation

Coverage: seller billing periods, marketplace service fees, order/settlement references, shipping/payment/return-RTO adjustments, applicable tax amounts, seller statements and invoice/document status.

Billing principle: every billed amount should trace back to a validated marketplace or settlement source. Billing documents must preserve version history and should not silently overwrite previously issued records.

Controls: billing differences are recorded for review; duplicate documents use unique references/versioning. Tax treatment must follow the applicable configured rules and current legal requirements.

Status flow: Draft → Validated → Approved → Issued → Delivered → Reconciled, with Correction/Void/Review paths where required.

Implementation status: seller billing/invoice data foundation is ready. Live invoice generation, tax-provider/e-invoice integrations, document delivery, recurring statements and automated billing reconciliation require connected financial/document backend services.

Seller Tax & GST Compliance Engine

Seller Tax Status → GST/Enrolment Reference → Seller/Customer State → Supply Type → Tax Rule → Tax Calculation → Filing Period → Compliance Review → Reconciliation

Coverage: GST status, GSTIN where applicable, permitted government enrolment reference, seller state, tax category, supply type, taxable value, output tax, eligible input-tax-credit references, refunds and filing-period status.

Compliance principle: VALUECOMBO does not issue GST registrations or government enrolment IDs. Seller eligibility and tax treatment depend on applicable law, registration status, supply type and current rules.

Controls: tax calculations must use a versioned rule and validated seller/order context. Conflicting or missing tax information goes to review rather than being guessed.

Status flow: Pending → Registration/Enrolment Check → Tax Rule Validation → Calculation → Filing Review → Reconciled → Compliant/Exception.

Implementation status: tax/GST compliance data foundation is ready. Live GST verification, invoice/tax automation, filing preparation, e-invoice/e-way-bill integrations and tax-provider connectivity require connected compliance backend services.

Seller Product Catalog & Bulk Upload Engine

Seller Upload → File/Data Validation → Duplicate Check → Category Mapping → Pricing/Inventory/Compliance Validation → Product Mapping → Admin Approval → Publish → Audit

Coverage: bulk product submission, catalog versions, product counts, duplicate detection, category mapping, pricing validation, inventory validation, compliance checks, errors and publish status.

Catalog principle: a bulk upload does not automatically make products live. Each submitted record must pass the applicable seller, product, content, pricing, inventory and compliance controls before publication.

Error handling: invalid, duplicate or unmapped products are separated for correction rather than silently published. Upload results should retain an error reference and version for traceability.

Status flow: Uploaded → Validating → Errors/Needs Correction → Mapped → Under Review → Approved → Published, with Rejected/Held paths.

Implementation status: catalog/bulk-upload data foundation is ready. Live CSV/API upload, automatic field mapping, duplicate detection, product creation/update, image import, inventory sync and batch publishing require connected catalog/backend services.

Seller Product Variant & SKU Management Engine

Approved Product → Variant Creation → Option Mapping → Unique SKU → Barcode/Inventory Mapping → Price/MRP Validation → Approval → Live Variant → Controlled Edit/Retirement

Coverage: seller-specific SKU identity, product variants, option combinations, barcode references, cost/selling price, MRP reference, inventory item mapping, weight and variant lifecycle.

SKU principle: each sellable variant should have a unique, traceable SKU within the seller/catalog context and must map correctly to the underlying Shopify product/variant and inventory item where applicable.

Controls: duplicate SKU/variant combinations, invalid pricing, unmapped inventory or inconsistent barcode data should be held for correction. Variant edits that materially affect customer expectations or compliance should return through review.

Status flow: Draft → Validation → Mapped → Approved → Live → Edit Review → Suspended/Retired.

Implementation status: variant/SKU data foundation is ready. Live bulk variant creation, barcode validation, inventory-item synchronization, variant pricing updates and automated catalog publishing require connected marketplace/catalog backend services.

Seller Product Media & Content Management Engine

Seller Media Upload → Product/Variant Mapping → Quality & Authenticity Check → Content/Policy Review → Approval → Publish → Version Control → Retirement

Coverage: product images, real product videos, captions, alt text, media ordering, content versions, source references, quality checks and publishing status.

Content principle: seller media should accurately represent the product being sold, including quantity, packaging, included items and material/size where relevant. Real product demonstration videos can be used to show what the customer will receive.

Controls: misleading media, unsupported claims, mismatched product images or unverifiable content should be held for review. Replaced media remains version-traceable rather than silently overwriting history.

Status flow: Uploaded → Mapped → Quality Review → Policy Review → Approved → Published → Updated/Retired.

Implementation status: media/content data foundation is ready. Live media upload, image/video processing, CDN storage, automated quality checks, moderation and product-page publishing require connected catalog/media backend services.

Final Marketplace Completion Pack

Seller Shipping & Serviceability: pickup origin, serviceability, carrier/service level, COD availability, delivery rules and seller shipping status.

Seller Returns & Cancellation Policy: seller/product return eligibility, cancellation rules, replacement, inspection and approved policy versions.

Product Compliance Documents: certificates/declarations, issuer, validity, evidence, verification and expiry tracking.

Seller Brand & Store Content: brand name/tagline, store title/description, trust points, logo/banner references, content versions and publishing control.

Order Cancellation & Modification: controlled line/quantity changes, eligibility, approval, customer notification and financial/inventory impact.

Marketplace Offer & Coupon Rules: customer offers, coupon codes, minimum cart/quantity, discount rules, seller funding, validity and redemption tracking.

Customer Wishlist & Saved Items: saved products, sellers and combos, price/stock signals and notification preferences.

Customer Product Reviews: verified-purchase reviews, moderation, seller response, helpful/report signals and product trust data.

Shipping Rate & Fee Rules: retail/wholesale shipping rules, origin/destination, weight bands, customer charge, platform subsidy and versioned eligibility.

Order Fulfilment Groups: multi-seller order lines grouped by seller, fulfilment order, warehouse and shipment with allocation/dispatch/delivery states.

Configuration & Feature Flags: versioned marketplace rules, controlled feature activation, approval and rollback/change reasons.

System Health & Monitoring: integration/service status, failure references, retries, incidents, severity and resolution.

Change Management: platform/policy/workflow changes, risk, approvals, implementation version and rollback reference.

Launch Readiness: release-level checks for sellers, products, payments, fulfilment, compliance, customer protection, operations and blockers.

Final status: the VALUECOMBO marketplace workflow/data foundation is now consolidated across seller onboarding, KYC/access, catalog, variants/media, orders/allocation, inventory, fulfilment, returns/RTO, settlements/payouts, fees/tax/invoices, promotions, reviews, support, analytics, risk, customer experience, procurement, warehouse, finance and operational controls. Live seller isolation, automated routing, real-time inventory, logistics, payments/payouts, communications, fraud/risk automation, dynamic ranking and other external integrations still require the appropriate backend/app/provider services.

Seller Product Pricing & Promotion Rules Engine

Seller Price → Marketplace Price → Promotion Rule → Eligibility → Margin Guard → Inventory Guard → Approval → Customer Display → Performance

Coverage: base price, MRP reference, marketplace price, seller-funded promotions, minimum quantity/cart value, promotion period, eligibility, margin protection and inventory protection.

Controls: promotions must not create misleading discount, savings, urgency or scarcity claims. Price changes should remain versioned and approved where required; products with insufficient margin or inventory should be held from the applicable promotion.

Status flow: Draft → Validation → Guard Check → Approval → Scheduled → Active → Ended/Cancelled → Reconciled.

Implementation status: pricing/promotion rule foundation is ready. Live dynamic price application, automatic discount enforcement, real-time margin/inventory guards and promotion delivery require connected marketplace backend services.

Customer Checkout & Payment Orchestration Engine

Cart → Checkout Validation → Customer/Address Validation → Shipping Rule → Payment Method → Authorization/Capture → Order Confirmation → Seller Allocation → Reconciliation

Coverage: PREPAID, COD, payment status, gateway reference, authorization/capture, refunds, risk review, checkout status and reconciliation.

Controls: every payment attempt uses an idempotency reference; failed/duplicate attempts must not create duplicate orders or payouts. Payment status must be reconciled against the actual provider result before downstream seller settlement.

COD: COD order value and applicable prepaid/COD rules are recorded separately. Any future prepaid requirement or COD eligibility rule must be configured through approved marketplace rules.

Status flow: Checkout Started → Validation → Payment Pending → Authorized/Captured or COD Confirmed → Order Created → Reconciled. Failure/Refund → Review → Reconciled.

Implementation status: orchestration data foundation is ready. Live gateway activation, payment webhooks, automatic capture/refund, COD verification, risk checks and real-time reconciliation require payment-provider/backend integration and applicable KYC.

Customer Order Management & Post-Purchase Engine

Order Created → Payment Confirmed → Seller Allocation → Processing → Pickup → Shipped → Out for Delivery → Delivered → Return/Refund/Support if applicable → Closed

Coverage: customer order status, payment status, fulfilment, seller allocation, delivery, cancellation/modification, returns, refunds, tracking, support and customer notifications.

Controls: every post-purchase action must reference the real Shopify order and applicable line item/event. Cancellation, modification, return and refund eligibility must follow configured rules and authorized decisions.

Exception flow: Delivery/fulfilment/payment/customer issue → identify order → evidence → authorized action → financial/inventory reconciliation → customer notification → audit.

Implementation status: post-purchase workflow foundation is ready. Live customer order data, automatic status updates, carrier events, cancellation/modification, refunds and notifications require connected Shopify/backend/payment/logistics integrations.

Customer Account & Personalization Engine

Customer Account → Preferences → Wishlist/Saved Items → Shopping Signals → Personalized Assistance → Communication Preferences

Coverage: customer account mapping, language/state preferences, preferred categories, wishlist linkage, shopping interests, budget preferences, communication preferences and AI assistance context.

Privacy controls: personalization should use only necessary customer information and applicable consent/preferences. Sensitive credentials, OTPs, passwords and payment credentials must never be stored in this personalization layer.

Customer control: personalization is an assistance layer, not a guarantee of recommendations or prices. Customers remain able to browse, search and purchase without relying on automated recommendations where applicable.

Implementation status: account/personalization data foundation is ready. Live customer-specific recommendations, preference synchronization, wishlist behavior and consent-aware personalization require connected Shopify/backend services.

Customer Search & Discovery Engine

Customer Need → Search/Category → Intent → Filters → Sort → Product/Seller Results → Availability → Relevance → Discovery Action

Coverage: keyword search, natural-language intent, categories/subcategories, filters, sorting, price range, product/seller references and discovery source.

Discovery controls: search relevance should prioritize accurate product/category matching and valid availability. Sponsored visibility must remain distinguishable from organic discovery where applicable.

AI search: natural-language queries can be converted into product/category intent, but live price, stock, seller, delivery and promotion information must come from validated marketplace data.

Implementation status: search/discovery data foundation is ready. Live search indexing, relevance ranking, filters, availability synchronization and personalized discovery require connected search/backend services.

Marketplace Recommendation & Personalization Engine

Validated Signals → Eligibility → Product/Seller/Combo Candidate → Availability & Price Validation → Ranking → Placement → Customer Action → Performance

Coverage: product recommendations, combo recommendations, seller discovery, category suggestions, personalized placements, recommendation reasons and performance attribution.

Controls: recommendations must use validated marketplace data. Sponsored recommendations must remain distinguishable where required; unavailable products or invalid prices must not be presented as purchasable recommendations.

Personalization: recommendations may use customer preferences and permitted shopping signals, subject to applicable consent/privacy settings. AI recommendations are assistance, not guaranteed outcomes.

Implementation status: recommendation foundation is ready. Live candidate generation, ranking, personalization, availability/price validation and conversion attribution require connected search/analytics/backend services.

Marketplace Cart & Smart Combo Engine

Cart → Cart Validation → Eligible Rules → Combo Opportunity → Price & Inventory Validation → Customer Approval → Apply → Checkout

Coverage: cart state, cart value, offer eligibility, combo suggestions, combo items, combo pricing, estimated savings, inventory/price validation and customer action.

Controls: combo suggestions must use validated product data. Savings must be calculated from real applicable prices/rules; the system must not invent discounts, stock, reviews or delivery promises.

Customer control: smart combos are suggestions unless the customer explicitly applies them. Cart changes must remain visible before checkout.

Implementation status: cart/combo foundation is ready. Live cart mutation, real-time inventory/price validation, automatic offer application and checkout synchronization require connected Shopify/backend services.

Customer Offers, Coupons & Loyalty Engine

Offer/Coupon → Eligibility → Validation → Customer Apply → Discount/Benefit → Order Redemption → Usage Tracking → Reconciliation

Coverage: coupon codes, cart-value/quantity rules, percentage or fixed benefits, usage limits, validity periods, funding source, loyalty benefits and redemption records.

Controls: offers must have clear eligibility and validity rules. Discount/savings claims must be calculated from applicable prices. Usage limits prevent repeated or unauthorized redemption.

Loyalty: future loyalty benefits can be recorded separately from seller-funded promotions and marketplace service fees, with explicit funding and approval.

Implementation status: offer/coupon/loyalty foundation is ready. Live coupon validation, checkout application, loyalty balance calculation and redemption enforcement require connected Shopify/backend services.

Customer Communication & Engagement Engine

Marketplace Event → Customer Eligibility/Consent → Message Rule → Channel → Delivery → Read/Click/Action → Engagement Record

Coverage: transactional order messages, delivery updates, return/refund communication, support updates, promotional campaigns, channel preference and engagement tracking.

Controls: transactional and promotional communications must be distinguished. Promotional messages should follow applicable consent/preferences and channel rules. Deduplication prevents repeated messages for the same event.

Channels: WhatsApp, SMS, email and account/in-store notifications can be supported subject to provider integration, consent and applicable rules.

Implementation status: communication/engagement foundation is ready. Live message delivery, provider webhooks, scheduling, retries, opt-out enforcement and engagement analytics require connected communication/backend services.

Customer Support & Helpdesk Engine

Customer Issue → Ticket → Order/Seller Identification → Priority → SLA → Assignment → Evidence → Resolution → Refund/Return Link → Escalation → Closure

Coverage: order issues, wrong/damaged product, delivery problems, payment/refund questions, returns/RTO, seller issues, product/listing complaints and general customer support.

Controls: tickets remain linked to the actual order/line item where applicable. Refunds, returns, deductions and seller liability require authorized decisions and reconciliation rather than automatic assumptions.

SLA: support cases can link to the marketplace SLA and escalation registry for priority, due time and escalation tracking.

Implementation status: helpdesk foundation is ready. Live ticket inbox, customer replies, agent assignment, SLA timers, notifications and automated refund/return actions require connected support/backend services.

Customer Trust, Ratings & Review Engine

Delivered Order → Verified Purchase Check → Customer Review → Moderation → Publish/Hold/Reject → Product/Seller Trust Signal → Seller Response → Reporting

Coverage: product reviews, seller ratings, verified-purchase status, moderation, review reports, helpful votes, seller responses and trust signals.

Controls: reviews should be linked to real orders where verification is claimed. Reported or suspicious content goes through moderation; rating averages should use published, valid reviews only.

Trust signals: Verified Seller, Verified Purchase Review, rating, review count and other validated marketplace signals may be displayed without implying a guarantee of product quality or future experience.

Implementation status: trust/review foundation is ready. Live review submission, verification, moderation tooling, rating aggregation, reporting and public display require connected Shopify/backend services.

Customer Price & Stock Alert Engine

Customer Alert Request → Product/Variant → Target Condition → Validated Price/Stock Check → Trigger → Customer Notification → Deduplication → Close/Reset

Coverage: price-drop alerts, target-price alerts, back-in-stock alerts and availability notifications.

Controls: alerts must use current validated product/variant data. A notification is triggered only when its configured condition is met; repeated notifications use deduplication controls.

Customer control: customers choose the alert type and channel where supported. Promotional communication preferences and applicable consent rules remain separate from transactional/alert delivery.

Implementation status: alert foundation is ready. Live price/stock monitoring, trigger evaluation and automated notifications require connected Shopify/backend and communication services.

Customer Referral & Invite Engine

Customer Invite → Referral Code/Link → Attribution → Qualification → Abuse Review → Referrer/Referee Benefit → Reward Reconciliation

Coverage: referral codes/links, invite channels, attribution, first-order qualification, referrer rewards, referee benefits, abuse review and deduplication.

Controls: rewards are issued only after configured qualification rules and authorized validation. Duplicate/self-referral or suspicious patterns can be reviewed before benefits are granted.

Implementation status: the existing Customer Referral & Invite Registry is available. Live referral links, attribution, qualification automation, reward issuance and abuse detection require connected backend/checkout services.

Seller-Customer Dispute Resolution Engine

Dispute Opened → Customer/Seller Positions → Order/Line Identification → Evidence → Review → Finding → Resolution → Refund/Settlement/Inventory Reconciliation → Closure

Coverage: wrong/damaged product, delivery disputes, return/RTO disagreements, payment/refund disputes, product/listing disputes and seller-customer service disagreements.

Controls: both customer and seller positions can be recorded separately. Decisions should be evidence-based and authorized; financial, inventory and settlement impacts must be reconciled rather than assumed.

Escalation: complex or unresolved cases can link to the existing SLA, Support, Customer Protection and Admin Audit registries.

Implementation status: dispute-resolution foundation is ready. Live dispute inbox, evidence collection, notifications, decision permissions and automatic refund/settlement adjustments require connected backend services.

Seller Verification & KYC Control Engine

Seller Application → Identity/Business Check → GST or Applicable Enrolment Check → PAN/Bank/Address/Documents → Risk Review → Admin Decision → Seller Access → Re-verification

Coverage: identity, business/shop proof, GST status, applicable government enrolment/registration status, PAN, bank, address and supporting documents.

Controls: VALUECOMBO does not issue government GST registration or enrolment IDs. Seller eligibility and applicable GST requirements must be determined under current law and verified through appropriate official sources/processes.

Decision states: Pending → Need More Information → Under Review → Verified/Approved or Rejected/Hold → Re-verification when required.

Implementation status: verification/KYC data foundation is ready. Live identity/GST/bank verification, document OCR, external KYC checks, automated risk decisions and secure seller access enforcement require approved backend/provider integrations.

Seller Account Security & Access Control Engine

Seller Verification → Account Provisioning → Role/Permission Scope → Login → Session → Authorized Workspace → Security Event Review → Access Review/Suspension/Recovery

Coverage: seller account mapping, portal roles, permission scopes, access status, session/security events, suspension, recovery and periodic access review.

Controls: seller access must be tied to the approved seller identity and permitted role. A logged-in customer account alone must not expose another seller's orders, products, inventory or settlement data.

Security: passwords, OTPs, payment credentials and sensitive authentication secrets should not be stored in marketplace registries. Security events should be auditable without exposing credentials.

Implementation status: access-control foundation is ready. True seller-specific authentication, authorization, session management, secure data isolation, MFA and automated suspension/recovery require a dedicated backend/authentication layer.

VALUECOMBO Integration & Launch Execution Plan

Phase 1 — Secure Backend: seller authentication, role-based authorization, seller-to-customer isolation, API/webhook layer, idempotency and audit logging.

Phase 2 — Shopify Marketplace Sync: seller/product/variant mapping, order and line allocation, inventory reservation, fulfilment groups, product lifecycle and controlled catalog synchronization.

Phase 3 — Payments & Settlement: PREPAID gateway activation after required KYC, COD controls, payment webhooks, refund handling, seller fee calculation, settlement ledger, payout reconciliation and duplicate-payout protection.

Phase 4 — Logistics: seller serviceability, shipping-rate rules, courier booking, pickup, tracking webhooks, delivery/RTO events and return routing.

Phase 5 — Customer Experience: live search, recommendations, cart/combo validation, wishlist, offers, reviews, alerts, support and order-status synchronization.

Phase 6 — Communications: WhatsApp/SMS/email provider integration, consent-aware templates, event notifications, retries, deduplication and delivery-status webhooks.

Phase 7 — AI: connect AI actions to validated marketplace APIs so AI can read permitted product, seller, inventory, order and policy data without inventing live facts. Seller/customer access must remain permission-scoped.

Phase 8 — Risk & Operations: KYC/compliance provider checks where appropriate, fraud/risk signals, support/SLA queues, admin controls, monitoring, reconciliation and incident handling.

Phase 9 — Testing: test single-seller and multi-seller orders, partial allocation, inventory races, payment success/failure/refund, COD, cancellation, return/RTO, seller settlement, duplicate webhooks, notification retries and access isolation.

Phase 10 — Controlled Launch: internal test → limited approved sellers → monitored customer launch → expand after reconciliation, fulfilment, support and security checks pass.

Current reality: Shopify workflow/data foundations are built. The remaining live capabilities above require a connected marketplace backend, authentication layer and approved third-party providers/credentials. They cannot be made genuinely live by Shopify page/metaobject configuration alone.

Marketplace Integration Connector Engine

Connector Registry: VALUECOMBO Marketplace Integration Connector Registry — valuecombo_marketplace_integration_connector — GID gid://shopify/MetaobjectDefinition/19351339178.

Integration coverage: Payments, logistics/courier, communication providers, authentication, analytics, AI services and other approved marketplace integrations.

Connector lifecycle: Requested → Security Review → Configured → Connected → Webhook Verified → Syncing → Healthy / Degraded / Failed → Reconnect / Disable.

Controls: provider, environment, credential reference, webhook reference, sync health, failure count, idempotency reference, data scope, owner and security-review status. Credentials themselves are not stored in the registry.

Failure protection: webhook failures, stale sync, duplicate events and provider errors must be isolated, retried where appropriate and reconciled rather than silently treated as successful.

Current status: Integration registry and architecture are ready. Actual provider connections, secrets, webhooks, live sync and automated actions still require the selected providers plus a connected backend/integration service.

Registry Foundation

Structured registries cover Seller, Product, Product Lifecycle, Order, Order Line, Return/RTO, Inventory Reservation, Inventory Sync Guard, Fulfilment/Shipment, Settlement, Promotion, Sponsored Campaign, Review/Trust, Support/Dispute, Performance, Growth Recommendation, Compliance/Risk and Event/Notification.