Last updated: July 2026

This page defines the quality, technical, security, privacy, delivery, documentation, access, ownership, communication, and professional-conduct requirements for services offered through WPBay. It applies to new service listings, resubmissions, listing updates, and every order delivered under an approved listing across all current WPBay service categories:

• Automation & Integrations
  • Analytics/tracking integration
  • CRM integration
  • Email marketing integration
  • Payment automation
  • Webhooks
  • Zapier/Make automation
• Consulting & Training
  • Code Review
  • One-on-One Training
  • Security Audit
  • Website Audit
  • WordPress Consultation
• Design & Branding
  • Banners/icons/graphics
  • Brand kit
  • Figma to WordPress
  • Landing page design
  • Logo design
  • UI/UX improvements
• Marketing & Content
  • Conversion copywriting
  • Email templates
  • Landing page copy
  • Newsletter setup
  • Product descriptions
  • Social media graphics
• Other Development
  • Headless WordPress
  • JavaScript Development
  • Laravel
  • PHP Development
  • React
  • REST API
• Performance, SEO & Analytics
  • Core Web Vitals
  • Google Analytics/Search Console setup
  • On-page SEO
  • Schema setup
  • Speed optimization
  • Technical SEO
• Security & Maintenance
  • Backup setup
  • Malware cleanup
  • Ongoing maintenance
  • Site recovery
  • Update service
  • WordPress hardening
• Translation & Localization
  • Multilingual Setup
  • Plugin Translation
  • Theme Translation
  • Website Translation
• Website Setup & Launch
  • Basic launch support
  • Demo import
  • Staging to live
  • Theme/plugin setup
  • Website migration
  • WordPress installation
• WooCommerce & eCommerce
  • Checkout customization
  • Dokan/multivendor setup
  • Payment/shipping setup
  • Product page improvements
  • Subscriptions/memberships
  • WooCommerce setup
• WordPress Development
  • API integrations
  • Bug fixing
  • Code cleanup
  • Custom WordPress features
  • Plugin customization
  • Theme customization

These are minimum marketplace requirements, not optional suggestions. Meeting them does not guarantee approval. WPBay also evaluates whether the service has genuine buyer value, a professional and realistic delivery model, clear boundaries, appropriate evidence, honest claims, and a price and package structure that can reasonably deliver what is promised.

Approval of a service listing is not a security, privacy, accessibility, performance, SEO, app-store, legal, regulatory, accounting, payment, or professional certification. It does not guarantee the outcome of a future order or transfer responsibility from the seller. The seller remains responsible for every action performed, every person or subcontractor involved, every delivered file, every third-party service used, every claim made, and every commitment accepted through the listing or order.

This is the authoritative technical and delivery standard for service listings 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 and delivery requirements. A violation can block approval, justify a correction request, or lead to removal.
• Should describes an expected professional practice. A different approach may be accepted when it is safe, appropriate, documented, and agreed with the buyer.
• May describes an optional practice.
• Blocker means an issue that must be corrected before the listing can be approved or before the affected order can be considered properly delivered.
• Recommendation means an improvement that normally does not block approval by itself.
• Service listing means the public WPBay page describing the seller’s offer, packages, price, delivery time, revisions, requirements, exclusions, and examples.
• Order scope means the exact work purchased and any written clarification or agreed change recorded for that order.
• Deliverable means the files, configuration, code, report, design, content, recording, documentation, deployed result, or other work the buyer is entitled to receive.
• Acceptance criteria means the observable conditions used to decide whether the agreed work is complete.
• Revision means a reasonable adjustment to delivered work that remains within the agreed scope. A revision is not an unlimited new feature, redesign, alternative project, or change of requirements.
• Production environment means a live website, store, application, account, domain, server, campaign, integration, or data source used by real people or business operations.
• Buyer-owned account means an account created in or transferred to the buyer’s name and under the buyer’s long-term administrative control.
• Material change means a change that can affect availability, security, privacy, revenue, search visibility, tracking, stored data, user experience, legal obligations, or third-party costs.

WPBay reviews services against six broad standards:

1. Honest scope: Can a buyer understand exactly what is included, excluded, required, delivered, and measured before ordering?
2. Professional execution: Does the seller use methods appropriate to the service, platform, risk, and buyer’s environment?
3. Safe access and change control: Are credentials, personal data, backups, production systems, and third-party accounts handled responsibly?
4. Verifiable delivery: Can the buyer and WPBay determine what was done and whether the written acceptance criteria were met?
5. Buyer ownership and continuity: Does the buyer receive the promised files, source, accounts, documentation, and control needed after delivery?
6. Responsible conduct: Does the service respect platform policies, intellectual-property rights, privacy, security, law, and the safety of buyers and third parties?

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

When a service creates or materially modifies a reusable plugin, theme, script, application, integration, or other software deliverable, that deliverable must also meet the applicable WPBay technical requirements for plugins, themes, or scripts. A custom-development order does not permit insecure, unlicensed, undocumented, obfuscated, or unmaintainable code.

Important clarifications

• Service approval evaluates the listing and proposed delivery process before a specific order exists. The seller must then apply these requirements to every order. A well-written listing does not excuse unsafe or incomplete delivery.
• WPBay approval does not confirm that the seller holds a government license, professional accreditation, platform partnership, certification, or specialist qualification. Such claims require verifiable evidence and must not imply endorsement by WPBay.
• A fixed-price service package is not an open-ended employment or support agreement. Its included work, quantity, complexity, delivery time, and revision allowance must be bounded.
• WPBay services currently use clear one-time packages. An ongoing maintenance or monitoring package must therefore cover a stated fixed service period. Continued service requires another WPBay order unless WPBay introduces and expressly supports a different service-billing model.
• “Unlimited revisions” means reasonable revisions within the original agreed scope. It must not be used to advertise unlimited new concepts or work while the seller privately imposes an undisclosed limit.
• The delivery period must reflect the actual work. The listing must explain any prerequisite that prevents work from starting, such as missing content, credentials, design approval, platform access, DNS control, or third-party account verification.
• Access to a website or account authorizes only the work agreed for that order. It does not authorize unrelated inspection, copying, marketing contact, data reuse, account changes, vulnerability testing, or use in a portfolio.
• An audit identifies and explains findings. Remediation, implementation, cleanup, redesign, migration, or ongoing monitoring is included only when the package says so.
• Installing a tool is not automatically the same as configuring, testing, securing, or validating the result. A service must describe the actual outcome it delivers.
• A backup is not considered reliable merely because a backup plugin was activated or an archive exists. The service must cover the promised files and data, use an appropriate destination and schedule, and be verifiable or restorable as stated.
• Automated reports, AI output, scanner scores, Lighthouse results, SEO plugin indicators, and validation badges are evidence inputs, not substitutes for professional review.
• Sellers may use automation and AI to assist delivery, but remain fully responsible for accuracy, confidentiality, originality, licensing, security, and the finished result.
• No seller can guarantee a search ranking, sales volume, conversion increase, perfect security, permanent malware removal, uninterrupted uptime, a specific Core Web Vitals field result, third-party platform approval, inbox placement, or legal compliance unless the outcome is entirely under the seller’s control and objectively supportable.
• A buyer may authorize work on a live environment, but staging and backups remain the expected default for material or risky changes.

Contents

• Review and listing readiness: review decisions, service eligibility, listing and packages, seller qualifications, and scope and acceptance
• Order execution: communication, access, backups and production changes, security and privacy, third parties, quality and testing, and delivery and handover
• Shared professional requirements: ownership and AI and claims and buyer control
• Category requirements: automation and integrations, consulting and training, design and branding, marketing and content, other development, performance, SEO and analytics, security and maintenance, translation and localization, website setup and launch, WooCommerce and eCommerce, and WordPress development
• Continuity and enforcement: ongoing services, corrections and disputes, common blockers, prohibited services, seller checklist, WPBay guidance, and official references

1. Review decisions and enforcement

WPBay may return one of the following decisions for a service listing.

Approved

The listing has no identified blocker after a proportionate review of its scope, packages, claims, requirements, delivery model, examples, technical approach, and risk controls. Approval means that the listing was suitable to offer based on the information available at the time. It does not pre-approve every future project or guarantee the seller’s work.

Changes required

The listing has one or more identifiable and repairable blockers. This is the normal result for unclear package boundaries, missing buyer requirements, unrealistic delivery times, vague deliverables, unverifiable guarantees, inadequate access handling, unsafe production practices, missing third-party costs, insufficient evidence, inaccurate qualifications, or category-specific omissions. The seller may correct the listing and resubmit it.

Rejected

The service is deceptive, unlawful, abusive, plagiarized, fundamentally unsafe, outside WPBay’s marketplace scope, built around prohibited conduct, or presented by a seller who cannot credibly deliver it. Repeated serious violations, fabricated evidence, concealment, unauthorized access, or attempts to bypass review may also affect the seller’s account.

Temporarily disabled after approval

WPBay may temporarily disable an approved service when serious complaints, non-delivery, unsafe access handling, compromised credentials, harmful production changes, intellectual-property disputes, fraudulent claims, repeated missed commitments, platform-policy violations, or prohibited behavior are discovered later. Sellers are expected to respond promptly, preserve relevant evidence, and correct affected listings or orders.

The review depth is proportionate to risk. A banner-design service will not be evaluated like malware cleanup, a security audit, a live payment automation, a production migration, or a checkout customization. Services involving privileged credentials, personal data, financial state, live traffic, bulk communication, destructive changes, or security testing receive stricter scrutiny.

Automated tools can support review and delivery but do not decide either. A template, scanner, benchmark, validator, AI system, SEO score, accessibility tool, or generated report may provide evidence. The seller must interpret the result, remove false positives, identify limitations, and connect each material finding to the buyer’s real environment.

WPBay may inspect listing text, packages, requirement questions, portfolio examples, submitted evidence, order communication, delivery files, revisions, and complaints where necessary to review compliance or resolve a marketplace issue. Approval may be reconsidered when the real service repeatedly differs from the approved listing.

2. Service eligibility, category, and delivery model

2.1 A service must produce a defined professional outcome

A WPBay service must provide skilled digital work with a clear buyer-facing result. Depending on the category, that result may be:

• a configured website, store, account, integration, or automation;
• code, source files, a patch, repository changes, or a deployable build;
• a design, brand asset, Figma file, template, or content package;
• an audit, review, prioritized report, consultation plan, or training session;
• a migration, recovery, cleanup, hardening, optimization, or launch;
• translated and quality-checked files or localized website content;
• an ongoing maintenance or monitoring outcome with a defined service period.

The listing must not be merely an offer to “help with anything,” an unbounded hourly availability promise, access to a contact list, resale of another provider’s package, a disguised digital product, or a vague consultation with no defined duration or output.

The following are not sufficient as approved services by themselves:

• an invitation to contact the seller for a custom quote without a real purchasable package;
• a generic automated report that the buyer can obtain free without meaningful interpretation;
• a copied checklist, tutorial, prompt, template, or stock asset presented as custom work;
• account rental, license-key resale, hosting access, or API credits with no genuine professional service;
• referral to another freelancer while the listed seller accepts no delivery responsibility;
• an outcome dependent on prohibited spam, fake engagement, unauthorized access, pirated assets, policy evasion, or deceptive SEO;
• an impossibly broad promise such as “build any website,” “fix every error,” or “guarantee first position on Google” for one fixed package.

2.2 Select categories by the work actually performed

The primary category must describe the service’s main buyer outcome. Secondary tags and listing text may identify related work. Every applicable overlay still applies.

Examples:

• A Zapier flow that adds WooCommerce orders to a CRM must meet Zapier/Make automation, CRM integration, and relevant WooCommerce & eCommerce requirements.
• A Figma landing page implemented in a custom WordPress theme must meet Figma to WordPress, Landing page design, and WordPress Development requirements.
• A malware cleanup that also updates plugins must meet Malware cleanup, Update service, and WordPress hardening requirements.
• A technical SEO service that adds JSON-LD code must meet Technical SEO, Schema setup, and any applicable WordPress Development requirements.
• A headless WordPress project built with React must meet Headless WordPress, React, REST API, and WordPress Development requirements.

The seller must not choose a softer category to avoid requirements applicable to the real work.

2.3 State the delivery model

The listing must identify the actual delivery model, including as applicable:

• fixed deliverable with no production access;
• remote configuration in a buyer-owned account;
• work performed on staging and deployed to production;
• code delivered as files, a patch, a ZIP, or repository commits;
• design or content delivered as editable source and exports;
• written audit or consultation report;
• live one-on-one session, recording, and materials;
• migration between buyer-controlled systems;
• one-time repair or cleanup;
• maintenance or monitoring for a defined service period;
• implementation dependent on a separately billed third-party platform.

If a service combines several models, the package must identify each deliverable. A call plus recommendations must not be presented as completed implementation unless implementation is included.

2.4 Marketplace fit

Services should relate to WordPress, WooCommerce, websites, web applications, online business systems, digital design, integrations, security, performance, content, localization, or closely connected development work.

WPBay may reject a service that is technically legal but has no credible relationship to the marketplace, cannot be delivered through a clear digital workflow, creates disproportionate dispute risk, or requires WPBay to supervise a regulated or physical activity it is not designed to mediate.

3. Listing, packages, pricing, delivery time, and revisions

3.1 Title and short description

The title must name the concrete service, not use unsupported superlatives or keyword stuffing. It should distinguish the work from a plugin, theme, subscription, hosting plan, or open-ended employment offer.

The opening description must explain:

• the problem solved;
• the intended buyer;
• the main outcome;
• the platform or technology involved;
• the central limitation or prerequisite when it materially affects eligibility.

“Professional,” “premium,” “expert,” “secure,” and similar words do not replace specifics.

3.2 Every package must be independently understandable

For each Basic, Standard, Premium, or other package, state:

• exact included tasks;
• quantity limits, such as pages, templates, products, integrations, flows, events, languages, strings, hours, findings, or environments;
• technical complexity limit;
• delivered files, configuration, report, recording, or deployed result;
• delivery time;
• included revision count;
• required buyer inputs;
• whether staging and production deployment are included;
• whether source or editable files are included;
• whether post-delivery support or bug correction is included and for how long;
• important exclusions;
• third-party fees and licenses not included.

Differences between packages must be meaningful. Do not offer three names for effectively the same service or hide an essential step in a higher tier when the lower tier cannot produce the advertised result.

3.3 Scope units must be measurable

Use units that a buyer and reviewer can verify. Appropriate examples include:

• one WordPress site;
• up to five pages;
• one payment gateway;
• three webhook events;
• one CRM pipeline and ten field mappings;
• up to 2,000 translatable words or 250 software strings;
• one 60-minute consultation;
• review of one repository at a named commit and up to a stated code size;
• one logo concept with three agreed variations;
• migration of one production site up to a stated storage or database size.

Avoid “small,” “simple,” “basic,” “standard,” “reasonable amount,” or “minor work” as the only boundary. Such terms may be used only when the listing also defines what they mean.

3.4 Pricing must represent a deliverable

The displayed price must purchase the stated outcome without an undisclosed mandatory surcharge. The seller must not use a low package as a deposit, consultation fee, or lead-generation entry point when almost every normal buyer will be required to pay more.

Optional extras must:

• provide genuinely additional value;
• state their exact effect on scope, delivery time, or support;
• not duplicate work already promised in the selected package;
• not charge separately to correct a defect in the seller’s own delivered work;
• not be used to unlock a hidden mandatory license, plugin, account, or deployment step.

Custom additions discovered after review of buyer requirements must be agreed before the seller performs them. The buyer must be free to keep the original scope when it remains technically possible.

3.5 Delivery time must be realistic

The seller must choose a delivery time that accounts for:

• discovery and requirement review;
• backups and staging;
• third-party verification or account access;
• implementation;
• testing;
• documentation;
• deployment;
• time-zone differences where a live session is required;
• a reasonable margin for the complexity sold.

Do not advertise 24-hour delivery for a service that normally requires external approval, DNS propagation, field-data collection, app review, payment-provider verification, buyer feedback, or multi-stage deployment unless the package clearly limits the seller’s obligation to work under their control.

The listing must identify which buyer dependencies can delay work. Once blocked, the seller must notify the buyer promptly, explain what is missing, and avoid falsely marking incomplete work as delivered merely to stop a timer.

3.6 Revisions must be defined

A revision normally covers adjustment of the delivered result to the agreed brief, correction of an omission, or refinement within the original concept and quantity.

A revision does not normally include:

• a new platform or technology;
• a new design direction after an approved direction was implemented;
• added pages, features, integrations, languages, or products;
• changes caused by new buyer requirements;
• repair of unrelated pre-existing defects;
• repeated rework after the buyer or a third party changed the delivered result;
• work outside the listed compatibility or environment.

The listing should explain category-specific revision boundaries. Defects and unmet acceptance criteria must be corrected even when the nominal revision count has been used. A seller may not classify their own broken delivery as a paid revision.

4. Seller identity, qualifications, portfolio, and capacity

4.1 Identity and authority

The seller must provide accurate account, business, tax, and payout information as required by WPBay. If acting for a company or team, the seller must have authority to accept orders and bind the delivery team to the listing.

The person or business shown as the seller remains responsible for:

• communication;
• access and confidentiality;
• subcontractors;
• quality control;
• delivery;
• revisions;
• post-delivery commitments;
• evidence supplied to WPBay.

Subcontracting does not transfer responsibility away from the listed seller.

4.2 Qualification claims

Claims such as “certified,” “official partner,” “Google expert,” “penetration tester,” “native translator,” “senior developer,” “accessibility specialist,” “PCI compliant,” or “award winning” must be accurate, current, and verifiable where they materially influence a buyer.

Do not:

• use another person’s certificate;
• imply affiliation from ordinary use of a platform;
• present a course-completion badge as a regulated professional license;
• claim native-language ability that the delivery team does not possess;
• claim years of experience that cannot reasonably be supported;
• imply that WPBay tested or endorsed the seller’s qualification.

WPBay may request evidence for material qualification claims.

4.3 Portfolio and examples

Every portfolio item, screenshot, case study, metric, testimonial, and before/after example must be used with permission and must accurately describe the seller’s contribution.

The seller must not:

• copy another provider’s work;
• present a team member’s unrelated work as the seller’s own without explanation;
• expose a previous buyer’s confidential data, analytics, vulnerabilities, credentials, or unreleased designs;
• fabricate revenue, speed, SEO, conversion, security, or traffic results;
• imply that a template or stock asset was custom-created;
• use a live site as a portfolio example against the owner’s request.

If a result depended on hosting, advertising spend, a separate development team, brand strength, seasonality, or another material factor, the case study should not attribute the whole result to the listed service.

4.4 Capacity and availability

The seller must maintain enough capacity to accept the number of orders allowed by the listing. Delivery time must not assume that every buyer will wait for an undisclosed queue.

Team services should state whether buyers communicate with the named seller, a project manager, or another specialist. If the seller becomes temporarily unavailable, active buyers must be informed and given a realistic continuity plan.

Sellers must pause, extend, or update a listing when they can no longer meet its scope, technology, platform version, or delivery time.

5. Buyer requirements, discovery, scope, and acceptance criteria

5.1 Ask only for information needed to deliver

The buyer-requirements form must collect enough information to determine whether the order can begin, while avoiding unnecessary secrets and personal data.

Depending on the service, requirements may include:

• site or application URL;
• staging availability;
• platform, WordPress, WooCommerce, PHP, framework, theme, and plugin versions;
• hosting and server constraints;
• exact problem, goal, and affected workflow;
• reproduction steps and error messages;
• designs, copy, brand rules, glossary, source files, or content;
• integration providers, event list, field map, and expected data flow;
• target audience, language, locale, browser, device, and accessibility needs;
• required accounts and buyer-owned licenses;
• deadline and launch dependencies;
• authorized testing scope;
• acceptance criteria;
• known custom code or prior incidents.

Do not ask buyers to paste passwords, private keys, payment secrets, recovery codes, full customer databases, or cardholder data into a public requirement field.

5.2 Validate fit before changing anything

After receiving requirements, the seller must confirm:

• the purchased package fits the request;
• the required environment is supported;
• the buyer has authority to request the work;
• the seller has the necessary access and competence;
• the deliverables and exclusions are understood;
• third-party fees and approvals are known;
• the delivery time remains realistic;
• the acceptance criteria can be tested.

If the order does not fit, the seller must explain the mismatch before performing unrelated work. The seller must not create artificial blockers merely to upsell.

5.3 Scope statement

For work with material technical or business risk, the seller should summarize the agreed scope in the order conversation before starting. The summary should identify:

• target site, account, repository, branch, pages, files, or systems;
• current state and known problem;
• included work;
• excluded work;
• buyer dependencies;
• environment and access method;
• backup and staging plan;
• expected deliverables;
• acceptance tests;
• deployment responsibility;
• rollback plan;
• any approved downtime;
• important risks or unknowns.

For security testing, migration, payment, DNS, email, production deployment, and destructive work, this confirmation is required.

5.4 Acceptance criteria

Acceptance criteria must be observable and within the seller’s control.

Good criteria include:

• the named form creates a CRM contact with the agreed fields and no duplicate after a retry;
• the identified checkout flow completes in the payment provider’s sandbox and records the correct WooCommerce order state;
• the supplied Figma page is implemented at agreed breakpoints and passes the agreed keyboard and responsive checks;
• the migration preserves the agreed record counts, URLs, media, users, orders, and redirects;
• the audit delivers a report covering the stated scope, methodology, evidence, severity model, and recommendations;
• the translation contains all in-scope strings, preserves placeholders, and passes an interface review in the target locale.

Bad criteria include:

• “make it perfect”;
• “make Google rank it”;
• “remove every possible vulnerability”;
• “make it fast”;
• “increase sales”;
• “copy this website exactly” without rights or specifications.

5.5 Unknown conditions

Some services necessarily begin with uncertainty. Bug fixing, recovery, malware cleanup, performance work, code review, and migrations may uncover additional causes or damage.

The listing must explain how unknowns are handled. Appropriate models include:

• diagnosis only;
• diagnosis plus correction up to a stated effort or scope;
• correction of one verified root cause;
• a report followed by a separately agreed remediation;
• a bounded first phase with an explicit stop point.

The seller must report a material new condition before expanding scope, changing price, deleting data, replacing architecture, or abandoning the original acceptance criteria.

6. Communication, order lifecycle, delays, and scope changes

6.1 Keep a usable order record

Material decisions must be recorded through the WPBay order conversation or delivery workflow, even when a call, screen share, or external project tool is used.

Record:

• confirmed scope;
• buyer approvals;
• access changes;
• material risks;
• additional costs;
• schedule changes;
• deployment approval;
• delivery contents;
• revision requests;
• acceptance or unresolved issues.

The seller must not rely on an undocumented private conversation when a dispute depends on what was agreed.

6.2 Communication must be professional and timely

The seller must:

• acknowledge material buyer questions within the response expectations stated on the listing;
• explain technical issues in language appropriate to the buyer;
• distinguish confirmed facts from assumptions;
• disclose blockers promptly;
• avoid pressuring the buyer to approve incomplete work;
• not threaten data deletion, site disruption, public disclosure, or loss of access;
• not request a positive review in exchange for delivery, support, a refund, or a correction.

Buyers are not required to understand source code or server administration to receive the promised service. Documentation and explanations must match the intended audience.

6.3 External communication and tools

Calls, screen sharing, repositories, staging platforms, design tools, secure credential channels, and project systems may be used when appropriate. However:

• payment for the WPBay order and agreed additions must follow WPBay rules;
• material scope and delivery decisions must remain documented on WPBay;
• external tools must not be used to hide evidence or avoid marketplace protections;
• the buyer must be told what external account or software is required;
• sensitive data must not be moved to an external tool without a legitimate need and appropriate protection.

6.4 Delays

When the buyer has not supplied a required item, the seller must state exactly what is missing and why work cannot continue. When the delay is the seller’s responsibility, the seller must give an honest revised delivery estimate.

Third-party outages, account verification, DNS propagation, app review, hosting support, data volume, and field-data collection may affect completion. The seller must not promise control over these external timelines.

Repeatedly submitting a placeholder delivery to reset, stop, or satisfy a deadline is prohibited.

6.5 Scope changes

A scope change must identify:

• the new or changed requirement;
• why it is outside the original order;
• the added deliverable;
• price effect;
• delivery-time effect;
• testing and deployment effect.

The buyer must agree before the additional work begins. A seller may refuse an unsafe or incompatible change, but must still deliver the valid original scope when possible.

7. Authorization, access, and credential handling

7.1 Confirm authorization

Before accessing or testing a non-public system, the seller must have a reasonable basis to believe that the buyer owns it or is authorized to commission the work.

Explicit written authorization is required for:

• vulnerability scanning or penetration testing;
• malware investigation involving logs, accounts, or personal data;
• access to production databases;
• DNS, domain, email, payment, analytics, advertising, or cloud changes;
• bulk data export or import;
• impersonation or test transactions using real user roles;
• destructive repair or recovery actions.

Authorization for one domain, account, repository, IP range, tenant, store, or environment does not extend to another.

7.2 Least-privilege access

Use the lowest permission level that can complete the task. Prefer:

• a temporary named WordPress account over sharing the owner account;
• a provider’s collaborator or staff role over shared credentials;
• SFTP or SSH over unencrypted FTP;
• a scoped API token over an account-wide master key;
• read-only access for audits that do not require changes;
• a staging environment over direct production editing;
• a repository branch and pull request over editing an undocumented live file;
• sandbox payment credentials over live secrets.

Administrator, root, database-owner, billing-owner, domain-owner, or payment-account access must be requested only when the task genuinely requires it.

7.3 Credential exchange

Credentials and secrets must:

• be shared through an appropriately protected method;
• never be requested in public listing fields, screenshots, videos, or portfolio material;
• not be stored in plaintext notes, personal chat archives, source repositories, design files, browser recordings, or analytics;
• not be copied into AI systems, public scanners, paste sites, or unrelated project tools;
• be redacted from logs and delivery evidence;
• be limited by scope and expiry where supported.

The seller must not ask for a buyer’s email password when delegated access, an app password, OAuth, or a scoped account can perform the work.

7.4 Account changes and persistence

The seller must not:

• create hidden administrator users;
• reuse an account from another client;
• install a remote-management plugin, SSH key, scheduled task, API token, forwarding rule, recovery address, webhook, or monitoring agent without disclosure;
• change the buyer’s owner identity or recovery details without explicit instruction;
• retain access after the service ends without an ongoing-service agreement;
• disable multifactor authentication merely for convenience without restoring it;
• lock the buyer out of a system or make the seller the only owner.

Every access mechanism created by the seller must be listed at handover and removed, transferred, or intentionally retained with the buyer’s approval.

7.5 End-of-service credential hygiene

At delivery or termination, the seller must:

• remove temporary users, keys, tokens, and trusted devices no longer needed;
• transfer ownership of new accounts;
• identify credentials the buyer should rotate;
• delete local credential copies;
• revoke test webhooks and sandbox integrations no longer needed;
• confirm whether any continuing access remains and why.

The buyer should not need to keep the seller’s personal account as the permanent owner of a business-critical system.

8. Staging, backups, change control, and production safety

8.1 Establish a baseline

Before making a material change, record enough information to understand the starting state. Depending on the service, this can include:

• application and platform versions;
• active plugins, themes, integrations, services, and custom code;
• relevant settings;
• error logs;
• current performance or SEO measurements;
• page screenshots;
• analytics and conversion configuration;
• record counts and database size;
• DNS, SSL, email, and webhook state;
• known defects;
• current deployment commit or file checksum.

The baseline protects both parties and makes before/after claims verifiable.

8.2 Use staging when practical

Development, customization, updates, migrations, payment changes, checkout changes, performance work, malware-remediation testing, and design implementation should normally be performed or rehearsed in staging.

Staging must:

• be access controlled when it contains buyer data or unreleased work;
• prevent accidental search indexing;
• prevent real email, SMS, push, payment, fulfillment, accounting, and webhook actions unless intentionally sandboxed;
• not expose copied personal data unnecessarily;
• be refreshed or sanitized appropriately;
• be distinguishable from production.

When staging cannot reproduce the issue or the buyer explicitly authorizes live work, the seller must minimize change size, choose an appropriate maintenance window, maintain a rollback path, and explain the added risk.

8.3 Back up before risk

A current backup is required before:

• core, theme, plugin, framework, runtime, or dependency updates;
• database migration or search-and-replace;
• malware cleanup;
• site migration or staging-to-live deployment;
• large content import;
• checkout, payment, subscription, membership, tax, or shipping changes;
• destructive code cleanup;
• DNS, SSL, or account-ownership change where recovery information can be preserved;
• any other change capable of causing material data loss or downtime.

The backup must cover the state needed for recovery. For WordPress this normally includes the database, uploads, custom code, plugins, themes, configuration, web-server rules, and other non-reproducible files.

8.4 Verify the recovery path

The seller must not claim “full backup” or “easy restore” without checking that:

• the backup job completed;
• the archive or remote object exists;
• the expected database and files are present;
• encryption keys or credentials needed for restore are available to the buyer;
• retention and storage destination match the package;
• restoration instructions are documented;
• the chosen method can restore the stated environment.

A full test restore is required when the package promises verified restoration, disaster-recovery validation, or migration rollback. Otherwise, the seller must state the level of verification actually performed.

8.5 Change control

Material production changes must be:

• limited to the agreed scope;
• recorded sufficiently for rollback and handover;
• tested before or immediately after deployment as appropriate;
• scheduled around business impact where the buyer identifies a critical period;
• approved when they create downtime, change user-visible behavior, alter tracking, affect payments, or delete data.

Do not combine unrelated cleanup, upgrades, redesign, and configuration changes into one undocumented deployment.

8.6 Rollback and failed deployment

The seller must define a practical rollback or recovery plan before high-risk work. If deployment fails:

• stop further automated changes;
• preserve logs and evidence;
• restore service or data using the agreed plan;
• notify the buyer promptly;
• explain the current state;
• avoid concealing the failure with a temporary workaround presented as final;
• test the recovered critical workflows.

Restoring a backup does not end the seller’s responsibility to explain what failed and whether any transactions, form submissions, orders, emails, or user changes occurred during the affected period.

9. Security, privacy, confidentiality, and data retention

9.1 Security is part of every technical service

The seller must not weaken security merely to complete a task faster. This includes disabling TLS verification, authentication, authorization, multifactor authentication, security headers, file permissions, validation, escaping, malware detection, firewall rules, or platform protections without a necessary, documented, and temporary reason.

Any protection temporarily disabled for diagnosis must be restored and verified before delivery. A workaround that leaves a known vulnerability is not complete unless the buyer knowingly accepts a clearly documented limitation and the remaining risk is not unreasonable.

9.2 Protect the buyer’s environment

The seller must:

• keep the working computer, browser, development environment, and credential storage reasonably secured and updated;
• use unique authentication and multifactor authentication where supported;
• separate client projects;
• avoid downloading sensitive production data unless necessary;
• not use a public or shared test system for private buyer data;
• inspect scripts and tools before running them in the buyer’s environment;
• obtain software from trusted sources;
• avoid pirated, “nulled,” cracked, abandoned, or unverifiable code;
• prevent delivered debug tools and logs from becoming public;
• remove temporary archives, database exports, diagnostic pages, and test accounts.

The seller must not place another customer’s data, credentials, branding, code, or configuration into the buyer’s project.

9.3 Data minimization

Collect, copy, view, export, and retain only the data required to deliver the service.

Examples:

• Performance testing usually does not require a full customer database.
• Design work usually does not require production administrator access.
• A code review usually does not require real API secrets.
• Translation can usually use exported strings rather than production database access.
• Analytics configuration should not require the buyer to send historical user-level data to the seller.
• Malware analysis may require broader access, but unrelated customer content must still be handled carefully.

Where representative data is sufficient, use sanitized, synthetic, masked, or reduced data.

9.4 Confidentiality

Unless the buyer clearly authorizes disclosure, the seller must treat the following as confidential:

• source code and repositories;
• credentials, keys, tokens, certificates, recovery information, and account identifiers;
• unreleased designs, products, campaigns, features, and business plans;
• security findings and incident details;
• customer, employee, vendor, order, payment, analytics, health, membership, and support data;
• pricing, financial, operational, and conversion information;
• internal documentation and communications.

Confidential information must not be reused for training, demos, portfolio material, benchmarking, marketing, dataset creation, or another customer.

9.5 Personal data and legal roles

A service may cause the seller or a third-party tool to process personal data. The seller and buyer remain responsible for determining their applicable legal roles, instructions, lawful basis, notices, contracts, retention, transfer safeguards, and data-subject obligations.

The service listing must identify foreseeable processing that is material to the purchase, including:

• export or access to customer data;
• use of a seller-operated server;
• use of AI, translation, analytics, CRM, email, support, design, monitoring, or automation platforms;
• cross-border or regional processing constraints;
• recording of training or consultation sessions;
• storage of logs, backups, or test data.

WPBay approval is not a data-protection assessment or legal opinion.

9.6 Sensitive data

Services involving payment data, authentication secrets, health information, children’s data, precise location, government identifiers, biometrics, private communications, or another sensitive category require stricter minimization and protection.

Sellers must not request raw card numbers, security codes, bank login credentials, identity-document collections, production private keys, or complete authentication databases when a provider-hosted or scoped alternative exists.

If a service cannot be delivered without handling unusually sensitive data, the listing must disclose that fact and the seller may be required to demonstrate an appropriate secure process. WPBay may reject a service when the handling risk is disproportionate to the offer.

9.7 Local copies, retention, and deletion

The seller must define a reasonable working-retention period for downloaded databases, archives, logs, recordings, screenshots, exports, and source copies.

After the work and any stated correction period:

• delete copies no longer needed;
• empty cloud sync and temporary storage where practical;
• delete exported credentials and environment files;
• retain only material the seller is lawfully required or reasonably entitled to retain;
• preserve no secret access path;
• tell the buyer if a third-party platform retains data under its own policy.

“Deleted” must not be claimed when the seller merely removed a visible link while retaining accessible copies.

9.8 Security incident during service delivery

If the seller discovers or causes a suspected compromise, credential exposure, unauthorized disclosure, lost device, accidental public archive, destructive error, or other material incident, the seller must:

• take reasonable immediate action to contain further harm;
• inform the buyer without undue delay;
• preserve relevant evidence;
• identify affected systems and data as accurately as possible;
• rotate or recommend rotation of affected secrets;
• cooperate with reasonable recovery steps;
• inform WPBay when the incident materially affects the marketplace order, other buyers, or platform safety.

The seller must not conceal an incident to protect a rating or avoid a dispute.

10. Third-party services, accounts, licenses, and costs

10.1 Disclose every required dependency

The listing must disclose every material third-party dependency needed to obtain or keep the advertised result, including:

• premium plugins and themes;
• hosting, CDN, DNS, email, monitoring, backup, security, analytics, CRM, automation, translation, AI, payment, shipping, tax, search, map, font, stock-media, or design services;
• API plans and usage credits;
• app-store, advertising, or verification accounts;
• paid connectors and Zapier or Make task limits;
• developer tools required to maintain delivered source;
• renewal fees.

State whether the cost is included, paid directly by the buyer, or merely recommended. Do not describe a recurring third-party cost as included permanently when the package covers only setup.

10.2 Buyer-owned accounts

Business-critical accounts should normally be created in the buyer’s name using the buyer’s business email and billing control. This includes:

• domain and DNS;
• hosting and cloud infrastructure;
• Google Analytics and Search Console;
• tag managers and advertising accounts;
• payment providers;
• email and CRM platforms;
• automation platforms;
• backup and monitoring destinations;
• Figma or design-system ownership where editable files are promised;
• repositories and deployment accounts;
• app-store and merchant accounts.

The seller may be invited with the minimum necessary role. Creating permanent assets under the seller’s personal account is acceptable only when the listing clearly sells a fixed-period managed service and still provides a documented exit and transfer path.

10.3 Licensing and subscription responsibility

The listing must state who provides and owns each license. A seller must not:

• install a license intended only for the seller’s unrelated sites;
• share one-seat software contrary to its terms;
• use a temporary agency license while promising permanent buyer access;
• install a “nulled” or modified premium product;
• create dependency on a license that will be revoked immediately after delivery without disclosure;
• claim that a GPL license automatically grants rights to unrelated fonts, images, SaaS accounts, trademarks, or proprietary assets.

When a license cannot be transferred, the buyer must be told what they need to purchase and what functionality or updates will stop without it.

10.4 Platform permissions and terms

Integrations and managed accounts must use supported APIs, application types, scopes, and authorization methods. The seller must not:

• ask the buyer to misrepresent app use during provider review;
• bypass a platform’s authentication, billing, quota, anti-abuse, or distribution controls;
• use screen scraping where an official required API must be used and scraping violates the platform’s terms;
• create an integration under an account the buyer cannot maintain;
• promise continued operation against a deprecated or private interface without disclosure.

The seller must identify provider approval, business verification, or access reviews outside the seller’s control.

10.5 Third-party outages and changes

The seller must not guarantee the availability, pricing, policy, API behavior, ranking behavior, email delivery, payment approval, or continued existence of an independent service.

Where an order depends on such a service, delivery documentation should identify:

• provider and account;
• plan and material limits;
• configured integration;
• current API or platform version;
• monitoring or error location;
• renewal responsibility;
• what fails if the provider is unavailable;
• replacement or disconnection method.

11. Execution quality, testing, and evidence

11.1 Follow the platform’s supported methods

Services must use the official architecture, APIs, configuration, extension points, and deployment practices of the target platform wherever practical.

Direct edits to WordPress core, WooCommerce core, a vendor package, a parent theme, a generated build output, or another component overwritten by updates are blockers unless:

• the service is specifically forensic or emergency recovery;
• no supported alternative exists;
• the buyer understands the maintenance consequence;
• the change is isolated and documented;
• a durable patch or upstream strategy is delivered.

“It works now” is not enough when the implementation is predictably destroyed by the next routine update.

11.2 Quality applies to all delivered material

Delivered code must be readable, secure, maintainable, and appropriately documented. Delivered design must be usable, consistent, editable as promised, and based on licensed assets. Delivered content must be original, accurate, and fit the brief. Delivered reports must be specific, prioritized, supported by evidence, and understandable.

The seller must remove:

• placeholder content;
• dead code and abandoned experiments;
• debug statements;
• test accounts and keys;
• sample tracking IDs;
• temporary banners or maintenance pages;
• broken links and missing assets;
• unused public services created during implementation;
• confidential comments or metadata.

11.3 Test the affected workflow

Testing must cover the risk and scope of the service, including as applicable:

• normal successful use;
• invalid, missing, duplicate, expired, and boundary input;
• relevant roles and permissions;
• responsive and current-browser behavior;
• keyboard and assistive-technology use;
• cache enabled and disabled;
• logged-in and logged-out states;
• mobile and desktop;
• slow or failed third-party responses;
• retries and duplicate webhooks;
• payment sandbox outcomes;
• scheduled and background execution;
• imports, exports, and data integrity;
• upgrade and rollback;
• translated layouts and locale-specific formatting;
• critical post-migration routes, forms, search, login, checkout, email, and redirects.

Do not use a live card, send a real campaign, fulfill a real order, delete live data, or trigger a destructive automation solely as a test without explicit approval and appropriate safeguards.

11.4 No testing only as administrator

The seller must test from the perspective of the real user roles affected by the change. Administrator success does not prove:

• a customer can check out;
• a subscriber can access content;
• a vendor can manage products;
• an editor can use the interface;
• an anonymous visitor can submit a form;
• a webhook has correct object-level authorization;
• a translated page works for a non-default locale.

Permission changes must be tested directly at the action or endpoint, not only by observing whether a menu is hidden.

11.5 Before-and-after evidence

Where the service promises a measurable improvement, use a fair comparison:

• same relevant page or workflow;
• comparable device, location, network, cache, data, and login state;
• same measurement tool and settings;
• timestamp and environment;
• enough repetitions or field data for the claim being made;
• disclosure of other simultaneous changes.

Do not compare a cold mobile production test against a warm desktop staging test or attribute an unrelated hosting upgrade entirely to the seller’s optimization.

11.6 Delivery evidence

Depending on the service, evidence may include:

• repository commit or patch;
• changed-file list;
• configuration screenshots with secrets redacted;
• test results;
• before/after measurements;
• event or webhook logs;
• sample records;
• migration counts;
• checksum verification;
• accessibility or browser test notes;
• audit findings;
• a short walkthrough;
• deployment record;
• backup and restore verification;
• buyer-visible files and account ownership.

Evidence must show the actual buyer order, not a generic demonstration from another environment.

11.7 Tool limitations

The seller must understand and disclose material limits of the tools used.

Examples:

• Lighthouse lab data is not the same as Chrome User Experience Report field data.
• A malware scanner can miss persistence, database payloads, stolen credentials, or server-level compromise.
• An automated accessibility scan cannot validate every WCAG success criterion.
• An SEO plugin’s green indicator does not establish ranking quality.
• A translation engine does not understand every business, legal, cultural, or interface context.
• A static analyzer does not prove business-logic authorization.
• A successful backup log does not prove restoration.

12. Delivery, documentation, handover, acceptance, and revisions

12.1 A delivery must contain the promised result

The seller must not submit:

• an empty message;
• a progress screenshot;
• a request for more time;
• a link the buyer cannot access;
• an invoice or upsell;
• partial work presented as final;
• a generic report unrelated to the buyer;
• a promise to deliver later outside WPBay.

as the final delivery.

If a package has staged milestones, the listing or order must make those stages clear and the final delivery must identify what remains.

12.2 Delivery summary

Every material service should include a concise delivery summary stating:

• what was completed;
• where the work was performed;
• which files, pages, accounts, settings, records, or systems changed;
• what was tested;
• where the deliverables are located;
• known limitations;
• remaining buyer actions;
• access or credential actions required;
• applicable support or correction period;
• how to request an included revision.

12.3 Source and editable files

When the listing promises source or editable files, deliver them in an ordinary maintainable format. Examples include:

• plugin, theme, PHP, JavaScript, React, or Laravel source;
• repository history or a clean patch where promised;
• build and dependency files;
• unflattened Figma, vector, layered image, or design-system source;
• editable email templates;
• source translation files such as PO and documented locale assets;
• configuration export for automation or analytics where the provider supports it.

An exported PNG is not an editable logo source. A minified production bundle is not complete development source. A screenshot of an automation is not an export or maintainable specification.

12.4 Documentation

Documentation must be proportionate to the deliverable and may include:

• setup and configuration;
• dependencies and licenses;
• deployment and rollback;
• routine operation;
• account ownership and user roles;
• backup and restore;
• update process;
• renewal costs;
• troubleshooting;
• data flow and retention;
• test procedure;
• known limitations;
• how to disable or remove the implementation.

Code comments do not replace buyer-facing documentation.

12.5 Handover

At handover, the buyer must receive the promised control over:

• source and production files;
• repositories and branches;
• domains, hosting, deployment, analytics, design, CRM, email, automation, payment, backup, monitoring, and related accounts;
• license and renewal information;
• administrator ownership;
• recovery methods;
• documentation;
• remaining tasks.

The seller must remove or disclose their access as required by Section 7.

12.6 Acceptance

Acceptance is based on the agreed scope and criteria, not whether the buyer subjectively likes every aspect of work that matches an approved brief.

The seller must provide the buyer a reasonable opportunity to:

• open and inspect files;
• access the deployed result;
• run the agreed workflows;
• identify missing deliverables;
• request included revisions;
• report reproducible defects.

WPBay may consider listing promises, order messages, requirement answers, accepted changes, delivery evidence, and buyer cooperation when reviewing a dispute.

12.7 Corrections versus revisions

A correction fixes:

• a promised item that is missing;
• a reproducible defect introduced by the seller;
• failure to meet an agreed acceptance criterion;
• a delivered file that cannot be opened or used as promised;
• a security or data-integrity problem caused by the implementation.

A revision changes a valid delivered result within the agreed brief.

The seller must not consume a paid revision to fix their own defect. The buyer must not use defect correction to add new scope.

12.8 Post-delivery support

The listing must state whether it includes:

• no ongoing support;
• a limited defect-correction period;
• a named number of support questions;
• deployment assistance;
• maintenance for a defined period;
• future compatibility or updates.

Do not use “lifetime support,” “permanent maintenance,” or “always available” unless the seller has a clear sustainable definition and the commitment is allowed by WPBay. Ordinary support does not automatically include new features, third-party changes, buyer modifications, hosting administration, content work, or training.

13. Intellectual property, content rights, and AI-assisted work

13.1 Seller-created work

The listing must make clear what rights the buyer receives in custom code, designs, copy, translations, reports, recordings, templates, and other original deliverables, subject to WPBay’s current terms and the licenses of underlying components.

The seller must have authority to grant those rights. Work created by employees or subcontractors must be covered by appropriate agreements.

13.2 Buyer-supplied material

The seller may rely on the buyer’s representation that supplied logos, content, code, customer data, and designs are authorized for the project unless there is an obvious concern. The seller must not expand use beyond the order.

If the buyer requests an obvious clone, infringement, impersonation, pirated integration, or unauthorized removal of copyright or licensing controls, the seller must refuse that portion.

13.3 Third-party assets

Every font, icon, image, template, component, library, snippet, model, dataset, stock asset, and other third-party element included in the deliverable must have a license permitting the intended commercial use and delivery.

The delivery must identify as applicable:

• source;
• creator or vendor;
• license;
• attribution;
• purchase or renewal requirement;
• edit and redistribution limits;
• whether the buyer receives the source or only a usage right.

The seller must not purchase a single-use stock asset for one client and silently reuse it for others contrary to its license.

13.4 Logo and brand work

The seller must not promise that a logo is registrable, exclusive, or free from every conflicting mark unless a qualified search or legal service is actually included.

At minimum, logo work must avoid:

• copied logos;
• obvious near-duplicates;
• unlicensed typefaces or symbols;
• stock icons presented as fully exclusive custom marks;
• generated imagery whose rights or distinctiveness are misrepresented.

Trademark clearance and legal registration are separate professional services unless explicitly included.

13.5 AI-assisted work

AI-assisted service delivery is allowed. The seller remains responsible for:

• factual accuracy;
• code security and maintainability;
• originality and plagiarism review;
• asset and dataset rights;
• preservation of placeholders, data, and requirements;
• accessibility;
• translation quality;
• disclosure of material external processing;
• confidentiality;
• final human review.

The seller must not submit buyer source, credentials, private data, unreleased designs, security findings, or confidential content to an AI provider without appropriate authorization and disclosure.

Raw generated output is not a professional deliverable merely because it is long, polished, or syntactically valid.

13.6 Portfolio rights

The buyer’s purchase does not automatically authorize public display of private or unreleased work. The seller should obtain permission before publishing the buyer’s name, site, logo, metrics, screenshots, testimonial, source, security findings, or project details.

14. Claims, guarantees, account ownership, and vendor lock-in

14.1 Claims must be bounded and testable

Claims such as the following require a defined measurement and scope:

• “90+ PageSpeed score”;
• “WCAG compliant”;
• “GDPR compliant”;
• “hack-proof”;
• “100% malware removal”;
• “zero downtime”;
• “pixel perfect”;
• “inbox delivery guaranteed”;
• “first page on Google”;
• “double your conversion rate”;
• “works with every plugin.”

If the result depends on traffic, hosting, third parties, buyer content, browser behavior, field data, provider approval, or future platform changes, that dependency must be clear.

14.2 No guaranteed third-party outcome

A seller may promise to correctly perform work, submit information, meet documented platform requirements, or implement an agreed configuration. A seller must not guarantee:

• search ranking or indexing;
• rich-result display;
• app, merchant, advertising, payment, email, or API approval;
• email inbox placement;
• advertising performance;
• continued API access;
• successful trademark registration;
• legal or regulatory acceptance;
• a third party’s processing time.

14.3 Buyer control

The service must not create avoidable dependence on:

• the seller’s personal hosting;
• a seller-controlled domain;
• a seller-only repository;
• an undocumented custom framework;
• a hidden encryption or license key;
• an account the buyer cannot access;
• a continuing seller-controlled service or fee not disclosed in the package;
• an unpublished build tool;
• an API proxy operated only by the seller;
• a design source the buyer was promised but did not receive.

Fixed-period managed services may intentionally retain infrastructure under seller control, but the listing must identify the model and provide an appropriate export, transfer, or ending process.

14.4 No hostage behavior

The seller must not:

• disable a live site or integration to force acceptance or payment outside WPBay;
• retain the only recovery credentials;
• encrypt buyer data to prevent migration;
• insert a hidden expiry or remote kill switch;
• remove buyer access after delivery;
• withhold an included source file until a positive review;
• threaten public disclosure of vulnerabilities or business data;
• make rollback impossible without disclosure.

14.5 Future compatibility

A one-time service is responsible for the environment and versions agreed at delivery. It does not automatically include indefinite compatibility with future WordPress, WooCommerce, PHP, browser, provider, API, plugin, theme, or policy changes.

If future maintenance is included, define:

• supported period;
• update frequency;
• compatibility boundary;
• response target;
• excluded major redesigns or migrations;
• renewal or termination model.

15. Automation & Integrations

Automation services can affect many records quickly and often operate without a person reviewing each action. The seller must therefore design for authorization, data quality, retries, duplication, rate limits, observability, pause, and recovery.

15.1 Common integration requirements

Every integration service must document:

• source and destination systems;
• buyer-owned accounts and required plans;
• trigger and action;
• object and field mapping;
• authentication method and scopes;
• data direction;
• filtering and transformation rules;
• expected volume and frequency;
• rate and quota limits;
• failure behavior;
• retry and duplicate handling;
• logging and alerting;
• personal or sensitive data transferred;
• test method;
• disable and removal method.

The seller must use supported APIs and official connection methods where available.

Credentials must use the narrowest practical scopes and must not be embedded in client-side code, public URLs, shared screenshots, automation names, or export files. OAuth or platform-managed connections should be preferred over sharing an account-wide API key.

15.2 Data mapping and validation

Before enabling production writes, the seller must:

• identify required and optional fields;
• map identifiers, ownership, status, currency, dates, timezones, locale, consent, and enum values correctly;
• define how empty, malformed, truncated, unknown, and deleted values behave;
• preserve a stable external identifier for reconciliation;
• avoid matching people or orders on an ambiguous value when a stable ID exists;
• test sample records representing real edge cases;
• prevent formulas, markup, or commands from becoming active unexpectedly in destination systems.

The buyer should receive a readable mapping table or equivalent documentation for material integrations.

15.3 Idempotency, retries, and ordering

An integration must not create duplicate contacts, charges, orders, subscriptions, tickets, messages, invoices, or tasks merely because:

• the sender retried;
• a webhook was delivered twice;
• a job timed out after the remote side succeeded;
• the automation platform replayed history;
• messages arrived out of order;
• the user refreshed a page.

Where supported, use idempotency keys, unique external IDs, event IDs, state machines, locks, and safe upsert behavior. Retries must be bounded, delayed appropriately, and limited to failures that can safely be repeated.

When event order matters, the seller must define how stale or reordered events are detected and reconciled.

15.4 Production enablement

Before activation:

• use test or sandbox accounts where available;
• prevent test records from reaching real customers or accounting;
• validate with a small controlled production sample where necessary;
• confirm the automation is not recursively triggering itself;
• confirm filters and account selection;
• establish logs and alerts;
• document how the buyer can pause the flow;
• preserve the previous process until the new one is verified when practical.

Bulk historical synchronization requires a record-count estimate, rate plan, duplicate strategy, error export, and rollback or reconciliation method.

15.5 Analytics/tracking integration

Services in Analytics/tracking integration must state:

• tools and property/container IDs;
• websites, apps, domains, or subdomains covered;
• events, parameters, user properties, conversions, and attribution expectations;
• client-side, server-side, or hybrid implementation;
• consent and regional behavior;
• cross-domain and referral handling;
• test and debug tools;
• data retention and advertising features;
• filters for internal, staging, test, and payment-provider traffic;
• ownership and access roles.

The seller must:

• avoid duplicate page views and events;
• use stable event names and documented parameters;
• exclude secrets and unnecessary personal data;
• avoid sending email addresses, names, full form values, or prohibited identifiers to analytics tools;
• verify tags under accepted, rejected, and changed consent states where applicable;
• test real-time/debug collection and ordinary reports;
• distinguish configuration completion from the later availability of processed reports;
• avoid claiming exact parity between analytics, ad platforms, server logs, and Search Console.

Tracking must not be installed in a way that bypasses the buyer’s consent policy or applicable law. The seller may implement the buyer’s approved consent requirements but must not present a technical tag configuration as universal legal compliance.

15.6 CRM integration

Services in CRM integration must define:

• contact, company, deal, ticket, activity, product, and custom-object scope;
• field ownership and source of truth;
• create, update, merge, archive, and deletion rules;
• duplicate matching;
• pipeline, stage, owner, team, and permission mapping;
• consent, suppression, and communication-preference mapping;
• historical import and future synchronization behavior;
• conflict resolution.

The seller must not overwrite a more authoritative value merely because the remote field is non-empty. Bidirectional synchronization requires loop prevention and an explicit conflict policy.

Imports must preserve consent evidence and must not silently subscribe contacts to marketing. Test records must be clearly marked and removed. The handover must identify workflows, custom fields, lists, views, API apps, private tokens, limits, and any buyer action required to maintain them.

15.7 Email marketing integration

Services in Email marketing integration must:

• use permission-based audiences;
• preserve subscription status, unsubscribe, bounce, complaint, and suppression state;
• not import purchased, scraped, inferred, or unauthorized lists;
• define transactional versus marketing messages;
• configure domain verification and authentication appropriate to the provider;
• document sender identity and reply handling;
• test personalization, fallback values, links, tracking, plain-text content, mobile rendering, and unsubscribe behavior;
• avoid exposing API keys in browsers or mobile clients;
• process provider webhooks safely;
• avoid duplicate sends after retries.

SPF, DKIM, DMARC, branded tracking, and return-path configuration must be handled according to the sending provider and the buyer’s existing DNS. The seller must inspect existing records before replacing them. A valid DNS record does not guarantee inbox placement.

Email automation must respect applicable consent and commercial-email rules. The seller must not promise that a technical setup gives the buyer permission to contact a list.

15.8 Payment automation

Services in Payment automation receive strict review.

The seller must:

• use the payment provider’s official API, SDK, hosted fields, checkout, tokenization, or supported integration;
• use sandbox mode first;
• never request or store card security codes;
• avoid handling raw cardholder data when a hosted or tokenized method is available;
• keep secret keys server-side;
• separate test and live credentials;
• verify webhook signatures using the original payload;
• verify amount, currency, order, customer, merchant account, and event identity server-side;
• handle duplicate, delayed, failed, cancelled, refunded, disputed, and partially refunded events;
• use idempotency for payment creation and fulfillment;
• reconcile ambiguous states with the provider;
• avoid marking an order paid from a browser redirect alone;
• document tax, invoice, subscription, refund, and accounting boundaries.

The seller must not perform an unauthorized live charge or refund for testing. If a small live transaction is necessary, the amount, account, refund plan, and approval must be recorded first.

PCI DSS responsibilities, regulated payment activity, tax, accounting, and financial compliance remain with the applicable merchants and providers. A setup service must not claim to certify the buyer.

15.9 Webhooks

Services in Webhooks must document:

• event names and versions;
• endpoint URLs and environments;
• payload examples or schema;
• authentication or signature method;
• replay window;
• expected response;
• timeout;
• retry schedule;
• event ordering;
• idempotency;
• logging and retention;
• endpoint rotation or removal.

Webhook receivers must:

• require HTTPS;
• verify authenticity before processing;
• use constant-time comparison where appropriate;
• reject stale or replayed events when the provider supports timestamps or event IDs;
• acknowledge quickly and move long work to a queue;
• validate the payload after authenticity verification;
• enforce object-level authorization;
• not trust an event’s price, account, or entitlement without the provider’s authoritative context;
• return controlled status codes;
• redact secrets and sensitive payload fields from logs.

Webhook senders must sign or authenticate events when possible, retry safely, and provide a test event. A “secret URL” alone is not sufficient protection for a sensitive action.

15.10 Zapier/Make automation

Services in Zapier/Make automation must deliver more than screenshots. The buyer must receive:

• ownership or transferable access to the Zap, scenario, connection, folder, and related data store;
• a readable flow description;
• trigger, filters, routers, branches, error handlers, and schedules;
• connection and plan requirements;
• task or operation consumption estimate;
• test records and expected result;
• error and replay instructions;
• pause and disable instructions.

The seller must:

• name steps and variables clearly;
• avoid hard-coded client secrets in text fields;
• use platform connection objects;
• prevent infinite loops;
• add filters before expensive actions where practical;
• handle partial failure;
• define what happens when task quotas are exhausted;
• avoid storing sensitive payloads longer than needed in run history;
• test duplicate and missing-field behavior;
• leave the scenario disabled until production activation is agreed.

If custom code is used within Zapier or Make, it must meet the same input, secret, error, timeout, and maintainability requirements as ordinary code.

16. Consulting & Training

Consulting and training services are professional deliverables, not paid access to generic opinions. The package must define duration, preparation, topics, format, output, and whether implementation is included.

16.1 Common consulting requirements

The listing must state:

• session or review duration;
• channel and scheduling method;
• required preparation;
• technology and business scope;
• whether the seller reviews material before the session;
• whether the session is recorded;
• included notes, report, action plan, examples, or follow-up;
• implementation exclusions;
• cancellation or rescheduling expectations under current WPBay rules.

Advice must be based on the buyer’s facts and current environment. The seller must distinguish:

• fact;
• diagnosis;
• recommendation;
• assumption;
• risk;
• optional preference.

Generic AI-generated advice or a recycled checklist without buyer-specific analysis is not sufficient.

16.2 Code Review

A Code Review service must define:

• repository, archive, language, framework, and version scope;
• commit, tag, branch, or file set reviewed;
• approximate size or review limit;
• manual versus automated methods;
• focus areas, such as security, correctness, maintainability, performance, architecture, tests, or platform standards;
• whether dynamic testing is included;
• severity or priority model;
• report format;
• whether fixes or a retest are included.

The report must:

• identify each material finding by location;
• explain why it matters;
• distinguish confirmed defects from possible risks;
• include safe evidence or reproduction information;
• recommend a practical correction;
• identify limitations and unreviewed areas;
• avoid inflated severity;
• avoid copying scanner output without validation.

The seller must not exploit a production environment merely because source access was provided. Credentials discovered in code must be redacted and reported promptly.

Reviewing a snippet does not justify declaring an entire application secure. A code review must not be advertised as a penetration test unless the required dynamic scope and authorization are included.

16.3 One-on-One Training

A One-on-One Training listing must state:

• learner level;
• learning objectives;
• session duration and number;
• live or recorded format;
• software and accounts required;
• exercises or materials;
• whether the session uses the learner’s site or a safe practice environment;
• recording ownership and retention;
• follow-up questions or materials included.

The seller must:

• use legally shareable materials;
• avoid exposing another client’s environment;
• not request production administrator access when a demonstration site is sufficient;
• adapt pace to the advertised level;
• provide the promised examples or notes;
• disclose when a third-party course, certification, or paid tool is required;
• not promise employment, income, certification, or mastery from a short session.

If the session involves production changes, those changes must meet the same backup, authorization, testing, and handover requirements as an implementation service.

16.4 Security Audit

A Security Audit must have written rules of engagement before testing begins.

The scope must identify:

• authorized domains, IPs, applications, repositories, accounts, APIs, and environments;
• excluded systems and third parties;
• testing dates and timezone;
• permitted automated and manual techniques;
• whether authentication and test accounts are supplied;
• request-rate and concurrency limits;
• prohibited disruptive methods;
• contact and emergency stop procedure;
• data handling;
• report and retest scope.

Unless separately authorized, the seller must not perform:

• denial-of-service or resource-exhaustion tests;
• social engineering;
• credential attacks;
• destructive exploitation;
• persistence;
• data exfiltration beyond minimal proof;
• testing of a hosting provider, SaaS provider, customer, employee, or third-party system outside the buyer’s authority.

The report must contain:

• executive summary;
• scope and methodology;
• dates and environment;
• finding title and severity;
• affected component;
• evidence;
• impact;
• reproducible steps or sufficient technical detail;
• remediation;
• limitations;
• false-positive disposition.

Sensitive findings must be delivered privately. The seller must not publicly disclose a vulnerability or use it in marketing without the buyer’s permission and an appropriate disclosure process.

An automated vulnerability scan alone may be sold as a scan only if presented honestly. It must not be called a comprehensive security audit.

16.5 Website Audit

A Website Audit must identify the dimensions included, such as:

• usability and navigation;
• accessibility;
• performance;
• SEO;
• security;
• content;
• conversion;
• analytics;
• mobile behavior;
• technical quality;
• eCommerce workflow.

The report must prioritize findings by impact, confidence, and effort. Each material recommendation should identify the affected page or workflow and include evidence.

The seller must not:

• use only a generic score;
• report the same boilerplate recommendations regardless of the site;
• claim legal accessibility compliance from automation alone;
• claim a vulnerability from a banner or version number without verification;
• diagnose conversion problems without relevant evidence;
• present personal design preference as an objective defect.

Implementation is not included unless stated.

16.6 WordPress Consultation

A WordPress Consultation must define the decision or problem it helps resolve. Appropriate topics include architecture, plugin selection, build-versus-buy, hosting, migration, security planning, performance strategy, maintenance, marketplace products, WooCommerce, or development workflow.

Recommendations must:

• consider the site’s scale, budget, skill, data, traffic, business risk, and maintenance capacity;
• disclose affiliate, reseller, ownership, or other material commercial interest;
• distinguish free, paid, custom, and hosted options;
• identify important license and renewal costs;
• avoid recommending abandoned or incompatible software;
• include a written summary or decision record when promised.

The seller must not install or purchase a product without buyer approval merely because it was recommended.

17. Design & Branding

Design services must deliver original, usable, appropriately licensed work that satisfies the agreed brief and technical context. Visual appeal alone does not excuse unreadable text, inaccessible contrast, broken responsive behavior, missing source, or copied assets.

17.1 Common design requirements

The brief should identify:

• audience;
• brand and purpose;
• required dimensions, platforms, formats, and variants;
• content supplied by the buyer;
• style references;
• prohibited styles or competitors;
• accessibility needs;
• languages;
• print or digital color space where relevant;
• source-file requirement;
• revision and concept count.

The seller must provide the formats promised, use organized and editable source, preserve adequate resolution, and avoid accidental cropping or illegibility at the real display size.

17.2 Banners/icons/graphics

Services in Banners/icons/graphics must state:

• number of assets;
• exact dimensions or platform placements;
• static, animated, or interactive format;
• file formats;
• source-file inclusion;
• text and image responsibility;
• variant count;
• compression or file-size limits.

Assets must:

• remain legible at intended size;
• use safe margins where the target platform overlays controls;
• avoid misleading interface controls;
• preserve transparent backgrounds where promised;
• include optimized web exports where intended for the web;
• use consistent icon geometry and stroke where sold as a set;
• not rely on raster enlargement for supposedly scalable assets;
• use alt-text recommendations or accessible accompanying copy where relevant.

17.3 Brand kit

A Brand kit must list its components, which may include:

• logo system;
• colors with appropriate values;
• typography;
• spacing or layout principles;
• icon or image style;
• usage rules;
• social and web examples;
• editable source and exports.

The delivery must explain approved and prohibited logo use, minimum size, clear space, background variants, and font licensing where included.

A mood board alone is not a full brand kit. A list of colors and a logo export does not justify claims of complete brand strategy unless positioning, audience, voice, and application rules are actually included.

17.4 Figma to WordPress

Figma to WordPress combines design interpretation and development. It must meet both this section and Section 25.

Before implementation, confirm:

• pages and frames in scope;
• desktop, tablet, mobile, and intermediate behavior;
• component states;
• hover, focus, active, disabled, loading, empty, error, and validation states;
• content behavior for longer or missing text;
• font and asset rights;
• animation and interaction;
• CMS-editable content;
• reusable components;
• browser support;
• accessibility target;
• theme, builder, block, or custom-code approach.

The seller must not blindly copy absolute pixel positions from one desktop frame. The implementation must adapt responsibly to real content and viewport sizes.

“Pixel perfect” may describe close visual fidelity at agreed reference widths, but must not mean fragile fixed dimensions, inaccessible text, image-based text, or a layout that breaks between frames.

Deliverable code must:

• avoid unnecessary inline duplication;
• use responsive images;
• preserve semantic heading and landmark structure;
• support keyboard use;
• provide visible focus;
• use sufficient contrast;
• not globally conflict with the existing site;
• remain maintainable in the agreed WordPress editing model.

17.5 Landing page design

A Landing page design package must state whether it includes:

• wireframe;
• visual design;
• copy;
• implementation;
• mobile layouts;
• form or checkout;
• tracking;
• A/B test variants;
• image sourcing;
• post-launch analysis.

The design must make the main action understandable, avoid deceptive patterns, provide necessary context for forms and claims, and account for validation, success, error, loading, privacy, cookie, and consent states.

A visually complete mockup is not an implemented landing page unless development is included.

17.6 Logo design

A Logo design listing must define:

• number of original concepts;
• included refinement rounds;
• wordmark, symbol, monogram, or combined scope;
• color and monochrome variants;
• horizontal, vertical, icon, and small-size versions;
• vector and raster formats;
• source files;
• font and asset licensing;
• brand-guideline inclusion.

The seller must check the design for obvious similarity and stock-asset restrictions. If generative AI is used materially, the seller must review originality, disclose limitations where relevant, and must not promise exclusive registrable rights without a proper clearance process.

Final exports should normally include an editable vector format and practical web formats. The buyer must not be left with only a flattened low-resolution preview.

17.7 UI/UX improvements

A UI/UX improvements service must identify:

• pages and workflows;
• evidence source, such as heuristic review, analytics, user feedback, usability test, or accessibility review;
• design versus implementation scope;
• target devices and users;
• success criteria.

Recommendations must connect a real problem to a proposed change. The seller must not remove necessary disclosure, consent, pricing, cancellation, accessibility, or security friction merely to make a funnel appear shorter.

If conversion improvement is claimed, the seller must distinguish a hypothesis from a measured result. A redesigned interface must still preserve content, permissions, validation, error handling, and business logic.

18. Marketing & Content

Marketing and content services must produce original, accurate, lawful, audience-appropriate work. The seller must not fabricate evidence, plagiarize, impersonate customers, create deceptive claims, or use prohibited spam and manipulation.

18.1 Common content requirements

The brief should identify:

• audience and buyer stage;
• brand voice;
• factual sources;
• offer and call to action;
• target language and locale;
• required length and format;
• keywords or topics;
• prohibited claims;
• legal or compliance review responsibility;
• accessibility and plain-language expectations;
• source and citation requirements;
• number of variants.

The seller must verify names, specifications, prices, statistics, dates, links, and quoted claims supplied or introduced during writing.

18.2 Originality and AI

Content must not be copied, lightly paraphrased from a competitor, spun to evade detection, or generated without review.

AI-assisted content must be:

• fact checked;
• edited for the actual brand and audience;
• reviewed for repetition, hallucination, plagiarism, unsafe claims, and unnatural language;
• free of hidden prompts or irrelevant boilerplate;
• based only on information the seller is authorized to process.

The seller must not falsely advertise generic AI output as specialist human research, native translation, or original expert testimony.

18.3 Conversion copywriting

Conversion copywriting must be based on a credible understanding of the offer, audience, objections, differentiators, and intended action.

The seller must not:

• fabricate scarcity, countdowns, customers, reviews, guarantees, statistics, certifications, endorsements, or before/after outcomes;
• hide material price, renewal, limitation, or eligibility information;
• use fear, shame, or impersonation in a deceptive way;
• copy a competitor’s distinctive text;
• promise regulated outcomes without evidence.

If research, interviews, voice-of-customer analysis, or testing is included, define the source, sample, and output.

18.4 Email templates

Services in Email templates must state whether they deliver:

• design only;
• coded HTML;
• provider-native template;
• copy;
• responsive variants;
• dark-mode considerations;
• plain-text version;
• testing.

Coded email must:

• use techniques supported by the claimed clients;
• remain readable when images are blocked;
• include meaningful alt text;
• avoid image-only essential content;
• use a logical reading order;
• have clear links and buttons;
• avoid exposing test personalization values;
• use unsubscribe and legal footer areas appropriate to the buyer’s campaign;
• be tested in representative email clients when compatibility is claimed.

Email-client consistency is not the same as pixel identity. The listing must state the actual compatibility tested.

18.5 Landing page copy

Landing page copy must identify the included sections, word range, research depth, SEO scope, number of variants, and whether implementation is included.

The copy must align with the actual product and must not:

• claim unavailable features;
• invent testimonials;
• conceal mandatory costs;
• promise guaranteed rankings, income, security, health, or legal outcomes;
• use another brand’s protected identity deceptively.

18.6 Newsletter setup

A Newsletter setup service must define:

• provider;
• audience source;
• sender domain;
• form and consent flow;
• double or single opt-in behavior;
• lists, tags, groups, or segments;
• template;
• welcome or other automations;
• domain authentication;
• unsubscribe and suppression behavior;
• analytics;
• test campaign;
• ongoing campaign exclusions.

The seller must not import an unauthorized list or send a live campaign without approval. The buyer must own the audience and account. Domain DNS changes must preserve existing email services and be documented.

18.7 Product descriptions

Services in Product descriptions must define product count, length, source material, variation handling, SEO fields, tone, and format.

Descriptions must accurately reflect:

• product function;
• materials or technical specifications;
• compatibility;
• dimensions or variants;
• included items;
• limits and warnings;
• licensing or subscription conditions where material.

The seller must not invent specifications, reviews, origin claims, certifications, sustainability claims, medical benefits, or warranty terms.

For large catalogs, templating and AI may assist, but each output must retain correct product data and avoid near-duplicate filler that misleads users or search engines.

18.8 Social media graphics

Services in Social media graphics must state platforms, placements, sizes, number of concepts, editable source, and content responsibility.

Graphics must:

• fit current platform dimensions or adaptable safe zones;
• remain legible on mobile;
• use licensed imagery and fonts;
• avoid fake platform UI, verification badges, endorsements, or engagement;
• match the supplied campaign claims;
• identify animation or video requirements;
• include accessible caption or alt-text recommendations where requested.

The package does not include publishing, account access, advertising, moderation, or campaign performance unless stated.

19. Other Development

Development services must deliver secure, readable, maintainable code and must follow the WPBay technical requirements for the kind of software produced. The listing must define technology, version, repository, environment, code ownership, tests, documentation, deployment, and support.

19.1 Common development requirements

The seller must:

• use version control for material work where practical;
• work on a branch or isolated copy;
• preserve the buyer’s unrelated changes;
• follow the native coding standards;
• avoid editing dependencies or generated files as the only fix;
• validate and authorize every server-side action;
• protect secrets;
• use parameterized database access;
• escape output in context;
• avoid obsolete or unsupported dependencies;
• add or update tests where the project supports them;
• document setup, build, deployment, and changed public interfaces;
• deliver source and dependency manifests;
• identify migrations and rollback constraints.

The seller must not include code copied from an incompatible source or use a proprietary snippet without rights.

19.2 Headless WordPress

Services in Headless WordPress must define:

• frontend framework and hosting;
• WordPress role as content source;
• REST API, GraphQL, custom API, or build-time data strategy;
• authentication;
• preview and draft behavior;
• media handling;
• redirects and canonical URLs;
• SEO and structured data;
• cache and invalidation;
• webhooks and rebuilds;
• forms and search;
• localization;
• deployment and environment ownership.

The implementation must:

• preserve private and draft content boundaries;
• enforce authorization server-side;
• avoid exposing application passwords or API secrets to the browser;
• handle preview tokens safely;
• validate custom endpoints;
• avoid uncontrolled data enumeration;
• define what happens when WordPress or the frontend host is unavailable;
• keep canonical, sitemap, robots, social metadata, and redirects consistent;
• transfer both WordPress and frontend ownership to the buyer.

Headless architecture must not be recommended solely because it is fashionable. The consultation must account for hosting, build, preview, plugin compatibility, editor workflow, cache invalidation, maintenance, and total cost.

19.3 JavaScript Development

JavaScript Development must state browser, Node.js, framework, build, package manager, and compatibility requirements.

Delivered work must:

• avoid leaking secrets into client bundles;
• handle promises and errors;
• avoid unsafe eval, HTML injection, prototype pollution, command execution, and untrusted dynamic imports;
• scope browser globals and styles;
• clean up event listeners, intervals, observers, subscriptions, and requests;
• support keyboard and accessibility requirements;
• avoid blocking the main thread with unbounded work;
• include source maps or readable source as appropriate;
• use intentional dependencies and a reproducible install.

If a frontend application depends on a backend, the scope must state who provides and secures it.

19.4 Laravel

Laravel services must state the supported Laravel, PHP, database, cache, queue, Node.js, and deployment environment.

Delivered work must use Laravel’s supported facilities for:

• validation;
• authentication;
• authorization gates and policies;
• CSRF protection;
• password hashing;
• encryption;
• signed URLs;
• rate limiting;
• queues and scheduled tasks;
• migrations;
• configuration and secrets;
• logging and error handling.

The seller must avoid mass-assignment exposure, unsafe raw queries, unescaped Blade output, application secrets in source, development servers in production, and long work in web requests.

Deployment must cover .env, application key, storage, caches, workers, scheduler, migrations, maintenance mode, production asset build, trusted proxies, and rollback constraints. Long-running workers must be restarted when required by the release.

19.5 PHP Development

PHP Development must declare the supported PHP version, required extensions, framework, package manager, and hosting assumptions.

Delivered code must:

• follow a consistent modern coding standard;
• use Composer and autoloading where appropriate;
• run without avoidable warnings, notices, deprecations, or fatal errors;
• use secure password, session, HTTP, database, file, and random APIs;
• validate input and escape output;
• avoid unsafe deserialization, dynamic include paths, command interpolation, and disabled TLS verification;
• not require globally writable files;
• keep configuration and secrets outside public source.

The seller must not deploy with the entire project, configuration, backups, logs, or dependency metadata unintentionally exposed under the public web root.

19.6 React

React services must define the React version, framework, rendering model, build tool, browser support, and backend boundary.

The implementation must:

• use stable keys and predictable state;
• handle loading, empty, error, unauthorized, and offline states;
• preserve accessible names, focus, keyboard operation, and semantic HTML;
• avoid inserting untrusted HTML;
• cancel or ignore stale asynchronous work where necessary;
• avoid exposing server secrets in environment variables included in the client build;
• use intentional component boundaries;
• avoid unnecessary global state and re-render loops;
• include production build and deployment instructions.

If server-side rendering, static generation, server components, or hydration are used, caching, authentication, private data, and environment behavior must be tested in the actual production model.

19.7 REST API

REST API services must define:

• resources and operations;
• authentication;
• authorization and ownership rules;
• versioning;
• request and response schema;
• pagination, filtering, sorting, and limits;
• error model and status codes;
• idempotency;
• rate limits;
• webhooks or asynchronous jobs;
• documentation and examples.

The implementation must:

• use HTTPS;
• validate content type, size, and schema;
• enforce object-level and function-level authorization;
• avoid mass assignment;
• not expose sensitive fields by default;
• use bounded pagination;
• use timeouts and controlled errors;
• protect tokens;
• avoid user enumeration;
• log security-relevant events without sensitive payloads;
• document breaking changes.

OpenAPI or equivalent machine-readable documentation should be delivered for a substantial API when compatible with the buyer’s stack. A route list without schemas, authorization, examples, and error behavior is not complete API documentation.

20. Performance, SEO & Analytics

Performance, SEO, and analytics services must be evidence based. Sellers must distinguish configuration, technical eligibility, lab measurements, field measurements, indexing, ranking, traffic, conversion, and business results.

20.1 Baseline and measurement plan

Before changing the site, record:

• URLs and templates in scope;
• mobile and desktop context;
• tool, test location, device, network, browser, login state, and cache state;
• hosting and CDN;
• traffic or field-data availability;
• current theme, plugins, tags, and third-party scripts;
• known marketing or development changes during the measurement period;
• current Search Console, analytics, crawl, index, or performance state relevant to the service.

The listing must state whether the service targets:

• a lab score;
• Core Web Vitals field data;
• server response;
• front-end transfer and execution;
• crawlability and indexing eligibility;
• on-page content;
• measurement correctness;
• a specific technical defect.

20.2 Core Web Vitals

Services in Core Web Vitals must work with the current Core Web Vitals metrics and clearly distinguish field and lab data.

The seller must:

• identify whether the URL or origin has sufficient field data;
• use the 75th percentile and appropriate mobile or desktop population when evaluating field thresholds;
• avoid promising immediate field-data changes after deployment;
• test representative templates rather than one unusually light page;
• identify the LCP element and resource chain;
• investigate INP using real interaction or appropriate diagnostics;
• identify layout-shift sources rather than hiding them;
• preserve functionality, accessibility, analytics, consent, and visual integrity;
• document material before/after results and remaining constraints.

At the time of this page, the commonly referenced “good” thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1, assessed at the 75th percentile. Sellers must follow current official definitions if these metrics or thresholds change.

A service may target an agreed lab configuration, but must not present one successful Lighthouse run as proof that all users pass Core Web Vitals.

20.3 Google Analytics/Search Console setup

Services in Google Analytics/Search Console setup must establish buyer-owned properties with the minimum necessary roles.

For Google Analytics, define:

• property and data stream;
• time zone and currency;
• tag or Tag Manager implementation;
• events, parameters, and key events;
• cross-domain behavior;
• internal and developer traffic;
• referral exclusions where appropriate;
• consent behavior;
• retention and advertising settings;
• eCommerce measurement if included;
• DebugView or other validation;
• ownership and administrator access.

For Search Console, define:

• Domain or URL-prefix property;
• verification method;
• user roles;
• sitemap submission;
• important indexing, security, manual-action, and enhancement checks;
• connection to Analytics where requested.

The seller must not make themselves the only verified owner. DNS verification records must be documented. Removing an existing verification method, property, stream, filter, tag, or container requires approval.

Search Console verification and sitemap submission do not guarantee indexing or ranking. Analytics data can differ from Search Console and server data because they measure different things.

20.4 On-page SEO

Services in On-page SEO must define:

• page count and URLs;
• keyword or topic research included;
• title, description, headings, copy, internal links, images, alt text, canonical, social metadata, and schema scope;
• implementation versus recommendation;
• language and location;
• content approval process.

Changes must:

• serve users, not only a keyword tool;
• keep titles and headings accurate;
• avoid keyword stuffing and hidden text;
• avoid invented expertise, authorship, reviews, or dates;
• preserve accessibility and brand meaning;
• avoid duplicate or conflicting SEO-plugin fields;
• use descriptive links;
• not use alt text as a keyword dump.

The seller must not promise ranking from metadata changes alone.

20.5 Schema setup

Services in Schema setup must:

• use types and properties that accurately describe visible page content;
• select syntax appropriate to the platform, normally JSON-LD where supported;
• avoid duplicate or contradictory graph entities;
• use stable identifiers;
• connect organization, website, webpage, author, product, offer, breadcrumb, article, and other entities correctly where applicable;
• validate syntax and required properties;
• follow the search engine’s current feature-specific policies;
• avoid marking up hidden, fake, expired, or misleading content.

The seller must not create fake ratings, reviews, prices, stock, events, jobs, FAQs, authors, locations, or business details to obtain a rich result.

Passing Schema.org validation or a rich-results test establishes neither display nor ranking. The delivery must identify which pages and templates received schema and how the buyer maintains dynamic values.

20.6 Speed optimization

Services in Speed optimization must identify the real bottleneck before applying changes.

Potential areas include:

• hosting and server response;
• PHP and database behavior;
• object and page caching;
• CDN;
• images, video, and fonts;
• CSS and JavaScript;
• third-party tags;
• theme and plugin behavior;
• API calls;
• background jobs;
• cache variation for logged-in users, carts, languages, currencies, and geographies.

The seller must not:

• disable security, consent, checkout, accessibility, analytics, backups, updates, or essential features merely to improve a score;
• delete assets without confirming use;
• delay or block required interface behavior deceptively;
• apply database cleanup without backup and scope confirmation;
• combine cache and minification settings without testing;
• enable incompatible cache for carts, accounts, personalized pages, or nonces;
• remove query strings or versioning in a way that breaks cache invalidation;
• convert every image blindly without fallback or quality review;
• promise a score independent of hosting, content, third-party scripts, geography, and test conditions.

The delivery must identify settings, changed files, purges, exclusions, and how to disable or troubleshoot the optimization.

20.7 Technical SEO

Services in Technical SEO must define the crawl, index, architecture, migration, or rendering problem in scope.

Review as applicable:

• HTTP status codes;
• redirects and chains;
• canonical URLs;
• robots directives;
• XML sitemaps;
• hreflang;
• pagination;
• duplicate and parameter URLs;
• internal links and orphan pages;
• JavaScript rendering;
• mobile behavior;
• site architecture;
• faceted navigation;
• staging exposure;
• mixed protocols and hostnames;
• server logs;
• Core Web Vitals;
• structured data;
• expired or removed content;
• migration redirects;
• multilingual and multisite behavior.

The seller must not:

• cloak content;
• create doorway pages;
• purchase or automate manipulative links;
• generate scaled low-value pages;
• hide keywords;
• abuse expired domains;
• inject content into compromised sites;
• remove valid content or indexing controls without understanding business purpose;
• submit unauthorized removal requests;
• claim that a crawl automatically represents Google’s index.

Recommendations must follow current search-engine spam policies. The buyer must approve material URL, canonical, robots, redirect, noindex, or content-removal changes.

21. Security & Maintenance

Security and maintenance services require explicit authorization, careful access handling, verified backups, evidence, and honest limits. No service may be advertised as making a site permanently unhackable.

21.1 Common security requirements

Before work begins, establish:

• authorized site, server, account, and environment;
• owner and emergency contact;
• suspected incident or objective;
• business-critical workflows;
• backup availability;
• hosting responsibility;
• maintenance window;
• permission for scanning, file changes, account changes, credential rotation, and downtime;
• data sensitivity;
• exclusions.

Security services must not use pirated tools, unknown cleanup scripts, concealed remote agents, or indiscriminate deletion.

21.2 Backup setup

A Backup setup listing must state:

• data and files covered;
• schedule;
• retention count or period;
• storage destination;
• off-site behavior;
• encryption;
• incremental or full method;
• database consistency;
• exclusion rules;
• alerting;
• restore testing;
• storage and traffic cost;
• who owns the destination account.

The service must:

• back up non-reproducible state;
• avoid storing the only backup on the same server and account when off-site protection is promised;
• protect database and credential-containing configuration;
• not expose archives under the public web root;
• test notifications and schedule;
• verify at least one completed backup;
• document restore steps and encryption-key ownership.

If a restore test is included, perform it in an isolated environment unless the buyer authorizes a production restore. The seller must state whether the test covered only archive integrity or a complete application recovery.

21.3 Malware cleanup

A Malware cleanup service must address containment, eradication, recovery, and recurrence risk—not merely delete the first suspicious file.

The seller should investigate as applicable:

• WordPress core integrity;
• plugins, themes, must-use plugins, drop-ins, and inactive code;
• uploads and unexpected executable files;
• wp-config.php, web-server rules, PHP configuration, cron, scheduled actions, and system tasks;
• administrator and other privileged users;
• application passwords, sessions, API keys, SSH keys, hosting users, database users, email forwarding, and recovery details;
• database payloads, injected options, posts, widgets, redirects, and spam users;
• modified templates and JavaScript;
• rogue processes or server-level compromise where access permits;
• logs and likely entry point;
• vulnerable or abandoned components;
• connected sites in the same account.

The seller must:

• preserve a pre-cleanup copy or appropriate evidence;
• avoid executing malware;
• replace trusted core and vendor files from known sources where practical;
• remove persistence, not only visible symptoms;
• rotate or instruct rotation of affected credentials and WordPress salts;
• update or remove the vulnerable component;
• verify legitimate administrator accounts;
• test critical site behavior after cleanup;
• disclose areas not examined;
• recommend host or incident-response escalation when compromise may extend beyond WordPress.

The delivery must summarize findings, changes, credentials to rotate, vulnerable entry point if known, remaining uncertainty, and prevention steps.

No seller may promise permanent malware removal when the root cause, server, stolen credentials, or connected systems remain outside scope.

21.4 Ongoing maintenance

An Ongoing maintenance listing must define:

• service period;
• update frequency;
• backup responsibility;
• monitoring included;
• checks performed;
• response hours and timezone;
• incident and emergency scope;
• content or development exclusions;
• report frequency;
• supported number of sites;
• fair-use or time limits;
• how the buyer may purchase a following service period;
• ending and handover.

The seller must not imply 24/7 response, unlimited development, emergency recovery, uptime guarantee, or continuous human monitoring unless those are actually staffed and included.

Maintenance should include a documented inventory, buyer-owned access, change log, test process, and escalation path. The buyer must be told when a component is abandoned, incompatible, vulnerable, or cannot safely be updated.

21.5 Site recovery

A Site recovery service must define the recovery source and intended recovery point.

The seller must:

• preserve current state before overwriting it when forensic or recent-data value exists;
• identify backup date, contents, and integrity;
• distinguish disaster recovery from malware cleanup;
• restore files, database, configuration, DNS, SSL, caches, and external services as applicable;
• reconcile data created after the backup when included;
• test login, pages, forms, search, email, scheduled tasks, checkout, orders, memberships, and other critical workflows;
• document unavoidable data loss;
• secure the recovered environment.

If no usable backup exists, the seller must not promise full recovery. Reconstruction, content salvage, database repair, and clean rebuild must be described as separate possible outcomes.

21.6 Update service

An Update service must identify:

• components covered;
• target versions;
• staging and backup process;
• compatibility checks;
• custom-code review;
• database migrations;
• license requirements;
• deployment window;
• rollback;
• post-update testing.

The seller must not click “update all” on production without reviewing material compatibility and recovery.

Test as applicable:

• frontend and administration;
• login and roles;
• page builder and editor;
• forms and email;
• scheduled tasks;
• multilingual behavior;
• cache;
• checkout, payment, shipping, tax, orders, subscriptions, and memberships;
• APIs and webhooks;
• custom code and child themes.

Unsupported or abandoned software must be reported. The seller must not conceal an incompatibility by permanently disabling updates.

21.7 WordPress hardening

A WordPress hardening service must be based on the actual hosting and threat model. It may include:

• current supported versions;
• removal of unused software;
• least-privilege users and filesystem permissions;
• multifactor authentication;
• strong account and recovery controls;
• application passwords and API access review;
• TLS;
• secure configuration and secret handling;
• database and file access controls;
• backups;
• logging and monitoring;
• restricted administrative exposure;
• security headers;
• brute-force and abuse protection;
• disabled or constrained file editing where appropriate;
• environment separation.

The seller must not:

• break WordPress updates or normal functionality without disclosure;
• use broad IP blocking as the only protection;
• hide the login URL and claim the site is secure;
• apply generic file permissions that prevent updates or make everything writable;
• store secrets in public configuration;
• disable REST API, XML-RPC, cron, or other core behavior without analyzing dependencies;
• install multiple overlapping security products without testing;
• claim that a plugin installation alone completes hardening.

The delivery must identify every changed setting, file, rule, plugin, user, token, and access path, plus how to reverse or maintain it.

22. Translation & Localization

Translation services must preserve meaning, function, placeholders, formatting, context, and locale behavior. A technically valid file can still be an unusable translation.

22.1 Common translation requirements

The listing must state:

• source and target languages;
• target locale, region, and audience;
• word or string count;
• human translation, machine translation with human review, post-editing, or setup-only model;
• translator qualification or native-language claim;
• file formats;
• glossary and style-guide use;
• revision and proofreading;
• implementation and visual QA;
• delivery files;
• treatment of legal, medical, financial, or regulated text.

The seller must not advertise raw machine translation as native human translation.

22.2 Translation quality

The translation must preserve:

• meaning and intent;
• brand voice;
• terminology;
• names and trademarks;
• numbers, units, dates, times, currencies, and addresses;
• variables and placeholders;
• HTML and markup;
• plural and gender behavior;
• links;
• accelerator keys and interface constraints;
• legal qualifiers supplied in source;
• context between related strings.

The seller must not translate code, identifiers, URLs, placeholders, or protected terms that must remain unchanged.

22.3 Linguistic review and QA

Professional delivery should include:

• spell and grammar review;
• terminology consistency;
• missing and untranslated-string check;
• number and placeholder parity;
• punctuation and whitespace review;
• link and markup check;
• interface review where implementation is included;
• truncation, wrapping, and overlap check;
• locale and fallback check;
• RTL or bidirectional review where applicable.

When the seller cannot validate a specialist legal, medical, technical, or regulated term, the limitation must be disclosed and a qualified reviewer should be recommended.

22.4 Multilingual Setup

A Multilingual Setup service must state:

• WordPress multilingual solution;
• languages and default language;
• URL structure;
• translation ownership and workflow;
• manual, automatic, or mixed translation;
• menus, widgets, templates, forms, media, taxonomies, custom fields, SEO metadata, schema, and eCommerce scope;
• language switcher;
• fallback behavior;
• synchronization rules;
• hreflang and canonical strategy;
• license and renewal cost.

The seller must:

• back up before database changes;
• avoid duplicating content unexpectedly;
• preserve the site’s default-language content;
• test admin and frontend language context;
• avoid conflicting multilingual plugins;
• prevent indexing of incomplete or test translations where appropriate;
• verify forms, emails, search, checkout, accounts, and transactional content in the included languages.

Setup does not include translation of all website content unless stated.

22.5 Plugin Translation

A Plugin Translation must define:

• plugin and version;
• text domain;
• source string count;
• PHP, JavaScript, block, and metadata string scope;
• PO, MO, JSON, or platform translation delivery;
• bundled versus external translation location;
• whether source strings require correction;
• update compatibility.

The seller must preserve placeholders, translator comments, plural forms, HTML, and context. Generated translation files must use correct locale and naming conventions.

If the plugin is not properly internationalized, translation may require development work. The seller must not silently edit every hard-coded string in vendor code when an update-safe method or source change is required.

22.6 Theme Translation

A Theme Translation must meet the plugin-translation requirements as applicable and must also cover:

• theme and child theme;
• template and site-editor strings;
• patterns and demo content;
• JavaScript and block strings;
• RTL styles if included;
• typography support for the target script;
• front-end layout review.

