APG Withdrawal for WooCommerce

In the plugin settings you can configure the notification email, the withdrawal page, the withdrawal window in days, the deadline source (completed or created date), the extra grace days and which data to store (IP address, browser identifier).

Yes. The plugin is fully compatible with WooCommerce High-Performance Order Storage.

You can, but you should not. WooCommerce 11.1 added Order withdrawal under WooCommerce → Settings → Advanced → Features, off by default. With both running, your customers reach two different forms at two different addresses, each keeping its own record and sending its own acknowledgement, and neither knows about the other: the same declaration can be registered twice and answered twice. The plugin detects the core feature and warns you, with a link to the screen where you turn it off.

The core feature covers the basics: a form, a review step, acknowledgement emails, matching to the order and a note on it. This plugin adds what a shop needs around that — withdrawal type per product and per category with inheritance and the exclusion notice on the product page, the Article 16(m) digital-content waiver at checkout with its structured log, the printable Annex I.B model form, the SHA-256 receipt hash for the burden of proof of Article 16a(8), the WooCommerce refund panel driven by the declared lines, the GDPR exporter, eraser and anonymisation, and the REST API. Pick one of the two and turn the other off.

Yes. A logged-in customer gets their data pre-filled and picks from a dropdown of their own orders. A guest types the order number and the email address recorded on the order, which is the pair the plugin validates before accepting any declaration — the same proof WooCommerce asks for in its own order tracking. The plugin never lists a customer’s orders to a visitor who has only supplied an email address.

The withdrawal form page is auto-created on activation and contains the [apg_withdrawal_form] shortcode. To comply with Article 11a of Directive 2011/83/EU (added by Directive 2023/2673), the link to that page should be prominently visible and easy to find on the storefront. The plugin gives you several tools to place it; deciding where to place it is the merchant’s (or their web designer’s) responsibility:

• The fixed URL of the auto-created page, available in WooCommerce → Withdrawal → Withdrawal page .
• The [apg_withdrawal_link] shortcode, with optional label , class and target attributes, to drop the link inside any post, page, footer widget or HTML block.
• The matching Withdrawal link Gutenberg block for sites built with the Full Site Editor.
• The Withdrawal request action that is automatically added to every eligible order in the My Account → Orders table.

Typical recommended placements:

• The site footer, so the link is reachable from any page.
• The My Account menu (the per-order action is already added; you can also add a top-level menu item linking to the public form).
• The Terms and Conditions / Privacy Policy pages, alongside the rest of the consumer information required by Article 6.1.h of Directive 2011/83/EU.
• The order processing / completed emails (the plugin already injects the link there automatically via woocommerce_email_after_order_table , except on orders whose products are all excluded from the right of withdrawal).

Article 11a of Directive 2011/83/EU has applied throughout the EU since 19 June 2026, regardless of whether each Member State has transposed it. Spain had not done so at the time of this release — the European Commission issued a reasoned opinion against Spain in June 2026 — but the obligation applies by direct effect, and non-compliance is penalised through the general regime of the TRLGDCU, whose fines reach 100,000 € for minor infringements, 1,000,000 € for serious ones and 4,000,000 € (or 4% of the turnover in Spain, whichever is higher) for very serious ones. Check the regime applicable in your own country: this note is informative and is not legal advice.

Yes, in WooCommerce → Withdrawal → Request handling → Account for the refund (IBAN) , either as an optional or as a required field. It is disabled by default. The number is validated with the international control digits (ISO 7064 MOD-97-10) before being accepted, is stored alongside the request, is included in the privacy exporter and is deleted outright by the privacy eraser. Only enable it when you genuinely cannot refund through the original payment method.

Enable Confirm guest requests by email? . A visitor who is not logged in then has their request held while a single-use link is sent to the address recorded on the order; only opening it registers the declaration. The request keeps the date and time of the original submission, so the customer never loses days of their withdrawal period. Logged-in customers are unaffected, since WordPress has already authenticated them.

The public form targets WCAG 2.1 level AA , which is what EN 301 549 — the standard the European Accessibility Act points to — requires today: the line-item selector is a labelled fieldset of native checkboxes and number inputs operable with a keyboard, dynamic notices are live regions, and focus moves to each new step of the flow. It also already satisfies the WCAG 2.2 target-size criterion (2.5.8), which arrives with version 4.1.1 of that standard, and the guest confirmation link is the pattern WCAG 2.2 recommends for accessible authentication (3.3.8), since it asks the customer for no cognitive test.

Two caveats. First, the Accessibility Act (Directive (EU) 2019/882, in Spain Law 11/2023) has applied to e-commerce since 28 June 2025 , and it binds the shop , not a single plugin: colour contrast, focus visibility and page structure come from your theme, and the responsibility for the store as a whole is the merchant’s. Second, companies with fewer than 10 employees and a turnover below 2 million euros are exempt from the obligations on services. Check your own situation: this note is informative and is not legal advice.

Yes. Each request shows a Refund panel with the amount the declaration implies — the declared lines at their declared quantities, plus the standard delivery cost when the withdrawal covers the whole contract, as Article 13(1) of Directive 2011/83/EU requires — always capped by whatever is still refundable on the order, so a refund you already issued by hand is never handed out twice. Nothing happens until you press the button. By default the refund is only recorded in WooCommerce, without moving money or touching stock; two checkboxes let you send it through the payment gateway (when the gateway supports it) and restock the returned products. The apg_withdrawal_refund_plan filter lets you adjust the figures, for instance to deduct the diminished value of returned goods.

Yes, and nothing extra needs installing. Bizum runs on Redsys for e-commerce, and the WooCommerce implementations of Redsys — José Conti’s paid gateway, Codection’s, the official unified module — issue refunds through the standard WooCommerce refund API. The refund panel uses that same API, so ticking Send the money back through Redsys reaches your virtual POS directly. The panel names the gateway it is about to use, so you always know where the money is going.

Three things worth knowing. Redsys accepts both full and partial refunds , so a partial withdrawal is returned as declared. When the customer sees the money depends on their bank , typically between 2 and 31 days — the 14-day limit in Article 13(1) of Directive 2011/83/EU applies to you issuing the refund, not to their bank crediting it. And if you use a Redsys gateway that does not implement refunds, such as the free Light edition, the panel says so and records the refund in WooCommerce without moving money, so you can issue it from your bank’s back office and keep the accounting straight.

When a gateway rejects a refund, the reason it gives — the SIS code, in the case of Redsys — is shown in the error notice instead of a generic failure, so you have something to act on.

Yes, under the apg-withdrawal/v1 namespace. GET /requests and GET /requests/<id> list and read requests, and PUT /requests/<id> moves one through the workflow; all three require the manage_woocommerce capability. POST /requests registers a declaration coming from a headless storefront and is public, exactly like the public form: it goes through the same processor, so the order must match the email address, the rate limiter applies and the guest email verification kicks in when you enabled it.

The plugin does not delete withdrawal request records automatically. As a general recommendation, keep them for at least 5 years after their creation — the typical statute of limitations for consumer and contractual actions in many EU jurisdictions. Always check the applicable retention period in your country before deleting old records or running the plugin’s CSV export + uninstall flow.

APG Withdrawal for WooCommerce is a free plugin. Art Project Group does not provide free technical support, but offers a paid technical support service for installation and configuration.