OXID eShop bugtrack - Issues

0007682: Shipping costs are charged twice

Fri, 08 May 2026 09:28:48 +0200

The shipping costs are displayed or calculated twice in both the shopping cart and the checkout (e.g. 10 euros are displayed instead of 5 euros) until the shopping cart is recalculated, e.g. by clicking on "Address" on "Payment and shipping" in the checkout or by increasing the number of products in the shopping cart. After this, the shipping costs remain correct and are no longer displayed incorrectly even if the shopping cart is completely emptied. When you log in again, the shipping costs are displayed incorrectly again.

0007944: Vouchers in PayPal

Thu, 07 May 2026 16:59:36 +0200

We are currently facing an issue where vouchers are not being passed to PayPal, and the voucher is not attached to the order record following a successful checkout.
This issue occurs exclusively with the standard PayPal workflow, as it always proceeds via the following path:
if (PayPalDefinitions::isProxyControllerPayment($sessionPaymentId)) { ... }
The root cause lies in the function `\OxidSolutionCatalysts\PayPal\Model\Order::_markVouchers`. (Edited)

0007945: provide `paypaltrackingcarrier` and `paypaltrackingcode` with the send()-function does not work

Thu, 07 May 2026 16:59:05 +0200

PayPal tracking submission is not working because the `paypaltrackingcarrier` and `paypaltrackingcode` fields on the order object are not being set when the `send()` function is called. Furthermore, it is problematic that within the Order Admin interface, OXID's native tracking fields—such as `oxorder__oxtrackcode`—are being overwritten by the PayPal-specific fields; consequently, it is no longer apparent to the customer whether their order was shipped with a tracking code.

0007946: remove storno-flag if paypal heal a pending order

Thu, 07 May 2026 16:58:24 +0200

If there is a genuine pending order from PayPal, it is initially moved to the ERROR status and cancelled. If PayPal subsequently marks the order as paid after a short while, the status is indeed updated to OK and the order is marked as paid; however, the OXSTORNO field remains set, and the order continues to be displayed as "Cancelled" within the admin interface. The cancellation status must definitely be removed, and—if possible—the "Pending" order status should perhaps be utilized in cases where the order corresponds to a "Payment Pending" status within PayPal.

0007941: When using Ideal (uAPM) sometimes no order confirmation email is sent to owner and customer

Thu, 07 May 2026 15:19:27 +0200

Installed PayPal 2.8.4-rc (in CE/PE 6.5.5).
In addition to PayPal, the Amazon Pay module (2.2.0) is also active in the payment process.

An error has now occurred with IDEAL (uAPM):
The payment and order were processed successfully. However, no order confirmation email was sent to the shop owner or the customer in this instance.

0007943: Issue since the PayPal update v2.8.3: Stripe credit card payments are failing

Thu, 07 May 2026 15:14:40 +0200

When making a payment via the Stripe module using a credit card with 3DS, after entering the details you are redirected back to the payment page with the error ‘Order could not be found’.
No order has been created in the shop admin, but a capture has been triggered on the Stripe side

0007924: Issue since the PayPal update: Mollie credit card payments are failing at checkout

Thu, 07 May 2026 15:12:13 +0200

Shop environment:
OXID eShop CE 6.5.3
PayPal Checkout module currently v2.8.3
PayPal Client 3.0.20
Mollie module 1.1.2

The problem has occurred since the PayPal module was updated to v2.8.2 or v2.8.3

Symptoms:
In the frontend, an order is processed normally up to the payment stage
When selecting credit card via Mollie, the payment process is initiated
Afterwards, the customer is redirected back to order step 3 the payment methods
The message appears: “Order could not be found”

0006998: Ship Now email can only be sent in admin languages

Thu, 07 May 2026 09:50:23 +0200

If you have more languages than german and english (maybe french), it is not possible to send an "order send" email in the different language. CMS snippets are translated but the language vars are in german and not in french.

0007942: Verhalten bei Änderung der E-Mail - Änderung der E-Mail nicht möglich

