A withdrawal button for WooCommerce, with a timestamped record of every declaration

Where the link appears

Customers find the link wherever they look

On activation, the plugin creates a page called “Withdraw from contract” that holds the withdrawal form. Customers can reach it from several places, and the shop decides which ones to use under WooCommerce, Settings, Withdrawal.

• In the footer of every page. On by default. This keeps the function visible for the whole withdrawal period, as the article requires.
• In My Account. A link next to each order in the customer’s order list, shown only on orders that are still inside the withdrawal window and still have something left to withdraw. Also on by default.
• Anywhere else. The [fdwb_button] shortcode places the same link on any page, for example a returns page.
• One label everywhere. The link reads “Withdraw from contract” unless the shop sets its own wording in the settings.

Three ways in

For customers with an account, for guests, and for everyone else

The same form serves three different situations, so no customer is left without a way to withdraw.

• Signed in. From the order in My Account, straight into the form. The plugin checks that the order belongs to the customer who is signed in.
• Guest. The customer enters the order number and the email address used for the order. When both match, the plugin emails a link to that address. The link stays valid for 30 minutes and opens the form for that order only. The page shows the same message whether anything matched or not, so the form cannot be used to find out whether an order exists.
• Free text declaration. For a customer whose link expired, who no longer has access to that inbox, or who cannot find the order number. They give their name, a contact email and enough detail to identify the order. The declaration is recorded as unverified and marked for the shop to match by hand, and the customer still receives an acknowledgement.

Two steps

Declaring is a deliberate act, not a stray click

The form follows the structure of Article 11a. The customer first sees exactly what they are about to declare, then confirms it as a separate action.

• Step one shows the order and lets the customer choose what to withdraw. A reason can be given but is never required.
• Step two repeats the choice and asks for confirmation with a button labelled “Confirm withdrawal”. Nothing is sent before that.
• A double click cannot file two declarations. The first submission is recorded, and the second one lands on the same confirmation page.

Partial withdrawal

Per item and per quantity, counting refunds already made

Customers often withdraw from part of an order rather than all of it. The plugin offers only what is genuinely left to withdraw.

• The customer chooses which items, and how many of each.
• Refunds already issued reduce what is left. If a customer bought three, withdrew one and was refunded for another through WooCommerce, the form offers one, not two.
• Items already withdrawn, items in excluded categories and the individual parts of a product bundle are not offered.
• Partial withdrawal is on by default and can be switched off, in which case a customer withdraws from the whole order or not at all.

The acknowledgement

The email the article asks for

As soon as the customer confirms, the plugin sends an acknowledgement of receipt. It shows the reference, the date and time of receipt, the order, exactly what was declared, and an integrity code.

• The integrity code is calculated from the content of the declaration with a key that only the site holds. If the stored record were ever changed, it would no longer match the code in the customer’s email.
• The wording says received, never accepted. Receipt and acceptance are separate legal steps, and the email keeps them apart.
• It goes to the email address of the order, or to the address the customer gave in a free text declaration. Plain text format is available and suits a document the customer may want to keep or print.

The request list

Where the shop handles each request

All requests appear in one list under WooCommerce, with the number of pending requests shown next to the menu item so none are missed.

• Filter by status, and search by reference, customer name, email or order number.
• Every request keeps a full history: who did what, and when.
• Accept or reject with a note that goes to the customer. The note is optional when accepting. When rejecting, a reason is worth the thirty seconds it takes, because a refusal without one cannot be answered by the customer or defended later by the shop.
• Each request also adds a note to the order, and the order screen shows a panel with all of that order’s withdrawal requests.
• A declaration recorded outside the withdrawal window is marked as such in the order note, so the shop can see it at once and decide.

Orders and refunds

The plugin records declarations; refunds stay in WooCommerce

The plugin never moves money. The shop issues refunds with WooCommerce’s own refund controls on the order, through its usual payment gateway, after inspecting the returned goods.

