EU Withdrawal Compliance

From June 19, 2026, EU Directive 2023/2673 obliges every online retailer in the European Union to offer a digital withdrawal function that is at least as easy to use as the purchase flow itself. Most plugins in the directory stop at “a button”. This one ships the complete toolkit every EU store needs to comply — and a few things competitors don’t offer at any price.

The plugin helps you implement the right of withdrawal requirements of Directive 2011/83/EU on consumer rights, as amended by Directive (EU) 2019/2161 (the Omnibus Directive).

Only this plugin in the directory ships, all of it, for free

• Two-step confirmation function (Art. 11a(3)) — the EU-wide baseline of the online withdrawal right. The public form leads to a review screen with a read-only summary and a dedicated “Confirm withdrawal” button; the request is registered only when that button is pressed, preventing the unintended exercise of the right. Held server-side between the two steps in a single-use token, so it works even without JavaScript.
• Complete durable-medium acknowledgement of receipt (Art. 11a(4)): the confirmation email reproduces the full content of the declaration (name, order, order date, scope, affected products) and the exact date and time of submission, carrying a verifiable SHA-256 receipt hash as tamper-evident proof — recomputable from the stored fields if a dispute arises.
• Annex I.B model withdrawal form (Directive 2011/83/EU) generated dynamically from your shop data, rendered as a collapsible block below the public form, with a printable view on the same URL. Meets the pre-contractual information obligation of Art. 6(1)(h).
• Double-consent checkboxes at the WooCommerce checkout for the two consents the directive expects to apply specific exceptions:
  • Mandatory consent for digital content (Art. 16(m)) — blocks the place-order step until accepted.
  • Optional consent for services started within the 14-day window (Art. 14(4)(a)) — enables pro-rated billing if the customer later withdraws.
    Every consent is persisted on the order with the exact text shown, accepted/declined state, timestamp, IP and user agent — durable proof in case of dispute.

  Public-facing pieces

  • Public withdrawal page automatically created on activation with a neutral, translation-ready template and the form embedded via shortcode, ready to publish and with the reminder to review it with a legal advisor kept in the dashboard instead of in the page itself.
  • [ayudawp_withdrawal_form] shortcode for embedding the form anywhere on the site.
  • [ayudawp_withdrawal_link] shortcode for a permanent link to the withdrawal page from any widget area, footer or template part — helps meet the “clearly identifiable” requirement of Article 11a of Directive 2023/2673 without forcing a specific footer layout.
  • [ayudawp_withdrawal_excluded_notice] shortcode to place the excluded-product notice with page builders (Divi, Elementor, Bricks, ShopLentor) that render their own product template and skip the standard WooCommerce hooks.
  • HTML5-semantic form with HTML5 validation, honeypot anti-spam, escaped output, sanitized input and CSRF nonces.
  • Privacy-policy acceptance checkbox before submit, linked to the WordPress-configured Privacy Policy page.
  • Frontend and backend links generated by the plugin carry rel="noopener nofollow" to keep the site’s link equity contained.

  WooCommerce-specific pieces (auto-activated when WooCommerce is detected)

  • My Account → Right of withdrawal endpoint with a per-order “Withdraw” button shown while the order is in an eligible status, deep-linked to the form with the order pre-filled.
  • Request tracking for the customer: the same endpoint lists their own requests with date, order, scope, status, the note written when resolving them and the receipt code, and the order row shows the status of a request already open instead of an empty slot. Covers the requests they sent while signed in, including those registered without a matching order.
  • Withdrawal notice injected into transactional emails (processing, completed, customer invoice) with a direct link to the form pre-filled with the order number. Eligible order statuses configurable; admin emails never receive the notice.
  • Automatic verification of the order/email pair when WooCommerce is active: the request is matched to a real order and gated by the configured eligible statuses. The 14-day deadline is surfaced as an advisory flag for the admin, not an automatic rejection (the period legally runs from delivery, which the shop verifies).
  • Optional “Accept unmatched requests” mode: register requests that do not match any order as Unverified for manual review instead of rejecting them upfront, highlighted across the admin (notification email, list badge, detail warning and CSV column). Off by default.
  • Configurable advisory deadline: choose order date vs. WooCommerce completion date as the basis, plus optional grace days, for the deadline flag surfaced to the admin — all from the settings UI, no code.
  • Order-number compatibility with Sequential Order Numbers (free and Pro) and Custom Order Numbers for WooCommerce (both Tyche and WPFactory) out of the box, plus a filter to add any other numbering plugin or resolver.
  • “Withdrawal” column on the WooCommerce orders screen (legacy and HPOS) showing the status of any linked request, toggleable from Screen Options.
  • Private order notes added at every lifecycle step (request received, accepted, rejected, completed) including any admin comment.
  • HPOS-compatible from day one, declared via FeaturesUtil::declare_compatibility().

  Admin tooling

  • Full request log as a private custom post type with status lifecycle (pending → accepted → rejected → completed), customer details, scope (full / partial), IP, user agent and UTC submission timestamp for legal traceability.
  • CSV export of the request log for accounting and consumer-protection audits: an “Export to CSV” bulk action on the listing plus a filtered export by status and date range under Withdrawals → Export withdrawals. Columns include submission and resolution timestamps, scope, status, acknowledgement-delivery flag, receipt hash and excluded items, with cells escaped against CSV/formula injection.
  • Audit trail per request: resolution timestamp recorded on every status change and a flag for whether the acknowledgement email was accepted for delivery (with its timestamp), both shown in the request detail and the CSV as burden-of-proof evidence.
  • Bulk actions to mark several requests as accepted, rejected or completed at once, with email notification on transition.
  • Status metabox with required comment when rejecting, optional comment when completing — comment forwarded to the customer email.
  • Acknowledgement email to the customer on confirmation: the Art. 11a(4) durable-medium receipt with the full declaration content, the date and time of submission and the SHA-256 hash as proof, plus a follow-up email on every status transition.
  • Notification email to the shop admin with reply-to set to the customer, sanitized against header injection.
  • Captured checkout consents surfaced in the request detail metabox: exact text, accepted/declined state, timestamp, IP, user agent — durable proof on file.
  • Consistent admin menu: always a top-level Withdrawals menu with a Settings submenu, regardless of whether WooCommerce is active. Same path on every install.
  • Legal disclaimer block in the settings page making it explicit that the plugin provides optional technical tools and does not guarantee legal compliance.
  • Mandatory / Recommended / Optional tags on every setting description so the merchant can scan the form quickly.

  Multilingual stores: WPML and Polylang

  Compliance cannot depend on the language the customer was browsing in, so both plugins are supported natively, with nothing to configure:

  • Set the withdrawal status once, on the product or category in your original language, and it holds across every translation: excluded-product notice, Art. 16(m) and Art. 14(4)(a) checkout consents, and excluded items recorded on the order. An explicit status on a translation still wins, for per-language exceptions.
  • Every link follows the visitor’s language: withdrawal page, printable Annex I.B view, button in the WooCommerce emails, excluded-notice link and [ayudawp_withdrawal_link] shortcode.
  • Your own texts stay translatable, with no snippets: a bundled wpml-config.xml exposes the notice titles and bodies, the form intro, the consent texts and the trader address under String Translation, copies the withdrawal status to translations, and marks the request log as non-translatable.

  The plugin’s own strings arrive as language packs per locale. See the FAQ for the current limitation on the plugin’s emails.

  Built for production

  • Conditional asset loading: CSS only loads on the withdrawal page, single-product pages that actually show the excluded notice, and plugin admin screens.
  • Translation-ready: Spanish (es_ES) and every other locale are delivered as language packs from translate.wordpress.org, so they update on their own. Follows WordPress Coding Standards, fully escaped output and sanitized input, capability checks and nonces on every admin action.
  • 11 documented filters and 4 actions for developers and agencies to extend the plugin without forking.
  • PHP 7.4+, WordPress 6.0+, WooCommerce 7.0+ (optional).

  Read the full description on the official page →