EU Withdrawal Compliance

Yes, when WooCommerce is active. If the order is older than the configured window the plugin rejects the request with a clear message. You can configure the calculation basis (order date vs. completion date) and add extra grace days directly from Withdrawals → Settings. The legacy ayudawp_euw_grace_days and ayudawp_euw_skip_deadline_check filters still work for programmatic overrides.

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.

• 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, etc.), no checkout consent needed.

From version 1.5.0 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.

Yes, from version 1.5.0. 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. 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 with the 14-day deadline, "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 looks up the customer-facing number in the standard _order_number post meta, which covers WooCommerce Sequential Order Numbers (free and Pro), Custom Order Numbers for WooCommerce (WPFactory) and any plugin that follows the same convention. For plugins that store the number elsewhere or compute it on the fly (e.g. YITH Sequential Order Number, custom integrations), use the ayudawp_euw_pre_resolve_wc_order filter to provide your own resolver.

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.

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. From version 1.4.0 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.

Currently the emails are sent in plain text and their copy is translatable through the standard WordPress text-domain. HTML email templates that respect the WooCommerce email theme are planned for a later release. For now, advanced customisation requires hooking into the wp_mail filters.

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 — return true to disable the deadline check entirely. Receives the WC_Order as second argument.
• 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_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.

The plugin covers the functional requirements that Directive 2023/2673 imposes EU-wide from 19 June 2026: a discoverable digital withdrawal function, deadline validation, 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) ships since version 1.7.0; 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.