WooCommerce EU Withdrawal Button: GDPR Checklist

Key Takeaways

WooCommerce 11.1, announced on 18 August 2026 and due to ship on 1 September 2026, adds a native EU right-of-withdrawal flow. The release notes are explicit that a customer "can request a withdrawal from a new My Account page /my-account/withdraw-order/, no auth required."
The feature is disabled by default and must be turned on under WooCommerce → Settings → Advanced → Features. That makes this a decision you get to make deliberately rather than a change that happens to you.
Requests that match no order are not discarded. WooCommerce's Tom Cafferkey confirmed that matching requests become an order note, while "Requests that don't match are still accepted and flagged for manual review" — a store of personal data about people you cannot match to any order.
The Article 30(5) small-business derogation will not save you here. It falls away when processing "is not occasional", and a withdrawal function that has to stay available throughout the withdrawal period — as the sources below describe Article 11a requiring — is not occasional processing.
The consumer-law obligation has applied since 19 June 2026. What is new on 1 September is not the duty but a specific implementation of it — and the release notes raise no data-protection question about it at all.

Introduction

Somewhere in your admin, on or shortly after 1 September, a new toggle will appear under Advanced → Features. Flipping it publishes a page on your storefront that any person on the internet can load, type an order number and an email address into, and submit — no account, no login. It is a good feature, built to satisfy a real legal obligation, and most merchants will enable it in about four seconds.

The four seconds are the problem. Not because the feature is dangerous, but because switching it on creates a new processing activity — a new collection point, a new retention question, and a new thing to write down — and nothing in WooCommerce's release notes tells you so. This article covers what actually ships, which parts are your responsibility rather than the platform's, and the specific checks worth running before the toggle goes green.

This is informational content, not legal advice.

What WooCommerce 11.1 Actually Ships

WooCommerce published the 11.1 pre-release notes on 18 August 2026, with final release scheduled for 1 September 2026. The relevant line is short: "WooCommerce 11.1 brings the right of order withdrawal functionality to better serve EU customers."

Three details in those notes carry all the compliance weight.

The endpoint is unauthenticated. A customer "can request a withdrawal from a new My Account page /my-account/withdraw-order/, no auth required." Despite living under My Account, it needs no session. That is a defensible choice — a guest shopper who never made an account still holds the withdrawal right — but it means the page is reachable by anyone.

Routing is to a human, not a workflow. "Submissions are then routed to merchants, who receive an email and an inbox notification to follow up with the customer." No automated eligibility engine stands between the form and your inbox.

It is opt-in. "Order withdrawal is disabled by default and must be enabled from WooCommerce → Settings → Advanced → Features."

What happens to a request that matches nothing

This is the detail worth slowing down for, and it comes from WooCommerce itself rather than inference. Replying to a merchant in the release-notes comments, WooCommerce's Tom Cafferkey explained: "When the submitted order number and billing email match an order, the request is recorded on that order as an order note, so it appears where merchants already work. Requests that don't match are still accepted and flagged for manual review."

Read that second sentence as a data-protection statement rather than a product one. A submission that matches nothing still contains an email address and whatever the sender typed. It is retained, it is queued for a human, and it belongs to a person your systems by definition cannot link to any customer record — so none of your customer-record retention rules reach it.

The design rationale is sound: a customer who mistypes an order number should not be silently dropped. But the consequence is a small, growing pile of personal data with no matching record, no obvious owner, and no documented expiry.

Yes. Collecting a name, an order reference and an email address through a web form, storing it, and routing it to staff for a decision is processing of personal data under the GDPR, and enabling the feature makes your store the controller for it. The obligation to offer withdrawal comes from consumer law; the obligation to handle the data properly is separate and yours.

To be fair to the people who have said this already: this is not an unnoticed point in the legal literature. Arnold & Porter, writing in May 2026, put it directly — "the withdrawal button is not merely a user experience feature; it is a data processing operation" — and flagged the need for a lawful basis, an Article 30 record and updated privacy notices. What no source appears to have done is connect that analysis to a shipped implementation. That gap is what this article is for.

Shopify's merchant guidance on EU withdrawal compliance confirms the same "New requirements taking effect on June 19, 2026" and tells merchants to provide "a clearly visible electronic withdrawal function, such as a button or link" — and, like WooCommerce's notes, never mentions GDPR or personal data. Our read: platform documentation is telling merchants how to satisfy consumer law and leaving data protection unaddressed. That is not a criticism of either company; it describes where the responsibility lands.

