WPBay Seller Guidelines & Product Review Process

Do this before you upload anything

A large percentage of avoidable review problems can be found by spending a little time testing the release as a customer would, instead of testing it only inside the development environment where it was created.

Install the final ZIP or package yourself—not your development copy—from a clean environment. Follow your own documentation as though you had never seen the product before.

If you cannot get from installation to a useful result by following the instructions you give customers, a reviewer probably will not be able to either.

Run through the main workflows. Save the settings and reload the page. Try invalid input. Disable a required dependency and see what happens. If the product connects to an external service, test an incorrect API key and a failed request. For WordPress products, turn debugging on while you test and look at the browser console as well.

If functionality changes according to the current user’s role, test it with a lower-privileged account too. A feature that correctly disappears from the interface but remains callable directly through an AJAX action or REST endpoint is still exposed.

Then inspect the archive itself. Make sure you have not accidentally included an .env file, development API key, private key, database export, debug log, customer information, old backup, test data or an obsolete copy of the product.

Finally, read your WPBay listing again. If the listing says a feature exists, make sure it exists in the submitted release. If it requires WooCommerce, Elementor, an external API, a paid account, a particular PHP extension, a subscription or another commercial product, tell the buyer before purchase.

What WPBay is actually looking for

A review is easier to understand when you know the questions behind it. Most of what we check falls into four broad areas.

How the WPBay review works

A typical review combines automated analysis, manual inspection and practical product testing. There is no single scanner or score that determines whether a submission is approved.

Possible review decisions

Plugin review reflects the fact that a WordPress plugin runs inside another application and often shares a site with dozens of unrelated extensions. Installation, compatibility, permissions, stored data and failure handling all matter.

Start with a normal, installable plugin

The submitted plugin archive should normally be directly installable through Plugins → Add Plugin → Upload Plugin.

It should contain one clearly named top-level plugin directory, with the main plugin file directly inside that directory. Runtime files required by the advertised functionality need to be present in the package.

A normal end-user plugin should not require the buyer to manually install Composer packages, run npm, edit PHP source files or import a database before it can activate. Developer-focused products can legitimately have build requirements, but those requirements need to be intrinsic to the product and clearly disclosed.

Use a stable product identity

The plugin folder, main filename, text domain, licensing identity and updater identity should remain stable across releases.

Renaming an established plugin folder can cause WordPress to treat an update as a completely different plugin. It can also break activation records, licensing and automatic updates. A product rebrand can usually change the name customers see without changing the technical slug underneath it.

Version information needs to agree

Inconsistent versions are confusing for buyers and make update problems unnecessarily difficult to diagnose.

Where applicable, the plugin header, readme stable version, changelog, PHP or JavaScript version constants, database schema version, WPBay release version, package filename and updater metadata should describe the same release.

Use predictable versioning. Breaking changes should not be silently shipped as though they were insignificant patch releases.

Compatibility fields deserve the same care. “Tested up to” means tested, not assumed. Do not increase WordPress or WooCommerce compatibility metadata simply because you expect the plugin to continue working.

Test the complete lifecycle

Do not stop once activation succeeds. Test installation, activation, normal use, deactivation, reactivation and updating.

Uninstall behavior should match what you tell customers. If uninstall deliberately preserves user data, that is acceptable when the behavior is documented. If the product offers an option to remove its data, verify that the option really works.

Updates deserve extra attention when your product stores structured data. If version 1.4 changes a database table used by version 1.3, test the upgrade from 1.3. A clean installation of 1.4 alone does not test the migration.

Dependencies should fail gracefully

If your plugin requires WooCommerce and WooCommerce is missing, the normal result should be an understandable notice—not a fatal PHP error.

The same principle applies to Elementor, another plugin, a PHP extension or an external service. Tell the user what is missing and what they need to do.

Use WordPress conventions responsibly

Plugin headers should correctly identify the product, author, version and requirements. Settings pages should appear in sensible locations. Actions and filters should be used without unnecessarily changing unrelated WordPress behavior.

