business Case study
Order Replacement / Price Fix Tools
A watch arrives damaged and is replaced with a different reference. A customer pays part in cash at the counter. A price was entered wrong. WooCommerce has no safe path for any of these once an order is paid, so the team was editing line items directly, which loses the history and confuses the totals.
The business problem
Editing a paid order in WooCommerce is possible and dangerous. The admin lets you change line items but nothing records what the order looked like before, and any change that touches the payment total risks disagreeing with what the gateway actually captured. The team needed to make these three corrections routinely, and the existing path had no undo.
What I delivered
- a2-order-replacement-box.php, a 3,294-line admin box at version 1.7.0 covering item replacement against one or several products, additional shipping, and same-item price correction.
- A snapshot taken before every change, with an undo that restores it, so a mistaken correction is reversible rather than a second manual repair.
- A history meta record on the order, so the sequence of corrections is readable months later.
- Separate recording of payments received outside the gateway, with the remainder split between what is owed to the gateway and what came in by card transfer.
- A fixed flag on the order, so corrected orders are identifiable in bulk rather than one at a time.
- A hard rule, stated in the plugin name itself: order status and payment gateway are never modified.
Technical approach
- Snapshot before mutate is the invariant the whole tool is built on. Nothing changes an order until the previous state is stored.
- The gateway boundary is a deliberate refusal. The tool corrects what the shop owes and what was received; it never tries to reconcile that back into the payment record, because the gateway is the authority on what was actually captured.
- Outside-gateway receipts are recorded as their own category rather than being folded into the order total, so the accounting stays separable afterwards.
- All actions run behind a nonce, and each writes an order note, so the audit trail is a side effect of using the tool rather than a step someone has to remember.
Result and evidence
The three routine corrections became routine. They are recorded, reversible, and they no longer require someone comfortable editing line items by hand. The order history now explains itself, which is what made the accounting reconciliation tractable.
Commercial value
This is where operations meets accounting. Corrections were always going to happen in jewellery retail; the question was whether they would leave a trail. Now they do.
Readable implementation brief
implementation_brief {
project: "Order Replacement / Price Fix Tools"
file: "mu-plugins/a2-order-replacement-box.php (3294 lines, v1.7.0)"
operations: "replace item (1..n products), add shipping,
correct price on the same item"
invariant: "snapshot before mutate; undo restores it"
never: "order status and payment gateway are not modified"
accounting: "off-gateway receipts recorded separately;
remainder split gateway vs card transfer"
audit: "history meta + order note per action, nonce-guarded"
discovery: "fixed flag so corrected orders are findable"
}What this project shows
The most important line in this project is the one about not touching the gateway. It would have been easy to make the numbers look tidy by adjusting the payment record, and that is exactly the change that makes reconciliation impossible later.
Snapshot and undo were not a feature request. They were the condition under which I was willing to give staff a tool that edits paid orders.