Wed, 06 May 2026 17:06:59 +0200

Wenn ich bei meinem Account versuche meine E-Mail zu ändern (in diversen Shops), kommt zusätzlich eine Passwortabfrage.

Egal was ich eingebe, ich kann die E-Mail nicht ändern, weil ich die alte E-Mail neu eingeben muss.

Dieser Workflow wirkt komisch.

Es gibt Fälle wo diese Passwortabfrage nicht kommt (Ich konnte nicht rausfinden warum?).

Ich würde erwarten das es eher eine Bestätigung - E-Mail kommt, in der ich meine E-Mail bestätigen muss bevor die Änderung aktiv wird, anstatt einer Passwortabfrage.

Ich habe ein Video angehängt wie das bspw. aussieht, hier in unserem Theme, aber genauso ist das ganze auch in anderen Themes oder einem DemoShop nachzustellen.

0006135: redundant article title + varselect logic in smarty

Wed, 06 May 2026 14:50:13 +0200

The business logic that combines a variants/parents title and its varselect value to the displayed string is redundantly done about 50 times directly in smarty.

This logic sould really be moved into php (probably oxarticle, oxbasketitem & oxorderitem).
Only then it would be possible to modify the varselect logic with modules without producing a tpl mess.

0007940: Case here with two orders from one customer that I unfortunately can't trace

Thu, 30 Apr 2026 15:48:08 +0200

We have a case here with two orders from one customer that I unfortunately can't trace. The customer claims she only placed one order, but the shop has received two orders. The first, presumably unintentional, was placed via PayPal Express at 5:39:33 AM (order number 106552), and the second was placed via regular PayPal at 5:40:06 AM (order number 106553).

The access log shows two POST requests to /index.php? (likely to cl=order, because they were preceded by a GET request to /index.php?cl=order) at 5:39:25 AM and 5:39:27 AM. It seems as if the customer somehow placed the order twice. The PayPal log also contains two (or rather three, since the last one is the second order at 5:40 AM) entries for "PayPal Payment Logger.DEBUG: finalizeOrder [] []" at 5:39:30 AM and 5:39:34 AM. These times are slightly different from the POST requests in the access log, but are likely due to the delay of the XHR calls in the frontend. The second finalizeOrder entry in the access log also redirects back to the payment methods with payerror=5. However, it seems that the unintended order was triggered precisely at this point (or shortly before).

No corresponding entries are found in the OXID exception or PHP error logs at that time.

The question now is how the customer unintentionally placed an order despite a payment error being triggered.

0007939: Customers with Apple iPhones and the "Google Search App" cannot log in (only loading animation is displayed).

Thu, 30 Apr 2026 14:00:46 +0200

WKWebView in app containers (the one used in the Google Search app on iOS) handles pop-ups with restrictions. The PayPal SDK opens the login via a pop-up window—if this is blocked by the container or malfunctions, the user never reaches the Approve page.

The log shows exactly what we see: `createOrder` runs, `PAYER_ACTION_REQUIRED` hangs, and no `onApprove` event is triggered.

Apple ITP/Cookie restrictions disrupt the cross-domain journey (shop <-> paypal.com <-> shop) if the user does manage to log in to PayPal.

0007934: Console Tools: oe-console commands incorrectly return exit code 0 on failure

Wed, 29 Apr 2026 09:26:13 +0200

Four console commands in the OXID eShop CLI (vendor/bin/oe-console) do not signal failure via the exit code. They terminate with exit code 0 (success) even though the operation failed. The error is printed to STDOUT as ..., but the exit code remains 0.

This is problematic for:
- CI/CD pipelines: Build scripts cannot detect failures and continue executing even when, for example, a license was not installed.
- Shell scripts: Constructs like command && next-step or set -e do not work reliably.
- Automation: Provisioning tools (Ansible, Docker setup scripts, Make targets) cannot handle failures correctly.

Affected commands and code locations
- oe:license:add
- oe:module:activate
- oe:module:deactivate
- oe:setup:demodata

0007933: Console Tools: Incorrect output for --version