• No monetary amount is stored with a request. What the shop owes depends on delivery costs, discounts spread across several items and the condition of the goods, so a figure fixed at the time of the declaration would look official and be wrong.
• Two optional order statuses, “Withdrawal requested” and “Withdrawn”, are off by default. When they are switched on, the previous status is remembered and restored if a request is rejected, and a partially withdrawn order returns to its previous status, because the rest of the order still stands.

Exclusions

Products that carry no right of withdrawal

Some goods are excluded by law from the start, such as items made to the customer’s specification or goods that spoil quickly. The shop can exclude them under WooCommerce, Settings, Withdrawal, Exclusions, and they are then never offered in the form.

• Exclude whole product categories.
• Exclude virtual or downloadable products, each with its own switch. Both are off by default, because a service or digital content loses the right of withdrawal only under strict conditions: the customer agreed in advance to an immediate start and acknowledged losing the right, and for digital content the shop confirmed this to them. These switches belong on only if the checkout collects that consent.
• Sealed health, hygiene and cosmetic products are not excluded automatically. They lose the right only once opened, and no software can tell whether a package was opened. That check belongs to the team receiving the return.

Five emails

The customer is told what happened, in the shop’s own words

Access link, acknowledgement of receipt, notification to the shop, acceptance and rejection. All five appear under WooCommerce, Settings, Emails, next to the shop’s other emails.

• Every one has WooCommerce’s standard Additional content box.
• The three that the customer reads also let the shop replace the closing paragraph, the one that explains what happens next. Clearing the field brings back the built in wording, in the customer’s language.
• The default acceptance text says that the shop will write separately about returning the goods and the refund. That is true of most shops but not all, so a shop with a different process should describe its own.
• The notification goes to the addresses set under Withdrawal, Notifications, or to the site administrator if none are set.

Deletion

Records can be removed, but never without a trace

Spam, duplicates and the test entries left behind during setup should be removable. A genuine declaration is different: it records that a customer used a legal right on a given date, and it is evidence for the shop as much as for the customer.

• Before a request is deleted, the whole record is written to the WooCommerce log, together with the reason given and the user who deleted it.
• The order receives a note with the reference, the time the declaration was received and the user.
• Neither can be deleted from inside the plugin, and there is deliberately no bulk delete.
• Uninstalling the plugin keeps all records unless the shop chooses otherwise under Withdrawal, Advanced.

Privacy

GDPR tools, with erasure off by default

Withdrawal requests appear in WordPress’s Export Personal Data and Erase Personal Data tools, and the plugin adds suggested text to the privacy policy draft.

• Erasure is off by default, and the erasure report says so instead of failing silently. A withdrawal declaration records a legal act and is the shop’s evidence that it was honoured, which is a recognised reason to keep it. WooCommerce treats orders the same way.
• When erasure is switched on, the name, address and free text are replaced while the declaration itself remains, so the proof is kept without keeping the personal data.
• Visitor IP addresses are used only for rate limiting, kept as a salted hash in the plugin’s own table, and never stored with a declaration.

How translations arrive

Language packs, installed automatically by WordPress

The plugin is written in English and has 302 translatable texts. Translations are managed on translate.wordpress.org, in the same way as WordPress itself, and WordPress installs the right language pack for each site automatically.

• Greek is complete. Every text, including the admin screens and the legal wording, was reviewed line by line by a fluent speaker and submitted to translate.wordpress.org. Greek language pack is available from translate.wordpress.org.
• Other languages are prepared but not published. Drafts exist for German, French, Spanish, Italian, Czech and Romanian. WordPress.org accepts only translations reviewed by a fluent speaker, so each one waits for that review.
• Anyone can help. A shop or translator can contribute or correct translations on the plugin’s page at translate.wordpress.org.
• Works with Loco Translate, WPML and Polylang. On a multilingual shop, the withdrawal link leads to the page in the visitor’s language, and the cache exclusion covers every translation of the page.