Couldnot place order "An error occured on the server. Please try to place the order again"

[prasannanwr]

I am unable to place the order in Magento 2.1.1. I don't get specific log details to track the error. The console log shows "Failed to load resource: the server responded with a status of 400 (Bad Request)" at http://example.com/rest/default/V1/guest-carts/36b703a23e05b25a08da0e8ba5ab031f/payment-information

I have previously installed an extension to delete orders. But I removed it too and upgraded setup and cleared cache too. But I can't place order now.

There are no table prefixes either. After setup upgrade, I runned "bin/magento setup:di:compile" command.

Please suggest

[southerncomputer]

Completely flush your cache (ie redis-cli -p 6379 flushall , redis-cli -p 6380 flushall,php bin/magento cache:clean, service php-fpm restart) then make a new login and try to checkout, you may have an quote with an already used reserved_order_id ! Of course if you applied the patch it would have thrown an exception or so!

[brvoltz]

Sorry but I would not know how to run the flush...

and it does not matter which payment method I use.. it does for all of them...

Ok... not logged in, and as "Guest" it works...

so can I delete my account and create it again?

[AirmanAJK]

You don't know how to flush your cache on the command line? This is Magento Community Edition. We're all here to help each other, but this is not the enterprise edition. You need to learn how to develop in this framework or consult with someone who does. You aren't going to get a simple "click here" solution to this problem. I bet you have a duplicate reserved order ID like the comment above suggests.

[brvoltz]

@AirmanAJK - I'm very sorry for asking how to Find the root cause / fix something here as the support from the plugins are so busy pointing fingers. I did not know this group was not for CE installations. What is funny is the support for the plugins pointed me here. The same with google search.
Others have so kind to offer suggestions, I take these back to one person and ask him to try or do it... and give me the results. (it has taken no less then 40 different "Consultants" to find someone that is not a charlatan.)

On the flush - I was simply stating fact not asking for you to do it or explain it.

I'm trying to get to the bottom of why this system is having so many problems. and I'm learning the Magento world has a lot of "self proclaimed experts" that simply are after a $ with no Knowledge of the system. The word I would use is "Fleecing". (to your point about consultants)

Southern had it right it was the user ID... Still have no idea how to "clean up" for that user (it is my test ID)....

[southerncomputer]

@AirmanAJK I just run setReserverOrderId() on my quotes on the last step of one-step-checkout since I like the actual OrderId to sync to the OrderId on CC provider. If i waste a few order #'s not a big deal. Customers enjoy having accurate orderId on their CC statements too!

I assume reservedOrderId is invalid rather than trusting it is unused as between the backend users modifying quotes/orders/cloning quotes/re-orders, the reservedOrderId is seriously broken.

@brvoltz: mysql : update quote set reserved_order_id=NULL ; should clean up that user's problem for now!

[nanae29]

Comment try, catch to see error /vendor/magento/module-checkout/Model/GuestPaymentInformationManagement.php/ /vendor/magento/module-checkout/Model/PaymentInformationManagement.php

