Athenian Swap Shop is a peer-to-peer exchange marketplace for the Athenian platform. It gives members a structured way to list products or services, discover trade opportunities, make offers, negotiate counteroffers, balance trade value with cash or store credits, and complete the accepted exchange through fulfillment and feedback. Instead of treating a swap like an informal message thread, Swap Shop keeps the listing details, offer terms, settlement obligations, fulfillment status, trader reputation, and resolution history connected to one managed workflow.

Most ecommerce tools are built for one-way purchases where a buyer pays a store and receives a product. Swap Shop handles the more complicated reality of two-sided trading: each participant may contribute goods, services, credits, cash, shipping coverage, or schedule commitments. It reduces the need for scattered messages, manual spreadsheets, and staff follow-up by giving both members and operators a clear path from discovery to negotiation, settlement, fulfillment, feedback, and resolution.

No. A classified board mainly publishes listings and leaves the actual exchange to private coordination. Swap Shop adds the transaction layer around those listings: searchable marketplace discovery, wanted-post demand capture, structured offer and counteroffer threads, accepted-term review, checkout and settlement handling, shipping or service milestones, reminders, trader reputation, feedback, analytics, and resolution workflows. The goal is to make peer-to-peer trading behave like a managed marketplace rather than a loose collection of posts.

Swap Shop is for marketplace members who want to trade products, exchange services, make credit-backed offers, or use cash adjustments to balance a deal. It is also for marketplace operators who need to monitor activity, reduce friction, and keep trades accountable after the initial match. The feature set fits communities where trust, fulfillment, value balance, and operational visibility matter as much as simple listing discovery.

Users create a listing from the front-end Swap Shop listing form. They can enter the core listing details, including title, description, estimated value, product or service type, category path, tags, desired trade items, photos, fulfillment preferences, and evidence details such as condition notes, serial or model numbers, provenance, and an optional evidence video link. The form is designed to capture both what the member is offering and what would make a good trade fit, so the listing can support search, matching, trust review, and negotiation.

Users can create product listings, service listings, and wanted posts. Product listings focus on item details such as condition, photos, estimated value, tags, package dimensions, and shipping availability. Service listings focus on scope, location, radius, duration, schedule notes, and service-area eligibility. Wanted posts capture demand and help trigger matches, but they are not directly exchanged until the user has a real offer listing available.

A wanted post is a way for a member to say what they are looking for before a matching offer exists. It can describe desired items, services, categories, tags, or trade keywords, helping the marketplace surface unmet demand and create future matching alerts. Wanted posts are especially useful in community marketplaces because they help other members understand what people value, but the actual swap still requires a real product or service listing to be proposed in an offer.

Yes. Users can save listing drafts before publishing, which is useful when they still need to add photos, refine the description, check package details, or gather supporting evidence. Drafts let members prepare a stronger listing without making incomplete information public. When the listing is ready, it can be published or submitted according to the marketplace review settings.

A listing detail page can show the title, listing type, product or service classification, status, estimated value, cash or credit preference, condition or service scope, fulfillment method, active thread count, location or service radius, schedule notes, serial or model information, provenance notes, evidence video links, tags, wanted items, evidence status, matching viewer listings, and a trader snapshot. This gives the viewer enough context to evaluate fit, trust, value, and fulfillment expectations before they open a negotiation.

Yes. Users can upload a featured image and supporting gallery images for a listing. Photos help other traders evaluate condition, completeness, and fit before making an offer. Product listings can also be checked against evidence expectations, so missing photos or supporting details can be surfaced before or after publication depending on the platform rules.

The evidence check helps users and operators understand whether a listing has enough supporting information for a trustworthy trade. Depending on category and listing rules, evidence can include a minimum number of images, a condition note, serial or model information, provenance notes, or an optional video link. Higher-risk categories can require stronger proof, while service listings can rely more on scope, location, scheduling, and provider details.

