Last updated: July 2026

This page defines the technical, security, functional, packaging, documentation, licensing, compatibility, presentationand maintenance requirements for scripts submitted to WPBay. It applies to new products, resubmissionsand updates across all current WPBay script categories:

• AI & Machine Learning
• APIs & Integrations
• Automation & Scraping
• C# / .NET
• Concrete CMS Add-ons
• CSS
• Database Tools
• Drupal Modules
• HTML5
• Java
• JavaScript
• Joomla Extensions
• Laravel Apps
• Magento Extensions
• Miscellaneous
• Mobile Scripts
  • Android
  • Flutter / React Native
  • iOS
• Moodle Plugins
• OctoberCMS Plugins
• Odoo Apps
• OpenCart Extensions
• PHP Scripts
• PrestaShop Plugins
• Python
• Ruby
• Security Scripts
• Shopify Apps
• TYPO3 Extensions

These are minimum marketplace requirements, not optional suggestions. Meeting them does not guarantee approval. WPBay also evaluates whether the product provides genuine buyer value, has a professional implementation, can be installed or integrated by its intended customerand is presented honestly.

Approval is not a security, privacy, accessibility, performance, app-store, regulatory or legal certification. It does not transfer responsibility from the seller. The seller remains responsible for the submitted code, dependencies, data handling, licenses, external services, platform policies, maintenance, support commitmentsand all claims made on the product page.

This is the authoritative technical standard for script products on WPBay. Older WPBay articles remain useful as background guidance, but this page takes precedence when an older example or recommendation conflicts with it.

How to read these requirements

The following terms are used deliberately:

• Must, required and must not describe approval requirements. A violation can block approval.
• Should describes an expected practice. A different implementation may be accepted when it is technically sound and clearly justified.
• May describes an optional practice.
• Blocker means an issue that must be corrected before approval.
• Recommendation means an improvement that normally does not block approval by itself.
• Host platform means the CMS, framework, runtime, application, mobile operating system or external service that the product extends or requires.
• Production package means the files a buyer actually installs, deploys, builds or integrates.
• Source package means the readable first-party source, dependency declarations, build configurationand other material needed to review and maintain the product.

WPBay reviews scripts against five broad standards:

1. Technical quality: Is the code secure, maintainable, appropriately structuredand consistent with the conventions of its actual ecosystem?
2. Real-world readiness: Can the intended buyer install, configure, build, run, updateand recover the product using the supplied package and instructions?
3. Honest presentation: Do the title, category, screenshots, demo, compatibility information, feature claimsand documentation accurately describe what is delivered?
4. Ownership and licensing: Does the seller have the right to sell every included componentand are the host platform and third-party licenses respected?
5. Responsible operation: Does the product handle credentials, personal data, remote services, automation, AI, security-sensitive actionsand failure conditions without exposing buyers or third parties to unreasonable risk?

The requirements are cumulative. Every product must meet the common requirements in this document and every category-specific requirement that matches what the product actually does. Selecting a broad or different category does not remove an applicable requirement.

Important clarifications to older WPBay guidance

Some examples in older marketplace guidance reflect a much earlier web-development ecosystem. For current script reviews:

• Testing Internet Explorer 6, 7 or 8 is not required. Browser-facing products must instead work in the current supported versions of the browsers and devices they claim to support.
• Inline CSS is not automatically rejected. Reusable and static styling should normally be kept in maintainable stylesheets, CSS modules, components or build sources. Small dynamic declarations can be acceptable when safely generated and clearly justified.
• Modern HTML and CSS are not rejected because an old validator does not recognize them. Real syntax errors, invalid nesting, duplicate IDs, inaccessible markup, broken layoutsand unsupported claims remain review issues.
• A complete no-JavaScript alternative is not required for a product whose purpose is inherently interactive. Essential content, navigation, formsand public workflows must still remain understandable and accessibleand progressive enhancement should be used where it is practical.
• Premium value is not measured by file count or feature count. A focused library, component, command-line tool or extension can be approved when its implementation, documentation, reliability, customization optionsand buyer value justify a commercial product.
• Minified, bundled, transpiled, compiled or mobile-obfuscated production assets are not automatically prohibited. WPBay must also receive readable first-party source and enough build information to review and reproduce the distributed result.
• Command-line installation is not automatically a defect. Composer, npm, NuGet, Maven, Gradle, Bundler, pip, Docker, framework CLIsand native build tools are normal in many ecosystems. Their use, versions, permissionsand exact commands must be disclosed and tested.
• WordPress coding standards do not apply to every script. A product must follow the standards and secure APIs of its actual language, framework, CMSand platform.
• GPL is not the only license accepted for scripts. The selected license must be accurately declared, compatible with the host platform and included dependenciesand consistent with the rights granted to the buyer.
• Loading JavaScript from a public CDN is not an automatic rejection. Runtime dependencies should normally be bundled or installed through the ecosystem’s package manager. Necessary external assets must be stable, secure, licensed, disclosedand supplied with a suitable fallback or installation explanation.
• A product is not required to support every database, server, browser, framework version, mobile platform or deployment model. It must state its actual support matrix accurately and work throughout that declared matrix.
• “Works on my machine” is not sufficient. A source project is a commercial deliverable only when another person can reproduce the documented installation or build from a clean environment.

Contents

• Submission and product readiness: review decisions, scope and classification, package, identity and versions, documentation and presentation, ownership, commercial qualityand functional completeness
• Engineering and security: architecture, security baseline, identity and sessions, data and network safety, dependencies, configuration, database behavior, APIs, privacyand reliability
• Product-type requirements: web products, AI, automation and scraping, security scripts, languages and runtimes, CMS and framework products, mobile productsand database, CLI, desktopand miscellaneous tools
• Delivery and verification: updates and licensing, testing, approval blockers, prohibited products, seller checklist, WPBay guidanceand official references

1. Review decisions and enforcement

WPBay may return one of the following decisions.

Approved

The product has no identified blocker after a proportionate code, package, compatibility, securityand product review. Approval means that the submitted version met the review standard based on the material available at the time. It does not guarantee that the product is free from every defect or compatible with every environment.

Changes required

The product has one or more identifiable and repairable blockers. This is the normal result for security omissions, packaging defects, broken installation, incomplete source, inaccurate requirements, exposed credentials, unreliable migrations, misleading claims, inaccessible essential controls, undocumented external services, avoidable compatibility failures or missing documentation. The seller may correct the issues and resubmit.

Rejected

The product is malicious, deceptive, stolen, intentionally dangerous, deliberately unreviewable, a prohibited clone, fundamentally non-viable or built around behavior that WPBay cannot responsibly distribute. Repeated serious violations, concealment or attempts to bypass review may also affect the seller’s account.

Temporarily disabled after approval

WPBay may temporarily disable an approved product when a serious vulnerability, malicious or compromised dependency, legal issue, broken update, major platform-policy violation, service shutdown, material compatibility failure or misleading claim is discovered later. Sellers are expected to respond promptly and provide a tested correction.

Automated tools support review but do not decide it. Linters, formatters, static analyzers, malware scanners, dependency audits, secret scanners, accessibility tools, validators, platform-specific checkersand test suites provide evidence. Reviewers assess the actual code, context, packageand user experienceand should verify likely false positives. Passing an automated scan does not guarantee approval, while a harmless warning does not automatically justify rejection.

The depth of review is proportionate to risk. A CSS component will not be evaluated like a payment application, an autonomous AI agent, a database migration utility or a penetration-testing tool. Products that process money, credentials, personal information, uploads, privileged actions, remote code or security-sensitive targets receive stricter scrutiny.

2. Product scope, categoryand delivery model

2.1 A script product must deliver usable software

A WPBay script must deliver reusable source code, an installable extension, a buildable application, a library, a component, a command-line tool, a mobile source project or another genuine software product.

The following are not sufficient as script products by themselves:

• a collection of links, copied tutorials or public documentation;
• a thin wrapper around a free project with no meaningful implementation or commercial value;
• an API key, hosted account, reseller access or subscription with no substantial buyer-usable code;
• a prompt list or generated text with no functioning software;
• an unfinished starter project, placeholder dashboard, non-working prototype or UI mock-up advertised as a complete application;
• custom development, installation, hosting or consulting sold without a reusable code deliverable;
• a remote service whose essential implementation is withheld while the listing presents it as a self-hosted script.

Custom work and hosting-only offers belong in the relevant WPBay service category. A script may use a hosted component, but the listing must clearly distinguish the code the buyer receives from the service the seller continues to operate.

2.2 Select the category by actual function and platform

The selected category must describe the product’s primary implementation or use case. Tags and the description may identify secondary technologies.

Examples:

• A Laravel application that uses an AI API belongs in Laravel Apps or AI & Machine Learning, depending on its main buyer value, but it must meet both overlays.
• A Shopify app written in Node.js must meet Shopify Apps, JavaScriptand APIs & Integrations requirements.
• A Flutter application targeting Android and iOS must meet Flutter / React Native plus the relevant Android and iOS requirements.
• A Drupal module that scrapes an external catalog must meet Drupal Modules, Automation & Scrapingand APIs & Integrations requirements.
• A Python vulnerability scanner must meet Python and Security Scripts requirements.

Miscellaneous is only for a product that genuinely does not fit another category. It is not a reduced-standard category and must not be used to avoid a stricter overlay.

2.3 State the delivery model

The product page and documentation must state which delivery model applies:

• directly installable CMS or platform extension;
• self-hosted full application;
• library, SDK, framework package or reusable component;
• browser-only web application or HTML5 product;
• command-line tool;
• desktop application source;
• native or cross-platform mobile source project;
• source code plus compiled release;
• integration requiring a separate third-party service;
• hybrid product requiring a seller-hosted backend.

The package, installation instructions, support expectationsand compatibility fields must match that model. Do not present a source project as a one-click application, a library as a complete business system or a hosted service as fully self-contained.

2.4 Supported environments must be real

The seller must identify and test the relevant environment matrix, including as applicable:

• operating systems and CPU architectures;
• language and runtime versions;
• framework, CMS, commerce platform or host application versions;
• required package manager and build-tool versions;
• web server, database, queue, cache, searchand process-manager requirements;
• browser and device support;
• Android API levels, iOS versions, Xcode, Gradle, CocoaPods, Flutter, React Native or related toolchains;
• required PHP, Node.js, Java, .NET, Python, Ruby or other extensions and modules;
• third-party services, accounts, plans, API versions, permissionsand regional availability;
• filesystem, cron, background worker, outbound-network, memory, storageand execution-time requirements.

“Works on most servers,” “compatible with all browsers,” “supports all versions,” and similar unbounded claims are not acceptable unless they can be demonstrated.

3. Required submission package

3.1 The buyer package

The submitted archive must be logically organized and must make the production deliverable easy to locate. An outer “all files and documentation” package may include:

• the production application or installable extension;
• readable source code;
• compiled or bundled production assets;
• documentation;
• license and third-party notices;
• database schemas, migrationsand optional sample data;
• examples, starter projects or integration samples;
• design-source files and editable media;
• platform-specific builds;
• optional test suites and development tools.

Each separately installable component must be clearly named and packaged in the format expected by its platform. If a CMS, marketplace, operating system or package manager expects its own ZIP, package, archive, manifest or folder structure, that component must satisfy it.

The buyer must not have to guess which archive to install, which directory is the project root or whether a folder is source, documentation, demo content or production code.

3.2 Complete and readable first-party source

WPBay must receive the complete human-readable source for all first-party functionality. This includes server code, mobile code, browser code, templates, styles, schema definitions, build configuration, prompts that materially control AI behaviorand scripts that produce distributed assets.

Compiled or optimized outputs may be included, but must not be the only reviewable form of first-party code. Examples include:

• minified JavaScript and CSS;
• transpiled TypeScript;
• bundled frontend assets;
• Java JAR, WAR or native image files;
• .NET assemblies;
• Python wheels;
• Ruby gems;
• Android APK or AAB files;
• iOS archives;
• Flutter, React Native, Electron or desktop binaries;
• encoded model, rules or workflow files.

Mobile release obfuscation, JavaScript minificationand similar production measures are acceptable only when the corresponding readable source and build settings are supplied. Encryption, packing or obfuscation must not be used to conceal behavior from review.

3.3 Buildable and deployable state

Where a build is required, the package must include:

• the correct project and dependency manifests;
• the lockfile or resolved-dependency file appropriate for an application;
• exact build and release commands;
• required environment variables with safe example values;
• instructions for development and production modes;
• generated artifacts required when the intended buyer is not expected to run the build;
• a list of non-public build dependencies or services;
• any code-generation, schema-generation, asset-compilation or native-toolchain steps;
• instructions for reproducing the shipped production output from the supplied source.

The build must not depend on the seller’s private filesystem, unpublished local package, inaccessible registry, undisclosed repository, expired token or internal CI service.

Libraries should not commit an application lockfile when their ecosystem discourages it, but their dependency ranges must still be deliberate and tested. Full applications should normally include a lockfile so the documented release can be reproduced.

3.4 Files that must be included

Every product must include, as applicable:

• the complete production code and readable first-party source;
• README.md, readme.txt or equivalent documentation;
• a license file;
• a changelog;
• the primary manifest or project file for the ecosystem;
• dependency declarations and required lockfiles;
• installation, configuration, build, deployment, updateand recovery instructions;
• database migrations and schema definitions;
• example configuration without real secrets;
• third-party copyright, sourceand license notices;
• all local assets required by the advertised default result;
• source maps or another practical source-to-build mapping when needed for review and maintenance;
• tests or a test plan appropriate to the product’s risk and complexity.

Online documentation may supplement the package but must not replace the basic included instructions needed to install, configure, updateand recover the product.

3.5 Files that must not be included

Remove unsafe, private, unrelated or development-only material, including:

• .env files containing real values;
• API keys, OAuth secrets, signing certificates, keystores, provisioning profiles, SSH keys, cloud credentials, passwords, tokens, database credentials, encryption keys or webhook secrets;
• production database dumps, customer records, analytics exports, support tickets, emails, logs, crash reports, cookies, session data or personal information;
• .git, .svn, IDE caches, operating-system metadata, editor swap filesand unrelated hidden files;
• __MACOSX, .DS_Store, Thumbs.db, backup files, duplicate releasesand abandoned source copies;
• development servers, hot-reload clients, local-only certificates, localhost endpoints, private source-map paths or production builds that still require a development runtime;
• unnecessary dependency caches, package-manager caches, build caches, coverage output, emulator data, virtual environments or full node_modules trees when the package manager is the intended installation method;
• unrestricted database snapshots or demo data copied from a live business;
• malicious samples, real exploit targets, active credentials, weaponized payloads or live malware;
• binaries with no source when the seller owns or controls the source;
• unrelated products, pirated extensions, nulled code or installable packages the seller is not authorized to redistribute.

Necessary test fixtures that resemble sensitive data must be fictional and clearly identified. Security products that require malware signatures or harmless samples must package them safely, document themand ensure they cannot execute accidentally.

3.6 Archive safety

Archives must:

• extract without path traversal, absolute paths, invalid filenames or filesystem escape;
• avoid unsafe symlinks and case-collision problems;
• use portable filename capitalization where the platform is cross-platform;
• avoid nested archive bombs or unexpectedly large extraction;
• place the documented project root in an obvious location;
• use stable folder and package names;
• not overwrite unrelated application or system files during installation.

Installers and importers must treat buyer-supplied archives as untrusted input and defend against Zip Slip, decompression bombs, executable uploads, path confusionand unsafe permissions.

4. Product identity, manifestsand version consistency

4.1 Stable identity

Every product needs a stable technical identity. Depending on the platform, this can include:

• package name, vendor namespace, module name, extension handle or machine name;
• application ID, bundle identifier, Java package, .NET namespace, Python distribution name, Ruby gem name, npm scope or Composer package name;
• database table prefix, configuration namespace, cache prefix, queue name, scheduled-task nameand public API namespace;
• WPBay product identity and licensing identifier;
• update channel and update endpoint;
• public hooks, commands, routes, events, classes, interfaces, components, CSS selectorsand extension points.

Do not rename an established technical identity after customers exist unless a documented and tested migration preserves updates, configuration, data, integrationsand buyer customizations. A marketing rebrand does not normally require changing the underlying slug or package identifier.

Do not impersonate an official package, use a misleading vendor namespace or reuse the identity of an unrelated public project. Product names and identifiers must not create a dependency-confusion risk.

4.2 Required manifest by ecosystem

The applicable manifest must be present, validand consistent with the package. Common examples include:

The absence of a particular package manager is not automatically a blocker when the ecosystem does not require it. The chosen structure must still be coherent, documented, maintainableand reproducible.

4.3 Version consistency

All user-visible and machine-readable version declarations must agree, including:

• primary manifest or project metadata;
• internal version constant;
• changelog and readme;
• WPBay listing version;
• package filename when it includes a version;
• database schema or migration version;
• update feed;
• mobile marketing and build versions where applicable;
• companion components and compatibility declarations;
• generated documentation that names a release.

Use a predictable versioning policy, preferably Semantic Versioning when the product exposes a public interface. Breaking API changes, removed configuration, renamed routes, incompatible schema changes, changed mobile identifiersand new mandatory services must not be hidden in a patch release.

Build numbers may differ from the marketing version where the target platform requires separate values, but the relationship must be documented and intentional.

4.4 Compatibility metadata

Minimum and tested versions must reflect actual testing, not copied values or guesses. Do not claim compatibility with an unreleased platform unless the product is clearly labeled as a beta tested against a named prerelease.

A product targeting an end-of-life runtime or host platform may be considered only when:

• the purpose genuinely requires legacy support or migration;
• the listing prominently states that the dependency is unsupported;
• the product does not present the environment as secure or recommended;
• a current supported path is provided where reasonably possible.

New general-purpose products should target supported stable platform versions.

5. Documentation, product description, screenshotsand demo

5.1 Included documentation

Documentation must enable the intended buyer to reproduce the advertised result without reading the implementation or contacting the seller for missing basic steps.

Document, as applicable:

• what the product is and is not;
• its delivery model and intended audience;
• the exact package or directory to install;
• prerequisites and a complete support matrix;
• installation from a clean environment;
• required commands and the directory from which each command runs;
• configuration files and every required environment variable;
• secure generation and storage of keys, secretsand credentials;
• database creation, migrations, seed data, permissionsand rollback or recovery;
• web server, queue worker, scheduler, process manager, cache, search engine, storage, mailand cron configuration;
• development, stagingand production differences;
• how to build source assets and create a production release;
• default administrator or test-account creation without shipping a universal credential;
• required third-party accounts, API permissions, plans, costs, limitsand regional restrictions;
• external data sent or received;
• all significant features and user roles;
• public API, hooks, events, commands, classes, interfaces, configuration pointsand customization boundaries;
• mobile application identifiers, signing responsibilities, store accounts, native capabilities, permissionsand backend requirements;
• import, export, backup, restorationand destructive-operation behavior;
• update instructions, migrations, compatibility notesand rollback limitations;
• uninstall behavior and what data remains;
• known limitations and intentionally unsupported environments;
• troubleshooting for common installation, permission, build, network, dependencyand database errors;
• support status, support channeland practical scope of support;
• a complete changelog.