Wed, 29 Apr 2026 08:12:11 +0200

When running "vendor/bin/oe-console --version", the command returns "Console Tool". It should display the actual version number instead.

0007930: Missing translation "SHOP_MALL_MALLINHERIT_OXNEWS" in Subshops

Wed, 29 Apr 2026 08:09:05 +0200

Translation error "SHOP_MALL_MALLINHERIT_OXNEWS" in the Mall tab of the subshop. The label text for the news inheritance option is missing here. The same error since version 7.4.

0007935: Add support for AliPay and WeChat Pay in PayPal Checkout module

Tue, 28 Apr 2026 18:54:23 +0200

Hello,

currently the PayPal Checkout module (osc/paypal) is used in an OXID eShop 6.4.x environment.

PayPal has extended its Checkout offering with additional alternative payment methods, including AliPay and WeChat Pay. However, these payment methods are currently neither available nor configurable within the OXID PayPal module.

From a technical perspective, the PayPal JavaScript SDK supports multiple funding sources, but the module seems to limit or not expose certain payment methods. In particular, there is currently no way to enable or integrate AliPay or WeChat Pay via configuration or standard module functionality.

It is understood that these payment methods may require additional handling (e.g. eligibility checks, regional availability, different checkout flows, or backend adjustments). Nevertheless, support for these methods would be highly valuable, especially for merchants targeting international customers.

Therefore, it would be appreciated if support for the following payment methods could be considered in a future version of the module:
- AliPay
- WeChat Pay

Thank you in advance.

0007932: VCMS 9.2: Image reference missing after reopening an entry

Tue, 28 Apr 2026 13:57:48 +0200

After adding a carousel widget, editing the widget causes the image reference to be lost

0007929: Fehler bzgl. Tausendertrennzeichen im Rückerstattungsbetrag

Mon, 27 Apr 2026 11:28:59 +0200

Folgende Meldung aus unserem Log

PayPal Payment Logger.ERROR: RES | POST | /captures/64U701349R9605015/refund | POST https://api.paypal.com/v2/payments/captures/64U701349R9605015/refund returned: 400 Bad Request
Returned Message: Request is not well-formed, syntactically incorrect, or violates schema
Error Details:
[{"issue":"INVALID_PARAMETER_SYNTAX","field":"\/amount\/value","value":"5,326.00","description":"The value of the field does not conform to the expected format.","location":"body"}]

Ich denke, hier wäre entweder eine Logik zur automatischen Umformatierung oder aber eine Fehlermeldung nötig, welche den Benutzer darauf hinweist, dass es ein Problem gab und wie die Werte zu formatieren sind.

0007927: Error when ordering by credit card if the first attempt is declined

Sat, 25 Apr 2026 10:38:12 +0200

If the first credit card attempt fails due to a rejection (INSUFFICIENT_FUNDS, DO_NOT_HONOR), you are redirected back to the payment page; however, the next order with valid credit card details is not charged due to ‘authorisation failed’.
After confirming again, you are redirected to the thank you page.

Three orders are created.
1. Order error and cancelled.
2. Order not finished and not cancelled
3. Order not finished and not cancelled

PayPal Checkout tab:
1. Order status: declined
2. Order notification: The order was abandoned during checkout and automatically cancelled.
2. Order notification: The order was abandoned during checkout and automatically cancelled.

0007928: PayPal log message: DEVICE_DATA_NOT_AVAILABLE

Fri, 24 Apr 2026 17:52:08 +0200

The following message is logged in the PayPal log: DEVICE_DATA_NOT_AVAILABLE

The message states that there is an issue with the PayPal Client Metadata ID header.
I found two places in the code where this MD5 hash is generated: getPayPalPuiFraudnetCmId() in the OrderController and PaymentController.

0007926: Changing variants on the detail page results in a JavaScript error if performed multiple times

Fri, 24 Apr 2026 13:26:27 +0200

PPC module update 2.8.3 installed with the RoxIVE theme.

