Needs clarification

"Paddle CLI forwarding webhooks to localhost" → whatever Swich's equivalent local-testing tool is (unconfirmed — Swich may not have a CLI-forwarding tool the way Paddle did; may require a tunneling tool like ngrok pointed at /webhooks/swich instead — Needs clarification).

"My payout hasn't arrived" — support checks Payout status (05. Payments) and Swich's own payout timeline before assuming something's broken; expected window unconfirmed pending real Swich integration — the original "2–7 day bank transfer window" figure was a working assumption, not Swich-verified (see FEATURE_LIST.md §7.1's Needs Clarification)

Genuinely new question this raises, not just a rename: SellVia's billing through Swich isn't purely card-based — the doc above assumes a Paddle-style card chargeback flow specifically. Swich's checkout also offers bank transfer, JazzCash, and EasyPaisa, and it's unconfirmed whether "chargeback" in the card-network sense applies to those methods at all — a bank transfer or mobile-wallet payment typically doesn't have…

How to read this document: SellVia's docs record decisions chronologically, with later "Update" sections superseding earlier text in the same file. This list reflects the latest resolved state as of the most recent updates (through 2026-08-23), not the original/superseded framing. Where a doc contains stale, unresolved, or contradictory statements, this is marked "Needs clarification" rather than guessed at. See SITE…

Edge cases: Application-rejected notification content unspecified (open question — Needs clarification); real-time vs. digest cadence for "sale made" unspecified (Needs clarification); exact merchant "milestone reached" thresholds undefined (Needs clarification).

Creator↔Offer matching | Ranks offer discovery results by embedding similarity on top of existing category/commission filters | Creator discovery/browse screen | Post-MVP per some docs, but described as an "initial AI level" item elsewhere — Needs clarification on MVP vs. post-MVP timing |

Disclosure nudge | Fixed, legally-reviewed FTC-style disclosure template shown at link-generation time | Creator "Get Link" moment | Deliberately templated, NOT LLM-generated (legal text) — Pakistan-specific disclosure norms not yet reviewed, Needs clarification |

Expected frontend behavior: Nav: logo left, links center/right ("How It Works," "For Businesses," "For Creators"), single "Join Waitlist" CTA — no dropdowns, no mega menus. Zeroed-metric device persists into early product messaging. Copy should reflect Pakistan-only scope once product messaging catches up to the 2026-08-23 revision — Needs clarification on whether the current live site copy needs an update pass.

API/backend dependencies: Waitlist signup endpoint (implied, not explicitly specified in Endpoint Specifications — Needs clarification).

Expected frontend behavior: Gate: an Offer cannot go draft → live until this is complete. Whether this is an embedded Swich widget (like the old Paddle Checkout iframe) or a redirect flow is Needs clarification — Swich's actual integration pattern isn't confirmed yet.

Edge cases: Needs clarification — the exact retry/escalation policy for a failed billing-cycle charge (the old "3 failed Paddle billing attempts over 3 days" rule needs re-mapping against Swich's own failure-webhook behavior, not yet done). Flagged in MVP Scope's Still-Open Items.

Edge cases: Exact Shopify app-install path (public Shopify App Store listing vs. a private/custom app SellVia distributes directly) is explicitly undesigned — Needs clarification, flagged in MVP Scope's Still-Open Items.

Edge cases: Onboarding-incomplete gate is resolved as hard-block (unchanged). Whether any Pakistani-tax-equivalent form (an FBR-relevant declaration, if any) is collected here is Needs clarification — Swich, like the bank-transfer default before it, is not confirmed to auto-collect this the way Paddle's onboarding did (Swich is a processor, not a Merchant of Record — see [Payments/Tax Considerations]).

Edge cases: Paused offers keep honoring in-flight attribution within the 30-day window, accept no new applications; ended offers stop attributing new clicks immediately but honor pre-end clicks within the window; high-commission/high-risk offers require Admin vetting before going live (thresholds undefined — Needs clarification); product image auto-fetch from a URL is a deferred v2 convenience — manual upload only fo…

Edge cases: Rejected applicants cannot resurrect the old application, only submit a new one; whether merchants see aggregate creator performance platform-wide or only the applicant's own submitted stats is unresolved (Needs clarification); self-dealing applications blocked server-side before reaching this queue.

API/backend dependencies: No explicit endpoint named in Endpoint Specifications — Needs clarification ("UI/API for how a merchant actually submits a credit request — not yet designed").

Expected frontend behavior: Post-MVP: AI similarity ranking layered on top of filters (timing unresolved — Needs clarification).

Expected frontend behavior: pending / approved / rejected states clearly shown; whether/how a rejection reason is communicated is unresolved (Needs clarification).

API/backend dependencies: Scoped read of applications (no dedicated endpoint explicitly named beyond the offer-scoped one — Needs clarification on a creator-facing "my applications across all offers" endpoint).

Edge cases: Whether engagement_rate is self-reported vs. platform-calculated is an open fraud-relevant question — Needs clarification before deciding if this field is editable or read-only/derived.

Edge cases: Exact vetting trigger thresholds undefined — Needs clarification. - Source: [Operations/Admin Panel], [Business Logic/Business Rules].

Edge cases: No formal appeals process designed yet (handled case-by-case via support) — Needs clarification. - Source: [Operations/Admin Panel], [Operations/Moderation], [Security/Session Management].

Important states: SellVia absorbs a merchant's first 5 lost disputes (lifetime counter) — this rule was written for a Paddle-chargeback world; whether it still applies as-is under Swich is Needs clarification.

API/backend dependencies: Not explicitly named in Endpoint Specifications — Needs clarification. - Permissions/roles: Admin only.

Edge cases: Who submits any dispute evidence, and to whom (SellVia vs. Swich vs. Swich-on-SellVia's-behalf), is unresolved — Needs clarification.

API/backend dependencies: Endpoint not explicitly named — Needs clarification; likely a scheduled job comparing SellVia's ledger against Swich's transaction-list API once that's integrated.

Edge cases: Beachhead niche/vertical *within* Pakistan (beyond the geography resolution itself) still undecided — Needs clarification.

Edge cases: Whether this ships MVP or post-MVP is an explicit open call — Needs clarification. - Source: [Operations/Founder AI Command Console], [Operations/Live Production Access for Support (Command Console)], [Database/Audit Log Design].

Relevant screens: Likely part of User Management detail or the AI Command Console, not necessarily a separate screen — Needs clarification on whether this needs dedicated UI.

Expected frontend behavior: Clear, specific error/status copy so common cases (e.g., normal Swich settlement/payout processing window) don't look like failures. Exact expected window under Swich is Needs clarification — the original "2–7 day" figure assumed Paddle's own rail and hasn't been re-confirmed against Swich's.

## Feature-Level "Needs Clarification" Summary

Responsive: Web-responsive only for MVP (no native mobile app). 12-column desktop grid per Technical Architecture/Frontend Architecture; specific breakpoints not documented — Needs clarification.

API dependencies: Waitlist submission endpoint — Needs clarification (not explicitly named in API/Endpoint Specifications).

Related docs: Security/Password Policy (open question: mandatory for Merchants before launch — Needs clarification).

Open item: Whether this is an embedded Swich widget or a redirect flow is Needs clarification — Swich's actual integration pattern isn't confirmed yet (see FEATURE_LIST.md §2.2).

Open item: Exact Shopify app-install path (public App Store listing vs. private/custom app SellVia distributes directly) is undesigned — Needs clarification.

Related docs: Edge Cases/User Edge Cases, Payments/Tax Considerations (whether any Pakistani-tax-equivalent declaration is collected here is Needs clarification — Swich is a payments processor, not a Merchant of Record like Paddle was, so it isn't confirmed to auto-collect this).

Open item: Rejection-reason display — Needs clarification.

Main UI sections: Niche, audience size, engagement rate (editability depends on self-reported-vs-calculated resolution — Needs clarification).

Needs clarification: whether onboarding is a dedicated route sequence or embedded as steps inside the Merchant/Creator dashboard's first-run state — not specified in the docs.

For an account holding both Merchant and Creator roles, UX/Navigation recommends "a role switcher rather than merging both role's navigation into one confusing menu." No specific route pattern is given. Two reasonable implementations, neither confirmed in the docs — Needs clarification:

This closes the "Needs clarification" item carried in FEATURE_LIST.md §0.5 and SCREEN_INVENTORY.md's global notes — both should be read as resolved now.