If product-specific assistance is required, buyers should be directed to the seller’s declared support channel. WPBay marketplace support is for account, billing, purchaseand download matters, not a replacement for developer support.

Instructions such as “configure normally,” “run the installer,” “add your API,” “deploy to a server,” or “publish to the app store” are not enough when prerequisites, commands, security steps or failure recovery are omitted.

5.2 Quick start and advanced reference

Complex products should provide both:

• a concise quick-start path from a clean environment to a working representative result; and
• an advanced reference covering architecture, configuration, integrations, extension points, deployment, securityand maintenance.

Libraries and SDKs must document public methods, parameters, return values, exceptions, asynchronous behavior, lifecycle, thread or process safety where relevant, examplesand compatibility promises.

Command-line tools must document commands, options, exit codes, standard input/output behavior, configuration precedence, non-interactive usageand destructive flags.

5.3 Product description and metadata

The WPBay listing must describe the exact submitted package. Every major claim may be tested.

The title, category, tags, keywords, compatibility fields, version, screenshots, demo, plan comparisonand description must be accurate. The listing must clearly disclose:

• whether the product is a full application, extension, library, component, template, source project or hosted-service client;
• what source and compiled files are included;
• whether installation requires command-line access or specialist knowledge;
• required runtime, framework, host-platform, server, database, browser, deviceand build-tool versions;
• all mandatory paid products, accounts, subscriptions, API usage, cloud services or commercial SDKs;
• whether a required backend is included;
• whether the seller continues to operate an essential service;
• whether app-store publication, provider approval, API access or a platform partner account is separately required;
• free-versus-paid feature differences;
• any usage limits, recurring costs, transaction fees, token costs, model costs or infrastructure costs;
• support and update commitments;
• known limitations and exclusions.

Do not use unrelated platform names, popular keywords, competitors, integrations or trademarks to attract search traffic. “Official,” “certified,” “approved,” “guaranteed,” “unlimited,” “100% secure,” “fully compliant,” and similar claims require verifiable authorization or evidence.

5.4 Screenshots and presentation

At least one clear screenshot or equivalent visual is required. Products with a user interface should show:

• the real frontend or application;
• the real administration or configuration experience;
• important workflows and states;
• representative mobile layouts when mobile support is claimed;
• error, empty, loadingand success states where they materially affect buyer understanding.

Do not use mock-ups that imply functionality not delivered. Do not hide a low-quality interface behind unrelated stock art. Screenshots must not expose personal data, credentials, license keys, private URLs, internal infrastructure or third-party content the seller cannot redistribute.

CLI, library, API, database or backend-only products may use accurate terminal captures, architecture explanations, generated output, API examples or workflow diagrams instead of inventing a graphical interface.

5.5 Live demo and review access

A live demo is strongly recommended for full applications and interface-heavy products. It must:

• match the submitted version;
• expose enough functionality to verify major claims;
• use safe, fictional data;
• prevent demo visitors from changing server configuration, installing code, reading secrets, reaching shells, viewing other sessions, sending spam or exhausting resources;
• isolate or reset visitor changes;
• rate-limit expensive actions;
• clearly identify disabled features.

If authentication, a third-party API, payment sandbox, mobile build or private service is required for review, the seller must supply safe review instructions and temporary test access through the approved review channel. Never include live credentials in the public package or product description.

6. Ownership, licensingand selling rights

The seller must own the product or have documented rights to sell and redistribute it. This applies to:

• source code;
• generated or purchased code;
• frameworks, libraries, SDKsand package-manager dependencies;
• fonts, icons, images, video, audio, datasets, models, embeddings, prompts, templates, design filesand sample content;
• APIs, scraped data, schemas, translationsand documentation;
• trademarks, logos, product names, screenshotsand demo material.

Every product must include a clear license file. The listing and package must not contradict each other about the buyer’s rights.

6.1 Third-party inventory

The package must identify material third-party components with:

• component name;
• source;
• version;
• license;
• copyright notice;
• any attribution, redistribution, source-offer, notice or modification obligation.

A structured dependency manifest may satisfy part of this requirement, but it does not replace notices for fonts, media, copied code, datasets, models or assets that are not represented there.

6.2 License compatibility

The product license and every dependency must be compatible with:

• each other;
• the host platform’s licensing requirements;
• the way the product is linked, bundled, modified or distributed;
• the rights promised to WPBay buyers.

Code that forms part of a GPL-governed CMS extension may require a GPL-compatible license even when sold commercially. A proprietary commercial license does not remove upstream copyleft, attribution, source-code or redistribution obligations. The seller is responsible for obtaining legal advice where necessary.

6.3 Open-source and generated work

Open-source code may be used when its license permits the intended distribution and the product adds legitimate implementation or value. Removing attribution, changing headers to imply sole authorship, selling a near-identical public project without meaningful work or concealing the source is not acceptable.

AI-assisted and AI-generated code, documentation, images, promptsand assets are allowed. The seller remains fully responsible for originality, rights, accuracy, security, functionality, maintainabilityand license compliance. “Generated by AI” is not evidence of ownership or permission.

6.4 Datasets and models

Products containing datasets, model weights, embeddings, fine-tunes, checkpoints or generated samples must document:

• source and provenance;
• license and commercial-use rights;
• redistribution rights;
• any usage restrictions;
• personal or sensitive data considerations;
• known model or dataset obligations;
• whether the buyer receives the asset or downloads it separately.

Do not include content scraped, copied, trained or downloaded from a source whose terms or license prohibit redistribution.

7. Originality, commercial qualityand buyer value

WPBay is a commercial marketplace. Functional code can still be declined when it offers no meaningful value beyond a trivial tutorial, an unchanged boilerplate, a public example or a freely available project.

Review considers:

• whether the product solves a real problem;
• whether it has a coherent scope and intended buyer;
• whether implementation quality justifies a paid listing;
• whether integration and customization are reasonably documented;
• whether the design and user experience are professional where a UI is included;
• whether the product is more than a renamed starter kit, generated dashboard or thin API call;
• whether advertised premium features are complete;
• whether a competing public project has been copied or lightly reskinned;
• whether the product can realistically be maintained.

A focused product is acceptable when it is exceptionally useful, robust, polished, extensible or easier to integrate than obvious alternatives. Adding unrelated features solely to increase a feature count does not create quality.

7.1 User-interface quality

Products with a UI must have:

• a coherent visual hierarchy;
• readable typography;
• consistent spacing, controls, colors, iconsand feedback;
• complete responsive behavior where applicable;
• understandable navigation;
• appropriate empty, loading, validation, error, offlineand success states;
• no placeholder text, broken stock images, unfinished screens, dead controls or copied branding;
• accessible essential workflows.

Admin dashboards are not exempt from design or usability review.

7.2 Libraries and developer tools

A library, SDK, code component or developer tool should normally provide:

• a stable and intuitive public interface;
• examples or a sample integration;
• clear configuration;
• extension points or customization guidance;
• meaningful error reporting;
• tests;
• compatibility documentation;
• enough abstraction to avoid forcing buyers to rewrite its internals.

8. Functional completeness and real-world readiness

The product must work as described from a clean environment using the supplied documentation.

All advertised primary workflows must be complete. Buttons, routes, commands, forms, APIs, scheduled tasks, exports, notifications, payment states, account flows, mobile screensand CMS hooks must not be placeholders or disconnected UI.

8.1 Installation

Installation must:

• detect missing hard requirements early;
• fail with an understandable message;
• avoid partially initialized or unsafe state;
• use supported platform and package-manager mechanisms;
• set safe permissions;
• not require editing vendor or core files;
• not depend on a seller-only account unless clearly disclosed;
• not create a universal default administrator password;
• not silently transmit information to the seller.

8.2 Configuration

Configuration must be centralized and documented. Buyers should not need to search source files for URLs, database credentials, API keys, feature flags or environment settings.

Example values must be safe. Placeholder credentials must be visibly invalid. Production mode must not enable debugging, verbose stack traces, test gateways, unrestricted CORS, weak cookies, default secrets or development servers.

8.3 Failure handling

The product must handle foreseeable failure without corrupting data or exposing sensitive details, including:

• missing or invalid configuration;
• unavailable database, cache, queue, mail, search, model or API service;
• revoked or expired credentials;
• rate limits and quotas;
• network timeout or partial response;
• invalid user input;
• duplicate webhook or job;
• concurrent request;
• full disk or unavailable storage;
• interrupted migration or import;
• denied mobile permission;
• unsupported runtime or platform version.

User-facing errors should explain the practical next step. Detailed internal errors belong in protected logs, not public responses.

8.4 Buyer control and portability

Self-hosted products must give the buyer meaningful control over their own configuration and data. A seller-hosted dependency must not be concealed.

Where the product stores business or user data, it should provide a documented export or migration path appropriate to the category. Expired licensing must not erase buyer data, corrupt an installation or prevent reasonable data export.

9. Code quality, architectureand maintainability

9.1 Follow the native ecosystem

Code must follow the current conventions of its language, framework, CMSand platform. When a host platform provides APIs for routing, permissions, configuration, database access, output rendering, dependency injection, caching, events, background jobs, updates, localizationand files, use those APIs instead of bypassing them without a documented reason.

Do not:

• edit host-platform core or vendor files;
• replace global services in a way that breaks unrelated products;
• depend on undocumented private internals when a public API exists;
• monkey-patch or override broad behavior without tight scope and compatibility testing;
• duplicate a framework security mechanism with a weaker custom implementation;
• suppress all errors to hide defects;
• leave substantial dead code, abandoned integrations, TODO implementations, debug branches or copied examples in production.

9.2 Separation of concerns

Business logic, data access, transport, rendering, configurationand external-service clients should be separated enough to support testing and maintenance. The appropriate architecture depends on product size; WPBay does not require unnecessary enterprise patterns for a small component.

Avoid:

• large files combining routing, SQL, HTML, authorizationand remote calls;
• controllers or UI components containing all domain logic;
• hard-coded global state;
• duplicated validation and permission rules;
• direct environment access scattered throughout the codebase;
• circular dependencies and hidden side effects;
• constructors, imports or plugin activation hooks that perform expensive remote work.

9.3 Namespaces and collision avoidance

Public identifiers must be uniquely scoped. This includes classes, functions, database tables, configuration keys, caches, queues, scheduled tasks, routes, commands, events, hooks, CSS selectors, JavaScript globals, package namesand mobile identifiers.

Generic identifiers such as Helper, Settings, plugin_data, api_route, .button or a top-level global app can collide with other software. Follow the host platform’s official naming system and use a stable vendor or product namespace where appropriate.

9.4 Public API and backward compatibility

Document which interfaces are public. Public APIs should:

• use clear names and predictable types;
• validate inputs;
• return consistent errors;
• avoid leaking implementation details;
• remain backward compatible within the stated versioning policy;
• provide a deprecation path before removal;
• avoid undocumented network or filesystem side effects.

If a product is designed to be customized, document safe extension points. Do not instruct buyers to edit generated files, dependencies, core files or code that will be overwritten during updates.

9.5 Error handling and logging

Errors must not be silently swallowed when they affect correctness. Logs must:

• use appropriate levels;
• include enough context to diagnose a problem;
• avoid passwords, tokens, cookies, authorization headers, payment data, prompts containing private content or unnecessary personal information;
• avoid unlimited growth;
• support rotation, retention or host-platform logging;
• not be publicly downloadable.

Production responses must not expose stack traces, SQL, absolute paths, environment values, internal hostnames, dependency versions or secrets.

9.6 Comments and generated code

Comments should explain decisions, contracts, security assumptions, difficult algorithmsand non-obvious platform behavior. They should not narrate obvious syntax or preserve stale copied explanations.

Generated code must be identifiable. Do not ask buyers to hand-edit generated output when a source template or configuration is the real source of truth. If code generation is required, include the generator, schema, commandand expected tool version.

9.7 AI-assisted development

The seller must understand and be able to maintain submitted code, regardless of how it was created. AI-assisted products will be returned for changes when they contain inconsistent architecture, fictional APIs, unused packages, repeated implementations, insecure placeholders, non-working features, fabricated documentation or licensing uncertainty.

10. Security baseline

Security requirements apply to every product, not only products listed under Security Scripts. Web applications and APIs should be designed and tested against the current OWASP Top 10 and the relevant parts of the OWASP Application Security Verification Standard. API products must also consider the OWASP API Security Top 10. Native applications, CMS extensions, mobile productsand libraries must follow their platform’s secure-development guidance.

The product must be secure for its advertised use, roles, deployment modeland data sensitivity. A seller cannot transfer responsibility to the buyer for a vulnerability that exists in the default product.

10.1 Deny by default

Protected functionality must require explicit authorization. The absence of a role check, route declaration, middleware rule, access-control list, policy, capability, record rule or permission must not result in public access.

Security decisions must be enforced on the server or trusted device boundary. Hiding a button, disabling a field, changing a route name or checking a JavaScript value is not authorization.

10.2 Least privilege

The product must request and use only the privileges needed for the current operation. This applies to:

• operating-system users;
• filesystem permissions;
• database accounts;
• cloud roles;
• OAuth scopes;
• CMS capabilities;
• mobile permissions;
• Shopify scopes;
• service tokens;
• model or agent tools;
• background workers;
• exposed network ports.

Do not require root, administrator, full database, all-store, all-files, all-sites or all-account access when a narrower setup is practical. When elevated access is genuinely required, document why, whenand how it can be removed.

10.3 Security controls must not be optional decoration

Controls such as CSRF protection, authorization, signature verification, rate limits, file restrictions, tenant scoping, webhook verificationand destructive confirmations must be enforced in the executing code. A saved setting that is never read, a UI checkbox with no backend behavior or a documented warning that does not match implementation is a blocker.

10.4 Dangerous execution

The following require exceptional technical justification, strict input control, documentationand review:

• eval, dynamic language execution, generated executable codeand runtime compilation from user input;
• operating-system command execution;
• arbitrary class, method, module or callback invocation from request data;
• unsafe deserialization;
• dynamic include, import, require, assembly loading, plugin loading or reflection controlled by untrusted data;
• remote code download or execution;
• executable file generation inside a public directory;
• macro, script, formula, template or expression engines that expose privileged functions.

They are blockers when untrusted input can influence the executable content or arguments in an unsafe way. A feature whose purpose is to run buyer-provided code must use an appropriate sandbox, isolated worker, restricted language, permission modeland explicit risk disclosure. A warning alone does not make arbitrary code execution safe.

10.5 No concealed behavior

Products must not contain:

• backdoors, hidden administrator creation, universal passwords, secret routes or undocumented remote consoles;
• call-home behavior concealed from the buyer;
• remote feature activation that silently changes the product’s security boundary;
• encrypted or encoded payloads intended to avoid review;
• dormant malicious code;
• hidden advertising, affiliate injection, traffic redirection, cryptomining or resource use;
• code that disables host security controls without an essential and documented reason;
• a remote kill switch that damages the installation or data.

Feature flags and license checks are permitted when they are transparent, scopedand do not create unsafe remote control.

10.6 Security headers and transport

Web-facing applications must use HTTPS in production and must be compatible with secure transport configuration. They should set security headers appropriate to their architecture, including as applicable:

• Content Security Policy;
• frame-ancestors or an equivalent anti-clickjacking policy;
• X-Content-Type-Options;
• Referrer Policy;
• Permissions Policy;
• HSTS after HTTPS is correctly deployed;
• secure cookie attributes;
• safe CORS headers.

Do not use Access-Control-Allow-Origin: * with credentials. Do not disable TLS verification, accept every certificate or fall back to cleartext transport in production.

10.7 Rate limiting and abuse controls

Public, anonymous, authentication, provisioning, search, export, upload, AI, scraping, payment, messaging, password-resetand resource-intensive endpoints must have limits appropriate to their abuse potential.

Limits must be enforced server-side and should account for:

• authenticated identity;
• IP address or network;
• tenant or store;
• API key;
• operation cost;
• concurrent work;
• daily or monthly quota;
• queue and infrastructure capacity.

The product should return understandable retry information and must not create an unbounded queue merely because the HTTP endpoint is rate-limited.

10.8 Security disclosure and updates

Sellers must provide a private route for vulnerability reports and must not knowingly ship an unpatched, exploitable dependency or unresolved high-impact vulnerability.

Security fixes must:

• identify affected versions;
• avoid publishing exploit instructions before a correction is available when doing so would create unnecessary risk;
• include a clear update notice;
• preserve data and compatibility where practical;
• increment the product version;
• be supplied to WPBay promptly.

11. Authentication, authorization, sessionsand accounts

Products that implement accounts or protected roles must use the host platform’s established authentication and authorization system where one exists.

11.1 Passwords

Passwords must:

• be stored using a current adaptive password-hashing function provided by the language or framework;
• never be stored or logged in plaintext;
• never be encrypted with a reversible product-wide key as a substitute for hashing;
• not be emailed back to the user;
• not have an undocumented universal default;
• support secure reset rather than recovery of the original password.

Do not invent a custom password-hashing algorithm. Password policies should permit long passwords and password-manager use rather than relying on arbitrary composition rules.

11.2 Login and enumeration

Login, reset, registration, verification, invitationand MFA endpoints must resist automated abuse. Error messages and timing should not unnecessarily reveal whether a username, email, tenant, license or account exists.

Rate limits, progressive delays, temporary lockouts or equivalent measures must not create a simple denial-of-service vector against known users. CAPTCHA may supplement appropriate controls but must not be the only protection.

11.3 Sessions

Session implementations must:

• generate unpredictable identifiers;
• rotate the session after login, privilege changeand other relevant trust transitions;
• invalidate sessions after password reset or account compromise where appropriate;
• use Secure, HttpOnlyand suitable SameSite cookie attributes;
• define an inactivity and absolute lifetime appropriate to sensitivity;
• prevent session fixation;
• avoid putting bearer tokens in URLs;
• handle logout and revocation correctly.

Client-side tokens must not contain secrets merely because they are encoded. Signed tokens still require expiry, audience, issuer, algorithm, keyand revocation considerations. Do not accept unsigned tokens or allow an attacker to choose an unsafe algorithm.

11.4 Authorization

Every protected action must verify:

• that the caller is authenticated when required;
• that the caller has the required role, capability, scope, policy or permission;
• that the caller may act on the specific record, file, store, organization, tenant, project or resource;
• that the requested state transition is valid.