Global functions, classes, constants, database options, AJAX action names, cron hooks, REST namespaces and frontend asset handles should use a distinctive prefix or namespace so the product can coexist with other software.

Security: what reviewers pay particular attention to

Security findings are among the most common reasons a technically functional plugin is returned for changes.

Most problems start with one incorrect assumption: information coming from the browser cannot automatically be trusted simply because your own interface sent it.

Users can construct requests manually. JavaScript can be modified. Hidden form fields can be changed. HTTP headers can be forged. REST endpoints can be called without using your interface.

The real security decision therefore needs to happen in server-side code.

Nonces and authorization are different things

WordPress nonces are useful for protecting requests against CSRF, but possession of a nonce does not automatically prove that the current user should be permitted to perform the action.

If only administrators should be allowed to change a setting, verify the appropriate capability as well.

REST endpoints require deliberate permission rules

A REST route is not protected because its URL is obscure or because your JavaScript is normally the only code that calls it.

If an endpoint accesses private information or performs a privileged action, its permission logic should enforce the appropriate access rule. Public endpoints can intentionally be public; the important point is that the access level should be deliberate rather than accidental.

Validation, sanitization and escaping are not interchangeable

Validation asks whether a value is acceptable for the operation being performed.

Sanitization transforms untrusted data into a form appropriate for storage or further processing.

Escaping protects data when it is inserted into a particular output context such as HTML, an attribute or a URL.

A value that was sanitized when saved can still require escaping when displayed. Likewise, sanitize_text_field() is not a universal security function that makes arbitrary input safe for every purpose.

Use the API appropriate to what the value actually represents.

Database access

User-controlled values must not be unsafely concatenated into SQL queries. Use WordPress database APIs and prepared queries where appropriate.

Dynamic table and column identifiers require additional care because they cannot always be handled like ordinary prepared values.

File handling

Uploads, downloads, imports, exports, backups and archive extraction receive additional attention because mistakes in these areas can have serious consequences.

Validate file types, names and paths. Prevent directory traversal. Do not allow arbitrary executable files to be written into a location where they may run.

A private download endpoint should verify that the current user is permitted to access the requested file instead of relying solely on knowledge of a filename or URL.

Custom tokens and authorization mechanisms

If your product implements tokens, signed links, invitations, webhooks, passwordless access or similar mechanisms, consider what happens if the value is copied or replayed.

Where appropriate, sensitive tokens should be unpredictable, scoped to the intended purpose, revocable or expiring.

A client-controlled value such as a custom HTTP header should not be treated by itself as proof that a sensitive request is authorized.

Privacy and information disclosure

Not every security issue gives somebody direct control over the website.

Information disclosure matters as well. For example, visibly different responses for “this email address does not exist” and “this email exists but you are not authorized” can reveal whether a user or customer record exists.

When reviewing API responses and error messages, consider what the response reveals to somebody who should not know whether the requested record exists.

Performance and reliability

We do not expect every plugin to be engineered for millions of requests per second. We do expect it not to create avoidable problems for an ordinary WordPress installation.

Avoid unnecessarily expensive database queries, repeated remote API calls and loading large libraries on every page when the feature is used only in one part of the site.

Scripts and styles should normally be loaded where they are needed. Production images and static assets should be reasonably optimized.

If your plugin uses cron jobs, queues or background processing, make sure jobs do not multiply indefinitely and that retries do not unexpectedly create duplicate records, imports, orders, emails, charges or other side effects.

External APIs should fail gracefully. A temporary OpenAI, Google, payment-provider or other API outage should not normally turn the entire WordPress administration area into a fatal error. Give the user a useful error and allow unrelated parts of the site to continue working.

Detailed standard: WPBay Technical Requirements for WordPress Plugins

Themes are reviewed both as software and as visual products. A theme can contain perfectly valid PHP and still create a poor buyer experience if its layouts break, its demo cannot be reproduced or basic interactions fail on smaller screens.

The theme needs to install correctly, follow the appropriate WordPress theme architecture and provide the design quality shown in its listing.

A classic theme should follow the relevant template hierarchy. A block theme should correctly use the architecture expected from a block theme, including templates, theme configuration and Site Editor functionality where appropriate.

