<?xml version="1.0" encoding="utf-8"?>
<!--RSS generated by Flaimo.com RSS Builder [2026-06-04 20:52:51]-->
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"><channel><docs>https://bugs.oxid-esales.com/</docs><link>https://bugs.oxid-esales.com/</link><description><![CDATA[OXID eShop bugtrack - Issues]]></description><title>OXID eShop bugtrack - Issues</title><image><title>OXID eShop bugtrack - Issues</title><url>https://bugs.oxid-esales.com/images/mantis_logo.png</url><link>https://bugs.oxid-esales.com/</link><description><![CDATA[OXID eShop bugtrack - Issues]]></description></image><language>en</language><category>All Projects</category><ttl>10</ttl><dc:language>en</dc:language><sy:updatePeriod>hourly</sy:updatePeriod><sy:updateFrequency>1</sy:updateFrequency><item><title>0007958: Missing functions on notice list in mobile view</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7958</link><description><![CDATA[In the mobile view it is not possible to remove items from the notice list and it is also not possible to put items from the list in the cart.]]></description><category>1.08. Listmania, Notice list, Gift registry</category><pubDate>Thu, 04 Jun 2026 10:24:08 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7958</guid><comments>https://bugs.oxid-esales.com/view.php?id=7958#bugnotes</comments></item><item><title>0007880: Price calculation in e-mails wrong when a % discount is applied to an order</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7880</link><description><![CDATA[When placing an order with an valid % discount the price calculation in e-mails is wrong.&lt;br /&gt;
The calculation displayed in the frontend is ok at the checkout, in the backend at the order page it is also ok.&lt;br /&gt;
It affects only the sent mails to customer and owner.&lt;br /&gt;
&lt;br /&gt;
See attached picture.&lt;br /&gt;
&lt;br /&gt;
We noticed this in our online shop with Oxid 7.2 and Apex based theme 2.0.0 but i have installed an actual shop 7.4 with Apex 3.0.2 to verify if the error still exists or if it is fixed already]]></description><category>1.02. Price calculations (discounts, coupons, additional costs etc.)</category><pubDate>Wed, 03 Jun 2026 17:30:47 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7880</guid><comments>https://bugs.oxid-esales.com/view.php?id=7880#bugnotes</comments></item><item><title>0007952: oxparams context will be removed from stdUrl after update</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7952</link><description><![CDATA[When updating the Seo-URL of a product for a specific category, the context(cnid/mnid/vnid) will be removed from the stdUrl.&lt;br /&gt;
index.php?cl=details&amp;anid=05848170643ab0deb9914566391c0c63&amp;cnid=0f41a4463b227c437f6e6bf57b1697c4 --&gt; index.php?cl=details&amp;anid=05848170643ab0deb9914566391c0c63]]></description><category>4.09. SEO, SEO URL</category><pubDate>Tue, 02 Jun 2026 17:31:22 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7952</guid><comments>https://bugs.oxid-esales.com/view.php?id=7952#bugnotes</comments></item><item><title>0007957: Payment method oscpaypal - inheritance chain for markVouchers is skipped and vouchers are not properly marked as used</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7957</link><description><![CDATA[In the file Model/Order.php the markVouchers method is overwritten: &lt;br /&gt;
    protected function markVouchers($oBasket, $oUser) // phpcs:ignore PSR2.Methods.MethodDeclaration.Underscore&lt;br /&gt;
    {&lt;br /&gt;
        $sessionPaymentId = (string) $this-&gt;getPaymentService()-&gt;getSessionPaymentId();&lt;br /&gt;
&lt;br /&gt;
        // Skip markVoucher if finalizeOrder is called in the proxyController.&lt;br /&gt;
        if (PayPalDefinitions::isProxyControllerPayment($sessionPaymentId)) {&lt;br /&gt;
            return null;&lt;br /&gt;
        }&lt;br /&gt;
&lt;br /&gt;
        return parent::markVouchers($oBasket, $oUser);&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
For payment methods like &quot;oscpaypal&quot; this means that that vouchers are never marked as used, only ever as reserved. And any module logic that depends on the inheritance chain of that method gets skipped.&lt;br /&gt;
&lt;br /&gt;
We implemented a temp fix in EventSubscriber/PayPalOrderCompletedSubscriber.php, where we call a copy-pasted version of the markVouchers method.]]></description><category>module PayPal checkout - sub</category><pubDate>Tue, 02 Jun 2026 09:22:18 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7957</guid><comments>https://bugs.oxid-esales.com/view.php?id=7957#bugnotes</comments></item><item><title>0007944: Vouchers in PayPal</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7944</link><description><![CDATA[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.&lt;br /&gt;
This issue occurs exclusively with the standard PayPal workflow, as it always proceeds via the following path:&lt;br /&gt;
if (PayPalDefinitions::isProxyControllerPayment($sessionPaymentId)) { ... }&lt;br /&gt;
The root cause lies in the function `\OxidSolutionCatalysts\PayPal\Model\Order::_markVouchers`. (Edited)]]></description><category>module PayPal checkout - sub</category><pubDate>Tue, 02 Jun 2026 09:22:18 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7944</guid><comments>https://bugs.oxid-esales.com/view.php?id=7944#bugnotes</comments></item><item><title>0007956: oxbillustidstatus stays 0, even with oxustidstatus is 1</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7956</link><description><![CDATA[EE Field oxbillustidstatus seems to be never updated to 1 in a normal workflow of register -&gt; order.]]></description><category>2.6. Administer orders</category><pubDate>Fri, 29 May 2026 17:24:30 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7956</guid><comments>https://bugs.oxid-esales.com/view.php?id=7956#bugnotes</comments></item><item><title>0007955: Unfinished orders are not cleaned up</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7955</link><description><![CDATA[the function cleanUpNotFinishedOrders() in Service/OrderRepository.php gets called from the webhook. I can see custom log entries before the execution of the query in this function but not afterwards. The orders are not being canceled.]]></description><category>module PayPal checkout - sub</category><pubDate>Thu, 28 May 2026 14:58:42 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7955</guid><comments>https://bugs.oxid-esales.com/view.php?id=7955#bugnotes</comments></item><item><title>0007937: Stored XSS via SVG upload in media-library-module (executes on direct SVG URL)</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7937</link><description><![CDATA[Media library accepts `.svg` uploads without sanitization. Direct request to the stored SVG is served as `image/svg+xml`, executing embedded `&lt;script&gt;` in the shop origin.&lt;br /&gt;
&lt;br /&gt;
Expected&lt;br /&gt;
Reject upload, sanitize content, or serve with non-active content type / `Content-Disposition: attachment`.&lt;br /&gt;
&lt;br /&gt;
Actual&lt;br /&gt;
Browser executes the embedded JavaScript in the shop's origin (cookie / session accessible).&lt;br /&gt;
&lt;br /&gt;
Impact&lt;br /&gt;
Anyone with upload access can host JS on a shop URL. A victim following the link executes the script under the shop origin -&gt; session theft, authenticated actions.]]></description><category>4.04. Security</category><pubDate>Wed, 27 May 2026 10:01:25 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7937</guid><comments>https://bugs.oxid-esales.com/view.php?id=7937#bugnotes</comments></item><item><title>0007938: Insufficient filename validation in media-library upload (defense-in-depth)</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7938</link><description><![CDATA[The validator chain executed during media-library file upload performs only minimal checks on the filename submitted by the client (non-empty, does not start with a dot, allowed extension). Filenames that carry path-related metadata are not rejected. The downstream code uses a path-joining helper that interprets such metadata when assembling the storage location, and the filesystem layer auto-creates intermediate directories.&lt;br /&gt;
&lt;br /&gt;
In the current production runtime stack the attack is neutralised by a sanitisation step performed outside the application code. No successful escape from the media folder was reproduced in the standard environment. However, the application itself provides no defense. The protection is provided incidentally by an external layer that the application neither knows nor controls.&lt;br /&gt;
&lt;br /&gt;
Expected&lt;br /&gt;
The application's filename validator rejects filenames containing path metadata or empty-segment patterns and aborts the upload with a validation failure, regardless of any sanitisation performed by lower layers.&lt;br /&gt;
&lt;br /&gt;
Actual&lt;br /&gt;
The application's validator accepts such filenames. The final storage location is determined by an external sanitisation step that is not part of the application code.&lt;br /&gt;
&lt;br /&gt;
Impact&lt;br /&gt;
- Today: no observable impact in the standard runtime stack.&lt;br /&gt;
- Latent: any change to the upload pipeline that bypasses the runtime-level sanitisation. Modern HTTP-foundation components, GraphQL upload handlers, alternative process models, an upstream proxy with its own multipart pre-processing turns this into an arbitrary file-write inside the shop tree. In combination with content-type issues already on file (see related ticket), this becomes a persistent attack on the shop origin.]]></description><category>4.04. Security</category><pubDate>Wed, 27 May 2026 10:01:16 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7938</guid><comments>https://bugs.oxid-esales.com/view.php?id=7938#bugnotes</comments></item><item><title>0007949: When activating easycredit and unzer, you’ll end up in maintenance mode.</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7949</link><description><![CDATA[System Settings:&lt;br /&gt;
PHP 8.4.19&lt;br /&gt;
&lt;br /&gt;
Module:&lt;br /&gt;
Unzer Payment für OXID 2.2.6&lt;br /&gt;
easyCredit-Ratenkauf für OXID 4.0.2]]></description><category>General</category><pubDate>Tue, 26 May 2026 10:55:29 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7949</guid><comments>https://bugs.oxid-esales.com/view.php?id=7949#bugnotes</comments></item><item><title>0007951: Incorrect PayPal orders with the status “COMPLETED” and payment made before the order was placed</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7951</link><description><![CDATA[Two faulty PayPal orders have been identified. &lt;br /&gt;
Both have the oxorder__oxtransstatus set to “COMPLETED” instead of “OK”, and in both cases the oxorder__oxpaid timestamp is a good two hours earlier than the actual oxorder__oxorderdate, which is not possible. &lt;br /&gt;
Both orders also had a payment ID that matches a second, successful order placed shortly afterwards (but using a different payment method) by the same customer. &lt;br /&gt;
1st order (PayPal) followed by 122611002 (invoice purchase) &lt;br /&gt;
2nd order 122608727 (credit card) followed by 122608729 (invoice purchase).&lt;br /&gt;
&lt;br /&gt;
In both orders, the customer initially started with PayPal / credit card, then switched to invoice purchase.]]></description><category>module PayPal checkout - sub</category><pubDate>Fri, 22 May 2026 13:16:49 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7951</guid><comments>https://bugs.oxid-esales.com/view.php?id=7951#bugnotes</comments></item><item><title>0007954: For PayPal orders, the oxtrackcode is not saved in the oxorder table</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7954</link><description><![CDATA[If you enter the oxtrackcode in the admin panel, it is not saved in the oxorder_oxtrackcode table for PayPal orders.&lt;br /&gt;
As a result, the tracking ID is no longer displayed to the customer in the frontend -&gt; Order History.]]></description><category>module PayPal checkout - sub</category><pubDate>Fri, 22 May 2026 13:16:31 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7954</guid><comments>https://bugs.oxid-esales.com/view.php?id=7954#bugnotes</comments></item><item><title>0007948: When activating easycredit and unzer, you’ll end up in maintenance mode.</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7948</link><description><![CDATA[System Settings: &lt;br /&gt;
PHP 8.4.19&lt;br /&gt;
&lt;br /&gt;
Module:&lt;br /&gt;
Unzer Payment für OXID 2.2.6&lt;br /&gt;
easyCredit-Ratenkauf für OXID 4.0.2]]></description><category>General</category><pubDate>Fri, 22 May 2026 09:10:57 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7948</guid><comments>https://bugs.oxid-esales.com/view.php?id=7948#bugnotes</comments></item><item><title>0007727: Increase bcrypt cost</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7727</link><description><![CDATA[PHP will increase the default cost value to 12 with PHP 8.4 of the bcrypt algorithm(*1). The current value was last changed in 2012 and the hardware became better by now. So it should be considered to increase our defined cost value as well(*2): &lt;a href=&quot;https://github.com/OXID-eSales/oxideshop_ce/blob/c7fffe8b2143ad8dc4c7598a9baecec174ad77ba/source/Internal/Utility/Hash/services.yaml#L2&quot; rel=&quot;noopener,nofollow&quot;&gt;https://github.com/OXID-eSales/oxideshop_ce/blob/c7fffe8b2143ad8dc4c7598a9baecec174ad77ba/source/Internal/Utility/Hash/services.yaml#L2&lt;/a&gt;&lt;br /&gt;
&lt;br /&gt;
The cost can be changed without affecting the old hashes (*3), since the cost is part of the hash:&lt;pre&gt;
cost 10: $2y$10$SqQvqdiFw3R3.hv6g5sq0.M6hlXIRmqNk8tShKCW/5zgX86XudM56
cost 12: $2y$12$fKcaDQwFvCQGcz1uEFADhuZ73e5D/AHo/n3gor8BJVuNFBpfewnj2&lt;/pre&gt;Sources&lt;br /&gt;
*1. &lt;a href=&quot;https://wiki.php.net/rfc/bcrypt_cost_2023&quot; rel=&quot;noopener,nofollow&quot;&gt;https://wiki.php.net/rfc/bcrypt_cost_2023&lt;/a&gt;&lt;br /&gt;
*2. &lt;a href=&quot;https://securinglaravel.com/security-tip-increase-your-bcrypt/&quot; rel=&quot;noopener,nofollow&quot;&gt;https://securinglaravel.com/security-tip-increase-your-bcrypt/&lt;/a&gt;&lt;br /&gt;
*3. &lt;a href=&quot;https://symfony.com/doc/current/security/passwords.html#the-bcrypt-password-hasher&quot; rel=&quot;noopener,nofollow&quot;&gt;https://symfony.com/doc/current/security/passwords.html#the-bcrypt-password-hasher&lt;/a&gt;]]></description><category>4.04. Security</category><pubDate>Thu, 21 May 2026 16:26:23 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7727</guid><comments>https://bugs.oxid-esales.com/view.php?id=7727#bugnotes</comments></item><item><title>0007928: PayPal log message: DEVICE_DATA_NOT_AVAILABLE</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7928</link><description><![CDATA[The following message is logged in the PayPal log: DEVICE_DATA_NOT_AVAILABLE &lt;br /&gt;
&lt;br /&gt;
The message states that there is an issue with the PayPal Client Metadata ID header. &lt;br /&gt;
I found two places in the code where this MD5 hash is generated: getPayPalPuiFraudnetCmId() in the OrderController and PaymentController.]]></description><category>module PayPal checkout - sub</category><pubDate>Thu, 21 May 2026 14:54:43 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7928</guid><comments>https://bugs.oxid-esales.com/view.php?id=7928#bugnotes</comments></item><item><title>0007920: In the sub-shop, the fallback credit card is displayed even though it is not active</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7920</link><description><![CDATA[In the sub-shop, the fallback credit card is displayed even though the payment methods (PayPal credit or debit card and PayPal credit or debit card fallback) are not active.&lt;br /&gt;
However, this only happens if ‘Vaulting: No’ is also set.&lt;br /&gt;
&lt;br /&gt;
/var/configuration/shops/1/modules/osc_paypal.yaml&lt;br /&gt;
  oscPayPalSandboxVaultingEligibility:&lt;br /&gt;
    type: bool&lt;br /&gt;
    value: false]]></description><category>module PayPal checkout - sub</category><pubDate>Thu, 21 May 2026 14:53:56 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7920</guid><comments>https://bugs.oxid-esales.com/view.php?id=7920#bugnotes</comments></item><item><title>0007923: PayPal checkTermsAndConditions = false</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7923</link><description><![CDATA[If you have a product which is not a downloadable one but require the additional checkbox in last step of the checkout (oxnonmaterial =&gt; 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.]]></description><category>module PayPal checkout - sub</category><pubDate>Thu, 21 May 2026 14:53:41 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7923</guid><comments>https://bugs.oxid-esales.com/view.php?id=7923#bugnotes</comments></item><item><title>0007925: Keine Fehlermeldung bei verdrehter shipping/address/admin_area_2 Angabe</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7925</link><description><![CDATA[Haben mehrere Fälle im Paypal Log beobachtet, bei denen eine 422 Unknown Error bzw. Unprocessable Entity Response mit der Ursache &quot;CITY_REQUIRED&quot; oder &quot;REQUIRED_PARAMETER_FOR_PAYMENT_SOURCE&quot; 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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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-&gt;createAcdcOrder() und dort dem doCreatePatchedOrder()-Aufruf (&lt;a href=&quot;https://github.com/OXID-eSales/paypal-module/blob/b-6.3.x/src/Controller/AjaxPaymentController.php#L448&quot; rel=&quot;noopener,nofollow&quot;&gt;https://github.com/OXID-eSales/paypal-module/blob/b-6.3.x/src/Controller/AjaxPaymentController.php#L448&lt;/a&gt;) Dieser ist nicht von einem Try-Catch Block umschlossen.&lt;br /&gt;
