Using Returns

Returns has two sides: the customer raises and tracks a request from My Account, and you manage it under WooCommerce → Return Requests in wp-admin. This page follows one return end to end.

The customer side

Opening a return

On an order that is in an eligible status, inside the return window, owned by the logged-in customer and not yet returned, a Request a return action appears in two places:

• as a row action on the Orders list in My Account, and
• as a button on the single order view.

Only the order’s owner ever sees the action. The endpoint that renders the form (/my-account/request-return/) is intentionally kept out of the account navigation menu, it is reached only from the per-order action, and it re-checks ownership, eligibility and the one-per-order rule on load, so a hand-typed URL gets a notice rather than a form.

The request form

The form lists every product line on the order. For each line the customer can:

• tick it to include it in the return,
• set the quantity to return, pre-filled to the quantity ordered and capped there, so you can never receive a request for more than were bought,
• choose a reason from a required dropdown: arrived damaged or faulty, wrong item received, no longer needed, size or fit issue, or other, and
• add an optional free-text note.

The form is a plain server-rendered POST, no JavaScript, no AJAX. On submit it is nonce-verified, the owner is confirmed again, and the selected items are resolved against the order’s real line items, so a tampered POST can never inject a product the order never contained. At least one item and a reason are required; missing either re-renders the form with an inline error. On success the customer is redirected to the orders page with a confirmation notice.

Tracking the status

Once a request exists, the customer sees it above their orders table in a Your return requests list, request number, order number, date and status. The status is drawn as a journey track: a return is a trip back to the shop, so each stage is a waypoint on a dashed return path. Steps already passed are filled, the current stage is a larger ringed marker, and the live status name is read to assistive tech as a single sentence (“Return status: Approved”). A rejected return forks off the path at a red marker, the journey stops there rather than carrying on to Completed.

A single order has one return request. After it is opened, the action is hidden for that order and a notice explains a return already exists.

The merchant side

Finding requests

Every submission lands in two places:

• a plain-text email to your site admin address, listing the order number, customer name, reason, the requested items with quantities, the note, and a direct link to manage the record, and
• a private Return Request record under WooCommerce → Return Requests.

The list adds Order, Status and Items columns. Status shows as a coloured badge; Order links straight to the order edit screen (resolved correctly under both HPOS and legacy order storage).

Reviewing a request

Open a record to see two boxes. Return details shows the linked order, the reason, the customer note and a table of requested items with quantities. Status is a dropdown, the only editable field, guarded by a nonce and the manage_woocommerce capability. The records cannot be created from wp-admin; they exist only because a customer submitted one.

The status workflow

Move each request through four stages:

1. Requested, the state set when the customer submits.
2. Approved, you accept the return.
3. Rejected, you decline it; the customer’s journey track forks to a red marker.
4. Completed, the return is finished.

The status is stored as post meta on the record, not as a WordPress post status, so it stays decoupled from publish states. Whatever you set is the exact label and journey position the customer sees in My Account, the two views never drift apart. Saving the same status again changes nothing and fires no hook.

Handling the refund

Returns stops at the request-and-status level. When you are ready to refund, use the standard WooCommerce order screen, partial or full refunds behave exactly as usual. The status box reminds you of this: setting a return to Completed does not refund anything. Set the status afterwards so the customer sees the outcome.

Accessibility and presentation

The storefront output is built with WCAG 2.2 AA in mind. The item picker is a real <fieldset>/<legend> with a label per checkbox and a screen-reader label on each quantity field; errors carry role="alert" and aria-describedby. Notices use role="status" or role="alert" as appropriate. Focus styles are visible.

There is no JavaScript and no external request, so the flow adds no layout shift and nothing to defer. The styles are CSS custom properties on the storefront stylesheet, including an “in-transit” teal accent (--returns-accent) that lifts for dark colour schemes to keep the journey labels above AA contrast, and the journey track stacks into a vertical timeline on narrow screens. The active waypoint plays one soft arrival pulse on load, suppressed under prefers-reduced-motion.