WordPress/WooCommerce Developer — deploy, verify & finish an EXISTING, already-tested plugin (full spec + full test suite provided)

We have a WordPress plugin that sells services on a CREDIT model. It is
already CODED and already TESTED on a local machine: 31 of 33 smoke tests
pass (the remaining 2 wait on OUR input data, not on defects) plus 6 of 6
payment-gate tests — including a real PayPal SANDBOX payment and refund.
We need an experienced developer to take it onto a real staging domain
and turn it into an accepted, live system:

Stand up a fresh WordPress -> install & configure the plugin per the
docs -> RE-RUN the provided acceptance suite on the real domain (30
smoke tests in M1; the 3 dataset tests complete the 33 in M2; plus 6
PayPal-gate tests) -> fix anything the real environment exposes -> go
live on PayPal (one real transaction + refund) -> finish the operator
docs -> hand over with a joint sign-off.

What the system does: a visitor clicks Buy now, creates an account at
checkout (if they don't have one — or signs in with Google), buys a
credit pack through PayPal; the plugin credits their wallet; they paste
a list and Submit; an external processing machine picks the job up over
a REST API and returns an Excel file; the buyer downloads it.

You do NOT build the plugin from scratch and you do NOT design anything —
the code exists with a complete English spec it was built to (DB schema,
API spec, UI contract, per-role flow maps). You configure, test, debug
and fix until it passes; the only thing you WRITE new is the operator
documentation at the final milestone. You also get a MOCK worker (Python)
that plays the processing machine, so you can run the whole buy ->
process -> download chain without our real system.

THE ACCEPTANCE BAR: the core measure is the test suite passing on
staging — plus the operator docs and the joint sign-off at the final
milestone. "Test-and-fix on the delivered code" is part of the contract:
a defect that makes a test fail is yours to fix whether it lives in the
plugin, the config, or the mock app; we don't argue about its origin. In
return, everything is specified and every test case is written for you —
you never guess a requirement.


SCOPE OF WORK

1. SITE SETUP on our staging domain from a clean WordPress: WooCommerce
(guest checkout off, create-account-at-checkout on), PayPal Payments,
an SMTP plugin (email must reach a real inbox), a self-hosted CRM
plugin (opt-in checkbox), and a standard social-login plugin for
Google sign-in (a NEW addition — you install from wordpress.org, pin
its version, configure and smoke it). We supply every other plugin
package at the tested versions.
2. PLUGIN INSTALL & CONFIG: activate (DB tables + seed + cron), create
the fixed credit-pack products via the built-in product-editor tab,
confirm the packages panel has no warnings, set the worker API key.
3. PAYMENT: on your own PayPal accounts until everything passes — see
THE PAYPAL RULES below; it is the most unusual condition of this job,
read it before you bid.
4. FULL ACCEPTANCE: re-run the smoke tests from the provided checklist
(30 in M1; 3 dataset tests complete the 33 in M2) using the mock
worker — from anonymous purchase to file download, admin/staff
permissions, retention purge, email, CRM opt-in.
5. FIX UNTIL IT PASSES: any defect the tests expose is in scope; record
each change in the deviation changelog. Fix rule: code that disagrees
with the docs is a bug; a doc that looks wrong is a question for us. A
failure caused by missing OWNER input (credentials, real seed, domain)
is a blocker to log and raise — not counted against you.
HOW CODE IS DELIVERED: every fix is COMMITTED to the private GitHub
repository we provide, with clear messages — your commit history is
how we review the work at each milestone. Code sent loose by zip or
email is not accepted.
6. GO-LIVE + HANDOVER: PayPal Live (one real transaction + refund as
evidence); WRITE the operator docs — 3 short guides (admin, staff,
buyer) with real staging screenshots; the technical specs already
exist, this final runbook is YOUR deliverable, no draft. Hand over
per the joint checklist.

THE PAYPAL RULES (read before you bid)
a) SANDBOX: your own sandbox account on the public staging domain
(needed for webhooks); re-run the 6 payment-gate tests there. The
full sandbox flow is already proven and a setup how-to is included.
b) LIVE-PATH REHEARSAL: before we connect anything of ours, prove the
LIVE path end-to-end on YOUR OWN live PayPal account using a
temporary low-value test pack (e.g. $0.10–$1, staging only, deleted
after): one real purchase -> correct credit -> one real refund.
Evidence required (transaction IDs + matching DB rows + screen
capture). Price these micro-transaction costs into your bid — they
are cents, and they prove your work is done.
c) OWNER SWAP AT GO-LIVE: only after the full suite passes and your
live-path evidence is accepted does the owner connect the production
PayPal account — the owner enters those credentials personally; you
never see or handle them. Then the final go-live check runs on it.