Yes. Product listings are built around condition, photos, package details, shipping options, and physical fulfillment. Service listings are built around scope, location, radius, duration, schedule notes, and completion approval. This lets Swap Shop support both physical trades and service exchanges without forcing every listing into a shipping-based checkout model.

Users can browse the public marketplace, search by keyword, and filter results by product or service type, category path, estimated value, shipping availability, and sort order. Logged-in users can also use dashboard areas for saved alerts, suggested matches, and listings that overlap with what another trader wants. This gives members both active search tools and passive discovery through matching signals.

Marketplace filters can include offer type, category path, value range, shipping option, and sort order. Common sort options include newest, value high to low, value low to high, and title A-Z. These filters are designed to make a large swap marketplace easier to scan without hiding important trade context such as fulfillment method or listing type.

“Can ship” means the owner has marked a product listing as shippable and can provide package details for fulfillment. A shippable listing may be eligible for shipping estimates, selected rates, label generation, and tracking workflows after an offer is accepted and settlement clears. Listings can also be local only, and service listings usually use service-area and scheduling rules instead of shipping.

A swap starts when a logged-in user proposes an offer against another user’s open listing. The proposer can include one or more of their own open listings, store credits when available, cash adjustments when allowed, shipping payer choices, and a proposal message. Swap Shop creates a dedicated negotiation thread so both participants can review the current terms and any later revisions in one place.

Yes. Swap Shop supports offers where either side contributes multiple listings, as long as the selected listings are open and belong to the correct participants. This is useful when one higher-value item is being exchanged for several smaller items, or when a product and a service are combined to make the trade feel balanced. The accepted terms preserve the selected listing sets so everyone can review exactly what is included.

Yes, when the credit ledger is active and the target listing supports credit-based offers. A user can make a credit-only bid or use a credit-based Buy It Now option when that mode is enabled for the product listing. Credit-only flows are intentionally controlled by listing settings and platform capability so the marketplace can avoid unsupported settlement promises.

Yes. If a trade is uneven, either side can include a cash adjustment when the listing preferences and marketplace settings allow it. Cash is treated as a balancing obligation, not as a replacement for the listing value itself. Once accepted, cash obligations can be represented through WooCommerce settlement orders so payment status stays connected to the swap workflow.

Yes, when the Athenian Store Credits integration is active. Credits can be added to offer terms, compared against cash-equivalent value for balance review, reserved after acceptance, transferred after successful completion, or released if the trade is canceled under the platform rules. This gives the marketplace a flexible value-balancing tool without requiring every adjustment to be paid as cash.

Yes. Swap Shop supports threaded negotiation with offers and counteroffers. When a recipient sends a counteroffer, the prior pending offer is marked as countered and the new proposal becomes the current offer to review. This keeps the active terms clear, avoids conflicting versions of the deal, and gives both sides a record of how the negotiation changed.

Yes. The sender of a pending offer can withdraw it while the negotiation is still open. Withdrawing closes that pending proposal so the other participant is not left reviewing stale terms. Once a swap has moved into accepted settlement or fulfillment stages, withdrawal is no longer the normal path and the trade follows cancellation or resolution rules instead.

Yes. The recipient of a pending offer can decline it. Declining marks the current offer as declined and closes the active negotiation thread for that proposal. This gives the sender a clear outcome and prevents the listing from being tied up by an offer the recipient does not want to pursue.

Yes. Swap Shop supports proposal messages and swap message threads so participants can discuss details while keeping the context tied to the trade. Users can review offer notes, message history, current terms, and active swap status from the dashboard. This helps avoid losing important details in unrelated inbox conversations.

Yes, when messaging is available through the connected user system. A listing page can show a Message Trader option so a user can ask about condition, timing, service scope, shipping expectations, or trade fit before proposing terms. Messaging is a helpful pre-negotiation step, but the actual trade still needs to be captured as a structured offer before it can move through settlement and fulfillment.

