APP MARKET REVIEW

This page covers code-facing and repository-verifiable requirements. App Dashboard, pricing-page setup, company profile, and listing-copy checks require separate dashboard or listing verification unless the user provides direct evidence.

Review Workflow

1. Identify the app surfaces first: billing model, auth/password usage, cookie usage, extension types, live-site surfaces, dashboard/setup surfaces, Wix business-solution dependencies, and webhooks.
2. Start with a report-only pass. List confirmed gaps, why they matter, and official Wix documentation links where available.
3. Do not mark a requirement as missing unless code, config, user statements, runtime behavior, or explicit absence supports that finding. Otherwise mark it Needs confirmation.
4. Before flagging secrets, config leakage, or similar security issues, verify the exposure is in a tracked file, the current diff, build artifacts, or another review-relevant surface. Do not treat a local-only workspace file by itself as repository exposure.
5. Do not infer app billing configuration from Wix Business Solutions Pricing Plans SDK/API usage. Business-solution Pricing Plans are for a Wix user selling plans to customers; App Billing/App Plans are for charging site owners for the app.
6. For any code-facing gap the user asks you to fix, implement the fix through the relevant wix-app extension reference first, then run validation.

Expected Output

Group findings by priority:

• Technical blockers: confirmed issues that are likely decline reasons.
• Should-fix items: high review risk, but not enough evidence to call them definite decline reasons.
• Nice-to-have hardening: improvements that reduce risk without blocking submission.
• Needs confirmation: requirements that cannot be verified from available evidence.

For each finding include:

• Applicability
• Evidence
• Impact
• Recommended fix
• Verification
• Confidence

Preserve qualifiers from the taxonomy and docs. Do not upgrade recommended, if applicable, or surface-specific guidance into a universal requirement.

Technical Checklist

Work through this before submission. Only applicable unchecked items are potential decline reasons.

Billing and Payments

• Not done: All in-app purchases route through Wix Billing unless Wix explicitly approved the app as Partner Billed; approved Partner Billed apps report charges through External Billing Events.
• Not done: No external purchase buttons, links, QR codes, license keys, or other custom mechanisms unlock paid content.
• Not done: Full checkout flow tested for every plan.
• Not done: If the app has premium features, there is a clear in-product upgrade link or CTA.
• Not done: Credits do not expire.

Setup and Access

• Not done: App configuration URLs are public and do not use localhost.
• Not done: A usable setup/settings UI exists. Embedded Script apps need a dashboard page.

Instance and Identity

• Not done: instanceId is used for user/site identification, not cookies or sessions.
• Not done: Billing is separated per instanceId.
• Not done: Auto-login works when the user reopens the app from Manage Apps.
• Not done: Site duplication is handled through originInstanceId: treat the copied site as a new install linked to the original and copy applicable settings/content where possible.
• Not done: Required Wix apps, such as Stores or Bookings, are checked through Get App Instance and surfaced clearly if missing.
• Not done: If the app supports Wix Stores catalog data, both Catalog V1 and Catalog V3 are supported. See STORES_VERSIONING.md.

Webhooks

• Not done: Any implemented webhook returns HTTP 200 on successful receipt.
• Not done: App Installed and App Removed webhooks are considered for lifecycle provisioning and cleanup. They are recommended, not a universal hard requirement.

Permissions

• Not done: Only minimum required permissions are requested.
• Not done: Redundant or overlapping permissions are removed.

Security

• Not done: Signed instance verification happens server-side before trusting user/site context.
• Not done: Signed-instance-backed edit/save actions validate signDate; stale signatures require refresh before continuing.
• Not done: All endpoints are HTTPS with no HTTP fallback.
• Not done: In-product flows avoid alert() and confirm(); use Wix modal, inline status, toast, or another surface-appropriate feedback pattern.
• Not done: XSS protection covers all user input fields.
• Not done: Passwords are stored as salted hashes, such as bcrypt or SHA-256 with a unique salt per password.
• Not done: Password reset uses an expiring email link and never sends raw passwords.
• Not done: Sensitive data is not stored in cookies and is encrypted where needed.

UX and Display

• Not done: In-product flows use Wix popup/modal patterns where appropriate. OAuth and documented Wix pricing-page upgrade CTAs are exceptions.
• Not done: First install shows realistic demo data, not placeholder lorem ipsum.
• Not done: Ads are not shown to site visitors unless ad display is the app purpose and the app has the required permits.
• Not done: Review prompts, if present, are non-blocking and do not force or incentivize reviews.
• Not done: Plugin content relates to the host app’s core functionality.

Performance and Quality

• Not done: Startup and load times meet App Market expectations.
• Not done: No known bugs or console errors remain.
• Not done: Supported-browser matrix is tested.
• Not done: Live-site extensions are responsive across screen sizes.
• Not done: Dashboard surfaces support the required desktop layout.

SEO, Accessibility, and Localization

• Not done: Widget components do not render <h1> tags.
• Not done: User-facing images expose alt-text customization where applicable.
• Not done: App output is UTF-8 encoded.
• Not done: Website components meet accessibility standards.

Cookie Consent

• Not done: Cookie consent workflow activates/deactivates cookies per visitor preferences.

Implementation Notes

Payment and Billing

All apps that collect money must route payments through Wix Billing unless Wix granted a formal exception. Approved Partner Billed apps still need to report charges/refunds through External Billing Events and submit revenue reports.

App Instance and Identity

The instanceId uniquely identifies an app installation on a site. Use it for identity, app data, and billing. Site duplication creates a new instanceId; use originInstanceId to relate the copied site to the original.

Webhooks, Setup, and Permissions

Security

UX, Performance, and Accessibility

Technical Review Taxonomy

Use these IDs for traceability when mapping findings to review feedback.