{
  "entries": [
    {
      "topic": "What is Web3Cart?",
      "content": "Web3Cart is a self-hosted crypto ecommerce and marketplace script. It helps store owners launch a modular Web3 store with product management, vendor plans, XPayr crypto checkout, license activation, installer-driven deployment, themes, plugins, and admin reporting. The current product direction is XPayr-first, modular, and extensible rather than legacy smart-contract-cart based."
    },
    {
      "topic": "Current Payment Architecture",
      "content": "Web3Cart now uses XPayr as the default and primary payment layer. Legacy wallet or cart smart-contract checkout should not be presented as the default payment method. Store admins configure XPayr credentials after installation, then customer checkout sessions are created through XPayr and confirmed by webhook."
    },
    {
      "topic": "XPayr Settings",
      "content": "XPayr credentials are managed from the Web3Cart admin panel. Settings are separated for testnet and live mode so admins can test checkout safely before switching to production. Required values include API/public key where supported, API secret, webhook secret, default network, default currency, and webhook URL. Empty secret fields should keep the existing saved value."
    },
    {
      "topic": "Testnet and Live XPayr Modes",
      "content": "Testnet and live credentials should be treated separately. Testnet mode is for faucet tokens, simulated onboarding, and safe checkout validation. Live mode is for real customer payments. Admins should confirm the selected mode, network, token, and webhook configuration before accepting production payments."
    },
    {
      "topic": "XPayr Checkout Flow",
      "content": "The standard checkout flow is: customer selects a package or product, Web3Cart creates an XPayr payment session, the customer pays through XPayr, XPayr sends a signed webhook, Web3Cart verifies the webhook, and the order/license/settlement status is updated. Payment success should be based on verified XPayr confirmation, not on an untrusted frontend redirect alone."
    },
    {
      "topic": "Marketplace Commission Settlement",
      "content": "Web3Cart records marketplace settlement data after XPayr payment activity. Admin commission, vendor net amount, payout wallet, payment status, and settlement state should be visible in admin/vendor reporting. If a split-capable contract or splitter is configured for a network, commission and vendor amount can be handled at payment time; otherwise reporting and payout tracking remain visible for operational settlement."
    },
    {
      "topic": "Vendor Payout Wallets",
      "content": "Vendors should save a valid payout wallet before payment options are published. The payout wallet is used to identify where vendor net funds should be paid when marketplace split or payout workflows are active. Admins should verify vendor payout wallet readiness from product/payment settings before approving products for sale."
    },
    {
      "topic": "Network and Token Selection",
      "content": "Checkout should first ask the user to select a network, then list only the tokens available on that selected network. Avalanche has been removed from the active Web3Cart/XPayr network set. Stablecoins such as USDC and USDT are important defaults where supported, but native network payments can also be supported when configured."
    },
    {
      "topic": "Installer Flow",
      "content": "The installer should focus on license validation, server requirement checks, database configuration, site/admin setup, and installation completion. Mandatory on-chain vendor registration should not block installation. XPayr payment configuration belongs after installation in the admin payment settings, so users do not need to leave the installer to create payment credentials."
    },
    {
      "topic": "License Activation",
      "content": "A customer registers on web3cart.site, selects a monthly or yearly platform package, pays with XPayr, and receives license/download access after verified payment. Licenses should only become active after payment confirmation. Creating a pending order is not enough to grant license verification."
    },
    {
      "topic": "Download Access",
      "content": "Download access should appear only after the user has a valid completed license/order or admin permission. The downloadable script should match the latest stable Web3Cart package and include the updated installer and XPayr-first payment setup flow."
    },
    {
      "topic": "Platform Plans",
      "content": "Web3Cart platform plans are sold from the main web3cart.site flow. Plans support monthly and yearly billing. The active public plan set should remain simple and understandable, with clear pricing, package limits, product/vendor limits, and commission rules. Low entry plans can use lower prices with higher commission, while larger plans reduce commission and raise limits."
    },
    {
      "topic": "Vendor Subscription Plans",
      "content": "Vendor subscription plans control marketplace seller capabilities such as product limits, commission percentage, vendor access, and feature availability. Admins should be able to create, edit, delete, and manage plan status. Product limits and commission values must be enforceable in product publishing and settlement calculations, not just displayed in the UI."
    },
    {
      "topic": "Product Publishing Requirements",
      "content": "Before publishing payment-enabled products, Web3Cart should verify the store/admin XPayr setup and the relevant vendor payout wallet requirements. Product tables should clearly show which vendor added each product, and broken media should be easy to identify and correct from admin."
    },
    {
      "topic": "Admin XPayr Credentials",
      "content": "In the installed Web3Cart admin panel, the store owner/admin enters XPayr API credentials. These credentials control the store's crypto payment acceptance. Vendor-specific XPayr registration is not required for the default central-admin payment model unless a future workflow explicitly enables vendor-owned checkout accounts."
    },
    {
      "topic": "Vendor Payments in the Default Model",
      "content": "In the default model, the site owner/admin configures XPayr and receives customer payments through the store checkout. Vendor amounts and commission are tracked in settlement reports. If instant vendor payout is required, Web3Cart can use a configured split/splitter flow for supported networks and tokens; otherwise vendor payout remains an operational settlement step."
    },
    {
      "topic": "Admin Payment Reports",
      "content": "Admin payment reports should show payment session/order reference, customer, vendor, gross amount, admin commission, vendor net amount, network, token, transaction status, settlement status, and timestamps. Reports should make it clear whether a vendor payout has already happened or still requires action."
    },
    {
      "topic": "Vendor Payment Reports",
      "content": "Vendor payment reports should show the vendor's own orders, gross amount, platform/admin commission, net receivable amount, payout wallet, payment status, and settlement/payout status. Vendors should not need access to admin-only XPayr secrets to understand their earnings."
    },
    {
      "topic": "Webhook Verification",
      "content": "XPayr webhook verification is critical. Web3Cart should verify the webhook signature/secret, match the order/session reference, prevent duplicate processing, and update order/license/settlement records only after trusted confirmation. Webhook endpoints should return 200 OK for valid processed events."
    },
    {
      "topic": "KYC and AML Settings",
      "content": "KYC and AML settings define transaction thresholds, verification requirements, risk checks, and review rules. These controls should be enforced by payment/order workflows and not remain display-only. Admins should use market-standard default thresholds but adjust them based on jurisdiction, risk appetite, and volume."
    },
    {
      "topic": "Contact Messages",
      "content": "Public contact modal submissions are stored separately from support tickets in the Contact Messages admin page. Messages have New, Read, and Closed statuses. Long messages are displayed as compact previews with a full-message expander. Contact messages are for pre-sales/public inquiries, while tickets remain for logged-in customer support."
    },
    {
      "topic": "Support Tickets vs Contact Messages",
      "content": "Support tickets require a logged-in user and are used for customer support workflows. Contact Messages are public landing-page inquiries submitted before login or purchase. These two systems should stay separate so public sales messages do not pollute authenticated support tickets."
    },
    {
      "topic": "Admin Sidebar Structure",
      "content": "The admin sidebar should avoid old landing editor links that no longer control the live MBOT-style Web3Cart landing page. Current useful admin sections include demo/contact messages, tickets, users, licenses, transactions, platform plans, XPayr settings, roadmap, plan features, changelog, and AI Knowledge Base."
    },
    {
      "topic": "Landing Page Theme",
      "content": "The official Web3Cart landing page uses the MBOT-style layout and visual system adapted to Web3Cart content. It uses the Web3Cart logo, blue accent colors from the logo, rotating hero words, updated pricing tabs, newsletter/contact/cookie components, and homepage/footer links suitable for Web3Cart. Do not use the old green/original landing module editor as the source of truth for the current live design."
    },
    {
      "topic": "Modular Product Direction",
      "content": "Web3Cart is being transformed toward a WordPress-like modular ecommerce script. The intended architecture supports themes, plugins, payment providers, feature gates, vendor modules, package limits, and future extensions without rewriting the core. XPayr remains the default payment provider."
    },
    {
      "topic": "Legacy Web3 and Smart Contract Cart Logic",
      "content": "Legacy Web3 cart-engine payment flows, mandatory on-chain installer registration, Networks/Currencies admin menus tied to the old payment model, and smart-contract-first checkout language should be removed from the default product surface. Contract components may exist for specific split or infrastructure needs, but the visible Web3Cart checkout experience should be XPayr-first."
    },
    {
      "topic": "Security Notes",
      "content": "Never expose XPayr API secrets, webhook secrets, signer private keys, or database credentials in public pages or client-side JavaScript. Store secrets server-side, mask them in admin UI, verify webhooks server-side, and keep empty secret form submissions from overwriting existing values."
    },
    {
      "topic": "Public Website Links",
      "content": "The Web3Cart public website should keep modern footer links for product, resources, AI guides, trust, and AI data pages. Product Hunt links are intentionally excluded from the current footer. Public pages should use the same header, footer, logo, and blue theme as the homepage."
    }
  ]
}