If customization is provided through the Theme Customizer, Site Editor, Global Styles or another supported WordPress mechanism, changes should save and reload reliably.

A theme intended to act as a parent theme should not make reasonable child-theme customization unnecessarily difficult.

Design quality is part of the review

We look at the interface, not only the files behind it.

Spacing should feel intentional. Typography should be consistent. Forms, buttons, navigation and other repeated elements should look as though they belong to the same product.

Responsive behavior matters. Menus need to remain usable on phones. Text should not unexpectedly leave its container. Important controls should not overlap. A WooCommerce theme should not become impossible to purchase from because its checkout breaks at a common mobile breakpoint.

Testing should focus on current supported browsers relevant to the product. Modern themes are not required to reproduce obsolete Internet Explorer behavior unless the seller explicitly advertises such compatibility.

Theme functionality should remain theme functionality

A theme is primarily responsible for presentation.

Features that create important content or functionality a user reasonably expects to retain after changing themes should generally not be permanently locked into the theme itself.

Where a theme requires companion functionality, an appropriate companion plugin can be used and the relationship should be documented clearly.

Demo imports need clean-install testing too

If you advertise one-click demo import, test it against an empty installation.

Do not assume that pages, menus, widgets, Elementor templates, options or media left behind from your development site already exist.

If the importer retrieves data from a remote server, test unavailable files and failed network requests as well.

Bundled assets need redistribution rights

Pay particular attention to demo images, fonts, icon sets and bundled plugins.

A license that permits you to display a stock photograph on your own demo site does not automatically permit you to place the original image inside thousands of customer downloads.

Detailed standard: WPBay Technical Requirements for WordPress Themes

“Script” covers a much wider technical range than WordPress plugins or themes, so WPBay applies the principles of the review to the actual technology and deployment model involved.

A PHP application, Laravel project, Node.js application, JavaScript component, Python application, CLI utility, Flutter project and React Native application all have different technical expectations.

The common principle is simple: another person should be able to reproduce the documented setup from a clean supported environment.

“Works on my machine” is not sufficient for a commercial software product.

Document the environment properly

Explain prerequisites, runtime versions, dependencies, environment variables, database requirements and the commands needed to install, configure, build or start the product.

Tell the user where those commands are expected to run and which parts of the process are required for production rather than development.

Do not ship your production .env, database password, private cloud credentials, API token or signing key as convenient example configuration. Use safe placeholders and explain what the buyer needs to generate.

Support the environments you actually test

You do not need to support every operating system, browser, database, framework release or server configuration.

It is considerably better to document a defined support matrix accurately than to make vague compatibility claims and leave customers to discover the real limitations later.

Security review depends on what the application can do

For larger applications, reviewers may inspect authentication, account recovery, role and permission handling, database migrations, uploads, payments, public APIs, queues, scheduled processes, webhooks, secrets, logging, backup behavior and the update path.

The depth of review remains proportionate to risk. A JavaScript presentation component is not reviewed as though it were an online payment application, and a payment application is not reviewed as though it were a presentation component.

Readable and reviewable source

Compiled and minified production assets are acceptable. They must not be used to deliberately conceal first-party product behavior.

When the distributed product relies heavily on generated or compiled first-party code, readable source and appropriate build information should be available so the reviewer can understand how the release was produced.

Detailed standard: WPBay Technical Requirements for Scripts

Services are different from downloadable software because there may be no package to install. In this case, WPBay is reviewing whether the offer can be sold responsibly and whether a buyer can understand what they are purchasing.

The listing should make it reasonably clear what you will do, what the buyer receives, what information or access they need to provide, what is included in the advertised price and where the boundaries of the service are.

Describe the work, not just the desired result

Imagine that you sell a service called “WordPress Performance Optimization.”

“Make your website faster” does not tell the buyer enough.

The listing should explain what kind of work may be performed, what access is required, whether a backup is created, whether hosting limitations can affect the result, what is included, what falls outside the package and what the buyer receives when the work is finished.

The same principle applies to custom development, security work, theme installation, migrations, WooCommerce configuration and ongoing maintenance.