Checking only a numeric ID or a broad “logged in” state creates insecure direct object reference risk. Multi-tenant products must scope every relevant query, cache, export, background task, search index, file path, logand notification to the correct tenant.

11.5 CSRF and request origin

Cookie-authenticated state-changing requests must use the platform’s CSRF protection or a securely implemented equivalent. Tokens must be verified server-side and bound to the appropriate session or request context.

GET requests must not perform meaningful state changes. CORS does not replace CSRF protection. A hidden form field is not protection unless it contains a validated unpredictable token.

11.6 MFA, passkeysand external identity

If MFA, passkeys, social login, SAML, OpenID Connect or another identity integration is advertised, the complete enrollment, recovery, revocation, account-linkingand error paths must work.

Recovery must not be weaker than the primary authentication. OAuth or OIDC flows must validate state, issuer, audience, redirect URI, token signatures, nonce where applicableand PKCE where required. Do not trust identity attributes from an unsigned client response.

11.7 Account lifecycle

Registration, verification, suspension, deletion, invitation, role changeand ownership transfer must preserve authorization boundaries. Deleting an account must not orphan privileged API keys, leave active sessions or expose another user’s data.

Sensitive role or ownership changes should be audited and may require recent authentication or step-up verification.

12. Input, output, files, networkingand cryptography

12.1 Validate at the trust boundary

Every value crossing a trust boundary must be validated for its intended type, format, range, length, encodingand allowed values. This includes:

• request parameters and bodies;
• headers and cookies;
• filenames and archives;
• imported CSV, XML, YAML, JSON, spreadsheetsand documents;
• webhook payloads;
• API responses;
• database values originating from users or integrations;
• AI model output;
• environment variables;
• command-line arguments;
• deep links and mobile intents;
• message queues and scheduled-job payloads.

Sanitization does not replace validation. Do not silently coerce an unsafe value into a different meaning.

12.2 Contextual output handling

Output must be encoded or escaped for its final context:

• HTML text;
• HTML attribute;
• URL and query component;
• JavaScript;
• CSS;
• JSON;
• XML;
• SQL;
• shell argument;
• email header;
• CSV or spreadsheet cell;
• template;
• log.

Escaping too early can cause double encoding, while using one escaping function for every context leaves vulnerabilities. Prefer templates and APIs that escape safely by default.

Rich HTML must be filtered with an allowlist appropriate to the product. Markdown rendering must not allow arbitrary scripts, unsafe URLs, event attributes or active content unless the feature is explicitly sandboxed.

12.3 Database queries

Use parameterized queries, prepared statements, the host ORM or its query builder. Do not concatenate untrusted data into SQL.

Dynamic table names, column names, sort directionsand SQL fragments cannot usually be parameterized; map them to explicit allowed values. Tenant and authorization conditions must be part of the trusted query, not added by client-side filtering after retrieval.

12.4 File uploads

Upload handling must:

• require authorization where appropriate;
• enforce size and count limits before expensive processing;
• use an allowlist of expected types;
• verify actual content rather than trusting the filename or client MIME type;
• generate safe server-side filenames;
• prevent path traversal and ambiguous extensions;
• store files outside executable or public locations where practical;
• prevent script execution;
• process images and documents with maintained libraries;
• protect against decompression bombs and parser abuse;
• set safe download headers;
• enforce record ownership when retrieving or deleting.

An antivirus scan can supplement, but does not replace, structural validation and safe storage.

12.5 Imports and parsers

XML parsing must disable unnecessary external entities, DTD processingand network access. YAML, object, pickle, Java, .NET, PHP, Rubyand similar deserialization of untrusted data must use safe formats and restricted parsers.

CSV and spreadsheet exports must prevent formula injection when values can begin with executable spreadsheet characters. Imports must detect malformed encodings, unreasonable row counts, duplicate identitiesand partial failures.

12.6 Paths and archives

User-controlled paths must be resolved against an allowed base directory and verified after normalization. Reject absolute paths, parent traversal, alternate separators, null bytes, unsafe symlinks, device filesand path forms the target operating system interprets specially.

Archive extraction must check each member before writing and must impose limits on file count, expanded size, nestingand compression ratio.

12.7 Server-side requests and redirects

Any feature that fetches a user-supplied URL must defend against server-side request forgery. Depending on the feature, this can require:

• explicit scheme allowlists;
• host or domain allowlists;
• DNS resolution and revalidation;
• blocking loopback, private, link-local, metadata, multicastand internal networks;
• limiting redirects;
• validating each redirect target;
• request timeouts and response-size limits;
• disabling unexpected protocols;
• avoiding forwarding internal credentials.

Redirect destinations must be validated against an allowlist or trusted local path. “Starts with the expected domain” is not sufficient URL validation.

12.8 Command execution

Avoid shell execution when a language API exists. When a process is necessary:

• do not build a shell command by string concatenation;
• pass arguments as a structured array;
• avoid invoking a shell;
• validate executable selection;
• set time, memory, outputand environment limits;
• use a low-privilege account;
• prevent path and option injection;
• capture and handle exit status;
• never expose raw command access to an ordinary web user.

12.9 Cryptography and random values

Use maintained platform cryptography and cryptographically secure randomness. Do not invent encryption, signing, password hashing, token generation or key derivation.

Keys and nonces must have the correct size and lifecycle. Encryption must include integrity, normally through an authenticated mode. Do not use obsolete hashes or ciphers for security decisions. Comparisons of signatures and authentication tokens should resist timing leakage.

12.10 Email, URLsand spreadsheet output

Email features must prevent header injection, respect recipient authorization, validate templates, avoid leaking addresses between recipientsand include rate and abuse controls. Bulk sending must comply with the provider and applicable policy; a script must not function as an open relay or spam tool.

Generated links containing secrets must be short-lived, single-purpose where practicaland excluded from analytics, logs, referrersand search indexing.

13. Dependencies, buildsand software supply chain

The seller is responsible for first-party and third-party code shipped or installed by the product.

13.1 Dependency declarations

Dependencies must be declared in the standard manifest for the ecosystem and separated correctly between production, development, optional, peerand platform dependencies.

Avoid:

• undeclared libraries copied into random folders;
• unbounded wildcard versions;
• branch names or moving Git references in production;
• packages downloaded from personal temporary URLs;
• duplicate libraries with conflicting versions;
• unnecessary dependencies for trivial behavior;
• abandoned or known-vulnerable packages;
• depending on an unpublished local package;
• package names vulnerable to dependency confusion.

Version constraints must be wide enough for supported environments but narrow enough to avoid known incompatibility. Compatibility claims must be tested against the resolved versions buyers will actually receive.

13.2 Lockfiles

Full applications should normally include and honor the ecosystem’s lockfile. The lockfile must agree with the manifest and must not reference private paths, credentials, inaccessible registries or development machines.

Libraries should follow their ecosystem’s accepted practice for lockfiles and must test both the lowest and a current supported dependency set when broad ranges are declared.

13.3 Install and build scripts

Package-manager lifecycle scripts, Composer scripts, Gradle tasks, setup hooks, post-install commandsand native build phases must not perform surprising or unnecessary actions.

Any install-time network request, executable download, system modification, telemetry call, service registration or privileged action must be essential, documentedand safely implemented. Install scripts must not:

• read unrelated user files;
• upload environment information;
• install system-wide software without consent;
• disable security tools;
• execute code from an unverified remote response;
• require root without clear need;
• persist after uninstall without disclosure.

13.4 Source and generated artifacts

The shipped production artifacts must correspond to the supplied source. Build instructions must be sufficient to reproduce them within reasonable environmental differences.

Do not include source maps that publicly reveal private filesystem paths, secrets, internal source or unpublished endpoints. If public source maps are inappropriate, provide review-only maps or an equivalent reproducibility path.

13.5 Dependency integrity

Downloads should use HTTPS and, where the ecosystem supports it, checksums, signatures, lockfile integrity data, trusted publishing or verified package sources.

Complex or security-sensitive applications should include a software bill of materials or an equivalent machine-readable dependency inventory. At minimum, the seller must be able to identify the component and version affected by a disclosed vulnerability.

13.6 Bundled code

Bundling is acceptable when required for buyer usability or host-platform conventions. Bundled dependencies must retain license notices and must be updatable.

CMS products intended for administrators without shell access should include runtime dependencies in the form required by that CMS. Node, Python, Java, Ruby, .NETand standalone PHP applications may use their normal package-manager installation when this is clearly documented and appropriate for the intended buyer.

13.7 Vulnerability management

Before submission and every update, the seller should:

• run the ecosystem’s dependency audit;
• investigate reachable high-impact advisories;
• remove unused packages;
• update vulnerable transitive dependencies where possible;
• document a necessary exception and mitigation;
• verify that a dependency’s license has not changed incompatibly.

An audit warning is not automatically a blocker, but an exploitable vulnerability in the product’s actual configuration is.

14. Configuration, secrets, installationand deployment

14.1 Environment separation

Development, test, stagingand production settings must be separable. Production defaults must be safe.

Do not ship production with:

• debug mode;
• verbose stack traces;
• hot reload;
• a development web server presented as production-ready;
• permissive CORS;
• disabled TLS checks;
• test payment gateways;
• sample administrator credentials;
• public database, cache, profiler, queue, mail-catcher or debugging ports;
• source maps or dev tools that reveal sensitive internals;
• automatic use of the seller’s development account.

14.2 Secrets

Secrets must be supplied by the buyer or generated securely during installation. The package must include a safe example configuration that identifies every required value without containing a working secret.

Secrets must not be:

• committed to source;
• embedded in mobile or browser code as if they can remain confidential;
• written to public JavaScript configuration;
• included in screenshots or logs;
• placed in URLs;
• stored unencrypted when they grant meaningful remote access and a secure credential store is available;
• reused across all installations.

The documentation must explain rotation and revocation for credentials managed by the product.

14.3 Web root and filesystem layout

Applications should place configuration, source, logs, backups, dependency metadataand private storage outside the public web root where the framework supports it. Public directories must not expose:

• .env;
• .git;
• database dumps;
• logs;
• backups;
• source configuration;
• package manifests that reveal unnecessary internals;
• uploaded executable code;
• private media.

Directory indexes should not expose file listings. Runtime-writable directories must be narrowly scoped and must not require globally writable permissions.

14.4 Installation checks

An installer should verify:

• runtime and extension versions;
• filesystem permissions;
• database connection and privileges;
• required services and ports;
• URL and HTTPS assumptions;
• scheduler or worker requirements;
• ability to write only the required directories;
• presence of production assets;
• missing migrations or incompatible existing schema.

Sensitive values should not be echoed back after storage. Installation routes must disable themselves or require authorization after completion.

14.5 Docker and containers

Docker files are welcome but do not excuse incomplete deployment documentation. Containerized products must:

• avoid embedding secrets in images;
• avoid running as root where unnecessary;
• pin or deliberately constrain base images;
• define persistent volumes;
• include health checks where useful;
• document exposed ports;
• avoid publishing databases and caches to the public network;
• separate development conveniences from production configuration;
• support orderly startup, migrationand shutdown.

14.6 Hosting claims

Do not claim “shared hosting compatible,” “serverless ready,” “one-click deploy,” “Windows compatible,” or “works on any VPS” unless that environment is tested and the required permissions, processes, extensionsand limitations are documented.

15. Databases, storage, migrationsand destructive operations

15.1 Database access

Applications must use a least-privilege database account. Runtime credentials should not normally have permission to create users, grant privileges, read unrelated databases or perform administrative server operations.

Queries must be parameterized and appropriately indexed. Avoid N+1 query patterns, unbounded scansand loading entire large tables into memory.

15.2 Schema and migrations

Database changes must be versioned and repeatable through the host framework or a documented migration system. Migrations must:

• run in a deterministic order;
• avoid reapplying completed changes;
• preserve existing buyer data;
• account for supported database engines;
• handle large tables and locks responsibly;
• define failure and recovery behavior;
• not depend on sample data;
• avoid irreversible destructive changes without prominent warning and backup guidance.

Do not tell buyers to manually edit arbitrary SQL after each update when a migration mechanism is appropriate.

15.3 Transactions and concurrency

Operations that must succeed or fail as a unit should use transactions when the database and operation permit it. Concurrency-sensitive behavior must use appropriate unique constraints, locks, atomic updates, compare-and-set logic or idempotency controls.

Checking availability and then writing in a separate unprotected step is not sufficient for bookings, stock, quotas, balances, license use, reservations or unique ownership.

15.4 Data integrity

Use database constraints in addition to application validation where they protect essential invariants. Currency must use fixed-precision representations, not binary floating point. Dates and timestamps must have a documented timezone policy.

Foreign keys, soft deletion, cascading behavior, audit historyand retention must be chosen deliberately. Do not leave orphaned records or silently reinterpret existing data during an update.

15.5 Destructive tools and operations

Delete, truncate, reset, overwrite, restore, schema conversion, bulk updateand migration tools must:

• identify the exact target;
• require appropriate authorization;
• present scope and consequences;
• provide a dry run or preview when practical;
• require deliberate confirmation;
• recommend or create a backup;
• avoid broad unresolved globs and unsafe defaults;
• provide progress and an auditable result;
• stop safely on error.

Factory reset and uninstall must not delete unrelated tables, files, users, settings or shared resources.

15.6 Backup and restore

If backup or restore is advertised, test both directions. A backup feature is not complete until the documented restore works on a clean compatible environment.

Backups containing private information or secrets must be protected from public access. Restore must defend against path traversal, hostile archives, schema mismatch, oversized dataand partial state.

15.7 Multi-database claims

A product claiming support for MySQL, MariaDB, PostgreSQL, SQL Server, SQLite, Oracle or another engine must test each claimed engine and avoid undocumented engine-specific assumptions.

Database Tools targeting one engine must state that clearly. A database-specific tool is acceptable; pretending to be portable is not.

16. APIs, integrations, webhooksand payments

This section applies to the APIs & Integrations category and to every other product that exposes or consumes an API.

16.1 Use supported interfaces

Prefer the provider’s documented and supported API, SDK, authentication methodand version. Unofficial, reverse-engineered, private, mobile or scraped endpoints must not be presented as official and may be rejected when their use violates the provider’s terms, bypasses access controls or is predictably unstable.

The listing must identify:

• provider;
• API or protocol;
• required account and plan;
• scopes and permissions;
• current supported API version;
• usage cost and quota;
• regional or approval requirements;
• data exchanged;
• known functional limits.

16.2 API client behavior

Clients must correctly handle:

• authentication and token refresh;
• pagination;
• rate limits;
• retries with bounded exponential backoff and jitter;
• timeouts;
• connection and DNS failures;
• partial responses;
• provider error formats;
• API deprecation;
• clock skew;
• duplicate requests;
• idempotency;
• asynchronous status;
• cancellation;
• data type and precision differences.

Do not retry every error. Authentication, validation, permissionand permanent client errors normally require correction, while transient errors may be retried within a strict budget.

16.3 API server behavior

APIs exposed by the product must:

• use standard HTTP semantics and status codes;
• validate content type and body size;
• authenticate and authorize every protected resource;
• enforce tenant and object ownership;
• paginate large collections;
• cap page sizes and expensive filters;
• return consistent machine-readable errors;
• document versioning and deprecation;
• avoid exposing internal models or stack traces;
• rate-limit abusive or expensive access;
• provide an OpenAPI description or equivalent reference for substantial HTTP APIs.

GraphQL APIs must enforce authorization per resolver or data boundary, limit query depth or cost, prevent unrestricted introspection exposure where inappropriateand avoid N+1 behavior.

16.4 OAuth and API credentials

OAuth implementations must follow the provider’s current flow and the current OAuth security best practices. Use exact redirect URI matching, state, PKCE where applicable, short-lived authorization codes, secure token storageand the minimum scopes.

Do not ask buyers to paste a password when OAuth or a scoped token is available. Do not expose client secrets in public clients, browser code or mobile binaries.

16.5 Webhooks

Webhook handlers must:

• verify the provider’s signature or equivalent authenticity mechanism using the raw request representation required by the provider;
• reject invalid or stale messages;
• prevent replay where the provider supplies timestamps, nonces or event IDs;
• acknowledge within the provider’s timeout;
• defer long processing to a job where appropriate;
• be idempotent;
• record enough event identity to detect duplicates;
• validate tenant, account, object ownership, state, amountand currency;
• handle out-of-order delivery;
• avoid trusting a callback merely because it comes from a familiar user-agent or IP.

Webhook secrets must be rotatable. A public callback parameter generated by the client is not a substitute for signature verification.

16.6 Payments, subscriptionsand financial state

Payment and billing products receive strict review. They must:

• calculate authoritative prices, discounts, taxes, currency, quantityand ownership on the server;
• never accept a final amount or paid status from an editable client field;
• create a clear order or transaction state before or during the provider flow;
• verify payment through a signed webhook or secure server-to-server provider lookup;
• bind the provider transaction to the correct local order, user, tenant, amountand currency;
• prevent replay and duplicate fulfillment;
• implement idempotency;
• handle pending, succeeded, failed, canceled, expired, refunded, partially refunded, disputedand reversed states where applicable;
• separate sandbox and production credentials;
• document refund, cancellationand webhook setup;
• avoid storing raw card data;
• comply with the payment provider’s current integration requirements.

A success redirect in the user’s browser is not proof of payment. A payment reference alone is not proof that the reference belongs to the current order or has not already been used.

16.7 Data synchronization

Synchronization must define:

• source of truth;
• identity mapping;
• conflict behavior;
• deletion behavior;
• pagination and checkpoints;
• retry and deduplication;
• timezone and currency handling;
• partial failure and resumption;
• auditability.

Do not silently overwrite newer data or duplicate records after a retry.

17. Privacy, telemetryand external services

17.1 Data minimization

Collect, process, transmitand retain only data needed for documented functionality. Products must not harvest contacts, content, credentials, browsing history, device identifiers, source code, prompts, files or usage information for undisclosed purposes.

The documentation and listing must identify:

• categories of personal or sensitive data processed;
• why each category is needed;
• where data is stored;
• external recipients;
• retention and deletion behavior;
• buyer-controlled privacy settings;
• required legal or policy configuration the buyer must complete.

17.2 Telemetry

Optional analytics, diagnostics, crash reporting, usage tracking, update checks that transmit installation dataand marketing communication must be transparent.

Non-essential telemetry should be opt-in and must be easy to disable. Essential operational requests must send the minimum data. Do not use dark patterns, preselected consent for unrelated tracking, hidden fingerprints or a license check as a pretext for analytics.

Telemetry must not contain:

• secrets;
• full request bodies;
• private prompts or generated content;
• customer files;
• payment data;
• unnecessary identifiers;
• raw IP addresses or precise location without a justified purpose;
• source code or database contents.