Which lawful basis applies

Article 6(1)(c) — processing "necessary for compliance with a legal obligation to which the controller is subject" — is in our view the cleanest fit, because offering the withdrawal function is a legal obligation. Directive (EU) 2023/2673 inserted a new Article 11a into the Consumer Rights Directive requiring it, and per Arnold & Porter it applies to "all businesses that sell online to EU consumers" from 19 June 2026.

This is not settled, and it would be dishonest to pretend otherwise. The same Arnold & Porter advisory reaches a different answer: "Article 6(1)(b) (performance of a contract) will generally apply, but the processing must be documented in Article 30 record of processing activity (ROPA) and privacy notices updated accordingly." Both readings are defensible — a withdrawal is an act under the sales contract, and offering the means to make it is a statutory duty. Our read: pick one, write down why, and be consistent between your record and your privacy notice. The choice you cannot defend is having made none.

Whichever you land on, two practical consequences follow, and they are why the basis matters rather than being paperwork:

You do not need consent, and you should not ask for it. A consent checkbox on a form that exists to satisfy a statutory duty misrepresents the relationship, and implies a right to withdraw consent that does not exist here.
The legal obligation defines the boundary. Data collected because the law requires the form is covered. Data collected because it is convenient — a phone number, a "reason for cancelling" box, a marketing opt-in — is not, and needs its own basis under Article 5(1)(c), which limits data to what is "adequate, relevant and limited to what is necessary".

That second point has an unusually firm backstop here, because consumer law is already policing it. Writing on the German implementation, Freshfields note that in the first step the consumer supplies "name, contract identification and an electronic address for confirmation" and that "additional mandatory fields are impermissible." Minimisation on this form is not only a GDPR principle to weigh — in at least one Member State's transposition, extra required fields are independently unlawful. The feature request that prompted WooCommerce's implementation summarised the rule the same way: "Only strictly necessary data may be requested."

What Goes in Your Article 30 Record

Article 30(1) requires a record of processing activities covering, among other things, "the purposes of the processing", "a description of the categories of data subjects and of the categories of personal data", "the categories of recipients", "where possible, the envisaged time limits for erasure of the different categories of data", and "where possible, a general description of the technical and organisational security measures".

Enabling the withdrawal form adds a row. Here is what that row honestly contains — including the entry most merchants will miss.

Record field	What to write
Purpose	Receiving and processing consumer withdrawal declarations under Art. 11a of the Consumer Rights Directive
Lawful basis	Art. 6(1)(c) legal obligation, or Art. 6(1)(b) contract — whichever you chose, stated once and used consistently
Categories of data subject	Customers; and any person who submits the form, including non-customers
Categories of data	Name, order reference, email address, submission timestamp, free-text content if enabled
Recipients	Store staff handling withdrawals; your email provider; your hosting provider
Retention	Separate periods for matched requests (attached to the order) and unmatched requests
Security measures	Rate limiting, anti-automation controls, access control on the review queue

The second row of that table is the one that catches people. Because unmatched submissions are retained, your data subjects are not simply "customers" — they include anyone who filled in the form, correctly or otherwise. A record that says "customers" is inaccurate on day one.

Before anyone reaches for the small-business exemption: Article 30(5) disapplies the record obligation only for organisations "employing fewer than 250 persons unless the processing it carries out is likely to result in a risk to the rights and freedoms of data subjects, the processing is not occasional, or the processing includes special categories of data". The feature request behind WooCommerce's implementation summarised the Art. 11a requirement as being "prominently displayed, clearly legible and easily accessible from the online interface, and continuously available throughout the withdrawal period". Processing that runs continuously by legal design is not occasional, so the derogation does not apply, and the 250-employee threshold never comes into it. If your record of processing activities lives in a spreadsheet named something like ropa_final_v3.xlsx, this is a reasonable moment to open it.

Three Risks the Release Notes Do Not Mention

1. Unmatched submissions have no purpose limitation

Once a submission fails to match an order, ask what it is for. It cannot serve the withdrawal purpose, because there is no contract to withdraw from. Under Article 5(1)(b) data must be "collected for specified, explicit and legitimate purposes", and under Article 5(1)(e) kept "no longer than is necessary for the purposes for which the personal data are processed". A queue of unresolvable requests satisfies neither once it has been reviewed.