Delivery times need to be realistic

Do not choose an unrealistically short delivery time simply because it makes the offer look more attractive.

If the work regularly depends on buyer feedback, DNS propagation, approval from a third-party service or access from another person, account for that in the offer.

Explain what a revision means

A revision is a reasonable adjustment to work that was already within the agreed scope. It is not an unlimited opportunity to redesign the project or introduce unrelated functionality.

Describe the revision policy clearly enough that both sides understand what happens after the first delivery.

Handle customer access carefully

Some services legitimately require WordPress administrator access, hosting credentials, SSH access or third-party accounts.

Request only the access you need. Where possible, use temporary accounts, the minimum necessary privileges and credentials that can be revoked after the work is completed.

Be particularly careful when modifying production websites. Work that can materially affect customer data, revenue, SEO visibility or site availability should use sensible backup and recovery practices before risky changes are made.

Do not guarantee an outcome you cannot control

You can guarantee that you will perform the work defined by the offer.

You usually cannot responsibly guarantee a particular Google ranking, an exact PageSpeed score on every environment, zero future security incidents, permanent compatibility with every third-party plugin or another result substantially controlled by systems outside your control.

Describe what you deliver instead of promising the impossible.

Detailed standard: WPBay Technical Requirements for Services

Treat documentation as part of the product

Documentation is not something to add after development is finished. It is part of what the customer purchases.

At minimum, a buyer should be able to understand what the product does, how to install it, how to perform the initial setup and how to use its main functionality.

More complex products need more explanation.

If the buyer needs an API key, explain where to obtain it. If a webhook needs configuration, show how. If cron must be configured manually, do not write only “set up cron normally”—give the user the actual information needed to do it or point them to a clear reference.

If functionality requires a paid third-party subscription, disclose that before purchase. If customer information is transmitted to another server, document the relevant behavior.

If uninstalling the plugin permanently deletes data—or deliberately does not delete it—make that behavior understandable.

Screenshots and screencasts can make complicated workflows much easier to follow, but they should supplement useful written instructions rather than replace them completely.

Documentation may be hosted online. Downloadable software should still contain enough basic information to identify, install and begin using the product if your documentation website is temporarily unavailable.

Support expectations

The product page should tell buyers how support is provided and what they can reasonably expect from it.

Ordinary product support typically covers installation questions, clarification of documented functionality and investigation of genuine product defects.

Custom development, redesigning a buyer’s website, modifying unrelated third-party products and implementing functionality that was never part of the purchased item do not automatically need to be included.

Make those boundaries clear.

A response target of approximately one to two business days is reasonable for many products, although your actual commitment can vary according to the support arrangement. Whatever model you choose, represent it accurately.

Your product page is part of the review

A technically good product can still create a poor marketplace experience if its listing sets the wrong expectation.

The title should identify the product clearly. The description should tell a buyer what the product actually does rather than relying entirely on vague marketing language.

Use relevant keywords naturally. Keyword stuffing makes the page less useful for buyers and rarely improves the quality of the listing.

Screenshots should be readable, current and representative of the submitted release. Do not present mock functionality or an interface belonging to a different release as though customers receive it.

A live demo is strongly recommended for themes and can also be useful for visual plugins and scripts, although not every product requires one.

Public demos need their own security review

Do not publish reusable administrator credentials to a persistent installation containing sensitive information.

Where appropriate, reset demo environments and restrict actions that could be abused. Demo access should not provide a path into your own infrastructure, private APIs, customer data or unrestricted privileged functionality.

APIs, plugins and third-party services

Modern software often depends on other services. There is nothing inherently wrong with that.

The important part is transparency.

If your AI plugin requires the buyer to provide an API key, say so. If a theme requires Elementor Pro, say so. If a script needs Redis, a particular Node.js release and PostgreSQL, say so.

If a feature depends on a third-party service that charges by usage or requires a separate subscription, disclose that as well.

The buyer should not discover an unexpected payment requirement only after purchasing your product.

