View Issue Details

Jump to Notes
IDProjectCategoryView StatusDate SubmittedLast Update
0007887module PayPal Checkoutmodule PayPal checkout - subpublic2026-01-29 14:482026-02-17 17:26
Reportermount7 Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status assignedResolutionreopened 
Product Version2.6.4 / 3.5.2 
Target Version2.7.1 / 3.6.1Fixed in Version2.6.5 / 3.5.3 
Summary0007887: Paypal Express Bestellungen benutzen immer nur die Default Versandart
DescriptionWenn der User per PayPal Express versucht zu bestellen wird immer nur die default Versandart genommen.

Fehler kommt aus Commit: 65e0e4ff Use any existing shipping options before creating one.

In der session "sShipSet" steht zwar die Passende Versandart (kommt aus calculateBasket) wird diese allerdings wird diese nie in den Basket geschrieben
Steps To Reproduce1. Alle session löschen
2. Artikel der nicht per default Versandart verschickbar ist in den Warenkorb
3. Paypal Express bestellung durchführen
Additional Informationprivate function getActiveShippingSetId($session, $user, $basket): void
    {
        $shippingSetId = $session->getVariable('sShipSet');

        # Hier zu viel optimiert da die shipping Methode im Basket immer noch null sein kann (=> default)
        if ($shippingSetId) {
            return;
        }

        /** @psalm-suppress InvalidArgument */
        [, $shippingSetId,] =
            Registry::get(DeliverySetList::class)->getDeliverySetData('', $user, $basket);

        if ($shippingSetId) {
            $basket->setShipping($shippingSetId);
            $session->setVariable('sShipSet', $shippingSetId);
        }
    }
TagsNo tags attached.

Activities

mario_lorenz

2026-01-29 17:39

developer   ~0018338

@mount7: We have made an adjustment so that if the sShipSet is in the session, it is also persisted in the basket:

https://github.com/OXID-eSales/paypal-module/commit/540c82ee739909183e48103d90a88a61b265881a

QA

2026-01-30 12:07

administrator   ~0018339

QA - ES

mount7

2026-02-03 15:27

reporter   ~0018345

Last edited: 2026-02-03 15:28

 Ich bin mir nicht sicher ob es schon zu 100% behoben ist:

Ich habe gerade folgendes Szenario:
Beim klick auf PaypalExpress wird jetzt korrekterweise "Versandart DE" in den Warenkorb geschrieben, wenn der Kunde aus Österreich bestellt, wird das allerdings im order Schritt nicht angezeigt und der Kunde kann mit "Versandart DE" bestellen.
In der Session steht hier wiederum schon die passende Versandart ("Versandart AT")

Als kleinen fix hab ich einen zusätzlichen Check in die Order render Methode eingebaut (3):

public function render()
    {
        $result = parent::render();
        // 1. Get the current User and Basket
        $oUser = $this->getUser();
        $oBasket = $this->getBasket();

        if (!$oUser || !$oBasket) {
            return $result;
        }

        $sActShipSet = Registry::getRequest()->getRequestEscapedParameter('sShipSet');
        if (!$sActShipSet) {
            $sActShipSet = Registry::getSession()->getVariable('sShipSet');
        }

        // 2. Validate the selected shipping type is possible
        [$aAllSets, $sActShipSet, $aPaymentList] =
            Registry::get(DeliverySetList::class)->getDeliverySetData($sActShipSet, $oUser, $oBasket);
        if (!array_key_exists($sActShipSet, $aAllSets)) {
            return Registry::getUtils()->redirect('index.php?cl=payment', false);
        }

        // 3. Validate basket shipping equals $sActShipSet
        $basketShippingId = $oBasket->getShippingId();
        if ($sActShipSet !== $basketShippingId) {
            $oBasket->setShipping($sActShipSet);
            Registry::getSession()->setVariable('sShipSet', $sActShipSet);
            $oBasket->calculateBasket();
        }


        // If everything is fine, proceed to show the Order Overview
        return $result;
    }

mario_lorenz

2026-02-05 14:37

developer   ~0018350

Last edited: 2026-02-12 14:58

 Hello @Mount7,

We just tried again and were unable to reproduce the Austria case.

Here's our test scenario:

* We have four payment methods with their respective rules.
* The first payment AAA method (backend sorting = 10) is explicitly for everyone except Austria!
* The second payment BBB method (backend sorting = 20) is explicitly for Austria.
* The shop is configured as a German shop by default.
* In the backend settings, the option "Calculate shipping costs even if the customer is not logged in" is enabled.

Test 1)