17.3 External-service disclosure

For every required external service, disclose:

• operator and purpose;
• information sent;
• account and subscription requirement;
• expected usage charges;
• quota and rate limits;
• dependency on service availability;
• country or region limitations;
• whether the buyer can replace or self-host it;
• what happens if the service changes or closes.

A product whose essential feature stops when the seller’s server closes must say so prominently. Do not advertise such a product as completely self-hosted or lifetime-independent.

17.4 Data-subject and account lifecycle

Products that store personal data should provide appropriate export, correctionand deletion mechanisms or integrate with the host platform’s privacy API. Deletion must cover derived records, files, caches, search indexes, queued messagesand external services where applicable, subject to documented lawful retention.

Uninstalling an integration should revoke or guide revocation of tokens and webhooks. Uninstall must not continue undisclosed data collection.

17.5 Sensitive categories

Products processing health, financial, biometric, precise location, children’s, educational, authentication, private communication, employment or similarly sensitive data require stricter controls and accurate limitations.

WPBay approval does not mean that a product is GDPR, HIPAA, PCI DSS, COPPA, FERPA, SOC 2, ISO 27001 or otherwise legally compliant. Such claims require a defined scope and verifiable evidence. A privacy-policy template or encryption checkbox does not establish compliance.

17.6 Logs, diagnosticsand support exports

Diagnostic exports must redact secrets and personal data by default, explain what will be includedand require a deliberate action before transmission. Publicly reachable logs, debug panels, profilers, metrics endpointsand health endpoints must not reveal sensitive internals.

18. Performance, scalability, resilienceand background work

18.1 Honest capacity

Performance claims must be measured in a described environment. “Unlimited,” “enterprise scale,” “millions of records,” “real time,” and similar claims must be supported by design and testing.

The product must not depend on an unbounded query, loop, queue, recursion, retry, log, cache, upload, export or AI request under normal use.

18.2 Web request behavior

User-facing requests should have bounded work. Long imports, exports, video processing, scraping, model inference, synchronization, email campaignsand bulk operations should use background jobs or chunked workflows where appropriate.

The UI should display progress and failure without pretending that closing a browser cancels server work unless cancellation is actually implemented.

18.3 Queues and scheduled jobs

Background work must:

• define how workers and schedulers are started;
• use durable status where required;
• have bounded retries and backoff;
• distinguish transient from permanent failure;
• be idempotent or deduplicate appropriately;
• enforce tenant and authorization context;
• avoid executing stale revoked work;
• expose protected monitoring or logs;
• clean up completed and failed records;
• handle worker crashes and deployment restarts.

Cron instructions must not suggest running expensive tasks every minute without locking. Concurrent scheduler invocations must not duplicate work.

18.4 Caching

Caches must preserve authorization and tenant boundaries. Cache keys must include every value that changes the output, including user, role, locale, currency, site, store or tenant where relevant.

Do not cache secrets in public stores, serve one customer’s response to another or rely on cache as the only source of durable data. Invalidation behavior must be correct for updates and deletions.

18.5 Resource controls

Set appropriate:

• network connect and response timeouts;
• response and download-size limits;
• upload limits;
• memory and batch limits;
• concurrency limits;
• API and model cost ceilings;
• subprocess execution limits;
• archive extraction limits;
• database page sizes;
• log retention.

External requests must not wait indefinitely. Timeouts must be handled as failures, not silently interpreted as success.

18.6 Graceful degradation

When a non-essential service is unavailable, the product should preserve unrelated core functionality and explain the degraded state. Circuit breakers, backoff, queues, cached data or local fallbacks may be appropriate.

The product must not repeatedly call a failing provider on every page load, lock the administration interface or corrupt local state because a remote service is unavailable.

18.7 Cleanup

Temporary files, expired tokens, abandoned uploads, old jobs, logs, caches, generated exportsand transient database rows must have a cleanup strategy. Cleanup must be scoped and must not delete active buyer data.

19. HTML5, CSS, JavaScriptand browser-facing products

This section applies to the HTML5, CSSand JavaScript categories and to the browser-facing part of every other script.

19.1 HTML and semantics

HTML must be structurally valid enough to work reliably with browsers, assistive technology, searchand scripts. Use the element that matches the meaning and behavior:

• headings in a logical hierarchy;
• lists for lists;
• buttons for actions;
• links for navigation;
• labels and fieldsets for forms;
• tables for tabular data;
• landmarks and native interactive elements where possible.

Do not make a div or span behave like a button without reproducing keyboard, focus, name, stateand activation behavior. Avoid duplicate IDs, invalid nesting, empty links, forms without labelsand interactive controls nested inside other interactive controls.

Templates must not hard-code a buyer’s domain, analytics ID, contact data, API key or private asset source.

19.2 Accessibility

Primary workflows and essential controls must be usable by keyboard and must expose an accessible name, role, state, focus orderand visible focus indicator. Browser-facing products should target WCAG 2.2 Level AA for the interfaces they control.

At minimum:

• color must not be the only way information is communicated;
• normal text and essential controls must have adequate contrast;
• layouts must tolerate zoom and text resizing;
• form errors must be programmatically associated and understandable;
• dialogs must manage focus and be dismissible appropriately;
• menus, tabs, accordions, carousels, tooltips, drag-and-drop interfacesand custom controls must implement established accessible behavior;
• animation must respect reduced-motion preferences where appropriate;
• auto-playing audio must not begin unexpectedly;
• timed interactions must provide reasonable control;
• status messages should be announced when needed.

Products advertised as “accessibility-ready,” “WCAG compliant,” or equivalent receive stricter review of the claimed scope.

19.3 CSS category requirements

A CSS product may be a framework, component collection, animation library, design system, template style layer, utility set or another substantial styling product. A few generic declarations, copied effects or minor variants of common free snippets normally do not provide enough commercial value.

CSS products must:

• include readable source and production output where preprocessing is used;
• document the supported preprocessors, build command, browser targetsand required HTML structure;
• scope component styles to avoid unintended global effects;
• document any reset, normalize layer, utility generation or global typography;
• use a coherent naming or component strategy;
• expose documented variables, custom properties, tokens, mixins or configuration where customization is advertised;
• avoid excessive !important, over-specific selectorsand brittle DOM dependence;
• avoid collisions with common frameworks;
• handle focus, hover, active, disabled, invalid, loadingand reduced-motion states;
• support responsive behavior and content expansion;
• include the rights for fonts, icons, imagesand demo assets.

Inline CSS is acceptable for small dynamic values or genuinely self-contained embed components. Static product styling should remain maintainable.

Browser-specific prefixes may be used when necessary. A validator warning caused only by a modern feature, vendor prefix, custom property or browser experiment is not a blocker. Broken syntax, ignored declarations that materially affect the designand unsupported compatibility claims are blockers.

19.4 JavaScript and TypeScript

JavaScript products must state:

• whether they target browsers, Node.js, an edge runtime, a desktop shell or multiple environments;
• whether the public format is ESM, CommonJS, UMD, IIFE or another module system;
• required browser or Node.js versions;
• required globals, peer dependencies, framework versionsand polyfills;
• whether TypeScript declarations are included;
• whether the buyer receives source, bundled filesand source maps.

Reusable libraries should:

• avoid unnecessary global variables;
• avoid modifying built-in prototypes;
• clean up events, observers, timers, DOM nodes, workersand subscriptions;
• support multiple independent instances unless clearly documented otherwise;
• expose a stable initialization and destruction lifecycle;
• avoid hard-coded selectors and IDs that permit only one instance;
• validate configuration;
• reject promises or report asynchronous errors consistently;
• preserve tree-shaking when advertised;
• provide type declarations when TypeScript support is claimed.

19.5 Browser security

Never insert untrusted data through innerHTML, outerHTML, document.write, string-built event handlers or unsafe template evaluation without a correct sanitization boundary.

JavaScript must not:

• evaluate untrusted strings;
• use unsafe dynamic imports from user-controlled URLs;
• trust postMessage without checking origin and payload;
• store high-value bearer tokens in insecure browser storage without considering the threat model;
• expose server secrets in a frontend bundle;
• accept unvalidated redirect or callback URLs;
• merge untrusted objects in a way that permits prototype pollution;
• use wildcard messaging or CORS unnecessarily;
• disable certificate or content-security protections through a native wrapper;
• treat AI-generated HTML, Markdown, SQL or commands as safe output.

Embedded widgets must isolate CSS and state appropriately and must document what data is sent to the provider.

19.6 Browser compatibility

Test current stable versions of the major browsers relevant to the product, including mobile browsers where mobile support is claimed. A clear support policy such as “current and previous major versions” is preferable to an unbounded promise.

The product must:

• avoid browser sniffing when capability detection is appropriate;
• provide required polyfills or document them;
• handle touch, pointer, mouseand keyboard input as applicable;
• handle responsive resizing and orientation changes;
• avoid relying on a development-only browser flag;
• not ship console errors or uncaught promise rejections during normal use.

Internet Explorer support is not required unless the seller explicitly advertises it.

19.7 Progressive enhancement

Not every interactive product needs a no-JavaScript duplicate. Essential information and navigation should remain meaningful where practical. Forms that perform ordinary server actions should not lose data or become impossible to submit solely because an enhancement fails, unless the product is explicitly a client-side application whose architecture is documented.

19.8 Frontend dependencies and CDNs

Runtime dependencies should normally be bundled or installed through the documented package manager. If a public CDN is used:

• the source and license must be disclosed;
• HTTPS is required;
• the version should be fixed;
• Subresource Integrity should be used for immutable third-party resources where practical;
• privacy and availability consequences must be documented;
• a failure must not create an unsafe state;
• the URL must not be controlled by untrusted input.

Do not load an arbitrary “latest” production script or execute remote code that can change without a product update.

19.9 HTML5 games, mediaand interactive content

HTML5 games and rich media products must:

• include all code and licensed assets needed for the advertised experience;
• document input, audio, fullscreen, storage, networkand device assumptions;
• pause or reduce work when hidden where appropriate;
• handle lost focus and resize;
• avoid excessive CPU, GPU, memory, networkand battery use;
• preserve progress or explain persistence;
• provide user controls for audio and motion;
• avoid third-party tracking or advertising that is not disclosed;
• not depend on a seller-hosted asset server unless disclosed.

20. AI and Machine Learning products

This section applies to AI & Machine Learning products and any script that calls, embeds, fine-tunes, trains, retrieves for or delegates actions to an AI model.

AI functionality must be reviewed as an untrusted, probabilistic component. A model response is not authorization, validation, factual proof, executable code or a security boundary.

20.1 Product disclosure

The listing and documentation must state:

• which model providers, model families, local runtimes or user-supplied endpoints are supported;
• whether models are hosted by the seller, a third party or the buyer;
• required accounts, API keys, plans, regionsand usage costs;
• whether prompts, files, outputs, embeddings or metadata leave the buyer’s environment;
• whether provider retention or training settings are configurable;
• context, file, token, image, audioand request limits;
• expected hardware for local inference or training;
• major known limitations;
• whether model availability can change independently of the script;
• which functions are deterministic application logic and which depend on generated output.

Do not advertise “unlimited AI,” “free AI,” “no API cost,” “private,” “offline,” or “self-hosted” when an undisclosed quota, seller proxy, remote model or paid provider is required.

20.2 Provider and model configuration

Do not hard-code a provider secret or route every buyer through the seller’s private API key. Buyers should normally use their own credentials or an explicitly disclosed seller-operated service with a sustainable commercial model.

Model identifiers, capabilities, limitsand pricing change. The product should:

• validate that a selected model supports the requested modality and feature;
• handle retired, renamed, unavailable, overloadedand permission-restricted models;
• separate provider adapters;
• avoid treating one provider’s response schema as universal;
• present actionable errors;
• allow model and endpoint configuration within safe boundaries;
• not claim support based only on a name appearing in a dropdown.

20.3 Prompt injection and untrusted context

User input, retrieved documents, web pages, emails, tool results, file contentsand prior model messages must be treated as untrusted. The product must not assume a system prompt can prevent prompt injection.

Where a model can access tools or sensitive context:

• separate instructions from untrusted content;
• minimize data and tools exposed to the model;
• enforce authorization outside the model;
• scope retrieved data to the correct user and tenant;
• validate tool arguments;
• validate and constrain model output;
• prevent untrusted content from changing tool permissions;
• avoid placing secrets in prompts;
• log safely;
• test direct and indirect prompt injection.

Retrieved content must not gain authority merely because it appears in a trusted UI.

20.4 Agentic and tool-using systems

Products that let a model send messages, publish content, modify a database, execute code, call business APIs, spend money, delete files, change permissions or operate accounts must apply least privilege and bounded autonomy.

High-impact actions must normally require a clear human confirmation that shows:

• the exact action;
• target;
• material parameters;
• expected consequence.

Confirmation must occur after the action is fully formed, not as a generic one-time permission during onboarding.

Agentic systems must:

• expose only necessary tools;
• enforce server-side policy per tool call;
• cap iterations, time, costand retries;
• prevent recursive or self-replicating work;
• stop on ambiguous authorization;
• isolate tenant context;
• preserve an audit trail;
• support cancellation;
• avoid treating model text as a trusted command;
• handle partial completion and compensation.

An AI model must never be able to expand its own permissions.

20.5 Output handling

Generated content must be validated for the destination. In particular:

• generated HTML must be sanitized;
• generated Markdown must use a safe renderer;
• generated SQL must not run automatically against production;
• generated shell commands or code must not execute without a secure sandbox and deliberate authorization;
• generated URLs must be validated;
• generated filenames and paths must be constrained;
• generated email recipients and payment parameters must be verified;
• generated structured data must be schema-validated;
• generated facts must not be presented as verified merely because they are fluent.

The product should show uncertainty and require human review where an error can materially affect finances, rights, safety, health, employment, legal decisions, publication or access.

20.6 Sensitive data and privacy

Before sending data to a model provider, the product must determine what is necessary and disclose it. It must not silently send:

• passwords or tokens;
• private keys;
• payment data;
• health or educational records;
• private source code;
• entire databases;
• unrelated files;
• hidden system context;
• other tenants’ data.

RAG and embedding systems must enforce tenant isolation during ingestion, indexing, retrieval, cachingand deletion. Deleting a source record must have a documented effect on chunks, embeddings, vector indexes, cachesand provider files.

20.7 Models, datasetsand provenance

Products that ship or train models must document:

• model and dataset origin;
• license;
• intended use;
• supported input;
• evaluation;
• known limitations;
• model size and hardware;
• security implications of loading the format;
• update method;
• checksums or integrity;
• whether the model can execute custom code during loading.

Do not load untrusted model files through a serialization format that can execute code. Do not enable remote model repository code by default without explicit trust and review.

20.8 Cost and resource controls

AI endpoints can create large and rapid costs. Products must provide:

• request and concurrency limits;
• token, duration, image, audio or output limits;
• bounded retries;
• per-user or per-tenant accounting where applicable;
• budget or quota controls for shared credentials;
• protection against anonymous use;
• cancellation where supported;
• clear cost estimates or provider links.

The product must not permit an anonymous endpoint to create unlimited model requests, GPU jobs, fine-tunes or agents.

20.9 Evaluation and claims

Claims such as “accurate,” “human-like,” “detects plagiarism,” “removes bias,” “guaranteed original,” “copyright safe,” “undetectable,” “medical grade,” or “fully autonomous” require a defined and reproducible evaluation.

Documentation should identify:

• evaluated tasks;
• dataset or representative test set;
• metrics;
• model and prompt version;
• major failure cases;
• whether results vary by language or domain.

Do not claim that AI output is automatically free from copyright, trademark, privacy, factual or platform-policy issues.

20.10 Content and safety controls

Where the use case can generate or transform harmful, illegal, abusive, sexual, violent, fraudulent, deceptive or rights-infringing content, the product must provide appropriate controls and must comply with WPBay and provider acceptable-use policies.

Safety cannot be represented by a hidden prompt alone when the application exposes high-risk actions. Moderation, authorization, rate limits, human review, output validationand audit controls may all be required depending on the use case.

21. Automation and Scraping products

This section applies to Automation & Scraping and to products that crawl, extract, monitor, import, post, message, provision, synchronize or perform repetitive actions against websites or services.

21.1 Authorized and responsible use

Automation must be designed for lawful, authorized use. A generic disclaimer does not make abusive functionality acceptable.

Products must not be primarily designed or marketed to:

• bypass authentication, paywalls, subscriptions, access restrictions, CAPTCHAs, rate limits, bans or anti-bot controls;
• harvest credentials, private profiles, contact lists, personal data or restricted content;
• perform credential stuffing, account takeover, mass account creation, fake engagement, spam or deceptive messaging;
• evade platform enforcement through fingerprint rotation, stealth claims or residential proxy abuse;
• copy or redistribute content without rights;
• interfere with service availability.

21.2 Robots, termsand site rules

A crawler should support responsible request rates, clear configurationand compliance with applicable site rules. The Robots Exclusion Protocol is a crawler-control standard, not proof of legal permission. Supporting or honoring robots.txt does not replace authorization, terms, copyright, privacy or contractual obligations.

Public web crawlers should normally:

• identify themselves through an appropriate user agent;
• support a buyer-configurable contact or identifier;
• respect crawl delays and exclusions where applicable;
• avoid authenticated or private areas unless explicitly configured by an authorized user;
• avoid hidden links, honeypotsand infinite calendars;
• cap depth, pages, domainsand downloaded size.

21.3 Rate, concurrencyand capacity

Safe defaults are required. Buyers must be able to configure:

• request interval;
• concurrency;
• per-domain limits;
• retry budget;
• timeout;
• maximum pages or records;
• maximum file size;
• schedule;
• bandwidth;
• stop conditions.

Retries must honor Retry-After where relevant and use backoff. The product must not create a denial-of-service risk through aggressive defaults.

21.4 Authentication and credentials

If the product automates an authenticated account:

• prefer official OAuth or API access;
• store credentials securely;
• never log passwords, cookies, tokens or authorization headers;
• isolate credentials by buyer and tenant;
• support revocation;
• avoid exporting browser session data;
• disclose when the automation can trigger provider security challenges or account restrictions.

Do not bundle a seller account, shared cookie, CAPTCHA-solving credential or unauthorized API access.

21.5 Extraction correctness

Scrapers must detect and report when selectors, schemas, response formats, pagination, authentication or expected fields change. Silently storing incorrect data is not acceptable.

The product should:

• distinguish “no result” from “parser failed”;
• validate required fields;
• preserve source URL and retrieval time where relevant;
• deduplicate predictably;
• normalize encoding, dates, unitsand currency carefully;
• handle pagination and lazy-loaded content;
• expose failed records and retry status;
• avoid inventing values for missing data.

21.6 Browser automation

