Briqpay for WooCommerce

Ændringslog

1.1.24

• Removed: The “Briqpay checkout fields” block on the order edit screen, added in 1.1.23, duplicated fields shops had already built for the same data and could write a stale value back over an edit made in such a field. The block, the per-shop list of seen fields and the invoice-field prefill on business hosted payment pages are gone; the order screen and the hosted page behave as in 1.1.22. The organisation number field is unchanged. The checkout still stores every collected field on the order as before.
• Fix: The plugin constants are now defined only once, so updating or re-activating the plugin from the admin no longer logs “Constant BRIQPAY_WC_VERSION already defined” and three similar notices for that request.

1.1.23

• Added: The rest of WooCommerce’s checkout hooks, fired at the moment Briqpay approves a purchase, in the order WooCommerce fires them (all behind the existing “WooCommerce checkout actions” setting): the validation hooks woocommerce_before_checkout_process, woocommerce_checkout_process, woocommerce_check_cart_items and woocommerce_after_checkout_validation, plus the woocommerce_checkout_posted_data filter – a plugin that refuses the purchase on any of them (by an error notice, a WP_Error or an exception) now stops it, and its message is shown to the customer in the payment window; woocommerce_checkout_update_customer and woocommerce_checkout_update_user_meta, with the logged-in customer updated from the form as WooCommerce does it; the woocommerce_checkout_customer_id and woocommerce_create_order filters (with woocommerce_resume_order) around order creation; and woocommerce_payment_successful_result on the redirect after payment. Plugins that validate on woocommerce_checkout_process had silently never run for Briqpay orders. The validation hooks are classic-checkout only, as in WooCommerce; account creation at checkout is not offered. The setting must be on.
• Fix: The company name and organisation number from a business purchase were only stored on the order (_briqpay_company_name / _briqpay_company_cin) when the purchase came through the B2B checkout page. A business purchase through the ordinary checkout (company lookup on a business session) now stores them too. When a business session carries no organisation number at all, the plugin logs an error naming the session, the country and what the company block did contain, so a missing number can be traced without verbose logging.
• New: The Briqpay checkout fields – reference, customer order number, invoice email, GLN, and every other field the shop’s Briqpay checkout has ever delivered – are now shown and editable on the order edit screen, next to the organisation number, and follow the payment method dropdown so they are there the moment Briqpay is chosen on an order built by hand. Values are saved into the same order meta the checkout writes (_briqpay_payment_field_ and so on), so exports and integrations read a manual order like a checkout order, and the invoice fields are sent on to Briqpay with a business hosted payment page. The briqpay_admin_order_fields filter adjusts the list.
• Fix: On shops where WooCommerce’s Cost of Goods Sold feature is off, every Briqpay order logged a “calculate_cogs_total_value was called incorrectly” notice under WP_DEBUG. The recalculation is now gated the way WooCommerce’s own checkout gates it.

1.1.22

• Fix: Product add-ons and other per-item data from plugins were missing from orders the plugin created. When Briqpay approves a purchase the plugin builds the order itself, and its line items lacked the cart data that WooCommerce’s own checkout attaches ($item->legacy_values and legacy_cart_item_key). Plugins that read that data while the line item is created – Product Add-Ons Ultimate (chosen add-ons), Discount Rules for WooCommerce (per-item rule details) and others – therefore saved nothing. Line items now carry it exactly as WooCommerce’s checkout sets it. Orders created before this update cannot be repaired by the plugin, because the cart they came from no longer exists.
• Fix: Variation attributes on orders the plugin created were stored under their raw cart key (“attribute_pa_color”) instead of the attribute name WooCommerce uses (“pa_color”), so they could show up with the wrong label in the admin and emails and be missed by export and ERP plugins. They are now stored the way WooCommerce stores them.
• Fix: The order number sent to Briqpay with the purchase (reference1) could be the WooCommerce order ID instead of the number the shop shows, when a sequential-order-number plugin assigns its number during checkout (for example SkyVerge’s Sequential Order Numbers, which numbers orders on woocommerce_checkout_update_order_meta). The reference was sent before those checkout actions ran. It is now sent after them and still before the purchase is approved, so payment methods that only accept the reference with the purchase (such as Two) get the right one, and it is read from a freshly loaded order so a number another plugin just saved is not missed.
• Fix: A failed update of that reference went unnoticed. It is now retried once – unless it timed out, so the customer never waits for two timeouts – and if it still fails, the error is logged and a note is added to the order. The purchase is never refused because of it. The reference sent is stored on the order (_briqpay_reference1).
• New: If the order number changes after the purchase is approved (plugins that number orders only once they are paid), Briqpay is updated with the new number, for payment methods that accept a late update, and an order note records that methods which only take the reference with the purchase keep the original.
• Fix: Four PHP warnings that showed up in the web server log during a checkout or on the admin order screen: an uninitialised variable when the plugin builds the order and nothing is in the WooCommerce session; the session-sync hash stored for a new session was handed an undefined session id; a Blocks checkout that sent shipping rates in an unexpected shape raised a warning and then cleared the chosen shipping methods; and a dynamic property on the gateway class that PHP 8.2 and later deprecate. None affected a completed purchase.

