EU Withdrawal Compliance

It does not auto-reject based on it. The 14-day withdrawal period legally runs from the moment the goods are delivered (or, for digital content, from the start of the download) — a date the shop cannot detect automatically — so rejecting a request on the order or completion date would risk turning away customers who are still within their legal window. Instead, the plugin flags requests that look past the approximate window in the admin notification email and lets you verify the real delivery date (for example from the carrier tracking) and decide. Eligibility for the form, the My Account button and the email notice is governed by the configured order statuses. You can still tune the advisory calculation (order date vs. completion date, plus grace days) under Withdrawals → Settings, and the ayudawp_euw_grace_days filter keeps working; the ayudawp_euw_skip_deadline_check filter no longer has any effect, since there is no longer a deadline gate to skip. If your shop’s start date is reliable (services and digital content, where the period runs from the contract date, or shop pickup and predictable carriers), you can switch the Deadline enforcement setting from Advisory to Strict, which hides the button and blocks new requests once the deadline plus grace days has passed; Advisory remains the default and the safe choice for goods with unpredictable delivery.

The plugin uses a single Withdrawal status dropdown set per category and per product.

1. By category: go to Products → Categories, edit the category and pick a “Withdrawal status” — for example Other Article 16 exception for perishable or custom-made goods, or Digital content (Art. 16(m)) for sealed digital content. Every product in that category (and its descendant categories) will inherit the status automatically.
2. By product: edit the product, scroll to the General tab and pick the “Withdrawal status” there. By default it is set to — Inherit from category; pick any other option (including Standard) to override the inheritance for that product only.

The four possible statuses are:

• Standard — withdrawal applies normally (default).
• Digital content (Art. 16(m)) — product is excluded from the withdrawal right, and a mandatory consent checkbox is shown at the WooCommerce checkout for any cart containing the product.
• Service started early (Art. 14(4)(a)) — withdrawal still applies, and an optional consent checkbox is shown at checkout so the trader can charge a pro-rated amount if the customer withdraws after the service has started.
• Other Article 16 exception — product is excluded (perishable, custom-made, hygiene-sealed, sealed audio/video/software media unsealed after delivery, etc.), no checkout consent needed.

When a withdrawal request lands on an order containing excluded items, the plugin flags it in the admin notification email and on the request detail screen. The request is never auto-rejected, because a partial withdrawal over the non-excluded items in the same order can still be valid. The admin reviews and decides.

If the Excluded products notice is enabled (default: yes), a configurable notice will also appear on the single product page between price and add-to-cart button so the consumer reads it before purchasing.

Upgrading from earlier versions: any category that was previously listed in the retired “Excluded categories” picker is migrated automatically to the new per-category dropdown (with status Other Article 16 exception) on the next admin request. No configuration is lost.

Page builders such as Divi, Elementor, Bricks or ShopLentor render their own single-product template and skip the standard WooCommerce hook (woocommerce_single_product_summary) where the plugin injects the excluded-product notice, so it does not appear automatically. Drop the [ayudawp_withdrawal_excluded_notice] shortcode into your product layout (most builders have a “Shortcode” element) and the notice will print for the current product whenever that product is flagged as excluded. With no attributes it resolves the product being viewed; pass id="123" to target a specific product.

The plugin can inject two consent checkboxes at the WooCommerce checkout when the cart contains products flagged for them:

• Type A (mandatory, Art. 16(m)): digital content. The customer must accept it to complete the order; without acceptance recorded, the customer keeps the 14-day withdrawal right even after accessing the content.
• Type B (optional, Art. 14(4)(a)): services started within the 14-day window. If accepted, the trader may charge a pro-rated amount when the customer withdraws after the service has started. Without it, an early withdrawal forces a full refund.

Each flag is set per product (General tab) or per category (Edit Category screen), with full subcategory inheritance — the same hierarchy used by the Article 16 exclusions module. The exact text shown to the customer, plus accepted/declined state, timestamp, IP and user agent, is persisted on the order so the trader has durable proof if the customer later contests the request. The metabox of each withdrawal request also surfaces these consents for the linked order.

The two checkboxes can be enabled/disabled globally from Withdrawals → Settings → Checkout consent, and their text is fully editable.

The right of withdrawal protects consumers (natural persons acting outside their trade or profession), not business buyers, but the plugin never decides that for you. Enable Consumer self-declaration under Withdrawals → Settings → Public withdrawal form and the form shows a required checkbox where the buyer declares they purchased as a consumer; a business that cannot declare it self-excludes, and the declaration is stored with the request as proof. It is off by default. Use the consumer_check="yes" shortcode attribute to force it on a specific landing page, or the ayudawp_euw_show_consumer_check filter for custom logic (VIES validation, a customer-type field, etc.).