Browser automation packages must:

• document the browser and driver versions;
• use isolated profiles;
• clean up processes and temporary profiles;
• cap parallel browsers and resource use;
• avoid exposing remote debugging ports;
• avoid disabling browser security in production;
• handle navigation timeout, downloads, popupsand crashes;
• avoid stealth or “undetectable” claims intended to bypass enforcement.

21.7 Content import and publication

Products that import or publish content must:

• preserve attribution and licenses where required;
• not imply that the buyer owns imported content;
• sanitize imported HTML;
• validate media types and sizes;
• prevent duplicate posting;
• provide preview or approval for large public actions;
• allow cancellation;
• expose source and status;
• avoid publishing generated or scraped material automatically into sensitive contexts without review.

21.8 Messaging and social automation

Messaging, email, socialand engagement automation must enforce:

• authorized accounts;
• recipient consent or another valid basis;
• provider rate limits;
• unsubscribe and suppression where applicable;
• duplicate prevention;
• campaign review;
• per-account limits;
• clear sender identity.

Tools centered on unsolicited bulk messaging, fake reviews, fake followers, artificial engagement or platform manipulation are prohibited.

21.9 Proxies

Proxy support can be legitimate for testing, corporate routing, geographic availability checksand buyer-owned infrastructure. It must not be marketed as a way to evade bans, defeat rate limits, conceal fraud or access prohibited content.

The seller must not bundle compromised, unauthorized or undisclosed third-party proxy access.

22. Security Scripts and dual-use functionality

Security tools receive heightened review because legitimate defensive functions can also enable abuse.

22.1 Acceptable purpose

The product must have a clear defensive, administrative, educational, testing or authorized assessment purpose. Examples can include:

• configuration auditing;
• vulnerability scanning within an authorized scope;
• integrity and malware scanning;
• log analysis;
• dependency auditing;
• encryption and key-management utilities;
• security monitoring;
• incident-response tools;
• safe training labs;
• backup verification;
• access review.

WPBay may decline a technically functional product when its practical value depends mainly on unauthorized access, evasion, persistence, data theft, exploitation or disruption.

22.2 Prohibited security behavior

Products must not provide or conceal:

• malware, ransomware, spyware, stalkerware, keyloggers, stealers, rootkits, botnet agents, cryptominers, destructive wipers or droppers;
• phishing kits, credential capture, session theft, token theft, cookie theft or browser-data extraction;
• mass credential testing or account takeover;
• bypasses for product licenses, DRM, paywalls, access controls, security software or platform enforcement;
• remote-control functionality designed to be hidden from the device or account owner;
• weaponized exploitation against arbitrary public targets;
• denial-of-service or resource exhaustion tools;
• persistence, privilege escalation or defense evasion intended for unauthorized systems;
• malicious macros, document payloads or executable generators;
• instructions or automation whose primary use is criminal or abusive.

Calling a product “educational” does not override its actual design.

22.3 Authorization and scope controls

Network, application, cloudand vulnerability scanners must make the target and scope explicit. Depending on risk, they should:

• require deliberate target entry;
• prevent accidental scanning of unrelated networks;
• limit concurrency and rate;
• display an authorization reminder;
• support allowlists;
• avoid destructive tests by default;
• require an additional opt-in for intrusive checks;
• preserve a record of target, timeand configuration;
• stop safely;
• not automatically pivot to discovered systems.

An authorization checkbox alone is insufficient for a tool built around indiscriminate scanning or exploitation.

22.4 Safe defaults and output

Security tools must default to non-destructive behavior. Findings should include:

• affected target or component;
• evidence sufficient to validate the finding;
• severity with a documented basis;
• limitation and false-positive context;
• remediation guidance;
• time and tool version.

Do not expose secrets in reports. Reports that may contain vulnerabilities, paths, user data or credentials must be access-controlled and excluded from public storage.

22.5 Malware and file scanning

Malware scanners must:

• avoid executing samples;
• isolate quarantine;
• prevent public access;
• disclose cloud submission;
• require consent before uploading files or hashes when privacy may be affected;
• update signatures or rules securely;
• verify update integrity;
• distinguish a heuristic warning from confirmed malware;
• permit recovery from false positives.

The production package must not include live malware. Harmless test strings or inert fixtures must be clearly contained and documented.

22.6 Encryption and secret-management tools

Encryption tools must use established algorithms and libraries, generate keys securely, protect integrity, document backups and recoveryand avoid irreversible operations without confirmation.

Products must not claim that forgotten encryption keys can always be recovered unless that recovery design and its security consequence are explicit. Master keys, escrow, recovery codesand remote key storage must be disclosed.

22.7 Remote administration

Legitimate remote administration requires:

• informed installation and visible operation;
• strong authentication;
• encrypted transport;
• authorization and role separation;
• audit logs;
• session expiry and revocation;
• explicit device or agent enrollment;
• safe update and removal;
• no stealth persistence.

Undocumented remote access is a backdoor and causes rejection.

22.8 Security claims

“100% secure,” “unhackable,” “detects all malware,” “guaranteed protection,” and similar claims are not acceptable. The product must state scope, assumptions, update dependenceand known limitations.

23. Language and runtime-specific requirements

Every product must meet the common requirements and the subsection for each principal runtime it uses.

23.1 PHP Scripts

PHP products must:

• declare the minimum and tested PHP versions;
• declare required extensions;
• use Composer metadata and PSR-4 autoloading where appropriate;
• follow the host framework’s standard or a consistent modern style such as PSR-12;
• run without warnings, notices, deprecations or fatal errors in the declared environment;
• use strict comparisons and predictable type handling for security-sensitive values;
• avoid short open tags;
• avoid suppressing errors as a substitute for handling them;
• use secure session, password, database, filesystemand HTTP APIs;
• escape output in context;
• validate uploaded and imported files;
• avoid unsafe unserialize, dynamic includesand command execution;
• not require globally writable files or directories.

Standalone PHP applications must provide a production web-server configuration or clear equivalent instructions. They must not instruct buyers to expose the project root, vendor, .env, logs, backups or storage directories publicly.

Composer applications must define intentional production and development dependencies. composer install --no-dev must not remove code required at runtime. Composer scripts must be safe and documented.

23.2 JavaScript, TypeScriptand Node.js

Node.js and JavaScript products must:

• include an accurate package.json;
• declare supported Node.js or browser versions;
• classify dependencies correctly;
• include a current lockfile for full applications;
• document the package manager used for the release;
• build from a clean install;
• not require a globally installed unpublished tool;
• remove development servers and debug middleware from production;
• handle rejected promises and process errors intentionally;
• use bounded request bodies and parser limits;
• avoid blocking the event loop with unbounded synchronous work;
• cleanly stop servers, workersand child processes;
• avoid unsafe object merging, prototype pollution, path traversal, SSRF, command injectionand dynamic evaluation.

An npm install hook that downloads or executes remote code receives strict review. Native modules must include build prerequisites and supported operating systems and architectures.

TypeScript products must include source and a valid configuration. Libraries advertising TypeScript support should include accurate declarations. Generated declarations must match runtime exports.

Applications using frontend frameworks must declare exact supported major versions and must not ship only a development build.

23.3 Python

Python products must:

• declare supported Python versions;
• use a modern package structure and pyproject.toml or a justified current alternative;
• define dependencies and entry points;
• include a lock or constraints strategy for full applications;
• document virtual environment and installation commands;
• avoid relying on an unlisted system package;
• handle Unicode, paths, timezonesand platform differences deliberately;
• use parameterized database APIs;
• avoid eval, exec, unsafe YAML loading, unsafe pickle or model deserializationand shell=True with untrusted input;
• limit subprocess, archive, networkand parser operations;
• not place credentials in notebooks, examples or committed configuration.

Libraries should provide wheels and source distributions where this materially improves buyer installation, especially when native extensions are involved. Native dependencies must state supported operating systems, architectures, compilersand system libraries.

Notebooks may supplement a product but should not be the only implementation of a production application unless the product is explicitly an educational or analysis notebook and is presented as such. Clear execution order and environment reproduction are required.

23.4 Ruby

Ruby products must:

• declare supported Ruby and framework versions;
• include a valid gem specification for a gem or a Gemfile and lockfile for an application;
• namespace public code;
• separate runtime and development dependencies;
• include migrations and update instructions for applications;
• use framework protections for CSRF, output escaping, sessions, passwords, mass assignmentand parameter filtering;
• avoid unsafe deserialization, dynamic evaluation, shell interpolationand untrusted constant lookup;
• filter secrets from logs;
• run tests against the declared supported versions.

Gems should avoid unnecessarily exact dependency pins that make integration impossible, while applications should resolve a reproducible release. Native extensions must document build requirements and supported platforms.

23.5 Java

Java products must:

• declare the required JDK or runtime and target bytecode level;
• include a working Maven, Gradle or documented equivalent build;
• identify the produced JAR, WAR, EAR, native image or application package;
• distinguish build-time and runtime dependencies;
• avoid bundling conflicting copies of common libraries without relocation or justification;
• handle character encoding, locale, timezoneand resource loading consistently;
• close files, streams, database connections, executorsand other resources;
• avoid unsafe native deserialization of untrusted data;
• harden XML parsers against external entities;
• avoid dynamic class loading or reflection from untrusted names;
• not disable TLS validation;
• use established cryptographic providers and algorithms;
• avoid logging secrets and tokens.

Executable JARs or native packages must not be the only delivery when the product is sold as source. Signing may be used for distribution, but private signing keys must never be included.

Server applications must document the servlet container, application server, framework, memory, databaseand deployment assumptions. Desktop applications must document supported operating systems and packaging.

23.6 C# / .NET

C# and .NET products must:

• include the solution and project files needed to restore and build;
• declare explicit target frameworks;
• target a supported .NET release unless legacy support is central and disclosed;
• declare operating-system-specific requirements;
• use reproducible NuGet package references and trusted sources;
• avoid package-source ambiguity and dependency confusion;
• not include private NuGet credentials;
• use safe configuration providers and secret storage;
• dispose of unmanaged and disposable resources;
• use asynchronous APIs correctly without hidden deadlocks or unbounded parallelism;
• validate serialization types and avoid dangerous polymorphic deserialization;
• use parameterized database access;
• use framework authentication, authorization, data protection, CSRFand output encoding for ASP.NET products;
• avoid unsafe process execution, dynamic assembly loadingand certificate bypass.

Warnings related to nullable reference types, analyzers or platform compatibility should be addressed or intentionally documented. Release output must not depend on Visual Studio being installed unless the product is explicitly a Visual Studio extension.

NuGet libraries must include accurate package metadata, license, symbols or source-link strategy where appropriate, dependencies, target frameworksand public API documentation. Desktop applications must state whether they use Windows-only technologies such as WPF, WinForms, COM, registry integration or platform services.

23.7 Multi-language products

Products using several runtimes must define the boundary and build order. Each component must have its own dependency declaration, configuration, testsand version compatibility.

A JavaScript frontend plus PHP, Python, Ruby, Java or .NET backend must not duplicate secrets into the frontend. Native helper binaries must be documented, licensedand available for every claimed operating system and architecture.

24. CMS, frameworkand commerce-platform requirements

Products extending a host platform must use its supported extension architecture. Direct core edits, copied core files, broad overridesand instructions that are destroyed by a normal update are blockers unless the platform explicitly defines that delivery method.

Every extension must:

• use a unique machine name or vendor namespace;
• declare platform and runtime compatibility accurately;
• install through the platform’s normal process;
• register permissions, routes, services, events, hooks, assets, translationsand configuration correctly;
• preserve unrelated platform behavior;
• include upgrade routines;
• uninstall without deleting unrelated data;
• use platform security APIs;
• test with a representative existing site, not only an empty installation;
• state compatibility with editions, distributions, multi-site modes, stores, languages, themesand required companion products.

24.1 Concrete CMS Add-ons

A Concrete CMS add-on must be delivered as a correctly structured package using Concrete’s package system.

It must:

• use a unique lowercase package handle and matching folder;
• place the package controller where the supported Concrete package format expects it;
• declare package name, description, versionand application-version requirements accurately;
• implement installation, upgradeand uninstallation through supported package lifecycle methods;
• register blocks, dashboard pages, single pages, jobs, entities, themes, attributes, permissionsand routes through supported APIs;
• namespace PHP classes and avoid global collisions;
• use the asset system for scripts and styles;
• use Concrete localization APIs rather than hard-coded interface text;
• use the platform database and schema tools for custom tables;
• enforce permissions on dashboard pages, AJAX handlers, routesand operations;
• protect state-changing requests;
• validate files and user input;
• avoid editing /concrete, application core or another package;
• declare package dependencies and version constraints.

Blocks must separate edit/add forms from view output and must scope their CSS and JavaScript. A block must support multiple instances unless it is explicitly documented as a single-instance application component.

Package upgrades must preserve block and entity data. Uninstall must clearly distinguish between removing the package code and destroying content created with it.

24.2 Drupal Modules

A Drupal module must follow the current supported Drupal extension structure and Drupal coding standards.

It must:

• use a unique valid machine name;
• include accurate .info.yml metadata and core compatibility constraints;
• place PSR-4 classes in the expected namespace;
• declare services, routes, permissions, menus, links, libraries, configuration schemaand dependencies correctly;
• use dependency injection for services where appropriate;
• use hooks, events, plugins, servicesand render APIs instead of editing core;
• enforce route access and entity access;
• use render arrays, Twigand the platform’s escaping model correctly;
• attach JavaScript and CSS through Drupal libraries;
• provide cache tags, contextsand maximum age appropriate to personalized output;
• use the database API and entity/query systems safely;
• use configuration for deployable settings and state/key-value storage for environment-specific runtime state;
• provide update hooks or post-update functions for schema and data changes;
• declare permissions narrowly;
• support translation through Drupal string APIs;
• avoid deprecated APIs within the declared compatibility range.

Module forms and state changes must use Drupal Form API and CSRF protections. Custom controllers, REST resources, AJAX callbacks, batch operationsand queues must validate access independently.

Configuration entities, content entities, field storageand custom tables must have an update and uninstall strategy. Default configuration must not overwrite administrator changes on every request or update.

If the module includes third-party libraries, Composer requirements and license compatibility must be documented. Do not commit an entire Drupal installation or unrelated vendor tree as the module.

24.3 Joomla Extensions

A Joomla extension must be packaged for installation through Joomla’s Extension Manager and must include a valid manifest.

It must:

• declare extension type, element, version, namespace, files, language files, database updatesand minimum Joomla/PHP requirements accurately;
• use a unique element and namespace;
• follow Joomla’s supported MVC, service-provider, plugin-event, module, component, library or package architecture;
• use Joomla’s database API and quoted/parameterized query mechanisms;
• use ACL permissions and verify them at the executing action;
• validate request tokens for state changes;
• use the input API and contextual output escaping;
• register assets through the Web Asset Manager where applicable;
• use language strings rather than hard-coded interface text;
• provide SQL install/update/uninstall files or supported migration logic;
• avoid editing Joomla core, templates owned by another product or shared files;
• define update behavior and dependency installation clearly.

A package containing several Joomla extensions must install and uninstall components in a safe order and must not leave a partially registered system after failure.

Administrator components must not assume that access to the administrator application alone grants permission to every action. Frontend forms, AJAX, web servicesand file operations require their own access and token controls.

24.4 Laravel Apps and Packages

The Laravel Apps category may contain a complete Laravel application or a Laravel package. The listing must identify which one is supplied.

Complete Laravel applications

A full application must:

• include the complete project and a valid Composer manifest;
• state the Laravel, PHP, Node.js, database, cache, queueand server versions;
• include .env.example without secrets;
• never include the seller’s live .env;
• generate a unique application key during installation;
• provide migrations and safe seeders;
• document storage linking and writable directories;
• document scheduler and queue-worker setup;
• provide production asset-build commands and production output where appropriate;
• disable debug mode in production;
• configure trusted proxies, hosts, CORS, cookies, sessions, mail, filesystemand queues safely;
• use Laravel validation, authorization policies/gates, CSRF protection, password hashing, encryption, signed URLsand rate limiting appropriately;
• avoid mass-assignment exposure;
• escape Blade output by default and clearly mark reviewed raw HTML;
• use jobs for long tasks and make them idempotent where retries are enabled;
• provide an initial-admin setup that does not ship a universal password.

The application must not rely on php artisan serve as its production deployment. Cache-building commands must succeed with the supplied configuration. Production deployment instructions should cover maintenance mode, migration ordering, workers, cache clearingand rollback constraints.

Laravel packages

A package must:

• use a unique Composer vendor/package name and namespace;
• register a service provider and package discovery correctly;
• publish configuration, views, translations, migrationsand assets only when needed;
• avoid overwriting buyer files;
• merge configuration rather than assuming it owns the application configuration;
• use configurable routes, middleware, table namesand prefixes where collision is possible;
• document how migrations are loaded or published;
• avoid depending on application-specific models, users, guards or frontend structure without an abstraction or explicit requirement;
• provide a clear public API and tests against supported Laravel versions.

24.5 Magento Extensions

Magento and Adobe Commerce products must follow the supported module and Composer package architecture.

An extension must:

• be a valid Composer package of the appropriate Magento type;
• include accurate composer.json, registration.phpand etc/module.xml;
• declare a unique vendor/module name, sequence only when required, PHP constraintsand Magento dependencies;
• install through Composer and Magento setup commands;
• compile successfully in production mode;
• avoid editing core or vendor;
• prefer service contracts, dependency injection, events, pluginsand supported extension points;
• minimize preferences and broad class overrides;
• use declarative schema and data/schema patches appropriate to the supported versions;
• declare ACL resources and verify authorization;
• use form keys and platform request protections;
• escape storefront and administration output;
• use repositories, resource models, collectionsand the database abstraction safely;
• preserve cache, full-page cache, indexer, Varnishand cron behavior;
• support the claimed store views, websites, currencies, tax, localeand customer groups;
• include upgrade and uninstall behavior.

Extensions that modify catalog, cart, checkout, order, invoice, shipment, credit memo, customer, pricing, inventory, tax or payment behavior must test the complete affected lifecycle. Do not overwrite a final price, order total, inventory state or payment result from client input.

REST, SOAPand GraphQL additions must declare resources and authorization correctly. GraphQL resolvers must consider query cost, cache identityand object-level access.

Admin configuration must use encrypted backend models or another appropriate protected store for credentials. Secrets must not be rendered back in full.

Extensions claiming Adobe Commerce compatibility must test features specific to that edition where relevant. A Magento Open Source test alone does not establish Adobe Commerce compatibility.

24.6 Moodle Plugins

A Moodle plugin must use the correct plugin type, folder, component nameand file structure.

It must:

• include valid version.php metadata with the correct component, version, release, maturityand Moodle requirement;
• use the Moodle frankenstyle component prefix consistently;
• define database schema through db/install.xml and updates through db/upgrade.php where applicable;
• define capabilities in db/access.php;
• use require_login, contextand has_capability or require_capability checks;
• validate state-changing requests with sesskey;
• use required_param, optional_paramand correct parameter types rather than reading request superglobals directly;
• use the Moodle database API with placeholders;
• use get_string and English language files for interface text;
• use Moodle output/rendering APIs and escape output correctly;
• namespace classes and avoid global collisions;
• scope CSS to the plugin;
• declare scheduled tasks, external functions, events, message providersand services through supported files;
• support backup and restore when the plugin type stores course or activity data that requires it;
• implement the Privacy API when personal data is processed or declare the appropriate null provider;
• avoid requiring an administrator to run Composer for normal plugin installation;
• work with the claimed supported database engines.

Third-party libraries must be documented and licensed compatibly with Moodle. They should be recorded through the platform’s expected third-party inventory mechanism.

Activity modules must implement the expected lifecycle, gradebook, completion, reset, backup/restoreand mobile behavior where those features are claimed. Grade, enrollment, completionand capability decisions must not be controlled by a hidden client field.

Plugin updates must not edit core tables directly when a Moodle API existsand uninstall must not remove shared course or user data belonging to another component.

24.7 OctoberCMS Plugins

An October CMS plugin must use the supported Author.Plugin structure and registration lifecycle for the declared October version.

It must:

• use a unique author and plugin code;
• include a valid Plugin.php registration file;
• declare plugin details, dependencies, permissions, navigation, components, settingsand services correctly;
• include updates/version.yaml and versioned migrations;
• namespace PHP classes consistently;
• use October and Laravel services rather than editing CMS core;
• enforce backend permissions and frontend authorization at the executing action;
• use the platform AJAX framework and CSRF protections correctly;
• validate file uploads and model input;
• use backend form/list definitions safely;
• register assets through the supported controller or component mechanisms;
• use message and language files for translatable text;
• avoid assuming a particular theme unless declared;
• provide uninstall and data-retention behavior.

Frontend components must define clear properties and must not expose unrestricted model fields or methods to AJAX handlers. Backend widgets, controllersand settings must use unique aliases and permission codes.

The plugin must state whether it targets October CMS’s current paid distribution, an older major line or a related fork. Compatibility with one must not be presented as compatibility with all.

24.8 Odoo Apps

An Odoo app must be delivered as a valid add-on module with a correct __manifest__.py.

It must:

• use a unique technical module name;
• declare version, dependencies, data, demo, assets, licenseand installability accurately;
• use supported models, fields, views, actions, menus, reports, controllersand inheritance;
• use the ORM rather than raw SQL when practical;
• use parameterized queries when SQL is necessary;
• define access rights and record rules;
• treat sudo() as an exceptional privilege escalation and scope it narrowly;
• enforce authorization in controllers and object operations;
• use CSRF protection for relevant HTTP routes;
• escape QWeb output and avoid unsafe raw rendering;
• avoid monkey patches and edits to Odoo core;
• avoid hard-coded database IDs and environment-specific XML IDs;
• use translation mechanisms;
• support the claimed Community or Enterprise edition explicitly;
• support multi-company, multi-currency, timezone, languageand access context where the feature requires it;
• include safe upgrade and migration behavior.

Data files must load in a deterministic order. Security definitions must be installed before menus or actions that expose protected records. Demonstration data must be separated from required production data.

Automated actions and scheduled jobs must not run with unrestricted sudo() across all companies without a justified and tested scope. Mail, portal, website, accounting, stock, payrolland payment extensions must preserve Odoo’s workflow and record rules.

Uninstall must not delete core or shared records. Records intentionally retained must be documented.

24.9 OpenCart Extensions

An OpenCart extension must state the exact supported OpenCart major and minor versions. OpenCart 3 and 4 use materially different extension structures; a product must not claim both unless both packages are supplied and tested.

For the targeted version, the extension must:

• use the documented extension package structure and installer;
• include accurate installation metadata;
• use a unique extension code and namespace;
• follow the platform MVC-L structure;
• use events and supported extension mechanisms rather than editing core;
• keep modifications narrow when OCMOD or an equivalent platform mechanism is genuinely needed;
• register administration and catalog controllers, models, language files, templatesand events correctly;
• enforce user-group permissions for administration actions;
• validate user tokens and state-changing requests;
• use the database driver and database prefix;
• escape Twig output and validate input;
• support the claimed languages, currencies, stores, tax modesand customer groups;
• include install, upgradeand uninstall routines;
• refresh or document modification and event caches where required.

Extensions must not overwrite shared language, theme, controller or core files through direct upload.

Payment and shipping extensions must verify cart ownership, amount, currency, provider response, signature, replay, order state, refund/cancellation behaviorand multi-store configuration. A client-selected gateway value must not permit bypassing payment.

24.10 PrestaShop Plugins

A PrestaShop product must be a valid installable module for the declared PrestaShop versions.

It must:

• use a unique lowercase module name and matching root folder;
• include the main module class and accurate name, version, author, compatibilityand dependencies;
• use hooks and services rather than core overrides wherever possible;
• avoid core edits;
• register and unregister hooks deliberately;
• use configuration keys with a unique prefix;
• use PrestaShop validation, request, security-token, database, translationand output APIs;
• support multistore behavior for settings and data where claimed;
• support the declared languages, currencies, tax configurationand shop context;
• provide versioned upgrade scripts;
• uninstall without deleting unrelated configuration or merchant data;
• pass the relevant PrestaShop validation tools without unresolved material issues.

Overrides are collision-prone and must be avoided for marketplace products unless no supported hook or extension point can implement an essential feature. Every override requires a documented reason and compatibility testing with another extension.

Payment modules must verify cart identity and ownership, authoritative amount, currency, provider authenticityand replay before validating an order. They must handle asynchronous and duplicate callbacks correctly and must not create a paid order solely from client input.

Admin controllers and AJAX actions must enforce employee permissions and tokens. Front-office actions must enforce customer/cart ownership.

24.11 Shopify Apps

A Shopify product may be a public app source project, custom-distribution app source, theme app extension, checkout UI extension, function or another supported Shopify app type. The listing must identify the actual type and must not guarantee App Store approval.

The app must:

• use Shopify’s current supported app architecture and APIs;
• declare the supported API version and update it before deprecation;
• use Shopify-managed installation, session tokens, token exchange, OAuth or the currently appropriate official authentication method;
• verify installation and callback HMAC values;
• request only necessary scopes;
• store shop tokens securely and isolate them by shop;
• validate the canonical shop domain;
• handle token revocation and uninstall;
• verify webhook signatures using the raw request body;
• process webhooks idempotently and handle retries/out-of-order events;
• implement required privacy or compliance webhooks for the app’s distribution model;
• serve production traffic over valid TLS;
• configure Content-Security-Policy frame-ancestors correctly for embedded or standalone operation;
• use App Bridge and the supported Shopify UI system where the app type requires them;
• respect GraphQL cost and platform rate limits;
• preserve merchant, store, userand resource authorization boundaries;
• avoid exposing the Shopify API secret in frontend code.

The listing must state who operates and pays for the required backend. If the buyer receives only frontend code while the seller’s server remains essential, it is not a complete self-hosted app.

Billing must use Shopify’s supported billing mechanisms for the distribution type. The app must not falsely report a subscription as active based on a client callback. Uninstall must stop charges and background access according to the actual platform lifecycle.

Extensions must not request broad customer, order, product or content scopes merely for future use. Protected customer data, payment, checkoutand regulated data access must be disclosed and handled according to Shopify’s current policies.

Products described as “Shopify App Store ready” must be tested against the current submission requirements, but WPBay approval does not predict or guarantee Shopify approval.

24.12 TYPO3 Extensions

A TYPO3 extension must use a unique valid extension key and the supported extension architecture for the declared TYPO3 versions.

It must:

• include accurate Composer metadata and TYPO3 constraints where Composer mode is supported;
• provide required extension metadata and registration files;
• use PSR-4 autoloading and namespaces;
• register services, dependency injection, events, backend modules, routes, plugins, content elements, TypoScript, TCAand assets through supported mechanisms;
• use Doctrine DBAL QueryBuilder or Extbase persistence correctly;
• parameterize custom queries;
• use Fluid’s escaping model and avoid unsafe raw output;
• enforce backend, frontend, record, page, fileand route permissions;
• validate request tokens for protected state changes;
• use the File Abstraction Layer for managed files;
• use XLIFF language files;
• preserve cache and workspace behavior;
• avoid editing TYPO3 core or shared configuration;
• provide database schema, migrations, update wizardsand compatibility notes;
• define data-processing and cleanup behavior.

TCA and TypoScript must be scoped to the extension and must not unexpectedly replace global configuration. Custom content elements must work in the backend preview and frontend and must preserve localization and workspace behavior where claimed.

Products must distinguish legacy Extbase/Fluid implementation from current platform APIs and must not claim compatibility merely because installation succeeds.

25. Mobile script requirements

The Mobile Scripts parent category and its Android, Flutter / React Nativeand iOS child categories must meet this section.

A mobile script is normally sold as source code. It must include a complete buildable project, not only a binary, screenshots or exported UI.

25.1 Common mobile package requirements

The package must include:

• readable application source;
• complete platform projects;
• dependency declarations and application lockfiles;
• app icons, launch assets, fontsand media with redistribution rights;
• build configurations;
• backend or API source when advertised as included;
• safe configuration examples;
• release-build instructions;
• instructions for changing display name, application ID or bundle identifier, URL schemes, deep links, icons, signing teamand service configuration;
• required native SDK and tool versions;
• a list of platform permissions and why they are needed;
• test or demo data;
• store-submission responsibilities and limitations.

Do not include:

• signing keystores;
• signing private keys;
• provisioning profiles tied to the seller;
• App Store Connect or Google Play credentials;
• Firebase or cloud administrator credentials;
• push-notification private keys;
• production service secrets;
• a shared bundle identifier or package name that buyers cannot safely transfer;
• development certificates;
• seller analytics or advertising accounts that continue tracking buyers.

The buyer must be able to replace all service and signing identities.

25.2 Common mobile behavior

Mobile products must handle:

• launch, background, foreground, terminationand restoration;
• temporary and permanent network loss;
• slow API responses;
• denied or revoked permissions;
• token expiry;
• orientation, resize, safe areas, keyboardand supported device sizes;
• accessibility settings, font scaling, contrastand screen readers;
• dark/light appearance where claimed;
• local data migration after an update;
• deep links and universal/app links;
• notification permission and navigation;
• offline state and synchronization where advertised;
• cancellation and retry;
• low storage and interrupted download where relevant.

The production build must not contain localhost URLs, development menus, debug logging of private data, mock payment logic, test advertising IDs, certificate bypass or an open remote debugger.

25.3 Mobile security

Mobile applications must:

• request the minimum permissions at the point of need;
• explain sensitive permissions;
• degrade sensibly when optional permission is denied;
• use Keychain, Keystore or another platform-protected store for high-value tokens;
• avoid treating a secret embedded in the binary as confidential;
• use TLS;
• validate deep-link parameters and destination ownership;
• restrict exported Android components and iOS URL handling;
• protect WebViews and JavaScript bridges;
• verify backend authorization independently of the app;
• not trust device-side price, entitlement, role, subscription or payment state;
• avoid logging sensitive data;
• use maintained SDKs.

Certificate pinning may be used when the seller documents rotation and failure recovery. A broken hard-coded pin that permanently disables the product is not acceptable.

25.4 Store and policy claims

The source must be technically suitable for the platform it claims to target, but WPBay does not guarantee acceptance by Apple, Google or another store. Store requirements can change and may depend on the buyer’s content, business model, account history, region, privacy disclosures, SDKsand branding.

The seller must not:

• promise guaranteed store approval;
• use another app’s name, icon, bundle identifier, screenshots or store listing;
• include hidden or undocumented features;
• use private platform APIs without disclosure and justification;
• bypass platform billing or privacy rules;
• include copied store assets.

25.5 Android

Android source must:

• include a complete Gradle project and wrapper;
• declare namespace, application ID, minimum SDK, target SDK, compile SDKand dependencies accurately;
• target the current level required for the intended Google Play submission when “Play Store ready” is claimed;
• build a release variant without the seller’s signing key;
• declare every permission, component, provider, service, receiver, intent filterand feature correctly;
• set exported-component behavior explicitly;
• use secure file sharing and content providers;
• avoid cleartext traffic unless a specific local use is documented and tightly configured;
• use safe WebView settings;
• avoid loading executable code from outside the application package;
• use Android background-work APIs rather than uncontrolled persistent services;
• handle process death and configuration changes;
• preserve app state and standard back navigation;
• include required data-safety and permission disclosure guidance for the buyer.

The product should follow Android’s current core app quality and security guidance. Android App Bundles, signing, Play Integrity, in-app billing, notifications, background location, accessibilityand sensitive permissions must be implemented according to the current platform rules when advertised.

An APK may be included for demonstration, but it does not replace source and a reproducible build.

25.6 iOS

iOS source must:

• include a complete Xcode project or workspace and all required local packages or dependency declarations;
• declare the deployment target and supported devices;
• build without the seller’s signing identity;
• allow the buyer to replace bundle identifiers, teams, capabilities, associated domains, URL schemes, service filesand entitlements;
• include accurate purpose strings for protected resources;
• use App Transport Security appropriately;
• use Keychain or another appropriate protected store for tokens;
• avoid private APIs and undocumented system behavior;
• handle application and scene lifecycle;
• validate universal links and custom URL schemes;
• support safe-area, rotation, dynamic type, VoiceOverand appearance behavior where applicable;
• include privacy manifests and required SDK privacy information where the current Apple rules require them;
• document push notifications, in-app purchases, background modes, Sign in with Appleand associated capabilities when used.

App Store publication requires the buyer’s Apple Developer membership, macOS, Xcode, certificatesand App Store Connect setup. These requirements must be disclosed.

An IPA or archive is optional and does not replace a buildable project.

25.7 Flutter

Flutter applications must:

• include pubspec.yaml and an application lockfile;
• declare a tested Flutter and Dart SDK range;
• include the complete Android and iOS platform projects for claimed targets;
• include web, desktop or other platform directories only when those targets work and are documented;
• avoid stale generated plugin registration;
• build release variants for every claimed platform;
• separate environment flavors without embedding production secrets;
• replace seller bundle IDs, signing, service filesand analytics identities;
• use maintained packages compatible with the declared Flutter version;
• document code generation and generated files;
• handle navigation, lifecycle, platform permissions, deep links, notificationsand native integrations on each platform.

The presence of an Android and iOS folder does not prove both platforms work. Platform-specific features must be tested on each target.

25.8 React Native

React Native applications must:

• include package.json, a lockfileand complete native Android and iOS projects;
• declare the tested React Native, Node.js, package-manager, JDK, Android, CocoaPods, Rubyand Xcode requirements as applicable;
• build release variants without Metro or a development server;
• avoid localhost and development bundle URLs;
• keep native dependency linking and configuration consistent;
• document code generation, new architecture, Hermes, Expo or bare-workflow assumptions;
• supply all required native permission and service configuration;
• replace seller package IDs, signing identities, service filesand remote endpoints;
• handle native module errors and platform differences;
• remove debugging libraries from production.

An Expo product must state whether it uses managed, prebuild, development-client or bare workflow and must document any paid Expo service dependency.

25.9 Mobile backends and subscriptions

When a mobile app requires a backend:

• the backend source must be included if the listing says it is included;
• deployment must be documented;
• mobile and backend versions must be compatible;
• authentication and authorization must be enforced by the backend;
• push, storage, paymentand subscription flows must not trust device claims;
• account deletion and data export must cover backend data;
• API keys restricted by mobile application identity are not a substitute for backend authorization.

If the seller operates the backend, this dependency, pricing, limits, data processing, continuityand support must be prominent on the listing.

26. Database, CLI, desktopand miscellaneous products

26.1 Database Tools

In addition to Section 15, products in Database Tools must:

• identify the supported engines and versions;
• use the minimum necessary database privileges;
• support TLS and certificate verification for remote connections where available;
• never ship saved live credentials;
• protect connection profiles;
• handle large datasets through streaming, batching, cursors or pagination;
• preserve character set, collation, precision, timezone, null, binaryand identifier behavior;
• quote identifiers correctly for the target engine;
• provide a dry run for destructive transformations where practical;
• show the exact database, schema, tables, rows or objects affected;
• support backup and restore verification when advertised;
• handle interrupted migration or export;
• not expose a public unauthenticated database administration interface.

SQL formatters, query builders, visual clients, migration generators, schema comparison toolsand converters must preserve meaning and clearly report unsupported syntax. Generated SQL must not be executed automatically against production merely because generation succeeded.

26.2 Command-line tools

CLI products must:

• use predictable command and option names;
• provide --help and version output;
• use standard exit codes;
• separate machine-readable output from human progress;
• support non-interactive use when advertised for automation;
• avoid prompts when standard input is not interactive unless explicitly requested;
• never place secrets in command history by default;
• redact sensitive values from errors;
• support safe path handling;
• provide dry-run and confirmation for destructive operations;
• handle signals and partial output;
• clean up temporary files and child processes;
• document environment variables and precedence.

Destructive commands should require an explicit flag or confirmation and must not infer a broad target from an empty variable or current working directory.

26.3 Desktop source projects

Desktop applications must identify supported operating systems, architectures, runtimes, installers, privileges, filesystem locations, update modeland code-signing responsibilities.

They must:

• not require administrator privileges for ordinary use without need;
• store user data and configuration in appropriate platform locations;
• uninstall without removing unrelated files;
• use secure update transport and integrity checks;
• avoid opening unnecessary network listeners;
• protect local IPC;
• validate file associations and custom URLs;
• handle multiple monitors, scaling, localizationand accessibility where relevant;
• avoid bundling outdated embedded browsers or runtimes.

26.4 Miscellaneous

The Miscellaneous category follows every common requirement in this page. The seller must clearly identify:

• language and runtime;
• delivery model;
• operating environment;
• dependencies;
• installation and update path;
• security boundary;
• applicable external platform policies.

If review shows that another category applies, WPBay may move the product or require the relevant overlay. Unusual technology does not reduce the need for readable source, documentation, secure behavior, testingand maintenance.

27. Installation, upgrades, uninstallationand licensing

27.1 Installation must be reproducible

A reviewer and an ordinary buyer with the documented prerequisites must be able to install the product from a clean environment by following the supplied instructions.

The installation process must:

• verify required runtime, extensions, services, permissions, storageand platform versions before making material changes;
• explain whether commands run as an ordinary user, service account, application owner, database owner, root or administrator;
• use the minimum privileges necessary;
• distinguish development setup from production deployment;
• provide safe example configuration;
• fail with an actionable message when a prerequisite is absent;
• avoid leaving an unknown half-installed state;
• be repeatable or safely detect that installation has already occurred;
• not silently overwrite an existing application, configuration file, database, account, virtual host, scheduled task, service or unrelated directory;
• not download executable code from an undocumented source;
• not require the seller’s private credentials, local files, internal network or unpublished packages.

If installation changes a web server, operating-system service, firewall, database server, scheduler, package registry, mobile project, CMS configuration or cloud account, every change and the required permission must be documented before the buyer runs the command.

One-command installers are welcome, but convenience does not justify hidden operations. An installer must display or document what it creates, changes, downloadsand starts. Destructive or security-sensitive actions require explicit confirmation unless the operation is running in a clearly documented non-interactive deployment mode.

Container images, Docker Compose projects, infrastructure templates, virtual-machine imagesand installation shell scripts must follow the same requirements as application source. They must use maintained base images, avoid embedded secrets, pin or constrain important dependencies, expose only required ports, use non-root execution where practicaland document persistent volumes, health checks, backups, upgradesand resource needs.

27.2 Upgrades and migrations

An update must preserve supported customer data and configuration unless a breaking change is clearly disclosed and justified.

The seller must test:

• a clean installation of the submitted version;
• an upgrade from the most recent public version;
• every older version from which direct upgrade is advertised;
• sequential upgrades when direct upgrade is not supported;
• database, filesystem, configuration, cache, queueand search-index migrations;
• interrupted or repeated migration behavior;
• background migration completion;
• rollback behavior where rollback is advertised;
• compatibility between application, mobile client, API, workerand database versions during staged deployment.

Migrations must:

• have a stable ordering and recorded state;
• be idempotent where the framework expects repeatable execution;
• use transactions where supported and appropriate;
• avoid loading an entire large dataset into memory;
• preserve data types, identifiers, relationships, precision, timezone, encodingand permissions;
• detect incompatible schemas instead of guessing;
• report failures clearly;
• not mark a migration complete before its material work succeeds;
• provide a backup recommendation when meaningful data is at risk;
• document operations that can lock tables, require downtime, rebuild indexes or take significant time.

Backward-incompatible changes to public APIs, configuration, database schema, extension points, command syntax, output format, authentication, minimum platform versions or third-party services must appear prominently in the changelog and upgrade guide. A semantic-version number does not replace an explanation.

If an update cannot be safely rolled back after a database migration, state that before installation and provide a tested backup-and-restore path. “Restore your backup” is useful only when the documentation identifies what must be backed up and how the restored application version will remain compatible with it.

27.3 Uninstallation and data retention

The product must document what happens when it is disabled, disconnected or uninstalled.

Uninstallation must:

• remove only files, services, jobs, routes, accounts, database objects, configuration, webhooks, tokensand resources created by the product;
• never infer a broad deletion target from an empty variable, relative path, wildcard, current directory or unverified configuration value;
• not remove shared dependencies or user-created content merely because the product once used them;
• stop workers, schedulers, listenersand background jobs safely;
• revoke or provide instructions to revoke credentials and external webhooks that are no longer required;
• allow the buyer to retain or export meaningful data when retention is reasonable;
• clearly warn and require confirmation before permanently deleting customer data;
• document data that remains with a third-party or seller-hosted service.

For libraries and source components, “uninstallation” may mean package removal. The package must still avoid post-uninstall scripts that delete unrelated data or alter the host system unexpectedly.

Products must not use customer data as leverage after a license expires or a service is cancelled. Buyers must retain a reasonable way to access, export, migrate or remove their own data, subject to the product’s disclosed technical model and applicable law.

27.4 Product licensing and activation

If the product uses license activation, the listing and documentation must state:

• what functionality requires activation;
• whether activation is required for initial use, updates, support, cloud features or all of these;
• the number and type of permitted installations or devices;
• how development, staging, test, localand replacement environments are counted;
• how a buyer deactivates or transfers an installation;
• what happens when the license expires, is refunded, cannot be verified or the licensing service is unavailable;
• what data is sent to the licensing service;
• how often validation occurs;
• whether the product can operate temporarily or permanently without network access.

License checks must:

• use HTTPS with certificate verification;
• use authentication appropriate to the protocol;
• have short connection and total timeouts;
• cache successful state so normal requests do not depend on a live licensing call;
• handle rate limits and temporary outages gracefully;
• avoid exposing license keys in URLs, logs, analytics, error pages, screenshots or client-side code when the key is intended to be secret;
• validate responses before trusting them;
• not accept a forged local flag as proof of entitlement;
• not create a performance bottleneck by validating on every page view, request, command or render.

An inactive or expired license may disable updates, support, premium remote services or clearly identified premium features consistent with the sale terms. It must not corrupt data, delete content, introduce security vulnerabilities, display unrelated public advertising, disable basic data export or make the buyer’s existing site or application fail unexpectedly.

License enforcement must not be disguised as telemetry. The transmitted fields must be limited, documentedand protected. WPBay may require a reviewer license or another practical review method.

27.5 Update delivery

A built-in updater or update server must be at least as secure as the application it updates.

Update systems must:

• retrieve metadata and packages over HTTPS;
• authenticate access when updates are restricted;
• verify package integrity with a cryptographic signature, trusted checksum or a platform-native equivalent;
• bind integrity metadata to the expected product, versionand channel;
• reject malformed, downgraded, unexpected or incompatible packages;
• extract archives without path traversal, symlink escape or overwrite of unrelated files;
• avoid executing downloaded code before verification;
• preserve configuration and user data;
• use an atomic replacement, maintenance mode or another safe installation method;
• retain enough state to recover from interruption;
• report the installed and available versions accurately.

The product must not download and execute arbitrary code controlled by an unauthenticated request, untrusted URL parameter, public paste, mutable gist, DNS-only trust decision or unsigned remote response. Update endpoints, repositories, release channelsand any seller-hosted dependency must be documented.

If the host platform provides a standard update mechanism, use it unless there is a documented technical reason not to. Replacing a platform’s updater with a less secure custom mechanism is a blocker.

27.6 Service continuity

When a product materially depends on infrastructure operated by the seller, the product page must make that dependency unmistakable. This includes licensing servers, relays, AI gateways, notification services, hosted databases, update servers, mobile backends, scraping proxies, payment intermediariesand proprietary APIs.

The seller must document:

• the service’s purpose;
• included and separately billed usage;
• material rate, storage, model, regionand retention limits;
• expected behavior during outage or cancellation;
• the buyer’s export or migration path;
• which features continue locally;
• whether the service is required after installation;
• the support and maintenance responsibility.

WPBay may require a correction, migration plan or temporary product disablement if an essential seller-operated service is materially degraded, discontinued, compromised or changed in a way that makes the product description inaccurate.

28. Testing required before submission

Testing must reflect the product’s actual risks and support claims. A static CSS component does not need the same test program as a payment application, but every product must be tested beyond the seller’s original development environment.

28.1 Minimum test matrix

The seller must complete the applicable parts of this matrix before submission.

The reviewer may ask for a test account, demo credentials, API sandbox, sample payload, test dataset, build log, automated-test output or short reproduction instructions. Such evidence supplements review; it does not replace a usable package.

28.2 Functional tests

Functional tests must cover:

• first run and ordinary repeat use;
• all advertised features and settings;
• empty, minimum, normal, maximum, invalid, duplicate, expiredand boundary input;
• failure and recovery paths;
• multiple users and roles where supported;
• localization, timezone, currency, number, date, encodingand right-to-left behavior where claimed;
• imports, exports, backups, restores, migrations, scheduled tasks, queues, email, notifications, uploadsand downloads where present;
• caching on and off;
• relevant third-party sandbox and production-like responses;
• disabling or removing optional dependencies;
• navigation from the documented starting point.

Placeholder buttons, unreachable screens, hard-coded sample values, fake counters, simulated integrations presented as realand settings that do not affect behavior are blockers.

28.3 Security tests

Security testing must be based on the product’s attack surface, not a generic scanner alone. Test as applicable:

• authentication bypass and account enumeration;
• horizontal and vertical authorization failures;
• session fixation, expiry, revocationand concurrent-session behavior;
• cross-site request forgery;
• cross-site scripting in stored, reflected, DOM, templateand rich-content paths;
• SQL, NoSQL, LDAP, XPath, expression-language, operating-system commandand template injection;
• server-side request forgery and unsafe redirects;
• path traversal, archive extraction, arbitrary file read/write/deleteand upload execution;
• insecure deserialization and object injection;
• mass assignment and over-posting;
• webhook spoofing and replay;
• duplicate payment or order events;
• rate-limit and resource-exhaustion bypass;
• password reset, email change, API-token, invitationand account-recovery flows;
• sensitive data in source, build output, logs, URLs, browser storage, mobile packages, crash reportsand error responses;
• dependency vulnerabilities that affect the shipped configuration;
• insecure default configuration;
• debug endpoints, development servers, source maps, dashboards, sample accountsand test routes exposed in production.

Automated dynamic scans must be authorized and directed only at systems the seller owns or has permission to test. A clean scan report is not proof that authorization and business-logic controls are correct.

28.4 Integration and payment tests

API and integration products must test:

• valid, expired, revoked, missingand insufficient credentials;
• permission or scope changes;
• rate limits and quotas;
• pagination and partial result sets;
• slow, malformed, duplicated, reordered, staleand unavailable responses;
• API version changes within the declared support range;
• webhook signature failure, replay, duplication, reorderingand delayed delivery;
• safe retries and idempotency;
• clock skew;
• sandbox and live-mode separation;
• reconciliation after a local or remote failure.

Payment workflows must additionally test successful, failed, abandoned, delayed, disputed, refunded, partially refunded, duplicatedand asynchronous outcomes. Access to a product or order must follow verified server-side state, not a client redirect or mutable browser field.

28.5 Browser and accessibility tests

Browser-facing products must be tested in the current supported versions of the browsers named on the product page. Unless the listing deliberately limits support, this should include current Chromium-based browsers, Firefoxand Safari on relevant desktop or mobile platforms.

Test:

• keyboard-only operation;
• visible focus;
• semantic names and landmarks;
• zoom and text resizing;
• high-contrast or forced-colors behavior where relevant;
• reduced-motion preference;
• screen-reader output for essential workflows;
• responsive layouts at representative widths;
• touch targets and pointer alternatives;
• loading, error, empty, offlineand permission-denied states;
• network and CPU throttling for performance-sensitive interfaces;
• JavaScript errors and failed asset requests;
• localization expansion and long unbroken content.

Passing an automated accessibility checker is useful evidence, but manual keyboard and assistive-technology checks are still required for meaningful interactive products.

28.6 Mobile tests

Mobile source projects must be tested using release builds, not only a debug simulator build.

The test matrix must include, as applicable:

• the minimum and current supported operating-system versions;
• representative small and large screens;
• at least one physical device for each supported platform before release;
• fresh install, update, reinstall, restore, background, force-stopand low-storage behavior;
• denied, limited, revokedand changed permissions;
• offline, slow, captive, changingand interrupted networks;
• deep links and universal or app links;
• push notifications in foreground, backgroundand terminated states;
• orientation, safe areas, keyboard, accessibility text size, dark modeand localization;
• account creation, login, deletion, subscriptions, purchases, restoreand sign-out where present;
• release signing, production API endpointsand removal of debug menus and development credentials.

The seller is responsible for compliance with the applicable app-store rules. WPBay approval does not promise acceptance by Apple, Google or another distributor.

28.7 CMS, frameworkand commerce tests

An extension must be tested:

• on a clean supported host installation;
• on the declared minimum supported host version;
• on a current supported host version;
• with the host’s debug or developer mode enabled;
• with realistic roles and permissions;
• through install, enable, disable, upgradeand uninstall;
• with common cache, queue, cron, localizationand multisite or multistore modes that it claims to support;
• with no optional companion products installed;
• with every required companion product installed at a supported version;
• with representative core themes, templates, storefronts or administrative layouts where presentation is affected;
• alongside ordinary third-party extensions to detect broad namespace, route, event, dependency or asset conflicts.

The product must not produce uncaught exceptions, fatal errors, deprecation floods, broken administration pages, invalid generated markup, corrupted configuration, duplicate global symbols or uncontrolled database queries in supported configurations.

28.8 Automated quality controls

Use the official or ecosystem-standard tools appropriate to the project. Depending on the product, these may include:

• unit, integration, end-to-end, snapshot, contractand migration tests;
• formatters and linters;
• type checking;
• platform coding-standard checkers;
• static security analysis;
• dependency and container scanning;
• secret scanning;
• license and software-composition review;
• HTML and CSS validation;
• accessibility automation;
• mobile static analysis;
• package-manager integrity checks;
• test coverage reporting.

Test and analysis configuration must be included when it is part of the project. Do not suppress a genuine defect merely to achieve a clean report. Suppressions must be narrow, documentedand justified.

Warnings caused solely by optional development tooling may not block approval, but production errors, security findings, unsupported APIsand incompatibilities must be resolved or clearly demonstrated to be false positives.

28.9 Release verification

Before uploading, the seller must test the exact final archive—not only the source directory from which it was made.

Verify that:

• version numbers and changelog agree;
• production mode is enabled;
• debug output and development routes are disabled;
• real secrets, tokens, test payment credentials, signing files, private certificatesand personal data are absent;
• dependencies and build assets are complete;
• executable permissions and filename case are correct;
• archives do not contain another stale release accidentally;
• documentation matches the final UI and commands;
• demo and reviewer credentials work;
• checksum or signing information corresponds to the uploaded package;
• the listing’s compatibility, price dependencies, screenshotsand feature claims remain accurate.

29. Common approval blockers

The following issues normally result in Changes required. This list is illustrative, not exhaustive.

29.1 Package and build blockers

• The archive cannot be opened, installed, built or started using the instructions.
• The installable package is buried in an unexplained outer archive.
• Readable first-party source is missing.
• Only a minified bundle, binary, mobile build or compiled assembly is supplied.
• Required assets, migrations, manifests, lockfiles, dependencies, examples or build configuration are missing.
• The build depends on an unpublished package, inaccessible repository, private local path or seller credential.
• Production output cannot be related to the supplied source.
• The package contains secrets, personal files, backups, repository history, caches, unrelated binaries, temporary archives or development databases.
• Filename case or permissions make the package fail on a supported environment.
• The package performs undocumented privileged or system-wide changes.

29.2 Identity, compatibilityand documentation blockers

• Product names, namespaces, identifiers, manifests, archives, version numbersand changelog disagree.
• The selected category or delivery model is misleading.
• Minimum runtime, platform, database, browser, device, service or build-tool requirements are missing or inaccurate.
• Installation, configuration, build, update, migration, recovery or uninstall instructions are incomplete.
• Required API accounts, paid plans, quotas, model costs, app-store accounts, licenses or seller-hosted services are not disclosed.
• The documentation refers to missing screens, obsolete commands or a different product.
• Screenshots or demos show features, branding, integrations, data or layouts not delivered.
• Support, update, refund-related behavior or service continuity is materially misrepresented.
• A user must contact the seller merely to discover basic installation steps or obtain a required undeclared file.

29.3 Functional and quality blockers

• An advertised workflow is incomplete, placeholder-only or reproducibly broken.
• The product generates uncaught exceptions, fatal errors, persistent warnings, failed requests, console errors, corrupt output or blank screens during normal supported use.
• Settings are ignored or save unreliably.
• The product relies on hard-coded local URLs, paths, IDs, accounts, regions, currencies, credentials or demo records.
• Common failure conditions leave jobs, payments, records, files or migrations in an unknown state.
• Duplicate requests, retries or concurrent actions create duplicate records or charges.
• Code is needlessly monolithic, copied repeatedly, globally conflicting, impossible to configure safely or so poorly structured that normal maintenance is unreasonable.
• Public extension points, examples or APIs advertised to buyers are unstable or undocumented.
• Debug mode, test routes, sample administrator accounts, verbose stack traces or development servers are enabled in the release.

29.4 Security blockers

• A privileged action lacks authentication, authorization or request-intent protection.
• Authorization checks only hide the user interface while the endpoint remains callable.
• User-controlled data reaches a query, command, template, URL, path, header, redirect, parser or HTML context without appropriate validation and encoding.
• Passwords, tokens, private keys, license keys, payment secrets or personal data are hard-coded, publicly exposed, weakly protected or logged.
• Uploads can escape the intended directory, overwrite arbitrary files or become executable.
• Archive extraction is vulnerable to path traversal.
• A network fetch permits access to internal or local resources without an explicit safe design.
• TLS certificate verification is disabled.
• Cryptography is invented, obsolete or used with unsafe key, nonce, salt, mode or random-number handling.
• Passwords use reversible encryption or a fast general-purpose hash.
• Sessions are predictable, never expire, survive password changes incorrectly or are exposed to client script without need.
• Webhooks are accepted without signature verification, replay protection or idempotency where the provider supports them.
• A dependency with a known exploitable vulnerability is shipped without a tested mitigation or compelling justification.
• Security depends on obscurity, filename secrecy, client-side checks or an untrusted mutable field.

29.5 Data, privacyand external-service blockers

• Personal or sensitive data collection is undisclosed or excessive.
• Telemetry, analytics, crash reporting, AI processing, remote fonts, CDNs or seller-operated APIs are activated without disclosure or appropriate control.
• The product sends source, prompts, files, customer content, credentials or database records to an external service unexpectedly.
• Logs expose secrets or sensitive content by default.
• Data export, deletion, consent, retention or subprocessors are inconsistent with the product’s claims.
• Uninstall removes buyer data without a clear warning and choice.
• A required remote service has no documented cost, limit, outage behavior or cancellation effect.
• The product continues collecting data after its relevant feature is disabled.

29.6 API, paymentand automation blockers

• API authentication, scopes, rate limits, pagination, errors or version requirements are not handled.
• Secrets intended for a server are embedded in browser or mobile code.
• A payment or entitlement is trusted from a browser redirect rather than verified server-side.
• Money is represented with unsafe floating-point assumptions or without a defined currency/minor-unit model.
• Retries can duplicate a write, purchase, message, job or destructive action.
• Automation has no rate control, pause, stop, audit or recovery mechanism appropriate to its impact.
• A scraper ignores the declared target, escapes an allowlist or places credentials in logs.
• A background job can run concurrently without a lock or idempotent design and thereby corrupt state.
• A destructive batch action lacks preview, scope confirmation or usable error reporting.

29.7 Browser, CMSand mobile blockers

