Configuration

Returns has three settings, all on one screen: WooCommerce → Returns in wp-admin. They are stored together in the returns_settings option (an array), and the page is gated to the manage_woocommerce capability. The plugin ships with working defaults, so configuration is optional.

Enable returns

The master switch, on by default. While on, a Request a return link appears next to eligible orders in My Account and the request form is reachable. Turn it off and both the link and the form disappear from the storefront, existing return records are untouched and stay in your wp-admin list. Stored as enabled.

Eligible order statuses

Tick the WooCommerce order statuses a customer may open a return on. An order in any other status never shows the Request a return action. The list is built from wc_get_order_statuses(), so it reflects your own custom statuses too; values are stored without the wc- prefix under eligible_statuses.

The default is Completed and Processing, the two statuses that normally mean the customer has the goods. Add On hold if you ship before payment clears, or restrict to Completed only if you never want a return raised before fulfilment is finished.

There is a deliberate safety net: if you untick every status and save, the setting falls back to Completed rather than disabling the feature silently. So the eligibility list is never empty.

Return window (days)

The number of days from the order’s creation date during which a return can be opened. Once an eligible order is older than the window, the Request a return action is hidden and, if the customer reaches the form by URL, a “not eligible” notice is shown instead. Stored as window_days.

• Set a value such as 14 or 30 to match your policy. Ships at 30.
• Set it to 0 to remove the time limit, eligible orders can be returned at any time.

The window is measured from the order, not from the customer’s visit, so it is consistent regardless of when they log in to start the request. The settings page renders a live example beneath the field, “an order placed today can be returned until 17 July 2026”, using your site’s date format, so you can sanity-check the number before saving.

There is no recipient setting

Every new request is emailed to your site’s Administration Email Address (Settings → General, the WordPress admin_email option). This is intentionally not a Returns setting. To send return notices elsewhere, change the site admin email, or route that address with an SMTP/forwarding plugin. The email is plain text and sent through wp_mail, so deliverability depends on your WordPress mail setup.

What is fixed by design

A few behaviours are not settings, because they keep the flow correct:

• One return per order. Once a request exists for an order, the link is hidden and a notice explains a return already exists.
• Logged-in owners only. The action shows only to the order’s owner, and ownership is re-checked on submit.
• The five reasons in the dropdown (arrived damaged or faulty, wrong item received, no longer needed, size or fit issue, other) are built in and not editable from the admin in the free edition.
• No money moves. Setting a status to Completed does not refund the order; the status box says so. Process refunds in the WooCommerce order screen.

Defaults at a glance

Setting	Option key	Default
Enable returns	enabled	On
Eligible order statuses	eligible_statuses	Completed, Processing
Return window (days)	window_days	30 (0 = unlimited)

After changing anything, open My Account → Orders as a test customer to confirm the action appears (or is correctly hidden) for the orders you expect.

Developer hook

When you change a request’s status in wp-admin, Returns fires an action, but only when the status actually changes to a new, valid value. This is the seam Returns Pro uses to email the customer on status changes:

add_action( 'returns/status_changed', function ( int $post_id, string $status, string $previous ): void {
    // $status / $previous are 'requested' | 'approved' | 'rejected' | 'completed'.
    // e.g. notify the customer that their return was approved.
}, 10, 3 );

Storage and cleanup

Settings live in the single returns_settings option; a returns_db_version option tracks the schema. Deleting the plugin runs uninstall.php, which removes both options. Submitted Return Request records (the returns_rma custom post type) are deliberately left in place, they are merchant records that should survive a reinstall. Remove them by hand from the Return Requests list if you want them gone. Everything stays in your own database; Returns contacts no external service.