No. Swap proposals are designed for member-to-member exchanges, so a user cannot target their own listing. This prevents circular trades, accidental self-negotiation, and unreliable marketplace metrics. Users can still manage, edit, close, or relist their own inventory from their listing and dashboard tools.

A listing may be unavailable if it is not open, is reserved, has already been swapped, is closed, is a wanted post, or already has an active offer or swap thread. Swap Shop pauses conflicting proposals so the same item is not promised in multiple negotiations at once. Once the active thread is closed or the listing becomes open again, it may become eligible for new proposals depending on its status.

Swap Shop helps users compare the net outcome of a trade rather than only comparing listing prices. It can consider the estimated value of each side’s listings, credits offered, selected shipping costs, and shipping coverage when one side pays for the other side’s shipment. The result gives members clearer guidance about whether the exchange feels balanced and what kind of adjustment, such as credits, cash, another listing, or shipping coverage, may make sense.

No. A listing’s estimated value remains separate from shipping. Shipping can still affect the fairness of the trade because it is a real cost or concession, but it does not change what the item or service is worth. This separation makes the terms easier to understand: listing value, credit value, cash adjustment, shipping responsibility, and actual payment due all remain distinct.

Credits are converted to a cash-equivalent value for trade-balance purposes. The current default model uses 1 USD = 1,000 credits unless a listing or credit-market setting provides a different rate. This lets credits participate in balance calculations while still being handled by the credit ledger instead of being charged as cash through checkout.

No. Credits are handled through the store-credit ledger. WooCommerce settlement orders handle cash obligations and applicable shipping or label fees, while credits are reserved, transferred, or released through the credit system. Keeping those paths separate avoids treating credits like a normal cash charge and helps preserve accurate ledger history.

After an offer is accepted, the swap moves into settlement review. The accepted terms are copied onto the swap, applicable credits are reserved, involved listings are reserved, and both participants review the trade, cash or credit settlement, shipping responsibility, and fulfillment gates before the swap proceeds. This creates a clear checkpoint between negotiation and execution so neither side begins shipping or service work before the accepted obligations are visible.

SwapShop Checkout is the review and settlement step for an accepted trade. It shows the accepted trade terms, credit or cash settlement, shipping responsibility, payment status, and fulfillment gates before physical shipping or service scheduling begins. It works alongside WooCommerce where cash or shipping payments are needed, but it remains swap-specific so participants understand the exchange rather than seeing only a generic cart order.

No. Some accepted swaps may have no cash due if the listing values are balanced, credits cover the adjustment, or no shipping cost is assigned to that participant. Even then, a participant may still need to confirm checkout, settle credits, or acknowledge fulfillment responsibilities. The important point is that payment, credit settlement, and fulfillment readiness are all checked before the trade advances.

Cash adjustments can be represented through WooCommerce settlement orders. If one side owes a cash amount or an assigned shipping or label fee, Swap Shop can create the operational order needed to collect that payment and track whether it has cleared. Cash adjustments are kept separate from credit transfers and listing value so the final trade terms remain understandable.

When OwlPay is available, cash-balanced swaps can create held payouts. A payout can remain held until the trade completes, and it can be blocked if a resolution case opens or a risk condition needs review. This helps protect the marketplace by preventing premature release of funds when fulfillment, delivery, or participant approval is still unresolved.

Yes. When store-credit rewards are enabled, the platform can reward successful participants after completed swaps. Rewards can encourage marketplace participation, reinforce good fulfillment behavior, and create a reason for members to keep trading inside the ecosystem. Reward behavior depends on the store-credit configuration and marketplace policy.

For product swaps, Swap Shop can estimate shipping, track who is responsible for each shipment, create label artifacts, email label details, and move the trade through physical fulfillment milestones. The workflow can include ready to ship, labels sent, in transit, out for delivery, delivered, received, and completed states. The default label workflow can be connected to live carrier logic by the platform when production shipping integrations are ready.