• Essential browser workflows are unusable by keyboard or lack accessible names, focus handling or readable error feedback.
• The interface breaks at claimed viewport sizes or in a claimed browser.
• Global CSS or JavaScript unexpectedly alters the host application.
• A CMS extension bypasses platform APIs, permissions, escaping, routing, dependency injection, schema or update mechanisms without justification.
• An extension conflicts broadly through generic namespaces, service IDs, routes, database names, events or asset handles.
• Mobile source cannot produce a release build from the supplied project.
• Mobile signing, package/bundle identifiers, capabilities, permissions, privacy declarations or store responsibilities are undocumented.
• The app requests unrelated sensitive permissions or embeds production secrets.
• Subscription, purchase restore, account deletion, deep-link or backend-authentication behavior is incomplete where advertised.

29.8 AI, scrapingand security-tool blockers

• An AI product presents generated output as guaranteed fact, legal determination, medical diagnosis, financial certainty or verified security result without appropriate controls and disclosure.
• Untrusted AI output can invoke privileged tools, queries, commands, URLs or filesystem actions without validation and authorization.
• Training, evaluation or demo data is included without clear rights.
• Model/provider dependencies, costs, limits, data handlingand fallback behavior are missing.
• A scraper has no target scoping, rate control, retry policy or legal/permission disclosure.
• A security tool lacks an explicit authorized-use boundary, safe defaults, target confirmation, audit trail or containment appropriate to its capabilities.
• A claimed scanner reports placeholder, random or unverified findings as real.

30. Outright rejection and prohibited behavior

Some products are not eligible for correction through ordinary resubmission. WPBay will reject products whose primary purpose, implementation or concealed behavior creates unacceptable harm, deception or legal risk.

30.1 Malicious software and concealed control

The following are prohibited:

• malware, ransomware, wipers, destructive payloads, credential stealers, keyloggers, spyware, cryptominers installed without informed consent, botnet components, backdoors, rootkits or hidden remote administration;
• code that exfiltrates credentials, private keys, payment data, personal content, source code, databases or system information without an explicit legitimate function and informed disclosure;
• concealed accounts, master passwords, secret endpoints, undocumented remote commands or seller access that bypasses the buyer’s authorization;
• remote kill switches that destroy, corrupt, ransom, publicly deface or deliberately disable buyer data or systems;
• code that downloads or executes an unreviewed payload to conceal the product’s actual behavior;
• deliberate evasion of malware scanners, static analysis, logging, review or platform protection;
• packages that modify security controls, antivirus exclusions, browser settings, DNS, proxies, startup items or system trust stores without an essential disclosed purpose and explicit authorization.

30.2 Fraud, abuseand unauthorized access

Products primarily designed to enable the following are prohibited:

• phishing, impersonation, credential harvesting, payment fraud or theft;
• credential stuffing, password spraying, account takeover, session theft or bypass of multifactor authentication;
• unsolicited bulk messaging, spam, fraudulent lead generation, fake reviews, fake followers, fake engagement, vote manipulation or mass account creation;
• bypass of paywalls, subscriptions, licensing, access controls, CAPTCHAs, rate limits, device protections, app-store rules or service restrictions;
• unauthorized exploitation, persistence, destructive denial of service, covert surveillance or evasion of lawful security controls;
• scraping, copying or republishing designed primarily to infringe copyright, violate privacy or defeat an access restriction;
• generation, sale, validation or laundering of stolen credentials, payment instruments, identity documents, license keys, coupons, tickets or accounts;
• tools marketed through claims that encourage use against systems, accounts, devices, people or data without authorization.

Legitimate testing, administration, migration, interoperability, researchand defensive security products may contain powerful functionality. Their documentation, defaults, target controls, permissionsand product positioning must make the authorized use case credible. Renaming an abusive tool as “educational” does not make it eligible.

30.3 Stolen, deceptive or unreviewable products

WPBay will reject:

• stolen, pirated, “nulled,” leaked, cracked or unlawfully redistributed code or assets;
• unauthorized clones, deceptive rebrandsand trivial reskins represented as original work;
• products containing third-party commercial components without redistribution rights;
• code intentionally obfuscated, encrypted, packed, generated or split across remote services to prevent meaningful review;
• fake applications, simulated integrations, fabricated scanners, misleading dashboards or products whose advertised core result is not produced;
• listings that materially conceal required fees, remote services, data collection, platform restrictions or the absence of a delivered core component;
• products submitted with forged licenses, falsified test reports, misleading screenshots, impersonated brands or false ownership claims.

Minification, compilation, release obfuscationand proprietary licensing are not prohibited by themselves. The rejection applies when they are used to conceal behavior or when readable reviewable source and necessary rights are not provided to WPBay.

30.4 Unsafe data and platform behavior

WPBay may reject rather than request changes when a product is fundamentally built around:

• indiscriminate destruction, publication or irreversible modification of third-party or buyer data;
• systematic collection or sale of sensitive data without a legitimate disclosed basis;
• unlawful biometric, surveillance, stalking or tracking behavior;
• impersonation of an official platform, financial institution, government body, healthcare provider or another person;
• unauthorized financial custody, transaction manipulation or deceptive investment claims;
• operation that inherently violates the applicable host platform’s core safety or developer rules;
• an essential seller-operated dependency that grants the seller undisclosed control over buyer systems or data;
• reckless security architecture that cannot be corrected without replacing the product’s core design.

30.5 Enforcement

Outright rejection may affect the product, related submissionsand the seller account. WPBay may preserve evidence, remove an approved listing, suspend downloads, notify affected buyers or cooperate with platform operators, payment providers, rights holders or authorities where appropriate.

A prohibited component cannot be cured merely by hiding it from the product description, moving it to a post-install download, calling it optional or asking the buyer to enable it after purchase.

31. Seller pre-submission checklist

Use this checklist against the exact archive and listing you intend to submit. A checked box should mean that the seller has personally verified the statement or has reliable test evidence.

Product scope and package

• [ ] The product is a complete, reusable software deliverable rather than an unfinished prototype, service-only offer, tutorial, prompt list or thin undisclosed wrapper.
• [ ] The selected category reflects the product’s main functionand every applicable category overlay in this page has been reviewed.
• [ ] The delivery model is clear: application, extension, library, component, CLI, browser product, mobile source, desktop source or hybrid.
• [ ] The installable or production package is easy to identify.
• [ ] Complete readable first-party source is included.
• [ ] Compiled, bundled, minified, transpiled, generated or obfuscated output has corresponding readable source and build settings.
• [ ] Required manifests, dependency declarations, lockfiles, migrations, schemas, assets, examplesand configuration templates are included.
• [ ] The exact submitted source can reproduce the supplied release output.
• [ ] The package contains no live secrets, personal data, private signing material, development databases, caches, unrelated archives or inaccessible dependencies.
• [ ] File permissions, filename case, directory structureand archive format work on every claimed platform.

Identity, versionsand compatibility

• [ ] The product name, slug, namespaces, package identifiers, archive names, manifests, documentationand listing identify the same product.
• [ ] The version number is consistent everywhere.
• [ ] The changelog includes the submitted version and accurately describes material changes.
• [ ] Minimum and tested versions are declared for every relevant runtime, framework, CMS, database, browser, device, operating systemand build tool.
• [ ] Required extensions, permissions, services, accounts, plans, API versions, quotas, cron jobs, workers, storageand outbound connectivity are disclosed.
• [ ] Unsupported combinations and known limitations are stated clearly.
• [ ] “All versions,” “all browsers,” “unlimited,” and similar claims are used only where they can actually be supported.

Documentation and presentation

• [ ] Included documentation covers installation, configuration, build, production deployment, ordinary use, updates, migrations, backups, recoveryand uninstallation as applicable.
• [ ] Commands have been copied and tested in a clean environment.
• [ ] Configuration fields, environment variables, permissionsand secret-handling responsibilities are explained.
• [ ] Every advertised feature is documented and present.
• [ ] Screenshots and demo media show the submitted version and do not imply undelivered features.
• [ ] Required third-party accounts, purchases, fees, licenses, models, data sourcesand seller-hosted services are prominent before purchase.
• [ ] Support scope, update policy, service dependencyand buyer responsibilities are accurate.
• [ ] A reviewer can access protected workflows using safe working credentials or another documented review method.

Ownership and licensing

• [ ] The seller owns the product or has documented rights to sell it.
• [ ] Every third-party library, asset, font, icon, model, dataset, template, sampleand copied excerpt has an identified source and compatible license.
• [ ] Redistribution rights cover the form in which each component is delivered.
• [ ] Required copyright notices, attribution, source offersand license texts are included.
• [ ] The product’s buyer license is declared and does not conflict with host-platform or dependency obligations.
• [ ] No trademark, logo, screenshot, name or branding misleadingly suggests official affiliation.
• [ ] AI-generated or AI-assisted material has been reviewed for quality, security, originalityand licensing; the seller can understand and maintain it.

Function and maintainability

• [ ] Every advertised workflow works in the documented environment.
• [ ] Empty, loading, success, invalid, denied, timeout, offlineand failure states are handled.
• [ ] The code follows the conventions of its language, frameworkand host platform.
• [ ] Components have clear responsibilities and do not rely on avoidable global state or generic global names.
• [ ] Public APIs, hooks, events, configuration, commandsand extension points are stable and documented.
• [ ] Error messages are actionable without exposing secrets or internals.
• [ ] Debug code, placeholder behavior, test routes, sample administrator accountsand temporary bypasses are absent from production.
• [ ] Logs are useful, bounded, appropriately leveledand redact sensitive values.

Security and accounts

• [ ] A threat model appropriate to the product has been considered.
• [ ] All externally controllable input is validated at the trust boundary.
• [ ] Output is encoded for its exact HTML, attribute, URL, JavaScript, CSS, SQL, shell, template, header, log or file context.
• [ ] Every privileged server action enforces authentication and authorization.
• [ ] Browser-originated state changes have appropriate request-intent or CSRF protection.
• [ ] Sessions, tokens, password storage, reset, invitation, email change, account deletionand recovery flows use current secure practices.
• [ ] Secrets are stored outside source and are not exposed to an untrusted browser or mobile client.
• [ ] Uploads, downloads, paths, archives, redirects, outbound URLs, parsersand serialized data are constrained safely.
• [ ] TLS certificate verification is enabled and cryptographic operations use maintained platform libraries.
• [ ] Rate limits, quotas, resource limits, lockoutsand abuse controls match the product’s exposure.
• [ ] Security-sensitive audit events are recorded without logging secrets.

Dependencies, buildsand deployment

• [ ] Direct and material transitive dependencies have been reviewed for necessity, maintenance, vulnerabilities, provenanceand license.
• [ ] Versions are pinned or constrained appropriately for an application or library.
• [ ] A lockfile is included where the ecosystem expects one for a deployable application.
• [ ] Install, build, lifecycle, containerand code-generation scripts have been manually reviewed.
• [ ] Package installation does not run surprising privileged or network actions.
• [ ] Production deployment does not expose development servers, source files, private configuration, dashboards or debugging.
• [ ] Containers use appropriate base images, users, ports, volumes, health checksand secret injection.
• [ ] The product starts, stops, restartsand recovers cleanly.

Data, databaseand privacy

• [ ] Queries use safe parameterization and dynamic identifiers are allowlisted.
• [ ] Transactions, constraints, indexes, concurrency, retriesand isolation are appropriate to the workflows.
• [ ] Migrations have been tested from every supported upgrade source and do not silently lose data.
• [ ] Destructive operations show their scope, use confirmation or dry run where appropriateand never rely on an unresolved broad path or identifier.
• [ ] Imports and exports validate format, size, encoding, formulas, filenames, referencesand duplicate behavior as applicable.
• [ ] Backups and restores cover all required state and have been tested when advertised.
• [ ] Personal and sensitive data collection, purpose, recipients, retention, export, deletionand external processing are documented.
• [ ] Telemetry, analytics, crash reporting, AI providers, CDNs, fonts, mapsand seller services are disclosed and configurable where appropriate.
• [ ] Logs, caches, queues, browser storage, mobile storage, backupsand temporary files do not expose data unnecessarily.

APIs, integrations, paymentsand background work

• [ ] API credentials use the narrowest practical scopes and are stored in the correct trust environment.
• [ ] Requests have timeouts, bounded retries, backoff, rate-limit handling, pagination, validationand useful errors.
• [ ] Webhooks use signature verification, replay resistance, idempotencyand safe asynchronous processing.
• [ ] API version and permission requirements are documented.
• [ ] Payment amounts, currency, order identityand entitlement are verified server-side.
• [ ] Successful, failed, delayed, duplicated, refundedand disputed payment states have been tested.
• [ ] Scheduled and queued work has ownership, locking or idempotency, bounded retry, failure visibilityand cleanup.
• [ ] Jobs can be paused, stopped, resumed or reconciled as appropriate.

AI, automation, scrapingand security functionality

• [ ] The AI model/provider, cost, limits, region, data use, retentionand account requirements are disclosed.
• [ ] AI output is treated as untrusted and cannot directly authorize or execute a privileged action without validation.
• [ ] Prompt injection, tool permissions, data leakage, unsafe content, hallucinationand provider failure have been considered.
• [ ] Model, dataset, sampleand generated-content rights are documented.
• [ ] Automation has explicit scope, preview, confirmation, scheduling, rate control, pause, stop, logsand recovery appropriate to its impact.
• [ ] Scraping targets, permissions, robots behavior, credentials, rate limits, cachingand content rights are documented.
• [ ] Security tools default to authorized targets, identify potentially disruptive actionsand provide appropriate safeguards and auditability.
• [ ] The product is not designed or marketed for credential theft, spam, fake engagement, access-control bypass, unauthorized intrusion, destructive denial of service or another prohibited use.

Web, CMS, commerceand mobile

• [ ] Browser markup is semantic, valid enough for reliable rendering, responsive, keyboard operableand accessible for essential workflows.
• [ ] CSS and JavaScript are scoped and do not unexpectedly affect the host page.
• [ ] Current claimed browsers have been tested.
• [ ] CMS and framework products use official extension architecture, APIs, permissions, configuration, routing, schema, events, assets, cachesand updater conventions.
• [ ] Commerce products preserve price, tax, currency, stock, order, refundand multistore integrity.
• [ ] Mobile release builds work on the minimum and current supported operating systems and representative physical devices.
• [ ] Mobile package identifiers, signing responsibilities, capabilities, permissions, privacy declarations, deep links, notificationsand backend dependencies are documented.
• [ ] App-store purchase, subscription, restore, loginand account-deletion rules are satisfied where applicable.

Testing and final release

• [ ] Clean installation, upgrade, uninstall, failure recoveryand representative data-volume tests have passed.
• [ ] Roles and authorization have been tested directly at the endpoint, not only through the interface.
• [ ] Static analysis, linting, dependency audit, secret scanand platform-specific checks have been run and genuine findings resolved.
• [ ] Relevant manual security abuse cases have been tested.
• [ ] Browser accessibility and mobile release tests have been completed where applicable.
• [ ] The exact final archive was installed or built in a clean supported environment.
• [ ] Version, changelog, documentation, screenshots, demo, checksum, compatibilityand listing metadata were checked after packaging.
• [ ] A backup copy of the exact submitted release and its build inputs is retained by the seller.

32. Related WPBay guidance

This page is the controlling technical review standard for scripts. The following WPBay pages provide additional marketplace, packaging, presentationand seller context:

• What Makes a Product WPBay-Ready?
• WordPress Plugins: Common Rejection Factors — useful historical background for general CSS, JavaScript, PHP, documentationand product-quality concerns; script reviews follow the current requirements on this page when the guidance differs.
• WordPress Themes: Common Rejection Factors — useful historical background for markup, CSS, browser testing, presentationand documentation; obsolete browser examples do not define the current script standard.
• WPBay Product Licensing Explained
• Warning and One-Strike Violations
• Seller Guidelines
• Acceptable Use Policy

Requirements from the WPBay Terms and Conditions, Acceptable Use Policy, privacy rules, licensing terms, seller agreement, payment rulesand individual host platforms continue to apply even when they are not repeated here.

33. Official development references

The following primary references help sellers interpret and implement these requirements. They do not replace this pageand passing a single checklist or automated tool does not prove that a product is ready. Use the current stable documentation for the versions your product supports.

33.1 Cross-platform security, APIs, accessibilityand packaging

• OWASP Application Security Verification Standard
• OWASP Top 10
• OWASP API Security Top 10
• OWASP Top 10 for Large Language Model Applications
• NIST Secure Software Development Framework
• NIST AI Risk Management Framework
• NIST Generative AI Profile
• W3C Web Content Accessibility Guidelines 2.2
• OpenAPI Specification
• OAuth 2.0 Security Best Current Practice, RFC 9700
• HTTP Semantics, RFC 9110
• Robots Exclusion Protocol, RFC 9309
• Semantic Versioning
• SPDX license information

33.2 PHP, JavaScript, Python, Ruby, Javaand .NET

• PHP supported versions
• PHP-FIG PSR-12 coding style
• Composer package schema
• npm package.json documentation
• Node.js security best practices
• Python Packaging User Guide
• Writing pyproject.toml
• RubyGems: Make your own gem
• RubyGems security practices
• Oracle Java documentation
• .NET releases and support
• NuGet security best practices

33.3 CMS, frameworkand commerce platforms

• Concrete CMS package development
• Drupal development documentation
• Drupal coding standards
• Joomla programmer documentation
• Laravel documentation
• Laravel package development
• Adobe Commerce Marketplace technical review guidelines
• Moodle development policies
• Moodle plugin contribution checklist
• October CMS plugin development
• Odoo module manifests
• Odoo web security
• OpenCart extension development
• OpenCart coding standards
• PrestaShop developer documentation
• PrestaShop payment modules
• Shopify app authentication and authorization
• Shopify guidance for common web vulnerabilities
• Shopify iframe protection
• TYPO3 extension architecture
• TYPO3 security guidance: never trust user input

33.4 Mobile platforms

• Android core app quality
• Android security best practices
• Android application signing
• Apple App Review Guidelines
• Apple security documentation
• Flutter deployment documentation
• React Native: publishing to Google Play
• React Native: publishing to the Apple App Store

Final note

These requirements are intentionally broad because “scripts” includes small frontend components, full web applications, CMS extensions, mobile source projects, developer libraries, automation systems, database tools, AI productsand security-sensitive software. Review applies the common baseline and the overlays matching the product’s real behavior.

Software ecosystems and platform rules change. When an official host-platform security or distribution requirement becomes stricter than an example on this page, the current official requirement governs. Sellers should update dependencies, compatibility claims, documentationand release processes accordingly rather than relying on a previously approved version.

A careful seller should be able to explain how the product is installed, where trust boundaries exist, what data leaves the buyer’s environment, which components and services are required, how failure is contained, how an update is recoveredand why every third-party component may legally be distributed. If those answers are clear in the code, package, documentationand product page, review is faster and buyers receive a more dependable product.