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

[muhupower]

@hubaig I think it might be important to note what type of payment method you are using during checkout... The odd thing was for me is that we used paypal offsite and onsite processing... the one that directed to their paypal.com payments page worked, but we were getting this error while trying to process cc on the actual website. In our case as it turns out the paypal tech support agent was able to configure settings on his end to let it go through.... So if you are having this issue, we though it was magento's fault for a while, and in the end it turned out being a setting in paypal

[hubaig]

@muhupower do you know what setting they enabled?

[LucienC]

Using @southerncomputer solution works for me.

In my case, store number 3 was broken so:

1. Added missing sales sequence meta
2. Created missing tables sequence_order_3, sequence_invoice_3, sequence_creditmemo_3, sequence_shipment_3
3. Added missing entries to sales_sequence_profile to match with sales_sequence_meta

INSERT INTO sales_sequence_meta (entity_type, store_id, sequence_table) VALUES ('order', 3, 'sequence_order_3'), ('invoice', 3, 'sequence_invoice_3'), ('creditmemo', 3, 'sequence_creditmemo_3'), ('shipment', 3, 'sequence_shipment_3');

CREATE TABLE sequence_order_3 ( sequence_value int(10) unsigned NOT NULL AUTO_INCREMENT, PRIMARY KEY (sequence_value) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE sequence_invoice_3 ( sequence_value int(10) unsigned NOT NULL AUTO_INCREMENT, PRIMARY KEY (sequence_value) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE sequence_creditmemo_3 ( sequence_value int(10) unsigned NOT NULL AUTO_INCREMENT, PRIMARY KEY (sequence_value) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE sequence_shipment_3 ( sequence_value int(10) unsigned NOT NULL AUTO_INCREMENT, PRIMARY KEY (sequence_value) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO sales_sequence_profile (profile_id, meta_id, prefix, suffix, start_value, step, max_value, warning_value, is_active) VALUES (13, 13, 3, NULL, 1, 1, 4294967295, 4294966295, 1), (14, 14, 3, NULL, 1, 1, 4294967295, 4294966295, 1), (15, 15, 3, NULL, 1, 1, 4294967295, 4294966295, 1), (16, 16, 3, NULL, 1, 1, 4294967295, 4294966295, 1);

[hubaig]

The main store that I am using has the ID of 1, all of my products are using that store. Here is the screenshot of my tables. Do you guys see anything wrong here?

SELECT * FROM sales_sequence_meta

SELECT * FROM sales_sequence_profile

All of the tables exist:

Even here is the store table:

SELECT * FROM store

[zeeshan2523806]

@nuwaus thank you for the answer, finally there were three storeids in my stores table, and table sales_sequence_meta and sales_sequence_profile only contain the data for the 2 store ids so added a record for the third store id and created tables manually with the same name and it solves my problem

[gooki]

Ran into exactly the same vague error as everyone. Went through all the steps everyone suggested and nothing. I would get no other error to show up anywhere.

I use Website Payments Pro (Canada), so finally I figured I'd see if I get some error codes via the manager.paypal portal. Looked at the transaction log and lo and behold Invalid Merchant Credentials galore. I though I supplied the correct ones but I guess not. tomorrow I'll double check with Paypal what they have to be and see if this helps, fixes the issue. [Need to wait till monday for integration support]

[gooki]

See also related:

8254

7977

Ok spoke with Paypal over the last two days, traced the issue to Magento and not Paypal.

Preconditions Ubuntu 16.04 Nginx 1.10.0 PHP 7.0.13 (CLI and FPM) MariaDB-10.1.21 Varnish-4.1.1 Redis-cli 3.0.6 Magento 2.1.3 - Single Store

Set Payment Method in Stores->Configuration->Sales->Payment Methods->Paypal Payflow Pro (Canada) (Includes Express Checkout) (Or Websites Payments Pro)

Give all required configuration information like Email, Partner etc.

Steps to reproduce

Add ANY product in cart

Go to Checkout page

Check out as guest or registered user

Provide Shipping information and choose any available shipping method.

Choose credit card payment method

Then click place order

Expected result

Order processed and confirmed

Actual result

Error message: "An error occured on the server. Please try to place the order again."

Analysis

Paypal Manager report shows:

• Transaction as a 10501 error. "Error 10501 Invalid Configuration – This transaction cannot be processed due to an invalid merchant configuration."
• Wrong currency being sent to paypal USD instead of CAD
• Zero cart amount being sent to paypal

Magento Debug shows (Anonymized Buyer Data) :

[2017-02-07 01:03:44] main.DEBUG: array ( 'request' => array ( 'user' => '', 'vendor' => 'frankjones', 'partner' => 'PayPalCa', 'pwd' => '', 'verbosity' => 'HIGH', 'BUTTONSOURCE' => 'Magento_Cart_Community', 'tender' => 'C', 'trxtype' => 'A', 'amt' => 0, 'createsecuretoken' => 'Y', 'securetokenid' => '804bbfbd34e7c38e767y5ced4b1a6a68', 'returnurl' => 'https://website.com/paypal/transparent/response/', 'errorurl' => 'https://website.com/paypal/transparent/response/', 'cancelurl' => 'https://website.com/paypal/transparent/cancel/', 'disablereceipt' => 'TRUE', 'silenttran' => 'TRUE', 'firstname' => 'Mark', 'lastname' => 'Rogers', 'street' => '101 Yonge Street', 'city' => 'Toronto', 'state' => 'ON', 'zip' => 'M1A7G6', 'country' => 'CA', 'email' => NULL, 'shiptofirstname' => 'Mark', 'shiptolastname' => 'Rogers', 'shiptostreet' => '101 Yonge Street', 'shiptocity' => 'Toronto', 'shiptostate' => 'ON', 'shiptozip' => 'M1A7G6', 'shiptocountry' => 'CA', ), 'result' => array ( 'result' => '0', 'securetoken' => 'XmOcHxPoCI8Wd3kC1g4VY2wL2', 'securetokenid' => '804bbfbd34e7c38e767y5ced4b1a6a68', 'respmsg' => 'Approved', 'result_code' => '0', ), ) {"is_exception":false} [] [2017-02-07 01:03:47] main.DEBUG: array ( 'STATE' => 'ON', 'ACCT' => '', 'ZIPTOSHIP' => 'M1A7G6', 'BILLTOLASTNAME' => 'Rogers', 'BILLTONAME' => 'Mark Rogers', 'SHIPTOCITY' => 'Toronto', 'LASTNAME' => 'Rogers', 'PNREF' => 'BT0PF45153E0', 'ADDRESSTOSHIP' => '101 Yonge Street', 'SHIPTOZIP' => 'M1A7G6', 'BILLTOFIRSTNAME' => 'Mark', 'AMT' => '0.00', 'SHIPTOCOUNTRY' => 'CA', 'TRANSTIME' => '2017-02-06 17:03:45', 'NAMETOSHIP' => 'Mark Rogers', 'ZIP' => 'M1A7G6', 'BILLTOCOUNTRY' => 'CA', 'EXPDATE' => '', 'STATETOSHIP' => 'ON', 'RESPMSG' => 'Invalid merchant information: 10501-This transaction cannot be processed due to an invalid merchant configuration.', 'COUNTRY' => 'CA', 'BILLTOZIP' => 'M1A7G6', 'SHIPTOSTREET' => '101 Yonge Street', 'SHIPTOSTATE' => 'ON', 'BILLTOCITY' => 'Toronto', 'BILLTOSTATE' => 'ON', 'CARDTYPE' => '0', 'FIRSTNAME' => 'Mark', 'AVSDATA' => 'XXN', 'CITYTOSHIP' => 'Toronto', 'SECURETOKEN' => 'XmOcHxPoCI8Wd3kC1g4VY2wL2', 'SECURETOKENID' => '804bbfbd34e7c38e767y5ced4b1a6a68', 'CITY' => 'Toronto', 'NAME' => 'Mark Rogers', 'HOSTCODE' => '10501', 'COUNTRYTOSHIP' => 'CA', 'BILLTOSTREET' => '101 Yonge Street', 'RESULT' => '5', 'ADDRESS' => '101 Yonge Street', ) {"is_exception":false} []

Further Considerations

The same error occurs no matter what we do with the CCV settings either in Paypal or Magento. Switching to Payflow link (something we are not signed up for but we did it just to test), does send the correct currency but throws the same error ultimately.

Conclusion

Having the ability to take payments is the essence of a shopping cart. We switched over to Magento 2 and wondered for a few weeks why our sales dropped off like crazy. Just a trickle came through. (People can check out using Paypal Checkout Express). Given the amount of people using paypal as their go to payment processor, makes this and other paypal issues some of the most pressing and important to solve on an expedited basis if possible. Some of the other bugs we can live with but not being able to take payments does make the Magento 2 proposition difficult to continue with.

[KalebHosie]

@gooki It appears your having the same issue as me. PayPal Payments Pro is not sending the proper currency to charge the customer in when doing the API call.

I can also confirm that my M2 installation passes an "AMT" of 0 as well. It charges the card afterwards (albeit in USD) so I don't see this being an issue in itself.

There shouldn't be any special config that is different from PayPal Payments Pro and PayFlow Link so I'm not sure why you're experiencing issues (unless there's a typo but I'm assuming you tried retyping everything a few times).

[gooki]

It may be the way the api is configured for PayPalCA, it may be taking the default settings for Paypal Payments PRO (American one) and applying them to Website Payments PRO (The Canadian Iteration). So it's passing the wrong information to Paypal ie. USD, and because it's sending USD instead of CAD the total transaction value is then zero because no CAD is being sent but USD? It's all conjecture but it may be the case. Thoughts?

[hostep]

@gooki: Magento 2.1.4 just got released and the release notes says something about fixing wrong currency being send to paypal, so maybe it's worth trying upgrading and testing if your issue is fixed by the update?

[gooki]

@hostep thanks for the suggestion will do and report back @supanatral maybe you can upgrade to 2.1.4 too and let us know if it helped

[gooki]

Tested with 2.1.4 and unfortunately no dice. USD still being sent to paypal, zero amount, and instead of Sale its sending Authorization. Tested with both Website Payments Pro and Payflow Pro

Paypal Report: Transaction Result Details Transaction ID: BU0PF3D82422
Result Code: 5 PayPal Transaction ID:
Timestamp: Feb 08, 2017 14:19:49 PM Response Message: Invalid merchant information Transaction Type: Authorization Authorization Code: 111111 Tender Type: Visa
AVS Street Match:
Credit Card Number: 4344
AVS Postal Code Match : Credit Card Expiration: 12 / 2017
International AVS Indicator:
Amount: 0.00 USD Card Security Code Match:
Tax Amount: 0.00 USD
ABA #:
Shipping/Freight Amount: 0.00 USD
Cust Ref #: Duty Amount: 0.00 USD
Recurring: No Original Amount: 0.00 USD
Payment Advice Code:

Transaction Status Transaction State: 1
Date To Settle: Feb 08, 2017 11:19:49 AM
Date Settled:
Response Code: 10501
Error Code:
Auth Resp Text:

[hubaig]

This is so frustrating. I am not sure what to do. I am using Pay-flow Canadian version and nothing I do works. I don't even know what alternate method to use.

[snez]

@hubaig many people have this problem for different reasons. Paste your exception here and I'll let you know how to debug it. The exception can be found by inspecting the AJAX request from your browser's network tab in the debugger and should look similar to https://github.com/magento/magento2/issues/6929#issuecomment-252723067

[pangteypiyush]

I'm using magento 2.1.4 and I have tried everything on this page.. but still I'm getting 400 on {magento_root}/rest/default/V1/carts/mine/payment-information.

Other things that I've tried were adding products which can be shipped ( i.e, not downloadable and have weight). This was done to make sure to have shipping tab on checkout page. The object being posted seems to be missing shipping address and other uninitialised fields in billing address.

POST payload : {"cartId":"1","billingAddress":{"customerAddressId":"1","countryId":"NL","regionId":"0","regionCode":null,"region":null,"customerId":"1","street":["wz857","streetline2"],"telephone":"9205920833","postcode":"3011 za","city":"amsterdam","firstname":"P","lastname":"P","saveInAddressBook":null},"paymentMethod":{"method":"paypalngp","po_number":null,"additional_data":null}}

P.S: I'm working on custom payment module, which worked perfectly on 2.1.3, without using REST API directly.

[KalebHosie]

I hate to add the pointless "I'm having this issue too" comment but; I have tested this on my end and I'm getting the same result as @gooki.

The when placing an order, the API call doesn't send PayPal the currency code.

I checked the differences between 2.1.3 and 2.1.4 and the only file that is different and refers to currency is "vendor/magento/module-paypal/Test/Unit/Model/Payflow/TransparentTest.php"

Maybe this is a silly question but does anyone know which file calls the PayPal API? (vendor/magento/module-paypal/Model/Api/PayflowNvp.php ???) I'm hoping there is a way that we can hard code it to send the currency, at least until Magento fixes this bug...

[hostep]

@supanatral, see this commit which is included 2.1.4: https://github.com/magento/magento2/commit/1c7f70d751f3cb2bcd2e076e97b900a3fc3912cc This is where the currency should be set correctly. (I'm not familiar with the Paypal code in Magento, so if you have other questions regarding this, I probably won't be able to answer them).

Maybe it is also a good idea for everyone who has a different issue in here, to create a brand new issue, because this thread is starting to fill up with a lot of different issues mixed together. The Magento support people probably will have a hard time figuring out what this thread is all about. If you create separate issues then it will be more clear for the support people what the exact issue is about and they might be able to help you quicker.

[KalebHosie]

Good call @hostep. I will start posting more information to issue #7977

If anyone else is having the issue of charging in USD funds than I would invite them to join us over there.

[fgp305]

Im having issues with Briantree and receiving the same error and now "record does not exist" message.

How to reproduce:

place item in cart and go thru the checkout process enter credit card and "place order"

should have order go thru but get this error on the screen shot.

Im using 2.1.3 in a development file not in production yet. Its been 4 months trying to resolve this and nothing. Im not the one doing the trouble shooting (hired a few people to do it)

Spoke to the people at brain tree and this is what they wrote:

What I can tell you is that the reason you are receiving the error is because a payment method nonce is not being populated in the API call to Braintree, which is something Magento is responsible for generating. Since we are not Magento ourselves, I have no ability to assist you with issues on the Magento side of things.

Hi Freddy,

Thanks for following up. I was able to locate a request from January 24 (the day of your screenshot) in our server logs. Here is the request:

Parameters: {"transaction"=>{"type"=>"sale", "customer"=>{"first_name"=>"freddy", "last_name"=>"pineda", "company"=>nil, "phone"=>"1234567890", "email"=>"fsb4e@yahoo.com"}, "amount"=>"106.53", "payment_method_nonce"=>nil, "order_id"=>"000000025", "channel"=>"Magento2_Cart_Community_BT", "billing"=>{"first_name"=>"freddy", "last_name"=>"pineda", "company"=>nil, "street_address"=>"1470 SE 18th Terrace", "extended_address"=>nil, "locality"=>"Homestead", "region"=>"FL", "postal_code"=>"33035", "country_code_alpha2"=>"US"}, "shipping"=>{"first_name"=>"fred", "last_name"=>"pineda", "company"=>nil, "street_address"=>"1470 SE 18th Terrace", "extended_address"=>nil, "locality"=>"Homestead", "region"=>"FL", "postal_code"=>"33035", "country_code_alpha2"=>"US"}, "options"=>{"store_in_vault_on_success"=>true, "submit_for_settlement"=>true}}, "merchant_id"=>"x2v3v33wk5pykk4n"}

and here is the error it caused:

[VALIDATION ERRORS] 91508 (Cannot determine payment method.), 81706 (CVV is required.) This error was caused because, as you see in the above log, payment_method_nonce​ is nil​. A payment method nonce is a string returned by the client SDK to represent a payment method. In your case, it likely indicates that you have not entered any card information in your checkout form. I'd suggest reviewing your inputs and attempting another test with a valid card.

I CAN ASSURE IM ENTeRING THE CORRECT INFORMATION ON THE CREDIT CARD SPACE.

also tried reaching out to my web host and this is what they sent:

Unfortunately we were not able to determine the exact reason for the issue. For some reason the application is returning:

POST https://www.freezerworkwear.com/development/rest/supermarket_en/V1/guest-carts/29940bfffa2007be4f5551fd0f6c7019/payment-information 400 (Bad Request)

[dey00]

i use Magento ver. 2.1.5 and experimented the error for many week on a dummy install with nothing else than magento, no template, no add on. (an error occurred on the server. please try to place the order again). No solution for this problem on Braintree or Authorize.net Thinking to return to 1.9. V1.9 work perfectly. What is an e-commerce solution without payment........!!!@!@#@!@#. BAD MOVE TO v2 of MAGENTO. THINKING ABOUT CHANGE SOLUTION E-COMMERCE>

[puples]

hello,

if you change the number of line addres 2 -> 1

you can execute this :

UPDATE customer_address_entity SET street=REPLACE(street,'\n',', ')

for me it's work...

[dey00]

Thanks for the help.

I made the change I receive 2 error messages.

One of magento

---

Attention Sorry, but something went wrong. Please contact the seller.

---

and one by email

---

Authorize.Net Developer Center Merchant,

Your script timed out while we were trying to post transaction results to it. Transaction ID: 0 Transaction Result: This transaction has been approved.

The following message was displayed to the customer:;

---

But the transaction complete !!!

do you have an idea

Thank a lot.

On 01/03/17 05:06 PM, puples wrote:

hello,

if you change the number of line addres 2 -> 1

you can execute this :

UPDATE customer_address_entity SET street=REPLACE(street,'\n',', ')

for me it's work...

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/magento/magento2/issues/6929#issuecomment-283486303, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ASVyfQn3lc_OLumL59IS7OJrpM0VvBUKks5rhev1gaJpZM4KRqIJ.

[AirmanAJK]

I encountered this issue due to the database field quote.reserved_order_id being an already existing order. The database constraint caused the insert statement to fail. This was immediately following a bad paypal order attempt, so perhaps the reserved id was updated in the quote, but the sales_sequence increment ID was not. I was only able to resolve this by manually deleting the reserved_quote_id from the database.

To make matters worse, these exceptions are not logged in the DB (WTF?), so if this happens to customers in production, you simply won't know.

[southerncomputer]

The problem is that the order was made using the reserved_order_id in attempt #1 quote, so now when you retry PayPal, it will try to use that reserved_order_id as the sales_order.increment_id and fail!

What I did was check the sales_order table to see if the increment_id existed before submitting the quote (to become an order), if it exists, empty reserved_order_id and if $orderData exists, unset increment_id. This will force the quote to use a new reserved_order_id to create a new order and succeed. Now PayPal knowing the original reserved_order_id or the new one - that is for you to work out!

Around here's what you'll ned to tweak: one page.php adminorder/Create.php module-paypal-express..checkout.php etc..

    $order = $this->quoteManagement->submit($quote, $orderData);

psst. does anyone know a fix that stops apostrophe's from killing the order submit (in shipping address?)

[AirmanAJK]

I'd recommend a plugin of "beforeReserveOrderId" in "\Magento\Quote\Model\Quote".

This way, it's not an invasive fix, and it's not dependent on any particular order method and will always ensure no bad reserved quote IDs are used. Here's my plugin code to do just that:

public function beforeReserveOrderId(\Magento\Quote\Model\Quote $quote) {
    $reservedOrderId = $quote->getReservedOrderId();

    if($reservedOrderId) {
        $order = $this->orderFactory->create()->loadByIncrementIdAndStoreId($reservedOrderId, $quote->getStoreId());
        if($order->getId()) {
            $quote->setReservedOrderId(null);
        }
    }

    return null;
}

As for apostrophe's in shipping addresses causing problems, I did a quick test and didn't have an issue (I used "123' Main Street". Can you explain in more detail what you're encountering?

[southerncomputer]

Yeah that seems more elegant. We have about 50+ concurrent admins creating/editing quotes and orders - so the plugin method wasn't as elegant since you may need to force constraint depending on the job at hand!

Say if the company had a single apostrophe in the customer_address_entity copied to quote_address and you made an ADMIN order in the backend, the ship method and totals would go to zero - upon clicking on a shipping method it would say no quotes available for this order! and kaput!

[candyjo]

Hi, I hope someone can help me. I have inherited a Magento 2 from another developer. We have had issues from the get go. I highest priority of the issues is some of our customers are able to place an order and others receive errors. Some errors are "An error occurred on the server. Please try to place your order again", and other errors to do with the server, and zip code. We recently upgraded from 2.1.0 to 2.1.5. The issues were occurring prior to the upgrade and still continuing after the upgrade. I am open to any solutions. The owner of the company is wanting to dump Magento all together. I need to try to save it if all possible. Thanks in advance.

[fgp305]

Candyjo - I've had issues with the checkout as well. My ordeal began in August 2016 and I decided to dump Magneto 2 in late January. After getting 4 different developers to try to help, no one has found the answer. Not even the developer of the check out module.....So after much wasted time and $$$ I dumped altogether and updated my Zen Cart.

So for the time M2 will be on the shelf for the near future.

Good luck with you project.

[SewHappy58]

I'm having the same issues with Magento 2.1.1. After following everything on this guide, I'm not able to find a fix. I have a feeling it's something with either Varnish or permission settings. Everytime I contact my hosting company, they were able to fix it, but after a customer goes online to purchase a product, it would fail again. And if you fail once, it will not let you use PayPal as that button becomes disabled.

My site is here - http://bit.ly/2nI8Qpt

[josealgardataborges]

(magento 2.1.5)

Me too could not place an order, with the same symptoms that everybody here, so I tried to make an order using the BACKOFFICE ADMIN login, and found out the exact problem (within the detailed error message that the backoffice provides, contrary to the frontend).

So, my advise, is try to place an order in the backoffice and check the errors (on screen).

[riprod]

Has anyone hound a solution to this. We are at the point of reverting back to Magento 1.9.x I am on 2.1.5 and every 4th or 5th order gives the "An error occurred on the server. Please try to place the order again" - This is obviously a bug

[josealgardataborges]

@riprod have you tried my solution (2 posts above?)

[riprod]

Are you referring to testing an order in the back end ? I can't do that because it says "No Payment Methods available". Not sure why

[josealgardataborges]

strange! Yes that was the only way i tracked the problem to a plugin.

[AirmanAJK]

The error message at checkout occurs essentially as a "catch all" for some part of the order creation process throwing in exception. Because there are many moving parts in order creation (plugins, events, etc), the straightforward way to figure out exactly why the order is failing is to restore a backup of the website to a development environment and debug the code. This is how I found out that my problem was using a reserved_order_id that already existed as an order. The actual exception thrown mentioned a duplicate key database constraint being violated.

My error was occurring at "\vendor\magento\module-quote\Model\QuoteManagement.php" at the line $order = $this->orderManagement->place($order);

That statement is wrapped in a try-catch block. Adding a breakpoint in the catch block will allow you to see the detailed error message. If your error is not occurring at this line, you can search the entire code base for the phrase "Please try to place the order again.". There are only 4 occurrences right now that are candidates for being the error message you are seeing. Add breakpoints at all of them and see what gets hit. From there, you have to follow the code until the error occurs.

The tricky part here is making sure the problem is reproducible on the dev environment to do proper debugging. You will likely need to log in as the particular customer encountering the issue which may require some password field manipulation/resetting in the dev version. Overall, I realize that this solution is not available to everyone since it requires a Magento developer with experience to be able to navigate and debug the code, but due to the error being so general and NOT EVEN BEING LOGGED, this is likely to be the only reliable method of squashing whatever bug may be occurring.

Also, please make sure your issue is not because of a reserved_order_id on the quote matching an already existing sales order. You'll have to look at the database fields in tables quote and sales_order. If any reserved_order_id in an ACTIVE quote matches the increment_id of a sales_order (both within the same store), the customer who owns that quote will get the dreaded error message you are seeing when Magento tries to create an order using an increment_id that has already been used.

[phronesis]

@AirmanAJK Really nice response. I see that the areas where the error occurs, there is a generic exception thrown without even logging the real exception. The way to really see the exact exception is to add breakpoints. Setting up remote debugging in your IDE will really go a long way in troubleshooting the issue. I migrated from Magento 2.0.11 to Magento 2.1.5 and started experiencing the issue. In my case, it was an error about Region being a required field. I set a breakpoint here: https://github.com/magento/magento2/blob/2.1.5/app/code/Magento/Checkout/Model/PaymentInformationManagement.php#L71 to see the exact error.

Turning off the setting from the admin that required state solved it for me.

What Magento2 seems to me is that the developers needed to meet the release deadline because management insisted that they had to, so developers had no choice but to release software was not ready for production. We were amongst the first shops to migration from Magento 1.8.x to Magento 2 - At the time, Magento 2.0.5. It was a horrible experience. Every single thing that could go wrong indeed went wrong. From wrong EAV attribute ids to customers not able to log out, to missing cart, just name it. I am currently facing an issue with Magento assigning the value of my region field (string) to region_id (int) and as a result throwing return type errors. Setting breakpoints in the browser using chrome developer tools, I seem to see where the error is coming from. Without using debuggers to step through Magento code(in the browser and in your IDE) in developer mode, it is almost impossible to get to the root of the errors. Really bad Magento team.

[msliman]

HI All, I have the same error : An error occurred on the server. Please try to place the order again.

And I catched it on the log as : INVALID_REQUEST: Field [order.avsDetails.billToFirstname] was not in charset [ISO-8859-1]

I used Arabic words in the inputs.

So any body can help.

[timpiele]

We're having the same issue. We have no 3rd party modules. It happens in Porto theme and Luma. Authorize.net shows successful transactions, and the orders show as pending in the backend, but the user sees an error. Any solution yet?

[gambi52]

We have had the same issue with our site.
Magento 2.1.4 Payment Method: Authorize.net Process: Customer status: immaterial Place any item in cart. proceed to checkout enter address/shipping method continue to payment page enter payment information Place Order

Expected Result: Order success page Receive transaction email with new order number

Actual Result: page blinks and all data remains on page no indication of success page no order verification emails received by customer Authorize.net receives payment and proceeds to process Order is created in Admin *Red error box appeared briefly during one attempt stating "An Error Occurred on the Server. Please try again."

Payments were processed through Authorize.net, the order was created in Admin, but Magento2 was not proceeding with payment success page or transaction emails. We had a breakthrough when we created an order through Admin and received the error "The transaction was declined because the response hash validation failed." We did not set up the md-5 hash function between Authorize.net and Magento on the recommendation of a rep at Authorize.net.

Once we set up the md-5 hash on Authorize.net and in Magento Admin, orders processed normally. Say a prayer that this fix sticks!

Thanks for all the clues.

[brvoltz]

What is the location in Magento to add the MD5 hash code? I'm not finding it...

Thanks in advance....

[gambi52]

It is located in the Magento Admin. Go to: Stores>Configuration>Sales>Payment Methods>Authorize.net Direct Post>Merchant MD5.

You must also save the same code on Authorize.net. It can be anything up to 20 characters.

[brvoltz]

Gambi52 - Many thanks... the issue is I'm using CIM and the plugin does not have the field... They are adding it, but feel this will not solve the issue.. I'm very green to Magento... so sorry for the newbie questions / comments...

[brvoltz]

May I ask, can someone translate this to English for me?

"{"message":"An error occurred on the server. Please try to place the order again.","trace":"#0 \/home\/digidwo\/public_html\/app\/code\/Amasty\/Checkout\/Model\/GuestPaymentInformationManagement.php(47): Magento\Checkout\Model\GuestPaymentInformationManagement->savePaymentInformationAndPlaceOrder('f03644e07e13fad...', 'bhills_4300@mai...', Object(Magento\Quote\Model\Quote\Payment), Object(Magento\Quote\Model\Quote\Address\Interceptor))\n#1 [internal function]: Amasty\Checkout\Model\GuestPaymentInformationManagement->savePaymentInformationAndPlaceOrder('f03644e07e13fad...', 'bhills_4300@mai...', Object(Magento\Quote\Model\Quote\Payment), Object(Magento\Quote\Model\Quote\Address\Interceptor), Array)\n#2 \/home\/digidwo\/public_html\/vendor\/magento\/module-webapi\/Controller\/Rest.php(307): call_user_func_array(Array, Array)\n#3 \/home\/digidwo\/public_html\/vendor\/magento\/module-webapi\/Controller\/Rest.php(216): Magento\Webapi\Controller\Rest->processApiRequest()\n#4 \/home\/digidwo\/public_html\/var\/generation\/Magento\/Webapi\/Controller\/Rest\/Interceptor.php(37): Magento\Webapi\Controller\Rest->dispatch(Object(Magento\Framework\App\Request\Http))\n#5 \/home\/digidwo\/public_html\/vendor\/magento\/framework\/App\/Http.php(135): Magento\Webapi\Controller\Rest\Interceptor->dispatch(Object(Magento\Framework\App\Request\Http))\n#6 \/home\/digidwo\/public_html\/vendor\/magento\/framework\/App\/Bootstrap.php(258): Magento\Framework\App\Http->launch()\n#7 \/home\/digidwo\/public_html\/index.php(39): Magento\Framework\App\Bootstrap->run(Object(Magento\Framework\App\Http))\n#8 {main}"}"

[southerncomputer]

@brvoltz you need to patch your code to track the actual error occurring or look in var/log/*.log for a better error message! see @hostep or my recommendations from earlier posts in this thread!

[brvoltz]

@southerncomputer - as I'm very green to this side.. What would take to have you make the changes, so we can log what is going on? What is interesting is I have no issues with placing a credit card order from the admin side... only the front end...

[southerncomputer]

try this patch and let me know what error it throws afterwards! https://github.com/southerncomputer/magento2/commit/79e8317e8e87b998d15f4b54fbeefce0901e4dc0

[snez]

@brvoltz if you apply the patch that @southerncomputer posted then you will get a more specific error which you will be able to debug. Magento 2 is essentially masking the true cause of the problem in that method.

[brvoltz]

Many thanks for the help... what is now very interesting, I changed my purchased theme back to the default (Luma) cleared the cache and then processed a credit card, no errors... Then I changed back to the purchased theme and cleared the cache and processed a credit card... NO Errors... Go figure... LOL

Now to figure out how to trim the logs after this....

[Weltpixel]

Hi,

Until now this are the measures that we took and seams to significantly improve the transaction decline rate. After applying all 3 solutions, we didn't receive any reports of other users not being able to checkout using Braintree on our Magento 2.1 store.

Hope this helps: https://support.weltpixel.com/hc/en-us/articles/115007753688-How-we-solved-Braintree-Magento-2-checkout-issues-with-our-Magento-2-1-store

Regards, WeltPixel Team

[brvoltz]

Well this really interesting... the site was working and now it has stopped... and giving the error, but not a thing in the logs.. nothing.. empty... I thought it was because of paypal, but I disabled it, still there, I moved back to the Luma theme, still there... I'm completely lost on this one....