Casefile

A WooCommerce plugin that turns a product store into a service delivery engine, written to answer four specific questions from a tender writing agency's brief.

This repository holds two things:

• plugin/casefile/ is the actual WordPress plugin. Zip it, upload it, activate it.
• The root is a small walkthrough site that explains the four answers with the real code and real screenshots.

What it does

Custom order statuses, registered in code. Five stages that match how a bid is actually produced: brief received, in drafting, with client for review, submitted to tender, outcome recorded. Inserted after Processing, present in the single order dropdown and in bulk actions on both the legacy and the HPOS orders screens, and kept inside woocommerce_order_is_paid_statuses and the reports list so the work in progress does not drop out of revenue figures.

A payment gateway called directly over its API. DPO Group, used across southern Africa and the right fit for BWP. Three calls: createToken to register the charge, a redirect to DPO's hosted page so card data never touches the server, and verifyToken on return. The verify step is not optional: a browser coming back is not proof of payment.

A client portal. Built on WooCommerce's own account endpoints rather than a second login, so there is one session and one password reset. Each order shows its stage on a progress rail and carries its own documents. Documents live in a directory denied by .htaccess and are streamed by PHP only after the order's owner is confirmed, because an unguessable URL is not access control for a tender document.

Signed webhooks to an automation tool. Four endpoints, each separately configurable: order.created, order.status_changed, payment.completed and document.uploaded. HMAC-SHA256 over the exact bytes sent with the timestamp in the signed string, queued through WP-Cron so a slow receiver never holds up checkout, retried with exponential backoff, and the last fifty attempts logged so a failure is visible rather than silent.

How it was verified

Not by compiling. The plugin was installed into a real site and driven headlessly:

• WordPress 7.1.3, WooCommerce 11.2.1, PHP 8.3.14, SQLite via the official database integration drop-in.
• Ten services seeded with BWP pricing, two customers, six orders spread across all five custom statuses.
• 21 assertions, all passing: the statuses appear with correct counts, a customer sees only their own orders, a second customer holding the first customer's exact download link is refused, the gateway registers in Payments, all four webhook endpoints appear in settings, and deliveries arrive with a signature an independent receiver verifies.
• Webhook delivery was tested against a real HTTP receiver that recomputed the HMAC. Three deliveries, three valid signatures, three 200s.

A bug the tests caught

The document list used (array) $order->get_meta( $key ). When the key is unset get_meta returns an empty string, and casting that gives array('') rather than an empty array, so the first read fatals on a string. Fixed at the source, and the reader now drops anything that is not a well-formed document.

Running the plugin

cd plugin
zip -r casefile.zip casefile
# then upload, or:
wp plugin install casefile.zip --activate

Settings are under WooCommerce, Casefile. Set the four endpoint URLs and the shared signing secret, and set the same secret in the automation tool.

Running the walkthrough site

npm install
npm run dev

Scope and honesty

This plugin was written for this brief, so it is new work rather than a past project. It is a working reference implementation, not a finished product: the DPO credentials are configuration rather than a tested live merchant account, and intake forms, Elementor pages and SEO are outside it.

Services, clients, prices and documents in the screenshots are representative.