public function savePaymentInformationAndPlaceOrder( $cartId, \Magento\Quote\Api\Data\PaymentInterface $paymentMethod, \Magento\Quote\Api\Data\AddressInterface $billingAddress = null ) { $this->savePaymentInformation($cartId, $paymentMethod, $billingAddress); //try { $orderId = $this->cartManagement->placeOrder($cartId); /} catch (\Exception $e) { //var_dump($e); throw new CouldNotSaveException( __('An error occurred on the server. Please try to place the order again.'), $e ); }/ return $orderId; }

[bytejan]

I had the same problem as well and I found the reason.

In my case, I only got the problems on my test server, locally no issues at all.

The reason is that I used an other database user on my test server, I changed my env.php but still was running into the error when I tried to make an order.

After logging the database I saw that some queries were trying to use my old user, I created a database dump and saw that some triggers are using the old user.

So be sure that your development, production, staging are using the same db user.

Maybe not all problems described here are related to my issue, but I hope that I can help at least some of you.

[oceancloud82]

so........ disappointed. Magento 2 to me a disaster. I really regret switch to magento 2. two significant issues in payment. we hit both: 1. Paypal Express could not intitialize. 2 This issue. this is directly related to payment. related to revenue!

[dey00]

I confirm. Magento 2 is a disaster, too slow, scheduling is bad, payment problematic. I'm staying at magento 1 waiting to choose another platform. They made (magento team) of a success a nightmare

[puples]

same for me, i regret too

[Bobstar040]

I am facing the same issue, upgrade to 2.1.8 was also not the solution. Busy with this for 3 weeks. I am now at the point to pull the plug on M2. The one issue after the other, this is no fun at all.

[jmellon]

I was also facing the same issue, even upgraded to 2.1.8 That was also not the solution. I began to disable modules. I disabled my debugging tool Commercebug and put it in production mode and transactions started to execute. Then when I un-did this to validate the observation. It still continued to work in production mode and dev mode. I will report back if I have other observations to add. Scratching my head.

[andidhouse]

I can confirm this happens some times in 2.1.7 - very bad!

" I am now at the point to pull the plug on M2" @Bobstar040 totally understand - same here. One issues is solved the other issue pops up....

Not productive at all!

[plentyhappy]

I spent about 20K on an issue similar to this...I am NOT exaggerating. The bug I was experiencing was the spinning wheel of death at checkout. The bug was finally fixed back several versions ago...

This is not the place to be negative...I know...I also know that Magento staff cares...but your upper management needs to understand real problems. This is the most important problem you have...checkout has to work. Everything else must take a back seat...good managers prioritize.

[Bobstar040]

Our issue is resolved now, checked all plugins which use api and disable or remove them. No proper debug logs or errors where generated by magento on this. Good luck with these issues, i know its very frustrating.

[puples]

@Bobstar040 for you which module was problem?

[Bobstar040]

@puples for me it was the Belco.io plugin, but it can be any plugin which requires api credentials to get customer data in my opinion.

[twosg]

I just found out that the problem (at least in my case) was related to the guest checkout email address. If there was an order before with a specific address and you use this address to checkout, Magento suggests to log in or leave the customer to optionally continue without login. When the customer does not log in, the error appears.

When using a complete new email address, unknown to Magento, checkout works as guest.

[vseager]

I have the same issue, but the other way around. No third party extensions.

• Checkout as a guest using the default 'Check/Money Order' payment method, and everything works as normal.
• Log into my account, then checkout using the same payment method and I get "An error occured on the server."

[andidhouse]

@veloraven @magento-team can you pls come around with an answer on this bug. I am not shure how you see this but if the checkout is not 100% perfect running the whole magento2 system can not be used. And by 100% i mean 100% not 99,8!

Can you pls let us know what you plan to do to solve this issue?

[vseager]

Update: Our team @outeredge have found the issue.

In our case, the 'Street Address' was saved in the database as two lines, for example:

Unit 2
The Street

But Magento will only accept a 1 line in the Street Address. After removing the multiple lines, the issue has resolved itself.

This still leaves the question of how we managed to get multiple lines in there in the first place. Perhaps an earlier version of Magento 2 allowed this, and the newer version is not backward compatible?

[southerncomputer]

I would try disabling persistent modules and clear out the quote table to see if it is running cleaner!

[southerncomputer]

@vseager see https://github.com/magento/magento2/issues/2450

[penguinotravel]

I discovered another issue that can cause the same problem while doing sandbox testing. In the Braintree configuration in the Admin Panel, under 'Basic Braintree Settings' it asks for the Merchant ID, and under Advanced Braintree Settings it asks for the Merchant Account ID.

Going through the form quickly I didn't realize they are not the same thing, and entered my Merchant ID in the Merchant Account ID field. This will produce the same error:

If you make the same mistake I did /var/log/debug.log will NOT show anything useful:

To clarify so someone else doesn't make the same mistake:

• The merchant ID is a unique identifier for your entire gateway account. This value is required to connect your integration to Braintree, along with the rest of your API keys.
• The merchant account ID is a unique identifier for a specific merchant account, and is used to specify which merchant account to use when creating a transaction. The merchant account ID can be found in the Braintree Control Panel (Sandbox or Production) by navigating to Settings > Processing > Merchant Accounts.
• If you only have one merchant account, it is not necessary to specify a merchant account ID.

[ibecmattb]

My issue was happening because my development database dump was setting the DEFINER attribute on the triggers to a user that did not exist on the production database. There is a part of the magento cloud docs at the bottom that may be helpful. You basically need to run mysqldump and tell it to not set that DEFINER user. Once I did this, I was able to checkout again! Here is the code snippet I neededmysqldump -h <database host> --user=<database user name> --password=<password> --single-transaction main | sed -e 's/DEFINER[ ]*=[ ]*[^*]*\*/\*/' | gzip > /tmp/database_no-definer.sql.gz

You can read more here: http://devdocs.magento.com/guides/v2.0/cloud/live/stage-prod-migrate.html#troubleshooting-the-database-migration

Also, to the best of my knowledge, I am not using cloud Magento, but this still pertained to me. Hope this helps someone!

[magento-engcom-team]

The issue has been fixed in MAGETWO-63651, MAGETWO-67290, MAGETWO-63650, MAGETWO-63637 and delivered

If you have any other issues, please, create new issue Thank you