&lt;br /&gt;
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 &quot;error&quot; &gt; &quot;failed to execute shop order&quot; Response anzufangen. Heißt, es wird keinerlei Fehlermeldung á la &quot;Ungültige Postleitzahl&quot; angezeigt oder irgendwohin (Schritt 2 Adresseingabe wäre wohl am sinnvollsten) zurückgeleitet.]]></description><category>module PayPal checkout - sub</category><pubDate>Thu, 21 May 2026 14:53:31 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7925</guid><comments>https://bugs.oxid-esales.com/view.php?id=7925#bugnotes</comments></item><item><title>0007926: Changing variants on the detail page results in a JavaScript error if performed multiple times</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7926</link><description><![CDATA[PPC module update 2.8.3 installed with the RoxIVE theme.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
To be more precise: the first variant switch still worked, but all subsequent ones were no longer possible.&lt;br /&gt;
&lt;br /&gt;
Technical background:&lt;br /&gt;
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:&lt;br /&gt;
Uncaught SyntaxError: redeclaration of let buttonPayPalButtonProductMain]]></description><category>module PayPal checkout - sub</category><pubDate>Thu, 21 May 2026 14:53:19 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7926</guid><comments>https://bugs.oxid-esales.com/view.php?id=7926#bugnotes</comments></item><item><title>0007927: Error when ordering by credit card if the first attempt is declined</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7927</link><description><![CDATA[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’.&lt;br /&gt;
After confirming again, you are redirected to the thank you page.&lt;br /&gt;
&lt;br /&gt;
Three orders are created.&lt;br /&gt;
1. Order error and cancelled.&lt;br /&gt;
2. Order not finished and not cancelled&lt;br /&gt;
3. Order not finished and not cancelled&lt;br /&gt;
&lt;br /&gt;
PayPal Checkout tab:&lt;br /&gt;
1. Order status: declined&lt;br /&gt;
2. Order notification: The order was abandoned during checkout and automatically cancelled.&lt;br /&gt;
2. Order notification: The order was abandoned during checkout and automatically cancelled.]]></description><category>module PayPal checkout - sub</category><pubDate>Thu, 21 May 2026 14:53:08 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7927</guid><comments>https://bugs.oxid-esales.com/view.php?id=7927#bugnotes</comments></item><item><title>0007939: Customers with Apple iPhones and the "Google Search App" cannot log in (only loading animation is displayed).</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7939</link><description><![CDATA[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.&lt;br /&gt;
&lt;br /&gt;
The log shows exactly what we see: `createOrder` runs, `PAYER_ACTION_REQUIRED` hangs, and no `onApprove` event is triggered.&lt;br /&gt;
&lt;br /&gt;
Apple ITP/Cookie restrictions disrupt the cross-domain journey (shop &lt;-&gt; paypal.com &lt;-&gt; shop) if the user does manage to log in to PayPal.]]></description><category>module PayPal checkout - sub</category><pubDate>Thu, 21 May 2026 14:52:04 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7939</guid><comments>https://bugs.oxid-esales.com/view.php?id=7939#bugnotes</comments></item><item><title>0007946: remove storno-flag if paypal heal a pending order</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7946</link><description><![CDATA[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 &quot;Cancelled&quot; within the admin interface. The cancellation status must definitely be removed, and—if possible—the &quot;Pending&quot; order status should perhaps be utilized in cases where the order corresponds to a &quot;Payment Pending&quot; status within PayPal.]]></description><category>module PayPal checkout - sub</category><pubDate>Thu, 21 May 2026 14:51:51 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7946</guid><comments>https://bugs.oxid-esales.com/view.php?id=7946#bugnotes</comments></item><item><title>0007945: provide `paypaltrackingcarrier` and `paypaltrackingcode` with the send()-function does not work</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7945</link><description><![CDATA[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.]]></description><category>module PayPal checkout - sub</category><pubDate>Thu, 21 May 2026 14:51:29 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7945</guid><comments>https://bugs.oxid-esales.com/view.php?id=7945#bugnotes</comments></item><item><title>0007929: Fehler bzgl. Tausendertrennzeichen im Rückerstattungsbetrag</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7929</link><description><![CDATA[Folgende Meldung aus unserem Log &lt;br /&gt;
&lt;br /&gt;
PayPal Payment Logger.ERROR: RES | POST  | /captures/64U701349R9605015/refund | POST &lt;a href=&quot;https://api.paypal.com/v2/payments/captures/64U701349R9605015/refund&quot; rel=&quot;noopener,nofollow&quot;&gt;https://api.paypal.com/v2/payments/captures/64U701349R9605015/refund&lt;/a&gt; returned: 400 Bad Request&lt;br /&gt;
Returned Message: Request is not well-formed, syntactically incorrect, or violates schema&lt;br /&gt;
Error Details: &lt;br /&gt;
[{&quot;issue&quot;:&quot;INVALID_PARAMETER_SYNTAX&quot;,&quot;field&quot;:&quot;\/amount\/value&quot;,&quot;value&quot;:&quot;5,326.00&quot;,&quot;description&quot;:&quot;The value of the field does not conform to the expected format.&quot;,&quot;location&quot;:&quot;body&quot;}]&lt;br /&gt;
&lt;br /&gt;
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.]]></description><category>module PayPal checkout - sub</category><pubDate>Thu, 21 May 2026 14:51:02 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7929</guid><comments>https://bugs.oxid-esales.com/view.php?id=7929#bugnotes</comments></item><item><title>0007924: Issue since the PayPal update: Mollie credit card payments are failing at checkout</title><author></author><link>https://bugs.oxid-esales.com/view.php?id=7924</link><description><![CDATA[Shop environment:&lt;br /&gt;
    OXID eShop CE 6.5.3&lt;br /&gt;
    PayPal Checkout module currently v2.8.3&lt;br /&gt;
    PayPal Client 3.0.20&lt;br /&gt;
    Mollie module 1.1.2&lt;br /&gt;
&lt;br /&gt;
The problem has occurred since the PayPal module was updated to v2.8.2 or v2.8.3&lt;br /&gt;
&lt;br /&gt;
Symptoms:&lt;br /&gt;
    In the frontend, an order is processed normally up to the payment stage&lt;br /&gt;
    When selecting credit card via Mollie, the payment process is initiated&lt;br /&gt;
    Afterwards, the customer is redirected back to order step 3 the payment methods&lt;br /&gt;
    The message appears: “Order could not be found”]]></description><category>module PayPal checkout - sub</category><pubDate>Thu, 21 May 2026 14:50:49 +0200</pubDate><guid>https://bugs.oxid-esales.com/view.php?id=7924</guid><comments>https://bugs.oxid-esales.com/view.php?id=7924#bugnotes</comments></item></channel></rss>