Yes. The plugin renders the Annex I.B model form dynamically from the shop name, address (from WooCommerce when available) and notification email, with an optional trader phone configurable from settings. It appears as a collapsible block right below the public withdrawal form, with a printable view available from the same page. Providing this model is a pre-contractual information obligation under Art. 6(1)(h) of Directive 2011/83/EU — the online function added by Directive 2023/2673 complements but does not replace it.

It is a SHA-256 hash computed from the request data (post ID, customer name, email, order reference, scope, order date and submission timestamp). The customer keeps the email as a tamper-evident proof on a durable medium. If a dispute later arises, you can recompute the hash from the stored fields with the ayudawp_euw_compute_receipt_hash() helper and confirm the original submission was not altered.

Each request is saved as a private custom post type entry called ayudawp_withdrawal. You can manage them under the top-level Withdrawals menu in your admin area. They are not publicly accessible from the frontend.

Yes, from Withdrawals → Settings → Permissions. Because each request stores personal data (name, email, IP), you pick which user roles, besides the administrator, may view and manage them. The administrator always has access and cannot be unticked. On sites updating from an earlier version, the roles that could already see requests (typically Editor, and Shop manager on WooCommerce) keep their access so nothing breaks; you then untick any you want to remove. New installs start administrator-only.

Yes. The plugin declares HPOS compatibility on load.

Yes. The form, shortcode, withdrawal request log, email notifications, SHA-256 receipt hash and native GDPR integration all run as a standalone tool, with their own top-level Withdrawals menu in the admin and a Settings submenu. The plugin layers extra features on top automatically when WooCommerce is active: order/email validation gated by eligible order statuses (with an advisory deadline flag for the admin), “My Account” withdrawal endpoint, withdrawal notice injected into transactional emails, “Withdrawal” column in the orders screen, private order notes on every status change, and Article 16 exclusions by product/category. Activating WooCommerce later lights those features up; deactivating it leaves the standalone features intact.

Yes. The form accepts both the internal WooCommerce order ID and the displayed order number. The resolver checks a list of known meta keys: the standard _order_number and _order_number_formatted (WooCommerce Sequential Order Numbers, free and Pro), plus _alg_wc_full_custom_order_number and _alg_wc_custom_order_number (Tyche / WPFactory “Custom Order Numbers for WooCommerce”). Add other numbering plugins with the ayudawp_euw_order_number_meta_keys filter; for schemes computed on the fly (e.g. YITH Sequential Order Number, custom integrations), short-circuit the lookup with the ayudawp_euw_pre_resolve_wc_order filter.

No. By default the notice is only added to the customer-facing emails relevant to the withdrawal window: order processing, completed and customer invoice (the manually triggered one). Admin emails never receive the notice. The notice is also gated by the configured list of eligible order statuses (default: Processing and Completed) so the manual invoice email only carries it when the order is in one of those statuses. You can change the email list with the ayudawp_euw_email_ids filter and the status list under Withdrawals → Settings → Eligible order statuses or with the ayudawp_euw_allowed_statuses filter.

Yes. Return an empty array from the ayudawp_euw_email_ids filter to remove the notice block (heading, text and button) from every order email:

add_filter( 'ayudawp_euw_email_ids', '__return_empty_array' );

This only affects the emails: the My Account button, the public form and the site footer link keep working, so the withdrawal function stays accessible as Article 11a requires. You can then add your own, more discreet wording with a plain link using WooCommerce’s per-email Additional content field (WooCommerce → Settings → Emails, then open each email such as Processing order or Completed order). Because it is set per email, your link appears only where you add it. Point it to your withdrawal page, and if you want to keep the order number pre-filled, add the {order_number} placeholder to the link, for example .../withdrawal/?order_id={order_number}. Do keep some reference in the order confirmation email: it is the contract confirmation on a durable medium, so the withdrawal information should stay reachable from it, just not necessarily as a prominent button.

All strings are translation-ready. Translations are managed through the official WordPress.org platform at translate.wordpress.org, so any locale with enough translated strings is delivered automatically to your site when the WordPress site language matches. Contributions to existing or new locales are welcome there.

The plugin asks for explicit privacy policy acceptance before submission and stores the visitor IP and user agent only for the purpose of legal traceability of the request. See the Privacy section above for the full list of stored fields. The plugin also integrates natively with the WordPress GDPR tools: a suggested Privacy Policy snippet appears in Settings → Privacy → Policy Guide, and withdrawal data is exposed to Tools → Export Personal Data and Tools → Erase Personal Data so admins can fulfil access and erasure requests without leaving the WordPress admin.