1.1.21

• Fix: A cart mixing VAT rates – 25% goods together with 6% or 12% goods, say – could not be paid at all when a coupon was applied: Briqpay refused to create the session with “Cart item … taxRate * unitPrice * quantity != totalVatAmount”, and the payment window never appeared. Every coupon was reported at the rate of the first product in the cart, so a coupon that only discounted the 6% products was labelled 25% while carrying 6% VAT. Coupons are now reported the way WooCommerce actually calculates them: each coupon’s share of every product is taxed at that product’s rate, and a coupon that touches more than one rate is sent as one line per rate (“Coupon: SPRING (6%)”, “Coupon: SPRING (25%)”). A coupon that touches a single rate is unchanged. The same applies to captures, refunds, the admin capture form and hosted payment pages, which build the same lines. Discounts from plugins that apply themselves as coupons (Discount Rules for WooCommerce, among others) are covered.
• Fix: Captures of orders paid through the WooCommerce Blocks checkout could be refused by Briqpay with “CART_ITEM_NOT_FOUND … has mismatching reference” when WooCommerce had created a draft order before the shopper paid. The plugin reuses that draft, but its items were built by WooCommerce and carried no Briqpay line reference, so the capture sent the bare SKU while the session had been created with “SKU-unitprice”. Reused draft items now get the same reference the session got. Orders already stuck on hold from this can be captured again after updating.
• Fix: Captures and refunds of orders discounted by a coupon plugin (Discount Rules for WooCommerce and others that apply their rules as virtual coupons) now rebuild the coupon from the snapshot WooCommerce stored on the order, exactly as WooCommerce’s own “Recalculate” does, so the capture carries the same coupon lines as the session. Briqpay matches capture lines to the session by reference, name and unit price; a fallback line built from the order totals alone would be refused.
• Translations: the new coupon line labels (“Coupon: CODE (6%)”, “Discount (6%)”) are translated in all eleven shipped languages, so a Swedish shop shows “Rabattkod: CODE (6%)” in the payment window, consistent with single-rate coupons.

1.1.20