Editing the parent theme directly is not an update-safe translation method. If visible source text belongs to imported content rather than the theme, the seller must classify it correctly and include it only when the package covers website content.

22.7 Website Translation

A Website Translation service must define:

• included pages, posts, products, taxonomies, menus, forms, popups, templates, emails, media, SEO fields, policies, and other content types;
• source word count;
• translation workflow and approval;
• implementation;
• updates after source changes;
• image text and downloadable documents;
• locale-specific adaptation.

The seller must not copy a translated legal policy from another business. Legal and regulated text requires buyer-provided or appropriately qualified review.

For eCommerce, verify translated product variation, price, tax, shipping, cart, checkout, account, order, subscription, refund, and email workflows included in scope.

23. Website Setup & Launch

Launch services must leave the buyer with a functional, secure, owned, documented website—not merely an installed WordPress dashboard.

23.1 Common launch requirements

Confirm:

• domain and DNS ownership;
• hosting and supported environment;
• WordPress, PHP, database, and web-server versions;
• SSL;
• theme and plugin licenses;
• content and media;
• email sending;
• backups;
• staging;
• privacy and consent requirements;
• analytics;
• SEO/indexing state;
• launch date and content freeze;
• rollback plan.

The seller must not create the domain, hosting, analytics, payment, or email system under the seller’s personal ownership without a disclosed managed-service model.

23.2 Basic launch support

A Basic launch support listing must define which checks and actions are included. Appropriate items may include:

• final backup;
• environment and URL review;
• SSL and mixed-content check;
• visibility and indexing settings;
• permalink and redirect check;
• forms and email;
• responsive and browser smoke test;
• analytics and consent;
• favicon and social image;
• cache and CDN;
• security baseline;
• admin ownership;
• post-launch monitoring window.

“Launch support” must not be used as an undefined promise to fix every pre-existing issue.

23.3 Demo import

A Demo import service must identify:

• exact theme, demo, and required plugins;
• clean or existing site;
• whether existing content may be overwritten;
• included license;
• server requirements;
• import size and time limits;
• expected differences from the public demo;
• image and font rights;
• customization exclusions.

The seller must back up an existing site before import. Demo data must not:

• overwrite production content without approval;
• create known default administrator credentials;
• leave test orders, forms, subscribers, API keys, tracking IDs, or payment credentials;
• import unlicensed premium media;
• present placeholder content as finished buyer content.

After import, remove unnecessary demo items when included and confirm menus, home page, permalinks, builder assets, and required plugins.

23.4 Staging to live

A Staging to live service must define:

• source and destination;
• full-site or selected changes;
• database merge or overwrite behavior;
• content freeze;
• files and tables included;
• live data that must be preserved;
• deployment window;
• DNS involvement;
• rollback.

The seller must not overwrite live orders, users, comments, form entries, subscriptions, bookings, or other records created since staging was copied unless the buyer explicitly accepts that loss.

Selective deployment must account for data dependencies and serialized values. After deployment, test URLs, media, forms, login, cron, caches, integrations, analytics, robots, email, and critical business workflows.

23.5 Theme/plugin setup

A Theme/plugin setup service must state:

• products and versions;
• installation versus configuration;
• license responsibility;
• demo import;
• required companion products;
• settings included;
• content or design customization;
• compatibility testing;
• update behavior.

The seller must:

• obtain packages from authorized sources;
• use supported installation methods;
• avoid overwriting existing configuration without backup;
• not activate unwanted bundled plugins;
• configure only documented safe values;
• remove installation archives containing sensitive data;
• document licenses and renewals.

Setup does not imply custom development unless stated.

23.6 Website migration

A Website migration service must identify:

• source and destination hosting;
• domain or path change;
• site size and database size;
• multisite, multilingual, eCommerce, membership, or custom infrastructure;
• email and DNS scope;
• expected downtime;
• content freeze;
• backup and rollback;
• post-migration validation.

The seller must:

• copy all required files and database state;
• preserve serialized data correctly;
• update URLs safely;
• preserve file permissions and configuration;
• protect transfer archives;
• avoid leaving public migration files or installers;
• preserve redirects and canonical host;
• verify SSL;
• reconfigure cron, cache, CDN, object storage, SMTP, webhooks, payment callbacks, licenses, and environment-specific paths;
• prevent staging or old-host duplicate indexing;
• test record counts and critical workflows;
• coordinate DNS with appropriate TTL and rollback planning.

For active stores or membership sites, define how new orders, users, subscriptions, and content during migration are preserved or reconciled.

23.7 WordPress installation

A WordPress installation must provide:

• supported hosting and database configuration;
• correct canonical URL and HTTPS;
• secure unique administrator account;
• appropriate site title, timezone, locale, and permalink setup;
• file and directory permissions appropriate to the host;
• removal of unused defaults when included;
• update configuration;
• backup baseline;
• search visibility state appropriate to launch;
• buyer ownership and recovery.

The seller must not:

• use a universal administrator password;
• use admin plus a weak password merely for convenience;
• leave a public installation script;
• install pirated themes or plugins;
• expose database credentials;
• make the seller’s email the permanent recovery owner;
• promise a complete website when the package includes only installation.

24. WooCommerce & eCommerce

eCommerce services affect money, orders, inventory, taxes, customer data, fulfillment, and legal obligations. They require strict staging, backup, testing, and server-side verification.

24.1 Common eCommerce requirements

The seller must identify:

• WooCommerce and WordPress versions;
• theme and extension compatibility;
• store country, currency, tax, language, and units;
• product types;
• checkout type;
• payment and shipping providers;
• account and privacy requirements;
• HPOS and block-checkout compatibility where relevant;
• subscriptions, memberships, bookings, multivendor, or marketplace features;
• sandbox availability;
• order and refund lifecycle;
• transactional email;
• legal configuration supplied by the buyer.

The seller may configure tax, invoice, privacy, return, age, shipping, or regulated-product settings according to buyer instructions, but must not provide unsupported legal or accounting guarantees.

24.2 Transaction safety

No service may trust a browser-provided price, discount, tax, shipping cost, product identity, entitlement, payment status, or user ownership without server-side validation.

The seller must test as applicable:

• simple, variable, virtual, downloadable, grouped, bundled, and subscription products in scope;
• guest and account checkout;
• coupons;
• tax and currency;
• shipping zones and methods;
• stock reduction and restoration;
• failed, pending, on-hold, processing, completed, cancelled, refunded, and disputed orders;
• duplicate callbacks;
• email;
• account and order ownership;
• cache exclusions;
• mobile checkout.

24.3 Checkout customization

A Checkout customization service must define:

• classic shortcode, Checkout block, or both;
• fields and validation;
• conditional logic;
• layout and design;
• payment and shipping interactions;
• account creation;
• order metadata and emails;
• analytics;
• compatibility scope.

The seller must use supported hooks, block extensibility, Store API mechanisms, and templates. Direct edits to WooCommerce core or copied outdated checkout templates without justification are blockers.

Required fields must have a genuine business need, accessible labels, server-side validation, privacy consideration, and correct storage. Hiding a field visually does not remove its server-side behavior.

24.4 Dokan/multivendor setup

A Dokan/multivendor setup service must define:

• Dokan edition and modules;
• vendor registration and approval;
• product publishing;
• commissions;
• withdrawals and payout providers;
• fees, tax, and shipping ownership;
• order splitting;
• refunds and disputes;
• store pages;
• vendor roles and capabilities;
• subscriptions;
• required pages and emails;
• buyer, vendor, administrator, and staff tests.

The seller must:

• use supported Dokan and WooCommerce settings;
• avoid granting vendors unrelated administrator capabilities;
• verify vendor data isolation;
• test product and order ownership;
• validate commission and withdrawal calculations with example orders;
• distinguish marketplace payment collection from vendor payouts;
• disclose provider and module costs;
• document operational steps the marketplace owner must perform.

The seller must not promise that technical configuration satisfies marketplace, employment, tax, KYC, payment, or consumer-law obligations.

24.5 Payment/shipping setup

A Payment/shipping setup service must identify providers, countries, currencies, methods, account verification, fees, and test mode.

Payment setup must:

• use the correct merchant account;
• use official extensions;
• keep live and test credentials separate;
• configure webhooks and callback URLs;
• verify signature and order state through supported code;
• test success, failure, cancellation, pending, duplicate, and refund flows;
• avoid logging sensitive payment information;
• document live activation.

Shipping setup must:

• define zones and location matching;
• method priority;
• classes;
• taxable status;
• free-shipping conditions;
• dimensions and weight;
• carrier API requirements;
• fallback behavior;
• packaging assumptions;
• address and international limitations.

The seller must use sample carts covering boundary conditions and must not activate live rates or charges without review.

24.6 Product page improvements

A Product page improvements service must define design, content, gallery, variation, structured data, review, performance, and implementation scope.

Changes must:

• preserve authoritative price, availability, variation, and purchase state;
• remain accessible and responsive;
• not add fake scarcity, reviews, ratings, badges, or stock;
• not hide required purchase terms;
• support selected variations and validation;
• avoid duplicate product schema;
• preserve theme and plugin compatibility;
• be tested with representative product types.

Conversion claims must be presented as hypotheses unless measured fairly.

24.7 Subscriptions/memberships

A Subscriptions/memberships service must define:

• products or plans;
• billing schedule;
• trial and sign-up fees;
• renewal, failed payment, retry, cancellation, pause, upgrade, downgrade, proration, refund, and expiration behavior;
• access rules;
• user roles;
• payment gateway compatibility;
• emails;
• migration of existing members;
• account pages;
• reporting.

The seller must test the lifecycle using provider and extension test tools where available. Access must follow authoritative server-side subscription state, not a mutable user field or browser callback.

Importing existing subscriptions may require provider tokens and strict mapping. The seller must not promise migration when the payment provider does not permit transfer of billing agreements.

24.8 WooCommerce setup

A WooCommerce setup listing must state which of the following are included:

• store settings;
• currency and units;
• tax settings supplied by the buyer;
• shipping;
• payments;
• accounts and privacy;
• emails;
• products and variations;
• inventory;
• coupons;
• pages and navigation;
• analytics;
• performance;
• backup;
• test order;
• launch.

The seller must use the buyer’s business details and instructions, not copied defaults from another store. A complete setup should finish with a documented test order and buyer administrator ownership.

25. WordPress Development

WordPress development services must follow the current WordPress APIs, coding standards, security practices, and WPBay technical requirements for the resulting deliverable.

25.1 Common WordPress development requirements

Delivered code must:

• support the agreed WordPress, PHP, and related product versions;
• use unique prefixes or namespaces;
• use hooks and supported APIs;
• avoid WordPress core edits;
• avoid direct parent-theme edits for site-specific customization;
• validate, sanitize, and authorize input;
• escape output at the latest practical point;
• protect state-changing requests with appropriate nonces while also checking capabilities;
• use parameterized queries;
• use WordPress HTTP, filesystem, options, metadata, cron, REST, enqueue, internationalization, and privacy APIs as appropriate;
• avoid global collisions;
• not expose secrets;
• avoid remote code execution and unsafe deserialization;
• work with debug mode without avoidable warnings, notices, deprecations, or fatal errors;
• be update safe;
• include documentation and source.

Code must not be placed in a theme’s functions.php merely because it was the fastest location when a small site-specific plugin or child theme is the durable architecture.

25.2 Compatibility and coexistence

The seller must test with:

• the buyer’s active theme and relevant plugins;
• ordinary user roles;
• caching and security configuration;
• multisite, multilingual, WooCommerce, or page builder behavior when in scope;
• current browser and responsive requirements for interface changes;
• the actual block or classic editing environment in scope.

The seller must not solve a conflict by silently disabling another required product.

25.3 API integrations

WordPress API integrations must meet Section 15 and Section 19.7.

They must:

• use the WordPress HTTP API for server requests where appropriate;
• use timeouts and controlled retries;
• verify TLS;
• keep credentials outside public output;
• encrypt or otherwise appropriately protect stored secrets;
• use cron or queues for long synchronization;
• register REST routes with explicit permission callbacks;
• validate remote responses;
• avoid blocking frontend requests with slow remote dependencies;
• provide logs or status without leaking payload secrets;
• cleanly disconnect and revoke webhooks or tokens.

If the integration creates public WordPress endpoints, rate limiting and abuse control must match the action’s risk.

25.4 Bug fixing

A Bug fixing service must define:

• one issue or stated issue count;
• supported environment;
• reproduction requirement;
• diagnosis versus fix;
• third-party code boundary;
• test and correction period.

The seller must:

• reproduce or otherwise establish the problem;
• identify root cause rather than hide the symptom where practical;
• preserve unrelated behavior;
• use an update-safe fix;
• document changed files and logic;
• test the original reproduction and relevant regression paths;
• explain when the real cause lies with hosting, a third-party service, unsupported software, or buyer data.

Disabling the affected feature is not a fix unless the buyer requested removal.

25.5 Code cleanup

A Code cleanup service must define the objective: formatting, standards, dead code, architecture, performance, security, deprecations, documentation, or dependency reduction.

Before refactoring:

• establish behavior and tests;
• identify public hooks, APIs, templates, shortcodes, blocks, commands, and stored data;
• preserve compatibility promised by the buyer;
• create a rollback point.

The seller must not:

• remove code merely because it appears unused without checking dynamic hooks, callbacks, templates, or integrations;
• reformat a whole repository and hide functional changes in the same diff;
• replace clear code with generated abstraction that cannot be maintained;
• change database formats or public identifiers without migration;
• claim cleanup from an automated formatter alone.

25.6 Custom WordPress features

A Custom WordPress features service must define user stories, roles, data model, interface, notifications, imports, APIs, reporting, and edge cases.

The seller must choose an appropriate architecture:

• plugin for site functionality;
• child or custom theme for presentation;
• block or pattern for editor content;
• custom post type, taxonomy, metadata, options, or custom tables based on data behavior;
• background processing for long work.

The feature must include explicit acceptance criteria, security, accessibility, internationalization, performance, tests, documentation, and an uninstall or removal plan appropriate to its data.

25.7 Plugin customization

A Plugin customization service must identify:

• plugin name, edition, version, and license;
• requested behavior;
• available hooks, templates, APIs, or extension mechanisms;
• update strategy;
• compatibility;
• ownership of custom code.

The seller must prefer:

• official hooks and filters;
• extension plugins;
• documented template overrides;
• supported APIs;
• an upstream contribution where appropriate.

Direct modification of the vendor plugin is acceptable only when clearly agreed as a temporary or unavoidable patch, delivered separately, documented, and accompanied by an update/reapplication strategy.

The seller must not remove license checks, attribution, telemetry controls, notices, or restrictions unlawfully.

25.8 Theme customization

A Theme customization service must identify:

• parent and child theme;
• classic, block, hybrid, or builder architecture;
• templates, pages, components, and breakpoints;
• design and content scope;
• browser and accessibility expectations;
• update strategy.

Use a child theme, supported block-theme customization, site-specific plugin, custom CSS location, or another update-safe method appropriate to the change.

The seller must not:

• edit WordPress core;
• make undocumented parent-theme edits;
• place business logic in presentation files without need;
• copy premium demo assets without rights;
• replace semantic content with inaccessible image text;
• use unscoped CSS that breaks plugins or administration;
• hide broken layouts at one viewport with fixed heights.

Deliver changed source, documentation, and any export needed to reproduce builder or Site Editor configuration.

26. Ongoing services, monitoring, and service continuity

These requirements apply when a one-time service package covers work performed across a defined period, includes monitoring, or depends on the seller remaining available after initial setup.

26.1 Define the service period

WPBay services currently use one-time packages. An ongoing service package must purchase a fixed, stated period of service rather than create an undisclosed recurring charge. If the buyer wants another period, the seller may offer a new WPBay order on the terms available at that time.

The listing and order scope must state:

• that the package is a one-time purchase;
• when the service begins;
• the included service period and end date or duration;
• the work included during that period;
• any hour, task, site, incident, request, or usage allowance;
• what happens to unused allowances;
• how a following period may be purchased;
• what happens if the current order is cancelled or ends early under WPBay’s policies;
• the handover provided when the service ends.

“30-day maintenance,” “monthly maintenance,” “continuous monitoring,” “managed service,” and similar descriptions are incomplete unless the fixed purchased period, actual activities, and limits are listed. “Monthly” describes the covered period or work frequency; it must not imply automatic renewal when the package is a one-time purchase.

26.2 Maintain a service inventory

For each supported site or system, the seller should maintain an order-level record of the items relevant to the service, such as:

• production, staging, and development environments;
• domain, DNS, hosting, CDN, email, repository, deployment, analytics, and monitoring providers;
• WordPress, WooCommerce, theme, plugin, framework, runtime, and database versions;
• licensed products and the account that owns each license;
• integrations and scheduled jobs;
• backup locations and retention;
• security controls;
• custom code maintained under the order;
• excluded, unsupported, or end-of-life components.

The inventory must not expose passwords, API keys, recovery codes, or other secrets in ordinary delivery notes.

26.3 Scheduled work

The seller must define:

• the expected maintenance frequency;
• the normal maintenance window;
• whether approval is required before production changes;
• the backup and rollback process;
• how security releases are prioritized;
• whether major-version upgrades are included;
• whether compatibility testing occurs on staging;
• the report or evidence supplied after each cycle.

An automated update toggle by itself is not an adequate managed update service.

26.4 Monitoring scope

A monitoring service must identify exactly what is checked. Depending on the package, this may include:

• site or endpoint availability;
• HTTP status and response time;
• certificate expiry;
• domain expiry;
• scheduled task health;
• backup success;
• disk, database, CPU, or memory limits;
• application errors;
• malware or file-integrity signals;
• broken forms or checkout;
• transaction or integration failures;
• Core Web Vitals or other agreed performance signals.

The listing must state the check frequency, alert threshold, notification recipient, retention period, and any blind spots. “24/7 monitoring” may describe an automated monitor that runs continuously; it must not imply that a person provides 24/7 incident response unless that human coverage is expressly included.

26.5 Alerts and incident response

The service must distinguish:

• detection time;
• acknowledgement target;
• investigation target;
• restoration target;
• final-resolution target.

These are different commitments. A seller must not advertise an uptime guarantee, service-level agreement, or response time that the package cannot support.

For an alert or incident, the seller must:

1. confirm whether the signal is genuine;
2. assess impact and urgency;
3. preserve useful evidence;
4. notify the buyer through the agreed channel;
5. avoid speculative or destructive changes;
6. contain or restore the issue within authorization;
7. document actions, results, and remaining risk;
8. recommend follow-up work outside the package, if needed.

26.6 Availability and support boundaries

The listing must state:

• support days, hours, and time zone;
• expected response time;
• supported communication channel;
• whether emergency work is available;
• what qualifies as an emergency;
• whether holidays or planned absences affect coverage;
• whether work outside the included allowance requires a new order or agreed scope change.

“Priority support” and “emergency support” must be measurable. They must not merely mean that the seller may answer sooner.

26.7 Periodic reports

Where reports are promised, each report should identify:

• reporting period;
• checks and work performed;
• versions or configuration changed;
• backup and restore status;
• incidents and alerts;
• unresolved risks;
• recommended next actions;
• work deferred because approval, access, licensing, or additional scope was required.

Reports must reflect completed work. A generic automated report must not be presented as evidence of a manual audit that did not occur.

26.8 Continuity and seller dependency

An ongoing service must not be designed to make normal operation depend unnecessarily on the seller’s private account, server, repository, or undisclosed proprietary process.

If such dependency is genuinely part of the purchased service, disclose:

• the dependency;
• its recurring cost;
• data processed by it;
• availability expectations;
• export options;
• what happens if WPBay, the buyer, or the seller ends the service.

The buyer must be able to regain administrative control and obtain the deliverables and records promised by the package.

26.9 Ending an ongoing service

At the end of the service, the seller must, as applicable:

• complete the final agreed maintenance cycle;
• provide a current system and change summary;
• deliver buyer-owned source, configuration, reports, and exports;
• transfer or remove seller-controlled accounts;
• revoke seller access;
• identify upcoming renewals, expirations, and known risks;
• explain which monitoring, backups, licenses, jobs, or integrations will stop;
• securely delete retained buyer secrets and data when no longer required.

Ending a service does not authorize the seller to disable the buyer’s website, revoke buyer-owned licenses, remove paid work, withhold credentials, or leave an avoidable backdoor.

26.10 Material third-party changes

If a provider changes an API, price, quota, policy, authentication method, platform feature, or support status during an ongoing service, the seller must:

• assess whether the change affects the promised scope;
• notify the buyer promptly when action is needed;
• distinguish included maintenance from new development;
• provide a reasonable migration or remediation proposal;
• avoid concealing a broken service while continuing to report it as operational.

The seller is not automatically responsible for every third-party change, but remains responsible for accurate communication and for the work expressly included in the active package.

27. Corrections, delivery evidence, and disputes

27.1 Preserve a verifiable order record

The seller should keep the material order record on WPBay whenever the platform permits. This includes:

• the purchased package and options;
• buyer requirements;
• agreed clarifications;
• approved scope changes;
• delivery messages and files;
• evidence of tests and results;
• buyer-reported defects;
• correction deliveries;
• acceptance or unresolved objections.

External calls, repositories, design tools, help desks, or file-transfer systems may be used when necessary, but they should not erase the written record of what was agreed and delivered.

27.2 Evidence must match the claim

Useful delivery evidence may include:

• a URL and timestamp;
• before-and-after screenshots;
• screen recordings;
• test output;
• performance reports;
• accessibility findings;
• request and response examples with secrets removed;
• repository commits or diffs;
• changed-file manifests;
• deployment logs;
• backup and restore verification;
• analytics validation;
• buyer-access confirmation.

Evidence must come from the relevant environment and configuration. A seller must not use a different site, edited screenshot, unrelated benchmark, synthetic result, or temporary test state to claim completion.

27.3 Responding to a reported defect

When the buyer reports that the delivery does not meet the agreed scope, the seller must:

1. acknowledge the report within the stated support or correction period;
2. request the minimum information needed to reproduce it;
3. compare the report with the written requirements and acceptance criteria;
4. reproduce or investigate it in a safe environment;
5. explain whether it is a delivery defect, environmental issue, third-party change, buyer change, or new request;
6. correct an in-scope defect without treating the correction as a paid revision;
7. test the correction and provide a new delivery note;
8. disclose any part that remains unresolved.

The seller may reasonably require reproducible steps, access, logs, or current backups. The seller must not use those requirements merely to avoid addressing a clear defect.

27.4 Defect, revision, and new scope

Use these distinctions:

Labeling an obvious defect as a “revision” does not make it one. Likewise, a buyer cannot expand the service indefinitely by describing new work as a correction.

27.5 Safe correction process

Corrections must follow the same safety rules as the original work:

• preserve a backup or rollback point;
• avoid unapproved production experiments;
• protect evidence needed for security or incident analysis;
• avoid hiding the issue by deleting logs;
• retest affected and adjacent workflows;
• update the delivery record and documentation.

If immediate rollback is the safest response, the seller should restore the last known-good state first and then investigate.

27.6 Buyer cooperation

The buyer may need to provide:

• accurate requirements and content;
• lawful authorization;
• timely access;
• account verification or approval;
• licenses and paid third-party plans;
• test users or data;
• feedback within the stated review period.

When buyer action blocks delivery, the seller must identify the missing item and its consequence. The seller must not fabricate completion, access data without authorization, or substitute an unapproved paid service.

27.7 Security emergencies

If the seller discovers active compromise, exposed credentials, unlawful content, payment-data exposure, or another urgent risk, the seller should:

• stop any action that could worsen or destroy evidence;
• preserve relevant logs and timestamps;
• notify the buyer promptly without publishing sensitive details;
• recommend credential rotation or containment;
• stay within the authorization granted;
• record emergency changes;
• avoid claiming complete remediation until persistence, root cause, and affected scope have been assessed.

Public proof-of-concept disclosure or use of a buyer’s vulnerability for promotion requires explicit authorization and must not expose the buyer or users.

27.8 Dispute conduct

During a disagreement, both sides may be asked for requirements, communications, files, test evidence, and delivery history.

The seller must not:

• delete or alter evidence;
• threaten to damage or disable the buyer’s systems;
• retain control to force acceptance;
• expose confidential information;
• retaliate through code, accounts, reviews, public posts, or service interruption;
• pressure the buyer to mark an order complete before delivery;
• move payment off WPBay to avoid platform review.

Refund eligibility and marketplace remedies are governed by the current WPBay Refund Policy, seller agreement, platform terms, and the facts of the order. This technical requirements page does not promise a particular dispute outcome.

28. Common approval and delivery blockers

The following issues commonly result in a request for changes, delayed approval, removal of claims, or a requirement to narrow the package. The list is illustrative, not exhaustive.

28.1 Listing, package, and pricing blockers

• The title describes a broad profession rather than a purchasable result.
• The package does not identify a concrete deliverable.
• The package promises “complete,” “unlimited,” “any,” or “full” work without boundaries.
• The unit is missing: site, page, screen, template, workflow, endpoint, language, product, hour, session, report, or issue.
• The same package combines unrelated services without a coherent outcome.
• The category does not match the primary deliverable.
• Prerequisites or buyer requirements are missing.
• Delivery time begins before required access or content can reasonably be provided.
• Revisions are listed without defining what may be revised.
• Major third-party fees, plans, licenses, or usage charges are undisclosed.
• An essential paid component appears only after purchase.
• The package depends on a provider, plugin, theme, framework, or account that is not named.
• Optional extras are actually required for the advertised result.
• The listing uses a low starting price for an unusable package and shifts the real price to later negotiation.
• Different buyers could reasonably interpret the same package as radically different amounts of work.
• The seller requires off-platform payment, an undisclosed subscription, or a separate purchase from the seller.

28.2 Qualification and portfolio blockers

• The seller claims a certification, partnership, credential, employment history, or platform status that cannot be substantiated.
• Portfolio work is copied, purchased, generated as a mock project, or primarily created by someone else without disclosure.
• The portfolio does not identify the seller’s contribution to a team project.
• Private client material is shown without permission.
• The listing claims expertise in a regulated or high-risk area without appropriate limits.
• Automated tool output is presented as proof of expert manual review.
• Claimed outcomes cannot be connected to the seller’s work, date range, baseline, or project context.
• Case-study metrics omit material qualifications or use another party’s results.

28.3 Requirements and scope blockers

• The service starts without collecting the information necessary to deliver it.
• There are no acceptance criteria for a custom or technical outcome.
• The seller relies on an undocumented assumption that materially changes time or cost.
• Content, data volume, page count, language count, product count, environment count, or integration count is undefined.
• The browser, device, WordPress, PHP, framework, plugin, theme, or API compatibility range is missing where relevant.
• The seller cannot explain what is excluded.
• The package does not distinguish diagnosis from remediation.
• An audit package implies that fixes are included, although it only delivers a report.
• A setup package implies ongoing maintenance.
• A design package does not state whether implementation, copy, assets, or editable source are included.
• A development package does not identify source-code delivery or update strategy.
• A migration or launch package omits DNS, email, rollback, downtime, or final verification boundaries.

28.4 Access, privacy, and security blockers

• The seller requests the buyer’s personal password when a delegated role or invite is available.
• Credentials are requested in a public listing, ordinary requirements field, screenshot, or unprotected document.
• The seller asks for more privilege than the work requires.
• No one has confirmed that the buyer is authorized to grant access.
• The package involves personal, health, financial, payment, employment, student, or other sensitive data but says nothing about handling it.
• Production data is copied to staging without minimization or protection.
• The seller cannot explain where buyer data, backups, or secrets will be stored.
• A subcontractor or external service receives access without disclosure.
• Secrets are committed to source control or included in delivery evidence.
• A payment service proposes collecting raw card data without a compliant architecture.
• An analytics, advertising, email, or automation service ignores consent, unsubscribe, suppression, or privacy requirements.
• A security service seeks unlimited or open-ended permission to attack systems.

28.5 Execution and testing blockers

• Work is performed directly on production despite a practical staging option.
• No current backup or rollback point exists before a risky change.
• The seller cannot reproduce the reported issue.
• Testing covers only the administrator account.
• Testing omits the affected device, browser, role, locale, payment method, shipping zone, or integration.
• The service changes more code or configuration than necessary without explanation.
• WordPress core, vendor packages, or parent-theme files are edited without an unavoidable reason and update plan.
• Caches are used to conceal rather than solve an error.
• Debug warnings, broken links, console errors, failed jobs, or PHP errors remain in the delivered flow.
• Performance work has no reproducible baseline or comparison method.
• Security scanning substitutes for validation and human investigation.
• Accessibility work tests only an automated score.
• SEO or schema work is declared successful without inspecting indexability, rendered output, or eligibility.
• An integration lacks retry, duplicate, authentication, and failure-path testing.
• A design is approved only at one artboard width.
• A migration is declared complete before forms, email, scheduled jobs, redirects, media, and authentication are tested.

28.6 Delivery and handover blockers

• The final delivery is only “done” with no usable result or evidence.
• Editable or source files promised in the listing are missing.
• Custom code exists only on the production server.
• The seller does not identify changed files, settings, accounts, or dependencies.
• Build instructions, environment variables, deployment steps, or configuration exports are missing.
• Credentials remain under a seller-owned account without a transfer plan.
• Temporary users, keys, debug tools, maintenance pages, or staging-indexing settings are left behind.
• The buyer cannot operate the delivered result at the level promised.
• There is no correction path for an in-scope defect.
• Known limitations are concealed.
• Documentation describes a different version or generic product.
• Screenshots expose secrets or customer data.
• Delivery relies on an expiring link without a durable copy of the promised files.

28.7 Category-specific blockers

• An automation has no documented trigger, mapping, failure path, or ownership.
• Analytics events are duplicated or cannot be validated.
• CRM or email synchronization ignores consent, suppression, deletion, or duplicate records.
• A webhook accepts unsigned or unauthenticated requests where verification is available.
• Consulting provides generic copied advice rather than a buyer-specific deliverable.
• A code review supplies tool output with no prioritization, affected location, or remediation guidance.
• A security audit is advertised as a penetration test without defined authorization and rules of engagement.
• A logo or brand kit omits rights, source format, font licensing, or practical variants.
• Figma implementation does not match the approved design at agreed breakpoints and states.
• Copy promises guaranteed conversions, approval, inbox placement, or search ranking.
• A translation is raw machine output when human-quality translation was promised.
• Core Web Vitals work guarantees a PageSpeed score or field result outside the seller’s control.
• Malware cleanup removes visible files but does not assess persistence, accounts, credentials, or root cause.
• A backup service never performs or documents a restore test.
• A migration omits URL replacement, serialization safety, DNS, email, SSL, or rollback.
• Checkout work is tested only with a live charge or only with one happy path.
• Subscription or multivendor work omits renewal, failure, refund, cancellation, permissions, or payout states.
• A WordPress customization overwrites vendor code without an update-safe strategy.

28.8 Issues that may require a narrower listing

A service may be legitimate but too broad for a fixed marketplace package. WPBay may require the seller to narrow it when:

• the result cannot be estimated without substantial discovery;
• the buyer’s environment determines most of the effort;
• the package combines discovery, strategy, design, development, migration, and support with no limits;
• legal, regulatory, security, or infrastructure risk cannot be bounded;
• the service appears to be staff augmentation rather than an identifiable deliverable;
• the seller cannot state a meaningful maximum scope;
• the promised delivery time is not credible for the largest allowed input.

The seller may separate discovery or audit work from implementation and use a new order for the resulting defined scope.

29. Outright rejection and prohibited behavior

Some issues are not normal quality problems. They may result in rejection, removal, account action, or referral under WPBay’s current policies and applicable law.

29.1 Unauthorized access, intrusion, or surveillance

Services must not:

• access, scan, test, exploit, scrape, intercept, or modify systems without lawful authorization;
• obtain passwords, tokens, cookies, personal data, or communications through deception or technical bypass;
• provide credential theft, phishing, spyware, stalkerware, keylogging, session hijacking, or covert monitoring;
• bypass account controls, paywalls, access controls, rate limits, or platform bans without authorization;
• conduct denial-of-service, destructive testing, or indiscriminate scanning;
• conceal persistent access from the buyer or system owner.

Security testing must have a named target, authorized owner, dates, methods, limits, contact, data-handling rules, and stop conditions.

29.2 Malware, backdoors, and destructive mechanisms

WPBay does not allow services that deliver or install:

• malware, ransomware, cryptominers, botnet agents, web shells, credential stealers, or destructive payloads;
• hidden administrative accounts;
• undisclosed remote-control mechanisms;
• unauthorized scheduled tasks or callbacks;
• time bombs, kill switches, or code that disables the buyer’s system after a date, cancellation, review, or dispute;
• obfuscated code intended to hide malicious or prohibited behavior.

Legitimate licensing or managed-service checks must be disclosed, proportionate, privacy-conscious, and must not create unsafe remote execution or hostage behavior.

29.3 Spam, manipulation, and deceptive growth

Services must not offer:

• unsolicited bulk messaging or harvested contact lists;
• fake reviews, testimonials, followers, likes, comments, installs, clicks, traffic, leads, or engagement;
• search-engine spam, cloaking, doorway pages, hidden text, link schemes, hacked-site links, or automated abuse;
• ad, affiliate, attribution, analytics, or conversion manipulation;
• CAPTCHA bypass or account farming used to violate another service’s rules;
• deceptive consent, unsubscribe interference, or suppression-list evasion.

Automation and scraping must respect authorization, privacy, applicable law, provider terms, robots and rate controls where applicable, and the rights of data subjects and content owners.

29.4 Fraud and payment abuse

Services must not facilitate:

• payment-card theft or testing;
• fraudulent transactions, refunds, disputes, chargebacks, invoices, taxes, identity checks, or know-your-customer checks;
• laundering, evasion, deceptive fundraising, or impersonation;
• manipulation of marketplace sales, reviews, commissions, or referral tracking;
• collection of payment or platform fees outside WPBay when prohibited by WPBay terms.

29.5 Piracy and circumvention

Services must not:

• install, distribute, modify, or support pirated or “nulled” software;
• bypass license activation, subscriptions, feature restrictions, digital rights management, or vendor access controls unlawfully;
• remove copyright, attribution, trademark, or license notices without permission;
• reproduce a protected product, website, brand, design, course, database, or content library without rights;
• sell access to third-party accounts, licenses, assets, fonts, APIs, or services contrary to their terms.

Interoperability work and authorized migration may be legitimate, but the seller must be able to explain the lawful purpose and boundaries.

29.6 Privacy and data abuse

Services must not:

• collect, sell, disclose, combine, enrich, or reuse buyer or end-user data outside the agreed purpose;
• use buyer data to train models or build datasets without explicit authorization and a lawful basis;
• expose private information in portfolios, prompts, test systems, logs, screenshots, repositories, or support requests;
• install undisclosed tracking;
• create dark patterns that defeat privacy choices;
• retain credentials or personal data after they are no longer needed;
• make false claims of legal compliance.

29.7 Plagiarism, impersonation, and false representation

Services must not:

• plagiarize code, copy, designs, translations, reports, portfolios, or deliverables;
• impersonate a developer, designer, company, customer, certifying body, or platform;
• forge certificates, audit findings, invoices, test results, screenshots, analytics, signatures, approvals, or testimonials;
• claim manual or expert work that was not performed;
• resell another provider’s output as original work when rights or disclosure are required;
• use trademarks, logos, or identities to imply an affiliation that does not exist.

29.8 Dangerous or regulated work outside a lawful scope

WPBay may reject services that create unacceptable legal, safety, financial, or marketplace risk, including work involving regulated professional advice, high-impact decisions, sensitive surveillance, weapons, unlawful content, or critical infrastructure when the seller cannot demonstrate a lawful and appropriately controlled scope.

Sellers must not present ordinary technical assistance as legal, medical, financial, tax, or compliance certification.

29.9 Harassment, coercion, and retaliation

Sellers must not:

• threaten, intimidate, harass, discriminate against, or blackmail a buyer;
• threaten to publish vulnerabilities, credentials, data, communications, or private disputes;
• disable or damage work because of a review, refund request, dispute, or cancellation;
• withhold buyer-owned access or deliverables to force an unrelated payment;
• pressure buyers to communicate or pay outside WPBay to avoid accountability.

29.10 Concealed subcontracting and account sharing

A seller remains responsible for anyone used to fulfil the order. The seller must not:

• conceal a subcontractor when that person will access buyer systems or confidential data and disclosure is material;
• transfer credentials through unsafe channels;
• allow unapproved parties to access regulated, sensitive, or production data;
• falsely claim that the listed seller personally performs work when the package is fulfilled by an undisclosed third party;
• subcontract work to a party who lacks the promised qualification or lawful rights.

Using a team is not inherently prohibited. Access, responsibility, data handling, authorship claims, and delivery quality must remain clear.

30. Seller pre-submission checklist

Use every item that applies to the service. Checking a box does not guarantee approval, and an unchecked non-applicable item is not a failure. The seller should be able to demonstrate each claim during review or fulfilment.

30.1 Service identity and category

• The listing offers a service, not a downloadable product disguised as a service.
• The title names a clear result.
• The primary category matches the main deliverable.
• The most specific available subcategory is selected.
• Secondary capabilities do not obscure the primary service.
• The service is lawful and allowed by WPBay policies.
• I am authorized and qualified to provide it.
• I can deliver the largest scope allowed by the package.
• I have identified whether the service is one-time or ongoing.
• Any dependency on my continuing availability is disclosed.

30.2 Listing accuracy

• The first paragraph explains what the buyer receives.
• Every advertised feature is included or clearly marked optional.
• Deliverables are named and countable.
• The unit of work is stated.
• The maximum package scope is stated.
• Exclusions are prominent enough to prevent surprise.
• Required buyer inputs are listed.
• Required technical prerequisites are listed.
• Supported versions, platforms, browsers, devices, or providers are listed where relevant.
• Paid third-party products and likely costs are disclosed.
• Delivery time is realistic for the maximum stated scope.
• The point at which delivery time begins is clear.
• Included revisions are stated.
• The distinction between a correction and revision is clear.
• Post-delivery support, if any, has a defined period and boundary.
• No unsupported “unlimited,” “instant,” “complete,” or “guaranteed” claim remains.
• Examples, screenshots, and portfolio items represent the service accurately.
• The listing does not imply an affiliation, certification, or approval I do not have.

30.3 Packages, options, and pricing

• Each package produces a usable result.
• Package differences are based on objective scope or deliverables.
• The entry package is not merely a consultation unless advertised as one.
• Essential work is not hidden in an extra.
• Quantity-based pricing states the counted unit.
• Complexity tiers have understandable criteria.
• Rush delivery is offered only when it is operationally realistic.
• Recurring fees and renewals are disclosed.
• Buyer-owned and seller-provided licenses are distinguished.
• Usage-based API, hosting, email, AI, payment, storage, or automation costs are disclosed.
• Taxes, legal filings, ad spend, premium assets, and provider fees are not implied to be included unless they are.
• Any discovery required before a fixed quote is a separately defined deliverable.
• The buyer will not be pressured to pay outside WPBay.

30.4 Seller identity, qualifications, and portfolio

• My profile identity and business claims are accurate.
• Claimed credentials are current and verifiable.
• My portfolio work is mine or used with permission.
• My contribution to team projects is stated.
• Client names, sites, metrics, and private details are shown with permission.
• Case-study results identify relevant baseline, period, and scope.
• Demonstration projects are labelled as demonstrations.
• AI-generated samples are not misrepresented as client work.
• I have the technical skill to maintain what I deliver.
• I have the tools and capacity to meet the advertised delivery time.
• Any team member or subcontractor has the necessary qualification and authorization.
• Regulated or specialist claims are appropriately limited.

30.5 Buyer requirements and discovery

• The requirements form asks only for information needed to begin.
• It asks for the site, system, platform, or environment in scope.
• It asks for the desired result and current problem.
• It asks for the relevant quantity: pages, products, workflows, languages, screens, issues, or sessions.
• It asks for versions and important dependencies where relevant.
• It asks for acceptance examples or references when useful.
• It asks about deadline, launch date, maintenance window, or blackout dates when relevant.
• It asks who can approve work.
• It asks whether staging and current backups exist.
• It asks whether the buyer is authorized to grant access and provide content.
• It asks about privacy, confidentiality, and sensitive data where relevant.
• It asks about accessibility, localization, browser, device, and user-role requirements where relevant.
• It does not ask for passwords, payment-card data, recovery codes, or API secrets in an ordinary text field.
• It explains how sensitive access will be provided later, if needed.
• It identifies any information whose absence pauses the delivery clock.

30.6 Scope and acceptance criteria

• The order can be restated as a finite list of deliverables.
• Each custom result has observable acceptance criteria.
• The initial state or baseline is recorded.
• The target environment is identified.
• Content and data responsibilities are allocated.
• The number of review rounds or decision points is defined.
• “Done” does not depend solely on my opinion.
• Third-party approval, ranking, uptime, revenue, or performance outside my control is not an acceptance criterion I guarantee.
• Diagnosis and remediation are separated when both are not included.
• Configuration and custom development are distinguished.
• Design and implementation are distinguished.
• Launch and ongoing maintenance are distinguished.
• New scope requires a written agreement before work.
• A blocked dependency has a documented effect on time and delivery.

30.7 Authorization, access, privacy, and confidentiality

• The buyer or system owner has authorized the work.
• Security testing has separate, explicit written authorization.
• Each requested role has the minimum practical privilege.
• A delegated user or provider invitation is used instead of shared credentials where possible.
• Individual accounts are used when attribution matters.
• Multi-factor authentication remains enabled where supported.
• Secrets will use an appropriate secure channel.
• Secrets will not be committed to a repository, pasted into screenshots, or stored in ordinary notes.
• I know which people and subcontractors will receive access.
• I know which buyer or end-user data the service processes.
• Collection and access are limited to the service purpose.
• Sensitive production data will be minimized or masked in non-production environments.
• Logs and screenshots will be redacted before delivery.
• The storage location and retention period are proportionate.
• A process exists to return or delete buyer data and revoke access.
• Consent and privacy configuration are in scope for tracking, marketing, or personalization work where applicable.
• Payment data uses a provider-hosted or otherwise appropriately compliant flow.
• I will not reuse buyer data, credentials, prompts, designs, code, or content for another purpose without permission.

30.8 Backups, staging, deployments, and change safety

• The current production state is recorded before changes.
• A current backup or snapshot exists for destructive or material work.
• The backup covers the database, files, and relevant external configuration.
• Backup storage is not dependent only on the system being changed.
• Restore access and restore instructions are available.
• A restore has been tested when the package promises backup reliability.
• A staging environment will be used when practical.
• Staging cannot send real customer email, charge live payments, or be indexed accidentally.
• Production data copied to staging is protected.
• Deployment steps are defined.
• Database migrations are reversible or have a documented recovery path.
• The maintenance window and possible downtime are disclosed.
• DNS, cache, CDN, queue, cron, and worker effects are included where relevant.
• A rollback trigger and responsible person are identified.
• Emergency changes will be documented after stabilization.
• I will not edit WordPress core or unmanaged vendor files as an undocumented shortcut.

30.9 Third-party services, accounts, licenses, and dependencies

• Every material third-party provider is named.
• The account owner for each provider is clear.
• Buyer-owned accounts are used for durable production services where practical.
• Required plan level, quota, region, and feature availability are verified.
• License rights cover the intended use.
• Premium assets, fonts, code, models, data, and templates may lawfully be transferred or used.
• API and platform terms permit the planned integration.
• Rate limits and usage costs are considered.
• Provider sandbox or test modes are used where available.
• OAuth, API keys, webhooks, and service accounts use an appropriate security model.
• A provider outage or policy change will fail safely.
• The buyer knows which part cannot work without the provider.
• The buyer knows what happens when a subscription or license expires.
• There is no undisclosed seller-owned dependency or lock-in.
• Any replacement or export path promised in the listing is practical.

30.10 Execution and technical quality

• The implementation follows the official standards of the platform in scope.
• Deprecated and unsupported APIs are avoided or documented.
• Security controls are appropriate to the data and action.
• Input is validated and output is safely encoded.
• Authentication and authorization are tested separately.
• Error handling provides useful information without exposing secrets.
• Remote calls use reasonable timeouts and bounded retries.
• Duplicate, delayed, reordered, and failed events are handled where relevant.
• Long work does not block interactive requests unnecessarily.
• Logging is adequate for support and privacy-conscious.
• Performance avoids unnecessary queries, requests, assets, and processing.
• Accessibility and keyboard behavior are considered for user interfaces.
• Internationalization and locale behavior are considered for user-facing code.
• Custom work is separated from vendor and core code.
• Source is maintainable and not maliciously obfuscated.
• Build and generated files are identified.
• Dependencies are supported, pinned appropriately, and free of known unacceptable licensing conflicts.
• AI-generated code or content has been reviewed, tested, and licensed like any other work.

30.11 Testing and evidence

• A written test plan covers the acceptance criteria.
• The agreed environment and versions are tested.
• Relevant visitor, customer, editor, manager, vendor, and administrator roles are tested.
• Happy paths and important failure paths are tested.
• Empty, invalid, duplicate, large, and boundary inputs are tested where relevant.
• Relevant browsers, breakpoints, and devices are tested.
• Forms, email, uploads, downloads, search, authentication, and scheduled work are tested when affected.
• Caching and logged-out behavior are tested when affected.
• Payment changes use sandbox or test mode before an authorized live test.
• Refund, cancellation, failure, retry, renewal, tax, and shipping states are tested when affected.
• Integrations are tested at both ends.
• Migrations include record counts or another completeness check.
• Performance tests record URL, device/profile, date, cache state, tool, runs, and result.
• Accessibility tests combine automated and manual checks when accessibility is in scope.
• Security findings are manually verified before high-severity claims.
• Original reproduction steps pass after a bug fix.
• Adjacent workflows have regression coverage.
• Evidence does not expose credentials, personal data, or confidential information.
• Any untested area or limitation is disclosed.

30.12 Delivery, documentation, handover, and corrections

• Every promised deliverable is attached, transferred, or reachable.
• The delivery message summarizes the result.
• Changed files, settings, content, accounts, and integrations are identified.
• Source and editable files are included where promised.
• Repository and commit references are provided where applicable.
• Build, installation, deployment, and rollback steps are documented.
• Environment variables are named without exposing values.
• Account ownership and transfer are complete.
• The buyer has the level of access promised.
• Temporary accounts, keys, bypasses, debug settings, and test data are removed or documented.
• Backup, staging, search-indexing, maintenance-mode, email, and payment-mode status are confirmed.
• Test evidence and known limitations are included.
• Operating and maintenance instructions match the buyer’s expected skill level.
• Third-party renewals and future costs are listed.
• The buyer knows how to request a correction.
• Included revisions and post-delivery support remain available for the promised period.
• In-scope defects will be corrected without consuming a revision.
• Documentation identifies the delivered version or date.
• A durable copy of buyer-owned work is available.

30.13 Intellectual property, content, and AI

• I own or may lawfully provide all seller-created deliverables.
• Buyer-supplied material is used only for the order.
• Third-party licenses are documented.
• Required attribution is retained.
• Source assets and editable files may legally be transferred.
• Font, stock, icon, template, model, dataset, and code licenses are checked.
• A buyer is not promised exclusive rights to non-exclusive stock or shared components.
• Logo and naming work includes an appropriate originality and trademark disclaimer.
• Confidential work will not be placed in a public AI service without authorization.
• AI output has been checked for accuracy, originality, security, bias, and licensing risk as relevant.
• Machine translation is disclosed when human translation is not included.
• AI-assisted work is not misrepresented as a certification, expert audit, or hand-created deliverable.
• Portfolio use is separately authorized.

30.14 Category overlay

• For Automation & Integrations, triggers, actions, fields, authentication, errors, duplicates, retries, logs, ownership, quotas, and disablement are documented.
• For Consulting & Training, the agenda, evidence reviewed, deliverable, expertise boundary, and follow-up are documented.
• For Design & Branding, screens, states, breakpoints, content, assets, accessibility, source formats, and licensing are documented.
• For Marketing & Content, audience, voice, length, claims, references, channel constraints, review method, and editable format are documented.
• For Other Development, runtime, framework, architecture, repository, dependencies, tests, deployment, security, and documentation are documented.
• For Performance, SEO & Analytics, baseline, measurement method, controlled factors, consent, validation, and non-guaranteed outcomes are documented.
• For Security & Maintenance, authorization, inventory, backup, evidence preservation, severity, remediation boundary, reporting, and access removal are documented.
• For Translation & Localization, locale, source word count, file format, glossary, placeholders, human review, context, and linguistic QA are documented.
• For Website Setup & Launch, environments, backups, DNS, email, SSL, URL replacement, deployment, validation, rollback, and handover are documented.
• For WooCommerce & eCommerce, products, taxes, shipping, payment, checkout, email, privacy, roles, transaction states, and sandbox tests are documented.
• For WordPress Development, supported versions, hooks, update safety, security, accessibility, performance, internationalization, source, tests, and documentation are documented.
• Every selected subcategory’s specific section in this document has been reviewed.
• Any second category implied by the work has also been reviewed.

30.15 Ongoing service and final review

• A fixed-period ongoing package defines its one-time purchase, covered period, allowance, frequency, response target, support hours, and ending process.
• Monitoring states exactly what is checked and how often.
• Automated monitoring is not misrepresented as continuous human response.
• Reports reflect work actually performed.
• A following order, cancellation, ending, and handover effects are clear.
• Provider and license changes can be communicated without silently breaking service.
• The buyer can regain control when the service ends.
• No hidden account, access method, kill switch, or seller-controlled dependency remains.
• The listing, requirements, delivery template, and actual workflow agree with one another.
• All links, examples, prices, compatibility claims, and screenshots are current.
• Spelling, grammar, formatting, and category names have been checked.
• Confidential or identifying test data has been removed.
• I can demonstrate every factual and performance claim.
• I understand and can maintain the delivered work.
• I have read the current WPBay seller, acceptable-use, refund, and service guidance linked below.

31. Related WPBay guidance

This page should be read together with the current WPBay marketplace documents:

• Services are now available on WPBay — overview of service listings, fixed packages, buyer requirements, delivery, revisions, and the service-order workflow.
• Sell WordPress Plugins, Themes & Services — seller onboarding and marketplace overview.
• What Makes a Product WPBay-Ready? — baseline quality, documentation, licensing, version, compatibility, and code-integrity principles for product deliverables.
• WPBay Seller Guidelines — packaging, testing, ownership, licensing, support, presentation, AI-generated work, and seller conduct.
• WPBay Seller Agreement — contractual seller obligations.
• WPBay Acceptable Use Policy — prohibited use and marketplace-safety rules.
• WPBay Refund Policy — current refund conditions and process.
• Warning and One-Strike Violations — examples of conduct that may lead to warnings or stronger account action.

This page adds service-specific technical review requirements. It does not replace the WPBay terms, policies, order terms, or applicable law. If documents conflict, the current binding terms and policies take precedence. A seller must follow the current version in effect at the time of listing and delivery.

Code, themes, plugins, scripts, templates, or other digital products delivered as part of a service must also meet the applicable WPBay technical requirements for that product type. Approval of a service listing is not pre-approval of every future deliverable.

32. Official development and professional references

The following primary and standards-body sources support the technical expectations in this page. They are references, not external certifications imposed on every package. The seller must select the rules relevant to the actual service and follow current versions when standards change.

32.1 WordPress

• WordPress Coding Standards
• WordPress PHP Coding Standards
• Common WordPress security APIs
• Plugin Handbook: Security
• WordPress REST API Handbook
• WordPress hardening guidance
• WordPress backup guidance
• WordPress migration guidance
• WordPress accessibility coding standards
• Plugin internationalization
• Theme internationalization
• WP-CLI core checksum command

32.2 WooCommerce and payments

• WooCommerce Payment Gateway API
• WooCommerce payment token API
• WooCommerce Checkout Store API
• WooCommerce Checkout Block payment-method integration
• PCI Security Standards Council: PCI DSS

32.3 Application security and incident handling

• OWASP Application Security Verification Standard
• OWASP Web Security Testing Guide
• OWASP Top 10: 2025
• OWASP Secure Code Review Cheat Sheet
• NIST SP 800-61 Revision 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management

32.4 Privacy, consent, and direct marketing

• European Commission: Data protection in the EU
• ICO: Cookies and similar technologies
• ICO: Guide to direct marketing
• FTC: CAN-SPAM Act compliance guide
• Google Tag Platform privacy guidance
• Google consent mode

32.5 Performance, search, analytics, and structured data

• web.dev: Web Vitals
• Google Search Essentials
• Google Search spam policies
• Google SEO Starter Guide
• Google structured-data general guidelines
• Google Analytics setup
• Google Search Console: Get started
• Schema.org documentation

32.6 Accessibility and interface design

• Web Content Accessibility Guidelines 2.2
• W3C WAI: Designing for Web Accessibility
• W3C WAI image accessibility tutorial
• European Commission: European Accessibility Act
• Figma: Guide to Dev Mode

32.7 APIs, integrations, and automation

• OAuth 2.0 Security Best Current Practice: RFC 9700
• OpenAPI Specification
• Zapier Platform documentation
• Make API documentation
• Make webhooks
• HubSpot API overview
• HubSpot webhooks API
• Mailchimp OAuth 2
• Mailchimp webhooks

32.8 Email authentication and delivery

• Sender Policy Framework: RFC 7208
• DMARC: RFC 9989
• Google email sender guidelines
• Yahoo sender best practices

32.9 Branding, content rights, and licensing

• WIPO: Trademarks
• Creative Commons license conditions and attribution

32.10 Translation and localization

• ISO 17100: Translation services requirements
• Unicode Common Locale Data Repository
• Unicode plural rules
• W3C Internationalization

Final note

WPBay service approval means that the listing met the marketplace’s review requirements at the time it was reviewed. It is not a certification, legal opinion, security guarantee, accessibility conformance claim, search-engine endorsement, professional license, or promise of a particular business outcome.

The seller remains responsible for:

• the accuracy of the listing;
• lawful authorization;
• professional execution;
• security and privacy;
• licenses and intellectual-property rights;
• testing and delivery evidence;
• communication and correction of in-scope defects;
• maintaining ongoing services for the period sold;
• every person, tool, AI system, and subcontractor used to complete the order.

When a service changes materially, the seller should update the listing and package before accepting new orders. WPBay may re-review, restrict, unpublish, or require correction of a service that no longer meets these requirements.