By default, each side pays for their own outgoing shipment. During negotiation, the offer can specify a different payer map, such as one participant covering the other participant’s shipment or one participant covering both shipments. Those choices matter because shipping is both an actual payment obligation and, when cross-paid, a possible value concession in the overall trade.

Yes. If one participant covers the other participant’s shipping, that coverage can help balance the overall exchange. For example, a participant offering a slightly lower-value item might also pay the other side’s shipping to make the deal feel more even. Swap Shop keeps that shipping coverage separate from the intrinsic listing value so the trade remains transparent.

Shipping labels are the fulfillment artifacts used to move product-based swaps forward after settlement clears. Swap Shop can generate label artifacts and email label details to participants when the trade is ready for fulfillment. The built-in label generation can act as a stub in staging or be replaced by a live carrier workflow through platform integration.

Yes. Swap Shop supports tracking states such as label created, in transit, out for delivery, delivered, exception, returned, and unknown. Tracking can be synced on a schedule, and a live carrier lookup can be connected by the platform. These updates help members understand where each shipment stands and help operators identify trades that need attention.

Shipping exceptions are surfaced in the swap status and operational dashboards so they are not buried in messages. Participants can use the trade context to coordinate next steps, and staff can review the shipment, settlement, and participant history if the issue escalates. When needed, an eligible swap can move into a resolution case so payout or completion decisions can be held until the problem is reviewed.

A physical swap completes when required settlement is cleared and each participant who expects delivery has marked the incoming shipment as received, or when the applicable fulfillment rules otherwise mark the trade complete. Completion can trigger downstream actions such as feedback prompts, credit transfers, rewards, and payout release depending on the active integrations. This ensures the trade does not end simply because an offer was accepted; it ends when fulfillment is actually confirmed.

Yes. Swap Shop supports service-based listings and service exchanges. Users can publish services, define service areas, describe schedule requirements, negotiate service swaps, and move accepted service trades through scheduling, approval, in-progress, and completion-confirmation steps. This makes service exchanges manageable without forcing them into a package-and-shipping workflow.

After settlement clears, a participant can propose a service appointment with a start time, end time, location, and notes. The other participant can review and approve the proposed schedule before the service moves forward. This approval step helps both sides agree on timing, location, and scope before work begins.

Service swaps can move through service scheduling, schedule pending, scheduled, service in progress, completion pending, and completed. These statuses show whether the trade is waiting for a proposed appointment, schedule approval, active work, completion confirmation, or final closure. They also help operators identify which service swaps need participant action.

Yes. After service work starts, one participant can request completion and both sides can approve the completion request. This gives the service provider and recipient a shared checkpoint before the swap is marked complete. It also creates a clearer record if a resolution case is needed later.

Usually no. Service listings focus on location, service radius, schedule, scope, and completion approval instead of package details and tracking. However, a mixed trade can still include physical fulfillment if product listings are part of the accepted terms. In those cases, the swap may include both service milestones and physical shipping milestones.

The Swap Shop dashboard is the logged-in user’s control center for swap activity. It can show profile and trust information, current offers, messages, active swaps, listings, alerts, suggested matches, feedback, and recent trading analytics. The dashboard is designed to help members act on what needs attention without opening every listing or thread one by one.

Users can review inbound and sent offers, follow negotiation messages, manage active swaps, check settlement and shipping status, edit or monitor listings, review saved alerts, view suggested matches, and see recent feedback. Dashboard filters and counts help separate negotiations, fulfillment tasks, listing management, and reputation activity. This keeps ongoing swap work organized even when a member has several active listings or trades.

Saved alerts are watch rules that help users track listings matching their interests. A member can use alerts to stay aware of new opportunities without searching the marketplace repeatedly. Wanted posts can also create matching signals, helping the marketplace connect future supply with existing demand.