NOT in scope: writing the plugin from scratch; designing UI/DB/API
(done); rewriting UI copy or brand touchpoints (a fixed contract);
coding the real data-processing worker (we run our own; a mock is
provided); sales/marketing pages, a custom payment gateway, a data
viewer, or analytics.


YOU RECEIVE (on signed contract)

- The full plugin source as a snapshot into a private GitHub repository
we create and invite you into. No prior commit history — it starts
with you (transparency, not a gap). You work IN this repo and deliver
THROUGH it: the final repo state (fixed code + deviation log) is the
code deliverable at each milestone. Plus the mock worker (Python,
1-page guide).
- The complete English document pack the code was built to (product
brief + 12-step journey; site/payment setup; DB/API architecture; UI
spec; worker contract; acceptance checklist = 13-step deploy + 33
smoke + 6 payment tests; per-role flow maps; joint sign-off checklist;
mock-worker spec) + 3 browser-openable HTML contracts (2 UI screens
with backend annotations + 1 design-token file) + 6 sample
spreadsheets defining each service's exact output columns.
- Our local test evidence as a baseline (including the real PayPal
sandbox run).
- A real staging domain + hosting access (you install the fresh
WordPress; clean activation is a sign-off item) + all base plugin
packages at tested versions (the Google social-login plugin is the one
exception: new addition, you install and pin it). The package has NO
credentials: you use your OWN PayPal accounts (see THE PAYPAL RULES)
and your OWN Google OAuth test app for staging; the owner's PayPal and
production Google OAuth enter only at go-live, connected by the owner.
- Note: the shipped service seed is a small placeholder on purpose; the
real one is owner input, and its row count is NOT an acceptance
condition.


MILESTONES & ACCEPTANCE

- M1 — ASSET LANE LIVE (30 of the 33 smoke tests): site on staging;
sandbox purchase -> correct credit -> submit -> mock worker -> buyer
downloads; 6/6 payment gates pass; every exposed defect fixed;
live-path rehearsal on YOUR own PayPal account (with evidence); then
go-live of the asset lane — one real transaction + refund on the
owner's production account.
- M2 — DATASET/REVIEW LANE + docs: the 3 dataset tests pass (33/33);
operator docs finished; joint sign-off. Code deliverable = the final
repo state (fixed source + full deviation log), not a zip.
In one line: M1 = the main lane earning for real; M2 = the review
lane, the docs, and the signatures.
- MANDATORY EVIDENCE: every test group comes with a screencast or
screenshot; money/credit/order tests also carry the transaction ID +
matching DB row. No evidence = not accepted.


REQUIRED SKILLS

- MOST IMPORTANT: reading, debugging and fixing a WordPress plugin
someone else wrote (hooks, custom $wpdb tables, capabilities, WP-Cron,
REST API, admin-ajax). This is finish-existing-code, not greenfield.
- WooCommerce at the hook/lifecycle level (payment_complete, refund,
product meta). No payment-gateway internals needed.
- Test discipline with evidence capture; atomic UPDATE, idempotency and
race conditions understood so fixes land in the right place.
- WordPress security basics: nonces, current_user_can, prepared SQL,
output escaping.
- Reads English technical docs and follows a contract exactly (ask when
unsure — do not invent).
- Runs a simple Python app (the mock worker; guide provided).
- Git basics (clone, branch, commit, push) — all delivery is
repository-based, never by zip.


TO APPLY, PLEASE SEND

1. One or two projects where you TOOK OVER existing WordPress/WooCommerce
code to fix/finish (describe your role).
2. Concrete experience with custom DB tables + REST API in WordPress.
3. Your BID: a fixed price for M1, your timeline, and the warranty period
you offer (e.g. 30 days) — after reading the above.
4. Confirm you can test with your OWN PayPal accounts as described in THE
PAYPAL RULES (sandbox + a low-value live rehearsal). If you cannot,
say so plainly and we will discuss before signing.
5. Start your reply with the word "CREDIT" so we know you read this fully.

Pricing: fixed price per milestone — YOU bid it (see #3 above); payment
is released per gate, never by the calendar. We work in English.

Contract terms, up front: code ownership (all work transfers on milestone
payment) and no-reuse of this project's source, documents and data — your
general skills and experience are of course not restricted. Signed before
source and docs are shared.