As a result, it was no longer possible to switch between variants on the product detail page of the frontend once PayPal Express was activated.
To be more precise: the first variant switch still worked, but all subsequent ones were no longer possible.

Technical background:
When switching variants, part of the detail page is reloaded. Apparently, the same initialisation logic is executed in all loading processes, but when executed multiple times, it results in a JavaScript error. This causes the variant switch to be aborted:
Uncaught SyntaxError: redeclaration of let buttonPayPalButtonProductMain

0006240: Full urls are used for recources

Thu, 23 Apr 2026 20:14:15 +0200

Full urls are used in the html source instead of relative urls.

in the html source you find recourses (javascript, pictures and more) to be linkd with the full URL

What i expected:

Recources should be linked without the full URL because adding this URL

0007925: Keine Fehlermeldung bei verdrehter shipping/address/admin_area_2 Angabe

Thu, 23 Apr 2026 14:02:02 +0200

Haben mehrere Fälle im Paypal Log beobachtet, bei denen eine 422 Unknown Error bzw. Unprocessable Entity Response mit der Ursache "CITY_REQUIRED" oder "REQUIRED_PARAMETER_FOR_PAYMENT_SOURCE" von Paypal zurückkam. Beide beziehen sich auf das Feld shipping/address/admin_area_2 im Request, welches aus einem unbekannten Grund die Postleitzahl des Benutzers beinhaltet hatte. Gleichzeitig war der Name der Stadt im Feld shipping/address/postal_code zu finden. Also verdreht. Wie das passiert ist - keine Ahnung. Kann mir vorstellen, dass die Adresse so via Paypal Express reinkam oder schon ewig so im Benutzerkonto hinterlegt war und sonst nie anderweitig validiert wurde.

Unschön ist hier nun, dass der Benutzer in so einem Fall keinerlei Info dazu bekommt, was kaputt ist. Wenn er via Kreditkarte bezahlt, kommt kurz der Spinner vom Paypal Overlay aber schließt sich direkt wieder und zeigt die Bestellübersicht (Schritt 4) ohne irgendeine Fehlermeldung.

Im Netzwerktab vom Browser ist der passenden Request zu finden und der zeigt als Response vom Server die Offline-Seite vom Shop. Es wurde also eine Exception ausgelöst und nicht gefangen. Die Exception kommt in dem Fall aus AjaxPaymentController->createAcdcOrder() und dort dem doCreatePatchedOrder()-Aufruf (https://github.com/OXID-eSales/paypal-module/blob/b-6.3.x/src/Controller/AjaxPaymentController.php#L448) Dieser ist nicht von einem Try-Catch Block umschlossen.

Und selbst wenn der doCreatePatchedOrder()-Aufruf in den dadrüberliegenden Try-Catch-Block geschoben wird, weiß der JS-Teil im Frontend anscheinend nichts mit der "error" > "failed to execute shop order" Response anzufangen. Heißt, es wird keinerlei Fehlermeldung á la "Ungültige Postleitzahl" angezeigt oder irgendwohin (Schritt 2 Adresseingabe wäre wohl am sinnvollsten) zurückgeleitet.

0007923: PayPal checkTermsAndConditions = false

Thu, 23 Apr 2026 11:01:38 +0200

If you have a product which is not a downloadable one but require the additional checkbox in last step of the checkout (oxnonmaterial => oxserviceproductsagreement) the paypal checkout module doesn't check for it and it will show a notice that you need to accept the terms and conditions even if you checked it. You will be stuck in the last step of the checkout and can't finish with paypal checkout.

0007367: Recommended Composer version breaks removing of console commands

Thu, 23 Apr 2026 07:32:27 +0200

If you use recommended Composer version 2.2, running composer remove for an extension introducing a custom OE Console command, results in an error on Composer execution. See first note for the error written to oxideshop.log.

After updating to current Composer version 2.4, the executions runs without errors, but this version is not recommended for current OXID eShop 6.5:
https://docs.oxid-esales.com/eshop/en/6.5/installation/new-installation/server-and-system-requirements.html#composer