| 开发者 | artprojectgroup |
|---|---|
| 更新时间 | 2026年8月9日 17:12 |
| 捐献地址: | 去捐款 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GNU General Public License v3 or later |
| 版权网址: | 版权信息 |
[apg_withdrawal_form] shortcode._apg_withdrawal_type = digital), on every order, or on selected categories and/or selected products. The customer's choice is persisted to order meta as legal evidence.apg-withdrawal/v1 to list, read, create and progress requests from headless storefronts and back-office integrations.wpml-config.xml and through runtime string registration.apg-withdrawal-for-woocommerce folder to the /wp-content/plugins/ directory via FTP.[apg_withdrawal_form] shortcode to the page configured as the withdrawal page in the settings.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.
Yes. The form supports both logged-in customers (with pre-filled data and order selector) and guests (with email lookup of their orders).
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:
[apg_withdrawal_link] shortcode, with optional label, class and target attributes, to drop the link inside any post, page, footer widget or HTML block.woocommerce_email_after_order_table).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.
_apg_withdrawal_quantities, travel through the confirmation screen, and are shown in the acknowledgement email, the request detail screen and the CSV export as "Product x 1 of 3". They are also folded into the SHA-256 receipt hash as item:units pairs, so the digest covers the quantities and not just which lines were selected. Requests registered before this release keep working and are read as "all the units of the selected lines", which is what they meant.apg_withdrawal_change_status(), so each one still gets its log entry and, when enabled, its customer notification — and the Export CSV button now exports the status currently on screen instead of always the whole log.wc-apg-withdrawal ("Withdrawal requested"), registered for both the legacy and the HPOS storage, available in the order editor dropdown, in the orders list views, as a bulk action and inside the plugin's own Automation mapping. A new setting, Order status when a request is received, optionally moves the linked order to any status — the new one or an existing one — as soon as a declaration is registered. Disabled by default, so updating changes nothing until you opt in.apg_withdrawal_verification_ttl).EU baseline / ES) governs the statutory reference shown on the confirmation screen and in the acknowledgement email. Spain has not transposed Directive (EU) 2023/2673 yet, so both options currently apply the same requirements and the Spanish one additionally cites the TRLGDCU; the point of the layer is that every jurisdiction-specific branch goes through apg_withdrawal_jurisdiction_supports(), so the national extras can be switched on in one place once they reach the BOE instead of being retrofitted across the codebase. Both the jurisdiction and the feature matrix are filterable.apg-withdrawal/v1 namespace. GET /requests (paginated, filterable by status and order), GET /requests/<id> and PUT /requests/<id> require manage_woocommerce; POST /requests is public so decoupled storefronts can register a declaration, and routes through the very same processor as the public form — order/email match, rate limiting and, when enabled, guest email verification all apply, and a parked submission answers 202 with pending_verification. The refund account is only echoed back to a caller that can manage WooCommerce. A new apg_withdrawal_request_registered action fires once a declaration is fully registered.apg_withdrawal_refund_plan.apg_withdrawal_gateway_info.afterprint — and on the print media query ceasing to match, because Safari is inconsistent about which of the two it emits when the dialog is dismissed — also fixes the page being left blank after closing the dialog. The public form's link is labelled "Open the model form" and announces that it opens in a new tab.fieldset of native checkboxes and number inputs instead of a multi-select widget, so it is operable with a keyboard and announceable by screen readers; the dynamic notices became live regions (role="alert" for the order error, role="status" for the product warning); and focus is moved to the newly injected content after every AJAX step, which previously left it on a button that no longer existed (3.2.2 and 4.1.3). The line rows are also spaced so they already satisfy the WCAG 2.2 target-size criterion (2.5.8), which is not part of WCAG 2.1 AA but arrives with version 4.1.1 of EN 301 549 — the standard the European Accessibility Act points to, and which has bound e-commerce since 28 June 2025.wpml-config.xml shipped with the plugin, so WPML and Polylang pick up the six merchant-configurable strings and the withdrawal-type metas without any code running. The runtime wpml_register_single_string registration added in 0.6.0 stays in place for setups that read strings that way..mo (or .l10n.php) for the current locale under /languages, the lang_dir_for_domain filter returns that folder unconditionally, instead of only falling back to it when WordPress could not find anything in wp-content/languages/plugins/. Result: the locale shipped by the plugin (currently es_ES) is always rendered with the strings packaged in the current release, so new wording and changelog-driven copy adjustments reach users on the same day as the plugin update without waiting for translate.wordpress.org to regenerate its language pack. Locales for which the plugin does not bundle a translation continue to be loaded from the centralised system pack as before./languages) was not being loaded on sites where translate.wordpress.org had not yet generated a language pack. WordPress's just-in-time loader only inspects wp-content/languages/plugins/, so the .mo file shipped inside the plugin was ignored. The plugin now hooks the WordPress 6.6+ lang_dir_for_domain filter to return the bundled /languages folder when no language pack is available, without resorting to the WP.org-discouraged load_plugin_textdomain() call. On WordPress 6.5 and below the bundled translation will still not load until a language pack is published, but the plugin keeps working in the source language.WC_Email classes shipped by the plugin (customer acknowledgement, admin notification, status update) are picked up automatically by the new built-in EmailLogger. Each log entry is enriched via woocommerce_email_log_context with the withdrawal request id, scope and the SHA-256 receipt hash plus its UTC timestamp, so the log entry can be cross-checked against the email actually delivered to the customer. The filter is silently ignored on older WooCommerce versions.apg_withdrawal_label_is_ambiguous()) flags withdrawal labels that fail the "unambiguous wording" requirement of Article 11a of Directive 2011/83/EU. Used in two places: (a) the configurable confirmation button label (Settings → Button text) now surfaces an admin warning if the merchant saves an ambiguous wording (e.g. "Contáctanos", "Gestionar pedido", "Volver"); the choice is not blocked, only flagged; (b) the [apg_withdrawal_link] shortcode and the matching apg-withdrawal/link Gutenberg block emit a _doing_it_wrong() notice (visible with WP_DEBUG) when an ambiguous custom label attribute is used. Lists of "passes" and "blacklist" terms are filterable via apg_withdrawal_label_unambiguous_terms and apg_withdrawal_label_ambiguous_terms.?print=1 to the Annex I.B URL so the browser print dialog opens automatically on page load (the existing on-page Print button still works for users who reach the URL directly).WC()->countries->get_countries() and get_states()) instead of the raw XX:YY ISO code stored in woocommerce_default_country, each on its own paragraph. Every paragraph in the addressee block ends with a period, as expected in formal correspondence.wpml_register_single_string action) on init. When neither plugin is active the registration is a no-op and the original value is rendered unchanged.apg_withdrawal_is_rate_limited() helper throttles repeated submissions by IP + email pair (default policy: 5 attempts per 10 minutes, both filterable via apg_withdrawal_rate_limit_max and apg_withdrawal_rate_limit_window). A hidden honeypot field is rendered in both steps of the form and silently swallows automated submissions before any persistence happens. Client IP detection respects common reverse-proxy headers and is filterable via apg_withdrawal_client_ip.completed_date to created_date for orders that have not yet been marked complete. No code change required.product_cat, with automatic inheritance for products that keep the "Withdrawal allowed (default)" value. When a product belongs to several categories with conflicting types, the most restrictive type wins (priority order: excluded > personalized > digital > manual > allowed).[apg_withdrawal_notice] shortcode, matching apg-withdrawal/notice Gutenberg block and woocommerce_single_product_summary injection (priority 20, between the price and the Add to Cart button) that automatically displays the exclusion notice on the product page when the effective withdrawal type is not allowed.excluded, digital, personalized, manual) and a translated default text per type. Optional per-product override field on the Withdrawal product data tab to customise the notice for a single product.Never (disabled), On products classified as digital content, On every order — driven exclusively by the per-product / per-category withdrawal type. Legacy installations with mode virtual are migrated to digital; mode specific is migrated to digital and the previously selected categories / products are automatically marked with _apg_withdrawal_type = digital to preserve their behaviour. The legacy digital_waiver_categories / digital_waiver_products settings stop being honoured at the UI level (a one-time silent migration runs on init, flagged by the apg_withdrawal_migrated_to_0_5 option).?apg_withdrawal_model_form=1 with @media print styling, pre-populated with the store name, address, email (from WooCommerce settings) and an optional merchant phone (new Merchant phone (optional) plugin setting). The public withdrawal request form links to it as "Download the official model withdrawal form (Annex I.B)".[apg_withdrawal_link] shortcode and apg-withdrawal/link Gutenberg block to render a link to the public withdrawal form with optional label, class and target attributes. The default label uses the literal wording suggested by Article 11a(1) ("Withdraw from the contract here"). The My Account per-order action label has been updated to the same default for new installs._apg_withdrawal_receipt_hash, _apg_withdrawal_receipt_hash_timestamp) and exposed in the CSV export._apg_withdrawal_digital_waiver_log order meta) that includes the exact label shown to the customer, UTC timestamp, IP, user agent and checkout type (classic or block). The legacy _apg_withdrawal_digital_waiver boolean meta is also written for backwards compatibility.wp_mail() was invoked, whether it returned success (= "accepted by the mailer", not actual recipient delivery), the UTC timestamp and any error captured through wp_mail_failed. The information is surfaced in the request detail screen and exported as two additional CSV columns.[redacted]) and keeps the record itself plus the _apg_withdrawal_wc_order_id reference for legal evidence, in line with the burden of proof in Article 16 bis(8). The same anonymisation is also triggered automatically when a WordPress user is deleted (via Users → Delete, a customer-facing "Delete my account" button shipped by third-party plugins such as apg-gdpr-texts-for-forms, or any other path), so the withdrawal records never outlive the user account with personal data attached.=, +, -, @, tab or carriage return is prefixed with an apostrophe before being written via fputcsv.disabled, virtual, all, specific) so the values now match the actual mode selector.woocommerce_checkout_before_terms_and_conditions with priority 999) and block-based (via JavaScript that reinserts itself with a MutationObserver to remain right before the native terms checkbox, after any other custom one)..wp-block-woocommerce-checkout-terms-block .wc-block-components-checkbox plus jQuery .after()), avoiding duplicated privacy or marketing notices._apg_withdrawal_digital_waiver ('1' or '0') on both checkouts: the classic checkout reads the POST value on woocommerce_checkout_create_order, the block checkout injects the value into the StoreAPI request body under extensions['apg-withdrawal']['digital_waiver'] and the server hook woocommerce_store_api_checkout_update_order_from_request writes the same meta.apg_withdrawal_check_cart_waiver), re-checks server-side whether the current cart still qualifies, inserting or removing the checkbox without a full page reload._apg_withdrawal_type = digital setting, so virtual flag and explicit digital classification are treated as equivalent triggers.wc_print_notice() so they pick up the correct WooCommerce template for both block themes (block-notices/*.php) and classic themes (notices/*.php).wc_print_notice() and toggled by JavaScript, instead of being built by hand with legacy markup that breaks on block themes.woocommerce-invalid class on the email field.wc_wp_theme_get_element_class_name( 'button' ) for theme and block-theme compatibility.