Suggested matches are potential trade candidates based on listing overlap, categories, tags, wanted terms, and trade fit. They help users find relevant opportunities that may not appear obvious from a simple keyword search. Matches can also highlight a viewer’s own open listings that appear to fit what another trader wants.

Yes. Users can search across swaps, listings, and members from the dashboard. They can also filter by swap status or listing status to focus on negotiations, payment, service scheduling, shipping, completed trades, cancelled trades, drafts, open listings, reserved listings, or swapped listings. This is especially useful for active traders managing multiple threads at once.

Common listing statuses include draft, open, reserved, swapped, and closed. Draft listings are still being prepared, open listings can receive proposals, reserved listings are tied to an active accepted or in-progress trade, swapped listings have been completed, and closed listings are no longer active. These statuses help prevent the same item from being committed to multiple trades.

Common swap statuses include negotiating, payment pending, ready to ship, labels sent, in transit, service scheduling, schedule pending, scheduled, service in progress, completion pending, completed, and cancelled. These statuses show where a swap sits in the lifecycle and what kind of action may be required next. They also help operators separate negotiation friction from payment, shipping, service, or aftercare issues.

Swap Shop builds trust by surfacing trader context before and after a deal. Listing pages and profiles can show trust score, fulfillment score, completed swap count, average rating, feedback count, badges, category strengths, live listings, and risk notes when available. It also supports evidence checks, fulfillment tracking, feedback, and resolution history so trust is based on marketplace behavior rather than only profile claims.

The trader snapshot is a compact trust view shown on listing pages. It can summarize the listing owner’s tier, trust score, fulfillment score, completed swaps, feedback count, and average rating. This helps a viewer evaluate whether they want to message, make an offer, or review more profile details before committing to a negotiation.

A trader profile is a public-facing view of a member’s trading reputation and live marketplace activity. It can show trust summary, completed activity, active trades, open listings, wanted posts, category strengths, recent feedback, and risk notes. The profile helps users understand both the trader’s history and what they are currently offering or seeking.

Yes. After a completed swap, participants can leave ratings and written feedback. Feedback helps shape the trader’s public reputation and gives future trade partners more context about communication, accuracy, fulfillment, and overall reliability. It also gives operators a stronger signal for marketplace health and risk review.

Yes. Feedback can have moderation states such as published, flagged, or reviewed depending on platform rules and admin review. Moderation helps the marketplace handle inappropriate, inaccurate, or disputed feedback while still preserving accountability. Flagged feedback can also notify staff when an exchange may need closer review.

Users can open a resolution case for eligible swaps. The case keeps the issue connected to the swap history, offer terms, settlement state, shipment status, service milestones, feedback, and participant records. This gives staff and participants a clearer record for review, rather than trying to reconstruct the problem from disconnected messages.

The resolution center is a logged-in case-management view for disputes and trade issues. Participants can monitor open cases, case updates, payout holds, and dispute context from one place. It gives the marketplace a structured aftercare workflow for problems that cannot be solved through normal negotiation or fulfillment steps.

Yes. If OwlPay payout handling is active, a resolution case or staff review can block payout release until the issue is resolved or closed. This prevents funds from being released while delivery, service completion, condition, or participant approval is still in question. Once the case is resolved according to platform policy, payout status can move forward again.

Yes. Swap Shop can send emails for listing creation, new offers, received messages, accepted offers, labels ready, feedback submitted, flagged feedback, opened resolutions, payout blocked or released, matching alerts, and lifecycle reminders. These notifications help participants keep up with trade activity even when they are not actively watching the dashboard. Operators can also use event-level email settings to tune the communication experience.

Swap Shop can send reminder emails for stalled offers, unpaid settlement, pending shipment confirmation, shipment exceptions, and missing feedback. Reminders reduce manual follow-up and help trades keep moving through the lifecycle. They are especially useful in marketplaces where users may not log in every day but still need to respond to time-sensitive trade steps.

