Closed JustADude-86 closed 2 years ago
Hello @JustADude-86 ,
A lot of these errors seem to be quote/address validation problems when trying to order with Amazon Pay Now. Unfortunately, the Amasty One Step Checkout module has had compatibility issues with Amazon Pay in the past, and while some of the problems seem to have been resolved in the latest version, the issues you are experiencing have persisted. But knowing that you've purchased these extensions, I'm sure you'd like to use the APB feature with them if you can. Ideally we can work with Amasty to continue improving compatibility. But if not, we may need to explore some workaround for Pay Now.
To the overall point of transactions being created with Amazon and orders not being created in Magento, we're currently looking into ways that we can better handle order placement failures and provide some more visibility to merchants.
We too are having this issue, but with Magento 2.4.2 and the default magento checkout. We do not have any checkout extensions such as Amasty.
We had this also with the default flow and had issues on all versions of Amazon Pay V2 and had to revert to v1 for a long time which worked fine. Have you upgraded from Magento 1 by any chance? A fix for us was to reset the quote table autoincrement id, worked for us.
@jamieolney That's a good point you bring up, we did see this for a couple merchants who migrated. If this is the case, you should see some log output in the paywithamazon.log similar to "Unable to complete Amazon Pay checkout. Can't submit quote id: XXXX" as a result of Magento trying to place an order with a quote ID that already exists. This logging has been included since version 5.8.0 of our module.
Hi @sgabhart22 Yes, that is exactly what we saw, it was somehow referencing completely different and older quotes that no longer existed. Resetting the autoincrement id for the quote table appeared to resolve that.
I'm trying to debug a very similar issue. Default magento checkout, no problem on autoincrement but sometimes it doesn't work and logs the "Can't submit quote ID". Searching in sales_order for quote_id reported, I found multiple entity for the same user\order\timespan... I think is related to https://github.com/magento/magento2/issues/13952 but it's very difficult to reproduce and verify. There are some workaround linked to the issue, I found some solution applied by Adyen but there is too much knowlegde that I ignore.
@kionez Thank you for linking that issue, I don't believe I've seen that before. It certainly is difficult to reproduce, and potentially pretty hard to identify unless you are looking out for it on production. Seems like the problem has been around for quite some time as well, as the issue was opened several years ago at this point, but it does look like there's an open PR for it. Hopefully the Magento team can get that (or another) fix included in some early version of 2.4.4.
If you have any luck with any of the fixes or workarounds you try, please feel free to share!
Sorry, after two hour of digging in the code I found that in amazon-pay-magento-2-module/Model/CheckoutSessionManagement.php there is a "workaround" to avoid that issue, and it creates the exact issue reported. I am currently investigating the possibility of duplicates created by another payment system, especially when there are connectivity problems. I can replicate the duplication of quote_id, maybe it's just one of the many possible causes, but at the moment is everything i found. Is a very very hard task.. If I found something I'll share! Thanks!
@sgabhart22 After many hours of debug I found that the quote_id duplication was caused by another payment gateway module (easynolo/axerve-ecommerce-solutions) which restores the quote if the payment was unsuccessful (I think is a common pratice to enhance the user experience).
So I'm testing a little fix to amazon-pay-magento-2-module/Model/CheckoutSessionManagement.php, I've overrided canSubmitQuote function adding a third filter to exclude cancelled order in duplicated quote_id count:
->addFieldToFilter('status', ['neq' => \Magento\Sales\Model\Order::STATE_CANCELED]);
I am writing here to ask you if my idea is correct and if it makes sense to add this change to Amazon module's code
PS: please don't blame me for poor coding skills :)
What I expected
This error is random (does not happen all the time, randomly). I would expect that when the customer selects the payment Amazon Pay as the payment method the order would show up in the admin panel and the payment is "confirmed" and Order-ID is transferred to Amazon Pay.
What happened instead
Customers get some sort of error. From the log they get (different error per customer):
But because 99% of the customers don't report the error, but just choose Paypal or other payment methods this cant be investigated further. The payment is passed thru Amazon and payment is seen on the Amazon Pay dashboard but the order is never created and orderID is not passed from the shop to Amazon (because there is no order). For example on the error suppost to be because of (Einige Adressen können aufgrund der Konfigurationen für bestimmte Länder nicht verwendet werden.), but the customer address was from DE and our shop is in DE and DE is allowed so this error should not appear.
Steps to reproduce the issue
The problem is that I could not reproduce the issue. I tried with my own Amazon account and the issue never shows for me, also for some people work and for some not. For example, we had yesterday (2.2.2022) 3 orders with Amazon Pay, two had one of these errors and the third one was passed thru successfully and order was generated, so I really can't pinpoint what exactly is happening here but there is one or two order that has this issue. I tried to purchase with Express Pay (button) and the Payment method selection during the checkout process and for me all worked perfectly.
Other notes
This happened also on the previous version (Magento 2.3 and the previous version of the Amazon Pay module) a couple of times so that is why we had the plugin disabled.
The log was wiped by mistake one week ago by one of our team members si this log is only a week old. Here is also a screenshot from January and February where you can see that some orders were ok... others were not (totally bizarre)
Your setup
Any help would be appreciated 👍