Dependencies should also fail sensibly. A missing optional integration should not normally break unrelated functionality. An expired API key should produce a useful message rather than a PHP stack trace. Rate limits, unavailable services and malformed external responses should be treated as situations that can happen in production.

Declare the environment you actually support

WordPress products should be tested against the WordPress versions advertised in the listing, including the current stable release when current compatibility is claimed.

Declare the minimum PHP version required by the code and dependencies you actually distribute. The declared minimum should reflect the syntax and runtime requirements of the complete package.

Do not increase PHP, WordPress, WooCommerce or dependency compatibility fields just because a new version has been released and you assume nothing relevant changed.

Testing older versions is useful when you advertise them, but products should also be tested in a current environment rather than being maintained entirely around legacy configurations.

Required plugins, PHP extensions, frameworks, server capabilities and external accounts should be disclosed clearly.

Localization and accessibility

Product listings, core documentation and support communication must be available in English at minimum.

WordPress products presented as translatable should use WordPress internationalization practices and an appropriate text domain. Avoid unnecessarily hard-coding customer-facing text when the normal localization functions are appropriate.

Accessibility also matters, but it should be applied realistically rather than through obsolete blanket rules.

Modern JavaScript-powered administration interfaces are allowed. A complex interface does not need a complete no-JavaScript copy of every feature merely to satisfy review.

Important controls should nevertheless remain understandable and usable. Buttons should behave as buttons, form controls should have understandable labels, keyboard focus should be visible and navigation should not become trapped.

Themes in particular should pay attention to navigation, focus states, headings, form usability, contrast and other everyday accessibility concerns.

Small packaging mistakes can cause unnecessary delays

Before submission, open the actual archive you are going to upload.

It is surprisingly common for the development directory to be correct while the final ZIP is wrong.

A production package should contain the current release and the files the customer needs. It should not contain unrelated Git metadata, IDE settings, operating-system files, editor backups, stale copies of the product, debug logs, production database exports or customer information.

Never distribute private API keys, signing secrets, production access tokens, passwords, private keys or database credentials.

Compiled and minified production assets are allowed. They should not be used to conceal what first-party code does.

When a product relies significantly on compiled first-party source, keep readable source and reproducible build information available so the reviewer can understand how the distributed release was produced.

Common reasons a product is returned for changes

There is no useful universal list of every possible rejection reason. The examples below are more valuable because they show the kinds of mistakes reviewers repeatedly find in otherwise legitimate products.

The interface is protected, but the underlying action is not

A plugin may hide an administration button from subscribers but expose the underlying AJAX handler without checking the user’s capability. Anyone able to call the handler directly can bypass the interface.

The same problem appears with REST endpoints. Hiding a URL from the interface is not authorization.

A nonce is being used as the only permission check

The request may correctly protect against CSRF while still allowing a logged-in user with insufficient privileges to perform an administrative action.

Use the nonce for request intent and the relevant capability or authorization logic for access control.

Input is sanitized but output is not escaped

Sanitizing a value when it is stored does not automatically make it safe in every future output context.

When outputting dynamic content, apply escaping appropriate to where the value is being printed.

The product works only because the development site already contains data

A missing installation routine can remain invisible for months on a development site because the required option or database table already exists.

The first fresh installation exposes the problem immediately.

The release identifies itself as several different versions

The plugin header may say 1.4.2 while the readme and changelog say 1.4.1 and the WPBay product version still says 1.4.0.

This becomes especially problematic when automatic updates and migrations depend on those values.

A failure path reports success

A settings page may display “Saved successfully” despite a database failure. An integration may report that content was published even though the external API rejected the request.

Review both successful and unsuccessful paths.

A missing dependency causes a fatal error

If an optional integration disappears, unrelated functionality should normally continue running. If a required dependency is absent, provide a useful explanation instead of allowing the product to crash the site where reasonably possible.

A theme looks good on desktop but breaks on a phone

Common problems include inaccessible mobile navigation, controls positioned outside the viewport, overlapping elements, unreadable forms and WooCommerce interfaces that cannot be completed at smaller widths.

A demo importer depends on the seller’s development environment

Remote files may no longer exist, required pages may be expected to already be present or the importer may rely on a plugin the listing never mentioned.

The documentation assumes hidden technical knowledge

A script may require four environment variables and a database migration but never tell the buyer about them. A plugin may require a webhook but describe only where to paste an API key.

The customer should not have to reverse-engineer the source to discover the basic installation procedure.

The service is too vague to know what the buyer receives

“Complete website development” is not sufficiently informative if the offer never defines the number of pages, included functionality, revisions, required buyer materials, third-party costs or what counts as completion.

The archive includes something that should never have been distributed

This can include development credentials, customer information, private API keys, database dumps, backup files or commercial assets the seller has no right to redistribute.

What usually does not block approval by itself

WPBay review should distinguish actual risk from noise.

A small number of cosmetic coding-standard warnings are not automatically a reason to reject a product. Inline CSS is not universally prohibited: static styling normally belongs in enqueued stylesheets, while small genuinely dynamic values can be generated safely through appropriate platform APIs.

Minified JavaScript and CSS are not automatically prohibited. JavaScript-powered interfaces are not automatically a problem. A focused product is not automatically “too small” because it solves one problem.

Likewise, a scanner warning is not automatically correct simply because the word “warning” appears next to it.

The implementation and actual risk matter.

How to respond to Changes Required

A Changes Required decision is not a permanent rejection. It means that the reviewer identified something that needs to be corrected before the product is ready for buyers.

Read the full review before modifying the product.

Sometimes several reported symptoms come from the same underlying design problem. If three AJAX handlers are missing permission checks, fixing only the three lines named by the reviewer may leave another five similar handlers vulnerable.

Look for the pattern.

Fix the underlying issue and inspect related code. Then reproduce the affected workflow and test the correction yourself before creating another package.

Do not simply edit the line mentioned in the review and immediately resubmit the ZIP.

Tell the reviewer what changed

A short technical explanation makes a resubmission substantially easier to verify. You do not need to write an essay.

This tells the reviewer what you changed, shows that you looked for the same issue elsewhere and explains how the correction was verified.

If you believe something is a false positive

Explain the technical context.

Show why the reported behavior is safe rather than disabling correct code simply to satisfy an automated rule.

Before resubmitting

Make sure you are actually submitting the corrected build. It is easy to test an updated development folder and then accidentally upload an older ZIP.

Update the product version and changelog where appropriate. Check screenshots or documentation affected by the changes, then perform one final installation or build using the exact archive you intend to submit.

Updates and ongoing maintenance

Getting approved is the beginning of the product’s life on WPBay, not the end of the seller’s responsibility.

Keep the product compatible with the environment versions you continue to advertise as supported. Fix significant bugs promptly and give security issues priority appropriate to their severity and impact.

Maintain a meaningful changelog so existing customers understand what changed.

Try to preserve backward compatibility when introducing new functionality. When a breaking change is genuinely necessary, document it clearly instead of silently shipping it as though nothing important changed.

Database migrations should be designed around existing customer data. When an update changes stored data, test an upgrade from the previous public release as well as a clean installation of the new version.

WPBay may review product updates, particularly when a release materially changes security-sensitive functionality, dependencies, compatibility, licensing behavior or buyer-facing functionality.

Intellectual property and licensing

You must own the product or have the necessary rights to sell and distribute it.

Copyright applies to more than source code. Images, fonts, icons, music, video, documentation, templates, sample data and other creative material may carry separate licensing requirements.

Preserve copyright notices and attribution when a dependency requires them.

Do not distribute cracked, nulled or bypassed commercial software.

Do not use trademarks in a way that creates a misleading impression of affiliation. Being compatible with WooCommerce, Elementor or another third-party product does not automatically make your product an official product of that company.

AI assistance does not remove these obligations. The seller remains responsible for generated code and generated assets included in a commercial product.

WPBay may request reasonable evidence of ownership or redistribution rights where there is a legitimate concern.

Privacy and data collection

If your product collects, stores or transmits personal information, explain the relevant behavior.

In particular, buyers should understand when data leaves their WordPress installation or application and is transmitted to your infrastructure or another third-party service.