• Fix: On the classic checkout, the payment window could sit off to the side and slightly too high – by exactly the theme’s body margin. Since 1.1.16 the window is positioned over the spot it belongs in rather than placed inside it, and that position was computed relative to the page body, which is only right when the body starts at the very corner of the page. A theme that keeps the browser’s default 8px body margin put it 8px up and 8px left; a theme that centres the body put it a whole gutter off to the left. The position is now taken from where the browser actually places the window, so it lands on the spot regardless of what the theme does to the body. Themes where the body starts at the corner, which is where this was built and tested, are unchanged.
• Fix: A Briqpay status update could be logged as “Webhook processing failed” and only take effect five minutes later, most visibly on orders that had just been placed on hold for manual review. The customer’s return and Briqpay’s webhook for the same event land within the same second; since 1.1.19 they take turns on the order, and the return kept its turn until the page had finished sending – through the on-hold email and every other plugin that runs when a checkout completes. The webhook waited a few seconds, gave up, and counted that as a failed attempt. Finding the order busy is now simply a reason to come back thirty seconds later, without using up an attempt, and the return hands the order over the moment its own status change is written.
• Fix: On the order screen, the organisation number (with legacy B2B order meta mapping enabled) only appeared once the billing address was being edited, because it was rendered as an input field only, which WooCommerce hides until the pencil is clicked. It is now shown as soon as the order is opened, with the input still there for editing.
• Fix: When building a manual order in the admin, the Briqpay fields (the organisation number) did not appear until the order had been saved with Briqpay as its payment method. They now follow the payment method dropdown and appear the moment Briqpay is chosen.
• Fix: On the WooCommerce Checkout Block with Briqpay as the only payment method, the payment box appeared to have no top edge. The block draws its payment box as an accordion whose top row is the payment method’s radio label; with that label hidden and the iframe’s own top spacing removed in 1.1.17, the iframe started exactly on the box’s top edge and painted over it. The iframe now sits inset from the top of the box the same way it does from the sides. Only the Checkout Block is affected; the classic checkout and themed checkouts are unchanged.
• Fix: On the [briqpay_b2b_checkout] page, the “Loading payment…” spinner shown while the payment window loads kept running behind the window for the whole session. It used to be replaced by the payment window itself; since 1.1.16 the window is laid over its spot rather than placed inside it, so nothing cleared the spinner. It is now removed as soon as the payment window is in place.
• Change: The reference stamped on the Briqpay session for a storefront purchase is now the order number, as hosted payment pages already sent, rather than the order ID. The two are the same unless a sequential-order-number plugin is installed, in which case the order number is the one the merchant and the customer actually see.
• Fix: The reference, the customer’s own order number and the alternative invoice email were still lost on every order, even after 1.1.19 set out to save them. Those three are not part of the order note module or the custom form that 1.1.19 reads – they belong to the invoice payment method, which reports them separately, and Briqpay only fills them in a few seconds to a minute AFTER the purchase is approved. The order is built the moment it is approved, so at that point there was nothing there to read. They are now read from the payment method’s own fields as well, and the order is topped up with them when the customer returns to the shop and again on every status update from Briqpay – so they arrive even if the customer closes the tab and never comes back. Each one is stored as order meta (_briqpay_payment_field_, keeping Briqpay’s own spelling of the field name) and listed in the same order note as the other checkout fields. Nothing is written when nothing has changed, so a repeated update adds no second note.
• Fix: An order note the customer wrote in the Briqpay checkout was stored as order meta but left out of WooCommerce’s own customer note field, which is where it is actually shown on the order screen and in the order emails. It now fills that field too, unless the customer already wrote a note in WooCommerce’s own checkout form – that one is never overwritten.

1.1.19

• Fix: Hosted payment pages sent with the “Business – Full Checkout” flow gave the customer no way to leave an order note. The storefront checkout takes the note in WooCommerce’s own form, but a hosted page has no such form, so the note field was simply missing. The flow now also loads Briqpay’s order note module.
• Fix: The shipping address’s company was always overwritten with the buying company’s name. Briqpay reports the recipient’s company on the shipping address separately, and on a B2B order that is often a different company – so orders showed the wrong recipient. The shipping company now comes from the shipping address, falling back to the buying company only when Briqpay reports none. Applies to the storefront checkout and to hosted payment pages.
• Fix: Fields the merchant collects in the Briqpay checkout – such as a reference, an own order number or an alternative email – were never saved to the order. The plugin now reads them from the order note module and the custom form, stores each one as order meta (_briqpay_order_note_ and _briqpay_custom_form_), and adds one order note listing them so they are visible on the order screen.
• Fix: An order Briqpay flagged for manual review could have its stock reduced twice and the customer sent two “order on hold” emails. The customer’s return to the store and Briqpay’s webhook often arrive in the same second, and both put the order on hold – each one triggering WooCommerce’s stock reduction and email. Every path that changes a Briqpay order’s status (the return, the webhooks and the stale-order cleanup) now takes the same per-order lock and re-reads the order once it has it, so only one of them acts. The manual-review hold is also applied only once per order: an order the merchant has already released is never put back on hold.
• Fix: If Briqpay’s webhook put an order on hold before the customer got back to the store, the return reset it to “Pending payment”, undoing the hold. The return now leaves an on-hold order as it is.
• Fix: The plugin’s internal locks were built on WordPress’s add_option(), which is not atomic: two requests could both take the same lock, and a request waiting for a lock kept seeing it as taken after it was released. Locks now use a single database insert that only one request can win, and read the database directly. This also hardens the existing duplicate-webhook check, which uses the same lock.
• Fix: When a request re-read an order after taking its lock, WordPress could hand back the copy it had cached earlier in the same request – still showing the old status and the old “stock reduced” flag. The order’s cache is now cleared first, for both WooCommerce order storage types, so the re-read reflects what other requests have saved.

1.1.18

• Change: The company block on order confirmation pages, emails and the admin order screen was headed “Company (Briqpay)”. It now reads simply “Company”, in every shipped language. The payment provider has no business in a heading the customer reads on their receipt.

1.1.17