Two things make this pile bigger than you would expect. Order numbers get mistyped. And the withdrawal right does not cover everything: the European Commission's guidance for businesses lists exceptions including "perishable goods (e.g. certain foodstuffs)", "sealed goods that cannot be returned for hygiene reasons after being opened", and "tailor-made goods developed according to the customer's specifications or clearly personalised". A customer who tries to withdraw from an ineligible order still hands you their data on the way to being told no.

Recommendation: set an explicit deletion period for reviewed unmatched submissions and write it down. A short window — long enough to handle a follow-up from someone who mistyped, short enough that the queue does not become an archive — is defensible. An indefinite queue is not. The trade-off is real: delete too fast and you lose the audit trail showing you responded promptly, which is why the period belongs in your record rather than in someone's habits.

2. Order number plus email is a lookup key

An unauthenticated form that behaves differently depending on whether an order exists is an oracle. Submit a plausible order number and an email address, watch the response, and you learn whether that person shops with that store — the kind of inference Article 32(2) has in mind when it asks controllers to weigh risks "from ... unauthorised disclosure of, or access to personal data".

This is not a theoretical objection dreamed up for an article, and the strongest evidence comes from someone who had to solve it. WebToffee ships a third-party EU Order Withdrawal Button plugin for WooCommerce — the same self-service flow, in production today. When a merchant on its WordPress.org support forum reported that guest withdrawal requests were not producing a verification email, the plugin's support engineer explained the design outright: "we intentionally keep the response generic for security and privacy reasons, as showing whether an order exists or is eligible could expose order information."

A vendor shipping this exact form treats identical responses as a security requirement. That is a clear signal about what "appropriate technical and organisational measures" under Article 32(1) look like on this page: uniform confirmation regardless of match, plus rate limiting.

On the same forum, another merchant asked "whether reCAPTCHA could be added to the order withdrawal request form for security purposes". Support replied that the flow already includes "an order eligibility check for registered users and an email verification step for guest users before the request is processed", and passed the suggestion on. Be precise about what this shows: it is one third-party plugin's design, not a defect in WooCommerce core, whose full behaviour will only be readable when 11.1 ships. What it establishes is that merchants running this flow are already asking for anti-automation controls, and the vendor answering them treats guest verification as part of the job.

3. The form is live to everyone, not just the EU

The withdrawal right belongs to EU consumers, but a public page has no borders. On the same plugin's support forum, a merchant reported: "The button appears for all customers, not just customers in the EU... It would be wonderful to at least be able to set it off for certain countries."

The compliance consequence is mundane but genuine: your privacy notice and your record of processing should describe who actually uses the form, which is everyone who can reach it, rather than the audience the law had in mind.

What to Do Before You Enable It

Decide the retention period for unmatched submissions first, before switching the feature on. Retrofitting a deletion rule onto a queue that already exists is harder than starting with one.
Add the processing activity to your Article 30 record, with "any person who submits the form" in the data-subject column — not just "customers".
Update your privacy notice with the new collection point, the lawful basis you chose — Art. 6(1)(c) or Art. 6(1)(b) — and the retention periods for matched and unmatched requests.
Test the response behaviour on a staging site once 11.1 lands: submit a real order, a mistyped order and a fabricated one, and confirm the three responses are indistinguishable.
Put rate limiting in front of the endpoint. This is ordinary hosting or WAF configuration, not a WooCommerce setting, and it is the single most effective control on the list.
Do not add fields. Resist the reason-for-cancelling box. It is extra personal data, it needs its own basis, and in the German transposition additional mandatory fields are impermissible.
Name an owner for the review queue. "Routed to merchants" means an email lands somewhere; someone has to act on it and clear it.

Common Mistakes

Treating the toggle as a compliance checkbox. Enabling the feature satisfies the consumer-law duty to offer a withdrawal function. It does not satisfy anything under the GDPR, and it creates work rather than removing it. This is the most common and the most expensive mistake on the list, because it feels like completion.

Assuming the platform is the controller. WooCommerce ships the code. You run the store, decide the settings, and hold the data. Under Article 5(2) you must "be responsible for, and be able to demonstrate compliance with" the principles — a burden that does not transfer to whoever wrote the plugin.