The withdrawal log is independent of the WordPress user table — it lives as a private custom post type indexed by the customer email. Deleting the user account does not delete the log automatically; the customer must request erasure through Tools → Erase Personal Data (where the plugin registers an eraser that removes every withdrawal request matching the customer email) or you can delete the corresponding ayudawp_withdrawal entries manually if your retention policy requires it.

Yes. From Withdrawals → Settings → Withdrawal emails you can set the sender (“From name” and “From address”) for the plugin’s emails and edit the body of the accepted, rejected and completed status emails; left empty, each text falls back to the bundled default. The admin notification can be tailored with the ayudawp_euw_admin_email_lines filter, and all strings remain translatable through the standard WordPress text-domain. The emails are sent in plain text; HTML templates that inherit the WooCommerce email theme are planned for a later release.

Filters:

• ayudawp_euw_grace_days — extra days added to the 14-day deadline. The default is the value stored in settings; the filter receives that value, so returning $days + N adds on top of it.
• ayudawp_euw_skip_deadline_check — retained for back-compat but no longer has any effect: the deadline is advisory and never gates a submission, so there is nothing to skip.
• ayudawp_euw_email_ids — array of WooCommerce email IDs where the withdrawal notice is injected.
• ayudawp_euw_allowed_statuses — array of order statuses (without the wc- prefix) for which the withdrawal button and email notice are offered. Receives the value stored in settings and the current WC_Order (when available).
• ayudawp_euw_allow_unverified_order — return true to accept submissions whose order number cannot be matched against a real WooCommerce order. Useful for sites that also handle non-WC purchases.
• ayudawp_euw_pre_resolve_wc_order — short-circuit the order resolver. Return a WC_Order instance to accept, false to reject, or null (default) to fall through to the built-in strategies. Useful for plugins that store the displayed order number outside the standard _order_number post meta (e.g. YITH Sequential Order Number, custom ERP integrations).
• ayudawp_euw_resolve_wc_order — late filter that receives the resolved WC_Order (or false) and the raw reference, for auditing or last-chance overrides.
• ayudawp_euw_order_number_meta_keys — the list of order post-meta keys checked when matching a typed order number, in priority order. Add your numbering plugin’s meta key.
• ayudawp_euw_admin_email_lines — the array of lines of the admin notification email, just before they are joined, with the request context (post ID, name, email, order, scope, details) as the second argument. Add, remove or reorder lines.
• ayudawp_euw_validation_result — the order/email validation result before the request proceeds. Return valid => false with an error code to reject a submission, for example from a captcha integration.
• ayudawp_euw_show_consumer_check — whether the optional “bought as a consumer” checkbox is shown, with the current field values, so an integrator can decide per order (VIES validation, a customer-type field, etc.).

Actions:

• ayudawp_euw_after_submission — fires after a withdrawal request has been processed. Arguments: CPT ID, submission data array.
• ayudawp_euw_after_status_change — fires after a status change (individual or bulk). Arguments: CPT ID, new status, optional admin comment.
• ayudawp_euw_after_form — fires inside the public form wrapper, right after the </form> tag, so modules can inject content below the form without coupling. No arguments. Used internally by the Annex I.B model form.
• ayudawp_euw_form_before_submit — fires inside the form, right before the submit button, so an integrator can render a captcha/anti-spam widget or an extra field whose value is posted with the form. Arguments: current pre-fill values, lock flag.

The plugin covers the functional requirements that Directive 2023/2673 imposes EU-wide from 19 June 2026: a discoverable digital withdrawal function, eligibility by order status with an advisory deadline flag, Article 16 exclusions with subcategory inheritance, durable-medium proof via the SHA-256 receipt hash, the model form from Annex I.B of Directive 2011/83/EU and the double-consent checkboxes at checkout that enable the Art. 16(m) and Art. 14(4)(a) exceptions. On top of that it adds operational tools that the directive does not mandate but that make handling requests practical: per-status email injection, status lifecycle with bulk actions, native GDPR integration, public notice on excluded products and full traceability. Member States can layer extra national requirements on top of the EU baseline — the two-step confirmation flow with an intermediate review page expected by the strictest member states (Germany, for example) is built in; a future release will adapt to any further requirement in the final Spanish Real Decreto once it is published. Legal compliance ultimately depends on your business model, catalog and jurisdiction; the plugin provides the technical building blocks, not legal advice — consult a consumer-law specialist for your specific case.