Marketplace policies

• Accounts, buying, selling, bidding, offers, messages, reviews, and store services are subject to eligibility, location, age, identity, payment, risk, and category rules.
• Sellers must describe the actual item, condition, included parts, ownership, price, delivery choice, return terms, and material defects accurately.
• Buyers must review the item, seller, total, delivery method, return limits, and binding nature of any bid or accepted offer before committing.
• Off-platform payment, credential sharing, false evidence, manipulation, harassment, and attempts to bypass marketplace protections are not allowed.

Not final legal terms. The operating organization must approve the contract parties, jurisdiction, eligibility rules, dispute process, liability limits, notices, and effective version.

No outcome is automatic. The final operator policy must define eligible transactions, exclusions, evidence, deadlines, remedies, appeals, and how store or provider delays are handled.

• The available return window and remedy can vary by item, condition, source, seller, delivery method, digital program, final-sale rule, and applicable law.
• A request may require photos, packaging, serial or certificate comparison, tracking, store intake, or other evidence relevant to the reason.
• A store may document a return or receive an approved item, but staff must not promise a refund unless the authoritative decision allows it.
• Approved refunds must account for the original payment methods, tax, discounts, points or credit, shipping or service treatment, and provider timing.

• Public profiles must not expose private identity, payment, address, device, employee, or security information.
• Account, order, support, risk, store, and workforce data must be limited by role, ownership, purpose, and retention rules.
• Necessary session and security storage must remain separate from optional personalization, analytics, and marketing choices.
• Customers need clear ways to review applicable choices and request access, correction, export, restriction, or closure when required.

Current public frontend

• Google Tag Manager and Google Analytics are disabled until a visitor allows optional analytics. When allowed, Google Analytics uses a cookie-based client ID and standard session, browser, device, and approximate-location data to measure reviewed public route and action names. The choice can be changed through the privacy choices control.
• Analytics does not receive contact-form contents, search text, raw URL queries or fragments, payment details, account data, or private employee and seller-authoring routes. Enhanced Measurement, advertising tags, marketing pixels, remarketing audiences, and ad-personalization are off. User-level analytics event data is configured for a two-month retention period.
• The separate contact workflow sends submitted contact details to a protected server-side Supabase service. Protected network-address and email anti-spam identifiers support abuse limits, and the contact record is scheduled for deletion after reaching 180 days.
• Resend delivers contact messages to the project team without publishing the receiving address. If analytics was allowed, only the selected topic is recorded after the server confirms a successful send; no name, email address, organization, or message is sent to analytics.

A final privacy notice is still required. It must identify the controller or operator, data categories, purposes, legal bases where applicable, recipients, retention, transfers, rights, cookies, contact method, and effective date.

• Core buying, selling, account, support, and store-service paths need keyboard access, visible focus, clear labels, useful errors, and understandable status updates.
• Text, controls, zoom, contrast, reduced motion, images, media, countdowns, charts, tables, and live updates require accessible alternatives.
• Customers must have a practical way to request accessibility help without giving up account or transaction security.

Listings must follow the approved category and location rules. Prohibited or restricted items may include unlawful goods, stolen property, unsafe or recalled products, counterfeit goods, unauthorized digital rights, regulated items without the required controls, dangerous materials, privacy-invasive devices, and content that violates intellectual-property or marketplace rules.

Rules vary. The operator must publish the current category, jurisdiction, shipping, age, identity, evidence, review, and enforcement rules before accepting listings.

• A location may offer a service only when its current capability, trained role, equipment, category, value range, capacity, and appointment rules allow it.
• A basic item or condition check is not an authenticity guarantee. Any badge must identify the source, scope, date, and limitation of the recorded work.
• A tamper-evident label helps document custody. It does not prove authenticity, ownership, condition, or protection by itself.
• Pickup, shipping, return intake, and custody changes require the correct item, order, employee scope, status, and release or handoff controls.

Participating locations only. No store or retail partner should be shown as participating until the authorized capability and inventory source confirms it.

• A digital item may appear only in a program explicitly authorized by its game, publisher, or platform for the item class, region, accounts, and transfer path.
• Ownership, transfer eligibility, buyer eligibility, delivery, failure, reversal, restrictions, and support must come from the official service.
• PUPMKT must never ask for a game password, recovery code, session cookie, account sale, direct code exchange, or another method that bypasses platform rules.
• Payment and seller proceeds remain tied to the official transfer result rather than a screenshot, message, animation, or seller claim.

• Checkout totals, tax, discounts, loyalty, fees, delivery, inventory, and eligibility must be recalculated by the authoritative services before commitment.
• Payment details and seller bank information belong in approved provider-hosted experiences, not ordinary PUPMKT forms or browser storage.
• Payment completion, refunds, disputes, holds, releases, and payouts require verified provider events, replay protection, audit, and reconciliation.
• Sellers must be able to understand estimated proceeds, fees, holds, reserves, adjustments, payout status, and the reason for a delay without exposing bank details.

Commercial decisions remain open. The operator must approve the merchant model, payment and payout providers, fee schedule, tax treatment, refund allocation, reserves, dispute process, settlement timing, and customer notices.

Current publication decision: keep this framework out of search results until operator-approved policy documents replace it. The page is useful for product review and implementation planning, but it is not consent-ready legal text.