EU Withdrawal Compliance vs WP Consent API

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. Single “Withdrawal status” dropdown per product and per category with four explicit options (Standard, Digital content, Service started early, Other Article 16 exception). Drives both the Article 16 exclusion flag and the matching checkout consent in one place, with full subcategory inheritance. Configurable public notice on excluded products, rendered between price and add-to-cart, with separate title+body for digital content and other Article 16 exceptions. Article 16 exclusions with category inheritance — competing plugins gate this behind a paid Pro tier; here it’s free. Native GDPR integration: suggested Privacy Policy snippet + personal-data exporter + eraser, all keyed on the customer email — no second GDPR plugin to install. Standalone mode: the form, shortcode, request log, email notifications, SHA-256 receipt hash, Annex I.B model and GDPR integration all run without WooCommerce. The plugin always lives in its own top-level Withdrawals menu (with a Settings submenu), with or without WooCommerce — same path on every install. 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). Why this plugin? The EU directive becomes enforceable in every member state on June 19, 2026, so the WordPress.org directory is filling up with “withdrawal button” plugins. This one stands out for verifiable reasons: Fully free, no paid tier. No premium add-on, no feature locked behind an upsell, no “Pro” version on the horizon. Everything documented on this page is what you get on install. Two-step “confirm withdrawal” function built in, the EU-wide baseline of Article 11a(3): the public form shows a read-only review screen and registers the request only after explicit confirmation, fully server-side and working without JavaScript — where many “button-only” plugins register the request on the very first click. The only plugin in the directory that issues a SHA-256 receipt hash as durable-medium proof of every withdrawal request, recoverable from the stored fields if a dispute later arises. The only plugin in the directory that ships the Annex I.B model withdrawal form dynamically generated from the shop data, with a printable view — meeting the Art. 6(1)(h) information obligation that the new directive does not replace. The only plugin in the directory that injects the two consent checkboxes (Art. 16(m) digital content and Art. 14(4)(a) service started early) at the WooCommerce checkout, with durable proof persisted on the order. The only plugin in the directory that ships Article 16 product/category exclusions with full subcategory inheritance — competing plugins gate this behind their own paid Pro tier. Native integration with the WordPress GDPR tools (Privacy Policy snippet + personal-data exporter and eraser) — no second GDPR plugin to install. Standalone or with WooCommerce. Works without WooCommerce as a self-contained tool (form, shortcode, log, emails, SHA-256, GDPR, Annex I.B) and lights up store-specific features automatically when WooCommerce is detected. Compatible by default with Sequential Order Numbers (free and Pro) and Custom Order Numbers for WooCommerce (Tyche and WPFactory), with a filter for any other numbering scheme. Real multilingual support (WPML, Polylang): exclusions and checkout consents configured once hold across every translation, and your editable texts are translatable from String Translation. Configurable from the settings UI, without writing code: deadline basis (order date vs. completion date) and grace days plus an optional strict deadline mode, eligible order statuses, withdrawal page, notification email (now accepting several recipients), email sender and editable status-email texts, consent text per type, excluded-notice text per type, editable form intro, optional B2B consumer self-declaration, Annex I.B trader address/phone/email, and which roles may manage requests. Developer-friendly: 11 documented filters + 4 actions so agencies can extend it without forking. Maintained by a Spanish WordPress trainer with 20+ years on the platform: es_ES translation kept up to date by the author on the official WordPress.org translation platform, prompt replies on the WordPress.org support forum and an active roadmap of free improvements (classic widget, Gutenberg block, dashboard widget, custom WC order status and more — all free). Roadmap Planned for upcoming free versions: WooCommerce Checkout block support for the Art. 16(m) and Art. 14(4)(a) consents, for stores already migrated away from the classic checkout shortcode. HTML email templates inheriting the WooCommerce email theme, and plugin emails composed in the customer’s own language on multilingual stores. Gutenberg block and classic widget for the withdrawal link. Custom WooCommerce order status “Withdrawal requested”, with automatic transition on acceptance. PDF download of the request with the SHA-256 receipt hash printed on it. Dashboard widget with counters, pending requests and monthly stats. Privacy This plugin stores the following personal data for each withdrawal request, exclusively to fulfil the legal traceability of consumer rights and to allow the shop to handle the request: Customer name and email address (required to contact the consumer about the request). Order reference and order date (required to validate the request against the purchase). IP address and User-Agent string (required to evidence when and how the request was submitted, in line with the directive’s “durable medium” requirement). Submission timestamp (UTC) and SHA-256 receipt hash (required to recompute and verify the integrity of the original submission if disputed). Data is stored as a private custom post type entry (ayudawp_withdrawal) accessible only to administrators. The plugin does not transmit any data to third-party services; all communication happens between the shop and the customer via standard WordPress emails. You should add a section to your site’s privacy policy describing this storage. The plugin contributes a suggested Privacy Policy snippet that you can paste from Settings → Privacy → Policy Guide. Withdrawal data is also exposed to the native WordPress Tools → Export Personal Data and Tools → Erase Personal Data screens (filtered by customer email). Support Need private support or custom development? Do you need one-on-one help, priority troubleshooting, or a custom feature, integration, or tweak built specifically for your site? I offer private support and custom development. Just contact me and tell me what you need. Need help or have suggestions? Official website WordPress support forum YouTube channel Documentation and tutorials Love the plugin? Please leave us a 5-star review and help spread the word! About AyudaWP.com We are specialists in WordPress security, SEO, AI and performance optimization plugins. We create tools that solve real problems for WordPress site owners while maintaining the highest coding standards and accessibility requirements.

