| 开发者 | briqpay |
|---|---|
| 更新时间 | 2026年9月11日 16:39 |
| 捐献地址: | 去捐款 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
woocommerce_checkout_update_order_review action while syncing the payment session, which is the action every plugin that adds a field to the checkout uses to apply that field - a VAT plugin sets the customer's VAT exemption there, and because the action was never fired, it never ran and the cart kept charging VAT. Second, the check that decides whether the cart needs recalculating now takes VAT exemption and the billing address into account; both change the tax on an otherwise identical cart, so the recalculation was being skipped and the earlier figure kept. Third, the browser now re-syncs the payment session whenever WooCommerce recalculates the cart, instead of only when a checkout field changed - a VAT number is validated in the background, so by the time the exemption is applied the form looks untouched and the sync was skipped, leaving the payment window showing the total from before.briqpay_order_is_vat_exempt filter to override it, and briqpay_fire_order_review_hook to stop firing the order review action for a plugin that misbehaves on it. A plugin that throws an error on that action is logged and stepped over rather than being allowed to take the whole checkout down with it.woocommerce_checkout_order_created action so third-party plugins receive Briqpay orders the same way they receive any other order, but WooCommerce core itself is listening on that same action to reserve stock - so the replay made core reserve the order's stock a second time. The replay now unhooks core's own listener for the moment it runs and restores it immediately after; every other plugin listening on that action is unaffected.briqpay_payment_complete) could run twice for one order. The one-time-per-order guard is now backed by an atomic lock instead of a plain database read, so only one of the two can proceed.languages/briqpay-for-woocommerce.pot) is included for any further languages.fi rather than fi_FI. Briqpay rejected every session with "body.locale pattern mismatch". Locales are now always sent as a language-country pair (fi-fi, sv-se, de-de), including WordPress variants such as de_DE_formal. All English locales are sent as en-gb, whichever region the site is set to. Added the briqpay_locale filter to override any of this."400". WooCommerce stores cart quantities as text, and because the arithmetic still worked the wrong type was only visible when the API rejected it. Quantities are now sent as numbers everywhere, on both new and existing orders.manual_review payment tag) are now placed on hold instead of being moved to processing. The order stays on hold until someone releases it manually, and no later Briqpay event will advance it.briqpay_respect_on_hold_status filter if you want the previous behaviour.woocommerce_checkout_create_order, woocommerce_checkout_update_order_meta, woocommerce_checkout_order_created, woocommerce_checkout_order_processed, the Blocks Store API equivalents, and the woocommerce_checkout_create_order_line_item_object filter - so third-party plugins (custom checkout fields, ERP and invoicing connectors, delivery-date pickers, shipping brokers) receive them the same way they receive orders paid with other methods. The submitted checkout form is passed to those actions, captured during checkout and replayed, because the payment decision request carries only a session ID.briqpay_after_create_order). It will now run alongside the plugins it was standing in for, which can mean duplicate ERP exports, invoices or fees. New installs have the setting on by default because they have no such workarounds.briqpay_fire_checkout_hook (disable one specific checkout action), briqpay_superimpose_post_data and briqpay_order_created_via, plus a filters/checkout_hook_control.txt example.created_via of checkout rather than Briqpay, so plugins that only act on native checkout orders recognise them. Stores with the setting off keep the previous value.coupon_info snapshot, so orders still display their discounts correctly after a coupon is edited or deleted.woocommerce_checkout_order_processed handler that attaches the Briqpay session to orders created by WooCommerce's native checkout was never registered, so it never ran. It is now registered, and hardened so it can only promote a draft order and never move an order backwards.process_payment() no longer always fails. If Briqpay confirms the session is paid - verified against the Briqpay API, never from local data - the order completes through WooCommerce's own pipeline. Anything unconfirmed still directs the customer back to the Briqpay checkout, so the native button cannot bypass payment.woocommerce_checkout_order_exception fires when order creation fails, and woocommerce_checkout_create_order_tax_item is offered for each tax line (both behind the "WooCommerce checkout actions" setting).payment_complete().briqpay_amount_only_refund_items filter for stores that need to allocate across specific captured references.briqpay_payment_complete action never actually ran on a normal purchase. It was only fired on a code path that a storefront order never reaches, because orders already have the "pending" status by the time the customer returns. It now fires once per order whenever payment is verified at the return. If you added custom code elsewhere to work around this, it will now run alongside your original briqpay_payment_complete listener - remove one, or use the new briqpay_fire_payment_complete filter to suppress the action. Note this is a return-time signal; for "the payment is secured", use WooCommerce's own woocommerce_payment_complete or the order status transitions, which this plugin already triggers from the webhook and which fire even if the customer never returns.briqpay_allow_unsupported_currency_precision filter._billing_org_nr, the shipping email in _shipping_email, and mirror the payment method/autocapture meta the previous plugin used, alongside the meta this plugin already writes. Disabled by default; existing installs are unaffected._billing_org_nr when the newer _briqpay_company_cin meta is absent, so orders imported from the previous plugin display correctly regardless of the setting.body.briqpay-selected to prevent hiding other payment options.checkout.js, admin.js, blocks-checkout.js)._briqpay_company_name, _briqpay_company_cin) — no external filter snippet required.billing_company) is now correctly set on the WooCommerce order and customer at the decision point and on return, ensuring it appears on the thank-you page and in order confirmation emails.shipping_company so it appears correctly on shipping labels and in shipping address details.addressupdate event handler to sync country, city and state fields — not just postcode — so WooCommerce shipping zones resolve correctly.update_checkout is now always triggered on every addressupdate event (not only when field values differ) to handle cases where the hidden fields already contain correct values but WooCommerce has not yet recalculated shipping.$_SERVER['REQUEST_URI'] usages.blocks_data input.map_deep() sanitization on webhook payloads after json_decode().is_b2b_active to prevent re-activation on the success page.briqpay_b2b_checkout shortcode to automatically handle B2B session context without requiring external filters.