• Fix: On stores where Briqpay is the only payment method, the checkout sat inside WooCommerce’s own lilac payment panel with a small arrow floating above its top-left corner. That arrow is WooCommerce pointing at the payment method’s radio button – which this plugin hides when there is only one method to choose, leaving it pointing at nothing – and the panel itself is a second, unstyled box around a checkout the theme has already styled. Its padding is also uneven once the theme adds spacing of its own below the iframe, which is what made the payment window look like it was sitting too high in the box. Both are now removed for that case, so the Briqpay checkout sits directly in the theme’s own layout. Stores offering other payment methods alongside Briqpay are unchanged: there the arrow and the panel still do their job. A theme can put either back with a rule of its own.

1.1.16

• Fix: The payment window reloaded twice on every single checkout refresh, which is what was visible as it bouncing. 1.1.14 and 1.1.15 tried to protect the iframe from WooCommerce rebuilding the payment box by lifting it out just before and putting it back just after. Measured on a live checkout, each of those two moves reloaded it: taking an element out of the page, even for an instant, throws away the iframe inside it, and it starts again from scratch when it goes back. The element itself survived the trip, which is why the earlier check said it was fine, and why 1.1.15’s attempt to stop the movement being visible could not help – the reload was the problem, not the movement. The iframe is now created once and never moved again for the life of the page, living outside the payment box entirely and simply kept lined up with the spot it belongs in. WooCommerce is free to rebuild that box as often as it likes. Verified by counting actual reloads through repeated refreshes: previously two per refresh, now none at all.
• Fix: The payment window no longer locks and unlocks constantly while filling in the checkout. It was suspended for the duration of every session sync, including the great majority that finish in a fraction of a second having found nothing to change. The pause now waits a moment before taking effect, so those never lock the window at all, while any update that genuinely reaches Briqpay still suspends exactly as before, well before an amount could change under the customer.

1.1.15

• Fix: On the classic and B2B checkout, the payment window visibly jumped on every checkout refresh, and everything below it shifted up and snapped back. Regression in 1.1.14: to survive WooCommerce rebuilding the payment box, that release moved the live iframe out of the box for the duration of the refresh – but simply moved it to the end of the page, so for the whole request the iframe sat at the bottom of the page while the space it had left collapsed to nothing. On a store that refreshes the checkout often (a VAT plugin validating in the background, for instance) that reads as the payment window bouncing around. The move is now invisible: the space it leaves is held open at exactly its height, and the iframe itself is pinned at precisely the position it occupied, so nothing on the page moves at any point. The iframe still survives the refresh untouched, as 1.1.14 intended. Confirmed against the bounce reproduced live, before and after.

1.1.14

• Fix: Correcting a queued session sync during checkout produced a visible resume-then-suspend flicker in the payment window. The code released the iframe (which Briqpay’s SDK refreshes on) before checking whether another update was already waiting, so a second update queued up behind the first immediately suspended it again a moment later. The iframe now stays suspended across the whole queue and is only released once, after the last update in it has actually finished.
• Fix: The background session-reconciliation hook added in 1.1.13 called the same method the browser’s own sync uses to decide whether anything needs sending – but that method’s shortcut for “nothing changed, skip” only applies when the caller can prove the browser already has this exact session on screen, which a server-side hook reacting to a WordPress action never can. It therefore sent a PATCH to Briqpay on every single recalculation regardless of whether anything had actually changed, rather than the occasional one the earlier release described. Added a purpose-built method for a caller with no browser response to answer, whose shortcut depends on nothing but whether the payment-relevant data actually changed.
• Fix: On the classic and B2B checkout layouts, WooCommerce rebuilds the entire payment methods box – every gateway’s own fields included – on every single checkout refresh, unconditionally, by core design; a payment plugin has no way to opt a specific gateway out of it. That meant the Briqpay iframe was destroyed and rebuilt from scratch on every address, shipping or coupon change, not only losing the SDK’s own state but, in principle, any card details a customer had already started typing directly into it. The live iframe now lives in a separate, permanent element that is pulled out of the payment box just before WooCommerce replaces it and moved back the instant the replacement finishes – a same-document move, so the iframe itself is never actually removed from the page and is never rebuilt. Not applicable to the WooCommerce Checkout Block, which renders and updates its payment area a different way that was never affected by this.

1.1.13

