Senior WordPress / WooCommerce Developer — Urgent Production Investigation and Stabilisation

A live UK e-commerce site built on WordPress + WooCommerce, operating in a regulated healthcare context (so accuracy, auditability and reliability matter). The site serves real customers daily and has been live for some time, but has accumulated technical debt across several layers payment gateway integration, custom plugins, recent third-party feature additions, and a checkout flow that has been migrated between integration modes more than once. We're now hitting a cluster of inter-related production issues at the same time, and we need someone senior, methodical, and disciplined to come in, stabilise the site, and put the workflow on a proper version-controlled footing going forward. The current situation Over the past few days, several different problems have surfaced more or less simultaneously: Draft orders. Some customer orders are landing in "Draft" status in WooCommerce despite payment being successfully captured by the payment gateway (Elavon Converge). The order has no transaction ID and no payment notes attached — the gateway side completes cleanly but the WooCommerce side never receives confirmation that payment is done. Affected customers have had to be manually rescued by support staff. Existing-customer login issues. Multiple returning patients are reporting they cannot log in to their accounts. Because the site has separate flows for new patients and existing patients, this is preventing existing customers from reaching the reorder pathway entirely, and they're being forced (incorrectly) through the full new-patient eligibility assessment. The reorder pathway is critical. The site has two distinct customer journeys: new-patient eligibility (a multi-step clinical assessment built into a custom plugin) and quick-reorder (for existing patients to reorder previous treatments without redoing the full clinical workup). Significant prior work has gone into tightening the returning-customer identification and routing logic — a custom SPWL_Returning_Customer service that writes a flag on the user record at order time and reads it at decision time, instead of trying to re-derive returning-customer status from order history on every page load. The login issues are now breaking that logic for affected customers. Payment processing issues — broader than just the Draft orders, including reports of customers unable to complete checkout cleanly. A recent loyalty / referral system deploy (built on a WooCommerce loyalty plugin) and a parallel custom email automation plugin went live last week. The timing of the issues correlates with this deploy. The system also introduced three custom order statuses (Awaiting ID Upload, ID Uploaded – Awaiting Review, Prescription Approved) and an ID-upload customer flow tied to those. Payment gateway history. The site was on Stripe → migrated to Ryft → migrated to Elavon. Within Elavon, the integration was moved from HPP (hosted payment page) to Hosted Fields for UX reasons, which required moving WooCommerce checkout from shortcode to the block-based version. The installed Elavon plugin is significantly behind the current release (we're on a version pre-dating official block checkout support). What you'll be doing Take ownership of investigating the production issues, end-to-end. Diagnose, plan, implement, deploy, verify. Reproduce each issue on staging before attempting any fix on live. We have a staging environment (Kinsta) that has drifted out of sync with live — restoring it to mirror live is part of the work. Identify the actual root cause of each issue, not just patches. Particular focus on: The Draft orders / payment_complete callback failure The existing-customer login issues and how they intersect with the reorder pathway Why returning customers are being routed through the new-patient assessment when they should be reaching the quick-reorder flow Any other checkout / payment problems surfacing Audit the reorder pathway end-to-end. The eligibility wizard plugin, the quick-reorder plugin, the SPWL_Returning_Customer service, the order metadata attachment, the checkout integration. Make sure the existing investment in returning-customer identification is preserved and working. Upgrade the Elavon Converge plugin to the current version, with staging-first testing and a clean migration of settings/configuration. Review the recently-added custom plugins (loyalty system, custom automation plugin, ID-upload plugin) for hooks that could interfere with the WooCommerce order completion flow or the returning-customer routing logic. Recommend changes where needed. Resolve the login issues in parallel. Hand back a stabilised site with documentation of what was changed and why. Mandatory workflow requirements (non-negotiable) These are explicit and I will be enforcing them. If these aren't how you work, this is not the engagement for you. Everything goes through GitHub. No direct edits on the live server. No "I'll commit it later". Every change, however small, lands as a Git commit on a feature branch with a clear message. Pull request workflow. Every change is reviewed before merge — even if I'm the only reviewer. Force-pushes to main are not acceptable. First task is consolidation. Before any bug-fix work, the existing live site state needs to be brought into the repo as the canonical baseline — including the three new custom plugins, the theme, mu-plugins, and the WordPress configuration. The current repo is out of date. Staging-first testing for every change. Staging must be brought up to match live, then every fix is verified on staging before deployment to live. CI/CD pipeline restoration. There's a GitHub Actions workflow that's currently failing to deploy to Kinsta. Either fix it (preferred — likely an IP allowlist or SSH key issue) or document why it isn't suitable and propose an alternative. Use of Claude Code is mandatory. A significant portion of the existing custom code on this site was developed and is documented within Claude Code sessions, including the returning-customer service, the reorder routing logic, and an operational runbook (docs/RUNBOOK.md in the GitHub repo). The Claude Code conversation history contains design rationale, kill-switch information, log prefixes for observability, and the test methodology that should be followed. You must use Claude Code to fact-find the existing implementation before making changes. If you don't already have access to Claude Code, I'll provide my licence so you can use it on this engagement at no cost to you. Itemised reporting. Every step you take must be itemised and explained to me in writing. Repository consolidation is the foundation of this engagement. The site currently has no working single source of truth in GitHub. The existing repo at the URL I'll share with you is out of date — it doesn't contain the three new custom plugins, the recent theme modifications, or any of the mu-plugins. The current live site state has been built up through direct edits on the server. Before any bug-fix work begins, you and I will work together to bring the entire live wp-content directory into the GitHub repository as the canonical source of truth. This means: All plugins on the live site (custom and third-party) committed to the repo The active theme committed to the repo All mu-plugins committed to the repo A proper .gitignore excluding uploads, cache, and logs The repo structure laid out so that future deploys can rsync wp-content/plugins/, wp-content/themes/, and wp-content/mu-plugins/ directly from the repo to the server A documented mapping in the repo's README so anyone (including me) can immediately see what's tracked and what isn't This is not a task you do alone in a corner. It's a collaborative piece of work where you walk me through what's being added to the repo, why, and how the structure has been chosen. I expect to be looped in on every decision during this phase. Once the consolidation is complete and signed off by me, you will be authorised to proceed with the bug-fix work — and from that point forward, every single change goes through Git, with no exceptions. What's nice to have Experience with WPLoyalty Pro or similar loyalty/referral plugins Block checkout customisation experience Action Scheduler debugging experience Custom WooCommerce checkout customisation that includes pre-checkout multi-step forms (eligibility / qualification flows) UK e-commerce experience (delivery, VAT, GDPR familiarity) What we're offering Fair contract rate at senior level (open to your day-rate proposal — please include in your reply) Clear scope: stabilise, consolidate, document, hand back Direct working relationship with the engagement owner (me) — no layers of project management Continued ongoing work if the engagement goes well Claude Code licence access provided if needed