WP Consent API is a plugin that standardizes the communication of accepted consent categories between plugins. It requires a cookie banner plugin and, at least, one other plugin that supports the WP Consent API. With this plugin, all supporting plugins can use the same set of methods to read and register the current consent category, allowing consent management plugins and other plugins to work together, improving compliance with privacy laws. WARNING: the plugin itself will not handle consent. It will show you how many plugins you have without Consent API support and will improve compliance on your site by ensuring smooth communication between cookie banner plugins and plugins that set cookies or track user data. What problem does this plugin solve? Currently, it is possible for a consent management plugin to block third-party services like Facebook, Google Maps, Twitter, etc. But if a WordPress plugin places a PHP cookie, a consent management plugin cannot prevent this. Secondly, some plugins integrate the tracking code on the clientside in javascript files that, when blocked, break the site. Or, if such a plugin’s javascript is minified, causing the URL to be unrecognizable and won’t get detected by an automatic blocking script. Lastly, the blocking approach requires a list of all types of URL’s that tracks data. A generic API where plugins adhere to can greatly facilitate a webmaster in getting a site compliant. Does usage of this API prevent third-party services from tracking user data? Primary this API is aimed at compliant first-party cookies or tracking by WordPress plugins. If such a plugin triggers, for example, Facebook, usage of this API will be of help. If a user embeds a Facebook iframe, a blocking tool is needed that initially disables the iframe and or scripts. Third-party scripts have to blocked by blocking functionality in a consent management plugin. To do this in core would be to intrusive, and is also not applicable to all users: only users with visitors from opt-in regions such as the European Union require such a feature. Such a feature also has a risk of breaking things. Additionally, blocking these and showing a nice placeholder requires even more sophisticated code, all of which should in my opinion not be part of WordPress core, for the same reasons. How does it work? There are two indicators that together tell if consent is given for a specific consent category, e.g., “marketing”: 1) the region based consent_type, which can be opt-in, opt-out, or other possible consent_types; 2) and the visitor’s choice: not set, allow, or deny. The consent_type is a function that wraps a filter, “wp_get_consent_type”. If there’s no consent management plugin to set it, it will return false. This will cause all consent categories to return true, allowing cookies to be set on all categories. If opt-in is set using this filter, a category will only return true if the value of the visitor’s choice is “allow”. If the region based consent_type is opt-out, it will return true if the visitor’s choice is not set or is “allow”. Clientside, a consent management plugin can dynamically manipulate the consent type and set several cookie categories. A plugin can use a hook to listen for changes or check the value of a given category. Categories and most other stuff can be extended with a filter. Existing integrations Categorized, and sorted alphabetically Example plugin Example plugin. The plugin basically consists of a shortcode, with a div that shows a tracking or not tracking message. No actual tracking is done 🙂 Consent Management Providers Abconsent Sirdata CMP. Beautiful Cookie Consent Banner. Clickio Consent Cookie Consent CMP. Complianz GDPR/CCPA. Consent Studio. consentmanager. Conzent. Cookiebot. CookieFirst. CookieHub. CookieTractor. CookieYes – Cookie Banner for Cookie Consent. GDPR Cookie Compliance. GDPR Cookie Consent Plugin – CCPA Ready. GetTerms. iubenda | All-in-one Compliance. Lawwwing. Pressidium Cookie Consent. TrustArc Cookie Consent Manager Consent Requiring Plugins AddToAny. AFL UTM Tracker Plugin. Burst Statistics. Google Site Kit. Pixel Manager for WooCommerce. Woo. WP Statistics. Demo site wpconsentapi.org Below are the plugins used to set up the demo site: Complianz The example plugin javascript, consent management plugin //set consent type window.wp_consent_type = 'optin' //dispatch event when consent type is defined. This is useful if the region is detected server side, so the consent type is defined later during the pageload let event = new CustomEvent('wp_consent_type_defined'); document.dispatchEvent( event ); //consent management plugin sets cookie when consent category value changes wp_set_consent('marketing', 'allow'); javascript, tracking plugin //listen to consent change event document.addEventListener("wp_listen_for_consent_change", function (e) { var changedConsentCategory = e.detail; for (var key in changedConsentCategory) { if (changedConsentCategory.hasOwnProperty(key)) { if (key === 'marketing' && changedConsentCategory[key] === 'allow') { console.log("just given consent, track user") } } } }); //basic implementation of consent check: if (wp_has_consent('marketing')){ activateMarketing(); console.log("set marketing stuff now!"); } else { console.log("No marketing stuff please!"); } PHP //declare compliance with consent level API $plugin = plugin_basename( __FILE__ ); add_filter( "wp_consent_api_registered_{$plugin}", '__return_true' ); /** * Example how a plugin can register cookies with the consent API * These cookies can then be shown on the front-end, to the user, with wp_get_cookie_info() */ function my_wordpress_register_cookies(){ if ( function_exists( 'wp_add_cookie_info' ) ) { wp_add_cookie_info( 'AMP_token', 'AMP', 'marketing', __( 'Session' ), __( 'Store a unique User ID.' ) ); } } add_action('plugins_loaded', 'my_wordpress_register_cookies'); if (wp_has_consent('marketing')){ //do marketing stuff } Service-level consent In addition to category-based consent, the API supports service-level consent control. This allows consent management plugins to grant or deny consent for specific services (like ‘google-analytics’ or ‘facebook-pixel’) independently from their category. When checking service consent with wp_has_service_consent(), the API first checks if explicit consent exists for that service. If no explicit consent is set, it falls back to the consent status of the service’s category. This enables fine-grained control: a user might accept statistics cookies in general, but explicitly deny a specific analytics service. Service consent can be checked and set both server-side (PHP) and client-side (JavaScript): PHP: //check if a specific service has consent if ( wp_has_service_consent( 'google-analytics' ) ) { //activate google analytics } //check if a service is explicitly denied if ( wp_is_service_denied( 'facebook-pixel' ) ) { //service was explicitly denied by user } //set service consent wp_set_service_consent( 'google-analytics', true ); //grant consent wp_set_service_consent( 'facebook-pixel', false ); //deny consent //listen for service consent changes add_action( 'wp_consent_service_changed', function( $service, $consented ) { error_log( "Service {$service} consent changed to: " . ( $consented ? 'granted' : 'denied' ) ); }, 10, 2 ); JavaScript: //check service consent if ( wp_has_service_consent( 'youtube' ) ) { //activate tracking } //check if explicitly denied if ( wp_is_service_denied( 'facebook-pixel' ) ) { //service denied } //set service consent wp_set_service_consent( 'youtube', true ); //listen for service consent changes document.addEventListener( 'wp_consent_api_status_change_service', function( e ) { console.log( 'Service: ' + e.detail.service + ', consented: ' + e.detail.value ); }); Any code suggestions? We’re on GitHub as well!