• Fix: A VAT-exempt line was sent to Briqpay claiming the product’s normal tax rate – taxRate 2500 next to a VAT amount of zero – because the rate was looked up from the product’s tax class, which says what the product would be taxed at rather than what this customer was actually charged. The rate now comes from the tax applied to the line, so an exempt customer, a zero-rated product and a store with tax switched off all report zero, as they always should have. Coupon lines read the rate the same way. Note that a cart mixing several VAT rates still reports its whole discount at the first line’s rate.
• Fix: The recurring shape of the last several releases – the checkout showing the right amount, but only sometimes, in a way that depended on timing – is addressed at its root rather than patched again. Every previous fix in this area made the browser’s own guess about when to ask the server for a fresh amount more reliable, but that guess still ran as a separate request, racing whatever else was recalculating the cart (most concretely, a VAT plugin’s own background validation call) – and whichever request finished last won, regardless of which one was actually right. The Briqpay session is now reconciled from directly inside WooCommerce’s own total-recalculation process itself, in the same request that computes the final amount, for every plugin’s recalculation and not only this one’s own – so there is no second request left to race. This runs alongside the existing sync rather than replacing it, and only while Briqpay is the checkout’s chosen payment method. Added briqpay_sync_on_cart_recalculation to switch it off on a live store without a rollback, should it ever need it.

1.1.12

• Fix: Follow-up to 1.1.11, which stopped short of the moment the payment is completed. The VAT exemption is now also put back before the cart is recalculated as the payment is decided. That request carries only a payment session ID, so nothing re-applied the exemption and the cart was priced at full VAT for an exempt customer. That figure is what gets checked against the amount held by Briqpay, and a mismatch pushes the cart’s figure back – so the customer could be charged VAT while the order was correctly recorded as exempt. Because 1.1.11 corrected the order but not this, the charge and the order could disagree with each other; they now agree.
• Fix: A payment can no longer be decided while WooCommerce is in the middle of recalculating the checkout. It previously waited only for this plugin’s own pending updates, so in the window between WooCommerce starting a refresh and finishing one – exactly when a VAT number validated in the background changes the total – a customer clicking pay had the purchase decided against the amount from before the refresh. It now waits for WooCommerce to settle, with a ten second ceiling measured from the moment the payment was held, so neither a refresh that never reports back nor a plugin that refreshes the checkout on a timer can leave the customer unable to complete the purchase. Added briqpay_defer_decision_during_update to switch this off on a live store without a rollback, should it ever need it.

1.1.11

• Fix: On a checkout using a third-party VAT plugin, a customer who entered a valid VAT number could be shown – and charged – the amount with VAT still on it. Three separate things had to be right for the ex-VAT amount to reach the payment window, and each could fail on its own. First, the checkout now fires WooCommerce’s own 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.
• Fix: A plugin that refreshes the checkout twice for one change – a VAT plugin does exactly this, once when the number is entered and again when its VIES lookup answers – could have the second refresh dropped. If it landed while the payment session was still being created it was discarded, and nothing came along afterwards to reconcile it, so the payment window kept the amount from before the lookup. The second refresh is now always picked up, whether it arrives during the session being created or while an earlier sync is still running.
• Fix: The VAT exemption is now recorded when the amount is calculated and applied to the order from there. The request that creates the order carries only a payment session ID – there is no VAT number in it for a VAT plugin to act on – so asking at that point reported a customer who had proven their exemption as paying VAT, and the order and its confirmation were rebuilt with VAT the customer had been told they would not pay. Added the 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.

1.1.10

• Fix: Entering (or removing) a VAT number in the Briqpay checkout showed the correct VAT-exempt total in the payment window itself, but the order confirmation and the admin order screen still showed VAT. WooCommerce’s own checkout stamps the customer’s VAT-exempt decision onto the order before totals are calculated; this plugin’s own order-creation path skipped that step, so the order’s own tax calculation never learned about the exemption even though Briqpay had already applied it. The exemption is now stamped onto the order the same way WooCommerce’s native checkout does.
• Fix: A hosted payment page (or any other order that reaches “paid” purely through a capture confirmation, with no separate approval step beforehand) kept showing “PSP Name: N/A”, “Integration: N/A” and “Reservation ID: N/A” on the order screen forever, even after the order fully captured. That information was only ever filled in by the approval step, which a hosted payment page never receives by design. It is now also filled in when a capture is confirmed.

1.1.9

• Fix: A stock hold could be applied twice for the same order – “Stock hold of N minutes applied to…” appearing twice in the order notes, one after another. This plugin replays WooCommerce’s own 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.
• Fix: Two requests hitting the Briqpay return page within the same second – seen when the browser’s own completion redirect fires twice in quick succession – could each start the checkout-completion hooks before either had recorded that it was already running, so …