Collect only what the product genuinely needs and protect sensitive information appropriately.

Do not expose personal information through public endpoints, debugging output, logs or unnecessarily detailed error responses.

Where relevant, WordPress plugins should integrate appropriately with WordPress privacy tools or document the alternative mechanism used to export or remove personal information.

Sellers remain responsible for complying with applicable privacy and data-protection laws. WPBay approval is not a GDPR or other legal certification.

Prohibited products and behavior

Some submissions cannot be accepted regardless of how well the code is written.

Malware, spyware, credential theft, undisclosed backdoors and intentionally harmful functionality are prohibited.

Products must not silently insert undisclosed affiliate links, advertisements or redirects into customer websites.

Stolen, nulled, cracked or unlawfully redistributed commercial products are not allowed.

Products primarily intended to facilitate unlawful hacking, spam or other illegal behavior may be rejected.

Content and services must also comply with WPBay marketplace policies regarding illegal, abusive, discriminatory and explicit material.

WPBay must be able to understand the software it distributes. Deliberate obfuscation, encrypted payloads or similar techniques intended specifically to prevent review of first-party product behavior may result in rejection.

Enforcement is proportionate

Most ordinary technical problems result in Changes Required, not account punishment.

Enforcement becomes more serious when the underlying behavior is serious or a seller repeatedly disregards marketplace requirements.

Depending on the circumstances, WPBay may request corrections, reject a submission, temporarily disable an approved product, permanently remove an item, restrict a seller account or suspend or terminate an account.

Intent matters.

An accidental missing capability check in an otherwise legitimate plugin is not treated the same way as deliberately inserting a hidden administrative backdoor.

Attempts to conceal malicious behavior, mislead reviewers, distribute stolen products or repeatedly bypass review requirements can lead to stronger action.

What WPBay approval does—and does not—mean

WPBay review is intended to reduce buyer risk and improve marketplace quality. It cannot eliminate every possible software defect.

An approved plugin is not guaranteed to be free from every future vulnerability.

An approved theme is not guaranteed to work with every third-party plugin ever released.

An approved script is not guaranteed to work outside the environment and compatibility range documented by its seller.

An approved service listing does not guarantee the outcome of every future customer engagement.

Approval means that, based on the version and information reviewed, WPBay did not identify an unresolved approval blocker.

The seller remains responsible for maintaining the product, supporting advertised compatibility, correcting defects, protecting customer data, respecting third-party licenses and complying with applicable law.

Final pre-submission checklist

You do not need to memorize this entire guide. Before clicking Submit for Review, run through these final checks.

• I tested the exact final package, not only my development copy.
• I tested installation or setup from a clean environment.
• The main advertised functionality works from beginning to end.
• There are no known fatal errors, important PHP warnings or relevant JavaScript errors during normal use.
• Privileged actions enforce authorization on the server.
• User input is appropriately validated and sanitized, and dynamic output is escaped for its context.
• Required plugins, dependencies and third-party services are disclosed.
• Required accounts, subscriptions and additional costs are disclosed.
• Version numbers and compatibility information are correct and consistent.
• The package contains no private keys, API secrets, passwords, customer data or production logs.
• Documentation explains installation, configuration and the main workflow.
• Screenshots and product claims match the release being submitted.
• I have the right to distribute all included code, libraries, fonts, images and other assets.
• I opened and tested the final ZIP or archive after creating it.

If those points are covered, you have already eliminated many of the issues that cause unnecessary review cycles.

Review time and what happens next

When your product is ready, upload it through the WPBay Seller Dashboard.

Complete the product name, description, price, compatibility information and other required listing details, then submit the product for review.

A typical review takes approximately 1–5 business days.

Complex products can take longer, particularly when they contain a large codebase, unusual deployment requirements, several integrations or substantial security-sensitive functionality.

If the product is approved, it can be published on WPBay.

If changes are required, the review should identify the relevant blockers so you can correct them and submit a new version.

Detailed technical requirements

This page explains how WPBay review works in practical terms. Before submitting, also read the authoritative requirements for the type of product you sell.

Other useful seller resources