Skip to content

Release 6.4.3#1377

Open
TLabutis wants to merge 91 commits intomasterfrom
release-6.4.3
Open

Release 6.4.3#1377
TLabutis wants to merge 91 commits intomasterfrom
release-6.4.3

Conversation

@TLabutis
Copy link
Copy Markdown
Collaborator

Questions Answers
Branch? Master/Release
Description? Please be specific when describing the PR.
Every detail helps: versions, browser/server configuration, specific module/theme, etc. Feel free to add more information below this table.
Type? bug fix / improvement / new feature / refactoring
How to test? Indicate how to verify that this change works as expected.
Fixed issue ? If none leave blank

Tadas Labutis and others added 30 commits March 2, 2026 19:30
The `unset($items)` call only removed the local foreach variable, not the
actual entry in `$orderLines`. When a discount line was iterated first and
its totalAmount was less than remaining, the remaining value was inflated
instead of the line being removed — causing product prices to be distorted
by the full discount amount. This made the Mollie line totals diverge from
the order total, triggering "An error occurred while initializing your
payment".

Fixed by using `unset($orderLines[$hash])` and skipping non-product lines
(discount, shipping) so only physical/digital products are adjusted.
…ed" error

Add early savePaymentStatus() call immediately after createOrder() on the
Payment API path, matching the Order API path pattern (MOL-608, commit f236106).

This writes order_id to mollie_payments right after order creation instead of
at the end of webhook processing, eliminating the 5-27 second window where the
return page cannot find the payment link and shows a false error to customers.

Affected methods: iDEAL, Bancontact, PayPal and other Payment API methods.
Order API methods (Klarna, in3) were not affected as they already had this fix.
…tion

PIPRES-720: implement fallback to find correct payment
…into BUGFIX/PIPRES-720-payment-api-race-condition
…ce-condition

PIPRES-720 Fix Payment API race condition causing false payment failed error
fix: Replace "&" to "and" in name to bypass validation rules
fix: geolocation and webhook fix with inactive country
PIPRES-727: redirect to order confirmation instead of custom page for banktransfer/card
…-id-bug

INTERNAL: pay by bank transaction id update on open status
shippingAddress.givenName and familyName incorrectly referenced
getBillingAddress() instead of getShippingAddress() in PaymentData.php
GytisZum and others added 30 commits April 14, 2026 10:28
PIPRES-633 - PIPRES-631: add Croatian and Lithuanian translations
PIPRES-737: back office order creation bug
PIPRES-742: order creation improvement on failed description update
PIPRES-744: Implement association domain check and add banner in apple pay direct tab
…tive-country

PIPRES-724: fix apple pay direct payment then country is not active in shop
BUG-FIX: race condition prevention bug fix
PIPRES-629: add new translations el, et, is, lv, ro, sk
PIPRES-742: Fix rounding distribution for whole-number differences in order line amounts
INTERNAL Code standards fixes, unit tests, stan error fixes
…g-prefill

PIPRES-741 Restore shipment tracking pre-fill in Ship modal
…rs-api

PIPRES-738 Restore partial quantity support for Orders API order line actions
…name

PIPRES-735 Fix shipping address using billing name in Payments API
…eroundinginaccuracies

PIPRES-726 Fix unset bug in compositeRoundingInaccuracies causing payment failures
Per-line Capture button now greys out for the exact line that was
captured (previously only reacted to the global capturable counter,
so a captured line could be clicked again and trigger a duplicate
capture or 422). Refund button is now only enabled on lines that
were actually captured and not yet refunded. Button state is
precomputed in PHP with an epsilon tolerance to avoid float drift
in the template comparison.
With a discount, the authorized amount is lower than the sum of
product lines, so per-line capture cannot work reliably - one line
always ends up stuck (not capturable, not refundable). Hide the
per-line buttons in that case; merchants can still use the top-level
Initiate Capture and Initiate Refund amount inputs.
PIPRES-754: Fix Apple Pay Direct address and orphaned records bugs
PIPRES-757: Add manual capture support for Payments API methods
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants