The question:
When I use PayPal Plus(PayPal, credit cards) ,the checkout success page is not shown. Instead is redirected to checkout/cart/.
The redirection happens in this file:
MagentoCheckoutControllerOnepageSuccess
<?php
/**
* Copyright © Magento, Inc. All rights reserved.
* See COPYING.txt for license details.
*/
namespace MagentoCheckoutModelSession;
/**
* Test if checkout session valid for success action
*
* @api
*/
class SuccessValidator
{
/**
* @var MagentoCheckoutModelSession
*/
protected $checkoutSession;
/**
* @param MagentoCheckoutModelSession $checkoutSession
* @codeCoverageIgnore
*/
public function __construct(
MagentoCheckoutModelSession $checkoutSession
) {
$this->checkoutSession = $checkoutSession;
}
/**
* @return bool
*/
public function isValid()
{
if (!$this->checkoutSession->getLastSuccessQuoteId()) {
return false;
}
if (!$this->checkoutSession->getLastQuoteId() || !$this->checkoutSession->getLastOrderId()) {
return false;
}
return true;
}
}
I found out that all three :
$this->checkoutSession->getLastSuccessQuoteId()
$this->checkoutSession->getLastQuoteId()
this->checkoutSession->getLastOrderId()
return null.
Obviously there is something to do with the session but this is the furthest I could go.
The orders are completed and successful.Its just the order confirmation page that is not shown.
The Solutions:
Below are the methods you can try. The first solution is probably the best. Try others if the first one doesn’t work. Senior developers aren’t just copying/pasting – they read the methods carefully & apply them wisely to each case.
Method 1
Look very carefully to your var/log/system.log
.
In my case, I was missing some important information there and the problem was Redis. The session was being locked by some other process and didn’t allow Magento to update the cart/quote session there.
I just noticed that when added a breakpoint to MagentoCheckoutControllerOnepageSuccess::execute
and looking at my tail -f var/log/*
terminal tab.
Update: I faced the problem again and Redis config was the problem. I just changed the break_after_frontend
from 5 to 15 in app/etc/env.php
as I described here. It worked for me.
Method 2
I found a solution.
The problem was that
$this->checkoutSession->getLastSuccessQuoteId()
$this->checkoutSession->getLastQuoteId()
$this->checkoutSession->getLastOrderId()
Somehow were lost before paypal redirects to /checkout/onepage/success
.
When the order is created, I pass the id of the order to the /checkout/onepage/success
. Than I:
$this->checkoutSession->setLastSuccessQuoteId($order->getQouteId())
$this->checkoutSession->setLastQuoteId($order->getQuoteId())
$this->checkoutSession->setLastOrderId($order->getEntityId())
At this point, everything works fine.
Method 3
This was with us after the PayPalPlus order, because of the static block in the email template.
instead of this in email template:
{{block cacheable="false" id="terms"}} <!-- cacheable not working -->
I created sales_email_order_terms.xml
in Custom_Theme/Magento_Sales/layout
.
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd" label="Email Terms" design_abstraction="custom">
<body>
<block class="MagentoCmsBlockBlock" name="block_email_terms" cacheable="false">
<arguments>
<argument name="block_id" xsi:type="string">terms</argument>
</arguments>
</block>
</body>
</page>
and then use in email template:
{{layout handle="sales_email_order_terms"}}
Method 4
If you use blocks in your email templates to load content from cms or phtml templates into new order emails this can cause an issue where the call to the block destroys the customer session when the new order email is sent. This means when you return to the site after successful third party payment i.e. PayPal there is no session data and the customer is redirected to an empty cart.
Method 5
Ok, so we had the same problem, after card payment on PG instead of landing on success page there was a redirect to empty cart (order was successful).
Reason was session was cleared as well.
Main cause for that happen to be full_page cache being flushed.
Why that happened, since that page shouldn’t be in fpc?
Well, magento and its fantastic di system.
We made preference for OnepageSuccess
block, and while everything else worked, layout definition in checkout_onepage_success.xml
had specified no caching for original block, and not ours.
Specifying no caching for our block in layout removed the issue.
Hopefully smne will not lose same amount of time and life as i did.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0