* We add an item to the shopping cart.
* The shopping cart displays the shipping costs for the first payment method (this is the payment method AAA that matches the shop setup).

Test 2)

* Includes Test 1.
* We log in with an Austrian customer and go to the payment method selection list.
* Only the payment BBB method appears here. The payment method AAA is not available for Austria.

Test 3)

* We start with an empty session (no logged-in user, empty shopping cart).
* On the product details page, we click the PayPal Express button.
* In the PayPal pop-up, we select an Austrian address.
* We click "Continue" in the pop-up. The shop jumps to the final checkout page.
* The payment method BBB is correctly selected.

Test 4)

* We start with an empty session (no logged-in user, empty shopping cart).
* We add items to the shopping cart.
* We go to the shopping cart and see the German shipping costs from the payment method AAA.
* We click the PayPal Express button here.
* In the PayPal pop-up, we select an Austrian address.
* We click "Continue" in the pop-up. The shop jumps to the final checkout page.
* The payment method BBB is correctly selected.

Test 5)

* We log in and are an Austrian customer.
* On the product details page, we click the PayPal Express button.
* In the PayPal pop-up, we cannot select an address because we have already provided the user's address. It is the address of the Austrian customer.
* Clicking "Continue" in the pop-up takes the shop to the final page of the checkout process.
* The payment method BBB is correctly selected.

Please review our scenarios. If your scenario differs from ours, please describe it here again, including the exact steps for reproducing the issue.

mount7

2026-02-13 15:08

reporter   ~0018378

Hello @mario_lorenz,

Thank you for the detailed feedback and the effort in testing these scenarios. However, there seems to be a slight misunderstanding regarding the core of the issue.

The problem is not the selection of the Payment Method (Zahlungsart). In our case, the payment method is always PayPal Express and it is correctly selected. The issue lies within the Shipping Method / Delivery Set (Versandart) and a synchronization gap between the User Session and the Basket Object during the PayPal Express flow.

The Core Issue: Shipping Set Desync:
In OXID, the Shipping Set ID is stored both in the session (sShipSet) and within the Basket object ($oBasket->getShippingId()).

When a user triggers PayPal Express, the shop often defaults to a German shipping set (DE). After the user selects an Austrian (AT) address in the PayPal popup and returns to the shop, the session is updated with the new country (AT) and a matching shipping set (AT).

The Bug: Even though the session is updated, the oBasket object often retains the "old" Shipping Set ID (DE) in its internal state. Since oBasket->calculateBasket() relies on its internal shipping ID, the customer ends up on the final order overview with:

1. An Austrian address.
2. An Austrian Shipping Set in the session.
3. But: The German Shipping Set (price, rules AND display name) still active in the Basket calculation. It is important to note that the shipping method name displayed to the user in the order overview template is also pulled directly from the Basket object. This means that even if the session "knows" it's an Austrian order, the user explicitly sees the German shipping method name and price.



Why your tests might have missed this:
In your Test 4, please verify not just if the payment BBB is selected, but specifically check:

- What is the result of $oBasket->getShippingId() on the final page?
- Are the shipping costs calculated based on the AT rules or the previous DE rules?
- Which shipping method name is actually rendered in the checkout summary?

If your "Shipping Set DE" and "Shipping Set AT" have similar prices or if your delivery sets are configured to allow multiple countries, the discrepancy might not be immediately visible in the UI, but it creates legal and calculation issues (e.g., wrong VAT on shipping or wrong shipping flat rates).

Clarification on the Fix:
The fix I implemented in Order::render() ensures that the Basket's internal shipping state is forced to sync with the validated session/request state:

$basketShippingId = $oBasket->getShippingId();
if ($sActShipSet !== $basketShippingId) {
    $oBasket->setShipping($sActShipSet);
    $oBasket->calculateBasket();
}


Without this, the oBasket stays "stuck" on the initial shipping set selected before the PayPal popup was opened.

Updated Reproduction Scenario (Shipping focused):
1. Default Shop Country: Germany (DE).
2. Shipping Set A: Only for Germany (Price: 5.00€).
3. Shipping Set B: Only for Austria (Price: 15.00€).
4. Start as guest, add item to cart (Cart shows 5.00€ shipping).
5. Click PayPal Express.
6. Select an Austrian address in PayPal and "Continue".
7. On the final order step: Check if the shipping cost is 15.00€ (Set B) or still 5.00€ (Set A).

In our environment, without the fix, it remains at 5.00€ because the Basket object doesn't trigger a re-selection of the shipping set based on the new country data provided by the PayPal callback.

Could you please re-test specifically looking at the oxBasket shipping ID and the resulting costs?