Yes. Email templates are centralized and can be overridden by the site’s active theme. Brand settings such as sender identity, accent color, logo URL, and footer copy can be configured from Swap Shop settings. This lets marketplace operators keep transactional emails consistent with the larger Athenian brand while still using event-specific copy for offers, labels, feedback, resolutions, and reminders.

Operators can view marketplace activity through admin screens, dashboards, analytics, trader-risk views, resolution controls, swap status, settlement status, payout status, shipment status, feedback status, and operational queues. This visibility helps staff understand where trades are getting stuck, which participants may need review, and how marketplace liquidity is developing. It also creates a practical operating layer around what would otherwise be informal peer-to-peer activity.

Swap Shop can track listings created, offers sent, offers accepted, completed trades, cash volume, resolution cases, shipment exceptions, acceptance rate, open listings, active swaps, and other marketplace lifecycle metrics. These analytics help operators understand supply, demand, conversion, friction, fulfillment performance, and risk. When Athenian Data Intelligence is active, those events can feed broader reporting and trend analysis.

Yes. The trader-risk admin console helps staff identify high-risk, watchlist, and trusted members from one place. Trader profiles, feedback history, resolution history, fulfillment score, trust score, and payout state can all support risk review. This gives operators a more disciplined way to monitor marketplace behavior without relying only on anecdotal reports.

Yes. Admin resolution controls let staff move cases through statuses such as open, under review, awaiting user, resolved, and closed. Staff can add admin notes, review related payout or settlement status, and keep the case attached to the underlying swap. That makes dispute handling more auditable and easier to coordinate than resolving issues in separate email or chat threads.

Yes. Some integrations are optional. WooCommerce is the settlement backbone, while Store Credits, OwlPay, Athenian Social Users Core, Athenian Data Intelligence, and Athenian WC Dropship add deeper credit, payout, identity, analytics, or fulfillment-origin capabilities when available. Swap Shop is designed to degrade sensibly so core exchange workflows can still exist even when optional ecosystem features are not active.

WooCommerce provides the operational order and payment infrastructure for settlement. Swap Shop can use WooCommerce orders to represent cash adjustments, shipping charges, label fees, and payment status without pretending the swap is a normal one-way store purchase. This lets the marketplace use familiar commerce infrastructure while preserving the two-sided trade context.

Athenian Store Credits adds credit-based bidding, credit balancing, credit reservation, credit transfer, credit release, and optional rewards for completed swaps. It gives the marketplace a non-cash value layer that can make trades more flexible and easier to balance. It also keeps credit activity in a ledger instead of mixing it into WooCommerce cash orders.

OwlPay can manage held payouts for cash-balanced swaps and release or block payouts based on completion and resolution state. This is useful when a participant is owed cash after a successful exchange but the marketplace needs to wait for fulfillment confirmation before releasing funds. If a dispute opens, payout can remain blocked until the issue is reviewed.

Athenian Social Users Core connects swap activity to richer person records, messaging, profile identity, trader trust context, and member-level reputation surfaces. This helps the marketplace feel like a trusted member network rather than an anonymous listing board. It also gives Swap Shop stronger identity and relationship data for trader profiles, messages, and trust signals.

Athenian Data Intelligence can receive swap lifecycle metrics and provide trend-backed analytics for marketplace health, liquidity, risk, and operational pressure. It helps operators move from anecdotal marketplace management to measurable insight around listings, offers, completions, cash volume, shipment exceptions, and resolutions. Local fallback analytics can still render when the integration is unavailable.

Athenian WC Dropship can provide vendor shipping-origin data as a fallback for label and fulfillment workflows when that data already exists in the platform. This reduces duplicate setup for merchants or vendors that already maintain shipping origin details elsewhere in the Athenian ecosystem. It is especially useful when Swap Shop needs fulfillment context for product-based exchanges.