Confusing a withdrawal request with a data-subject request. They arrive through similar-looking forms, but a withdrawal is a consumer-law act, not an Article 15–21 request. That matters both ways: the one-month clock in Article 12(3) does not govern withdrawals, and Article 12(6) — which lets a controller with "reasonable doubts concerning the identity of the natural person making the request" ask for more information — is not directly available here. It is still the right standard to borrow when deciding how much verification a withdrawal deserves; just do not cite it as authority for a consumer-law process.

Verifying nothing because the law says minimise. Data minimisation limits what you may require on the form. It does not oblige you to act on an unverified request without thought. Confirming to the address on the order — rather than the address typed into the form — verifies without collecting anything new.

Leaving the free-text box on. If your implementation offers a "reason" field, every complaint and health disclosure a frustrated customer types now lives in your order notes. Optional beats mandatory; absent beats optional.

How PrivacyForge Helps

The work this feature creates is mostly record-keeping, which is exactly the work that decays quietly between the day a setting is switched on and the day someone asks about it.

PrivacyForge's data mapping module is built for the Article 30 record described above: adding the withdrawal form as a processing activity, capturing the lawful basis, the categories of data subject including non-customers, and separate retention periods for matched and unmatched submissions. Retention policies turn the deletion window for unmatched submissions into a stated rule with an execution log behind it, rather than a note in someone's calendar. And compliance scoring surfaces processing activities whose retention periods or privacy-notice entries have drifted out of date — the usual fate of a control added in a hurry.

None of this substitutes for deciding how your store should behave. It keeps the decision documented once you have made it.

Frequently Asked Questions

No. WooCommerce 11.1 provides the withdrawal function that EU consumer law requires, but it does not handle your GDPR obligations. You remain the controller for the personal data the form collects, which means you must record the activity under Article 30, set retention periods, update your privacy notice, and secure the endpoint yourself.

Is the WooCommerce withdrawal form really accessible without logging in?

Yes. The 11.1 pre-release notes state that a customer "can request a withdrawal from a new My Account page /my-account/withdraw-order/, no auth required." Despite the My Account location, no session is needed. That is intentional, since guest shoppers hold the withdrawal right too, but it means the page is reachable by anyone on the internet.

What lawful basis should I use for withdrawal request data?

Either Article 6(1)(c), compliance with a legal obligation, or Article 6(1)(b), performance of a contract. We prefer 6(1)(c) because offering the withdrawal function is itself a statutory duty; Arnold & Porter's advisory favours 6(1)(b). Both are defensible, so choose one and record it consistently. Do not use consent: it misdescribes the relationship.

How long should I keep withdrawal requests that match no order?

Set a short, explicit period and document it. Because an unmatched request cannot serve the withdrawal purpose, Article 5(1)(e) requires that it not be kept longer than necessary once reviewed. Keep it long enough to handle a customer who mistyped their order number, and no longer. An indefinite review queue is the outcome to avoid.

Does the Article 30 small-business exemption cover this?

No. Article 30(5) removes the record obligation for organisations under 250 employees only where the processing is occasional, low-risk and involves no special-category data. The withdrawal function is required to be continuously available throughout the withdrawal period under Article 11a as the sources cited in this article describe it, so the processing is not occasional and the exemption does not apply regardless of headcount.

When does the EU withdrawal button obligation apply from?

The obligation has applied since 19 June 2026, under the new Article 11a inserted into the Consumer Rights Directive by Directive (EU) 2023/2673. WooCommerce's native support arriving on 1 September 2026 does not change the deadline — it changes how a WooCommerce store can meet a duty that is already live.

Conclusion

The honest summary is that WooCommerce has done the hard part and left you the quiet part. The form is built, the legal requirement it serves is real, and turning it on is a one-click decision that most merchants should make.

Make it deliberately, though, and take the twenty minutes afterwards. Decide what happens to submissions that match nothing, write the processing activity into your Article 30 record with non-customers named in it, put rate limiting in front of the endpoint, and resist every temptation to add one more field. A public form that accepts personal data from anyone is not a problem — an undocumented one is.

If you are already reviewing how your store verifies people who arrive without a login, the same question is worth asking of WooCommerce's guest order linking feature, which matches past orders on an unverified billing email. For the record-keeping side, our guide to building a record of processing activities walks through the Article 30 fields in full, and the wider duties sit in our complete guide to GDPR compliance.

Sources

#woocommerce #right of withdrawal #data mapping #gdpr #ecommerce