magento2: Error 400 with braintree on checkout

Hi, We are facing this issue with some payment. Most of payment are successfull but sometimes it happend and we didn’t figured why. If the user close the browser window and reopen it, It can solve the issue, but we do not know if it’s always the case.

This issue can happend with logged in user, OR guests, and happend when user select stored card number OR, when the user give the card numbers. It’s difficult to reproduce this error, when we try to do so, it works … but this issue happend with 10% of our clients (estimation based on logs). When it happend, there is no exceptions in the log, even in debug mode for the braintree module.

here is some apache log lines :


XX.XX.XX.XX something.com - - [22/Mar/2017:16:02:57 +0100] "POST /rest/default/V1/guest-carts/xxxxxxxxxxxxxxxxxxxxxxxxxxxx/payment-information HTTP/1.1" 400 640 "https://something.com/checkout/" "Mozilla/5.0 (iPad; CPU OS 9_3_5 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13G36 Safari/601.1"
XX.XX.XX.XX something.com - - [22/Mar/2017:16:03:31 +0100] "POST /rest/default/V1/guest-carts/xxxxxxxxxxxxxxxxxxxxxxxxxxxx/payment-information HTTP/1.1" 400 640 "https://something.com/checkout/" "Mozilla/5.0 (iPad; CPU OS 9_3_5 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13G36 Safari/601.1"
XX.XX.XX.XX something.com - - [22/Mar/2017:16:03:52 +0100] "POST /rest/default/V1/guest-carts/xxxxxxxxxxxxxxxxxxxxxxxxxxxx/payment-information HTTP/1.1" 400 640 "https://something.com/checkout/" "Mozilla/5.0 (iPad; CPU OS 9_3_5 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13G36 Safari/601.1"
XX.XX.XX.XX something.com - - [22/Mar/2017:16:03:54 +0100] "POST /rest/default/V1/guest-carts/xxxxxxxxxxxxxxxxxxxxxxxxxxxx/payment-information HTTP/1.1" 400 640 "https://something.com/checkout/" "Mozilla/5.0 (iPad; CPU OS 9_3_5 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13G36 Safari/601.1"
XX.XX.XX.XX something.com - - [22/Mar/2017:16:04:45 +0100] "POST /rest/default/V1/guest-carts/xxxxxxxxxxxxxxxxxxxxxxxxxxxx/payment-information HTTP/1.1" 400 640 "https://something.com/checkout/" "Mozilla/5.0 (iPad; CPU OS 9_3_5 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13G36 Safari/601.1"
XX.XX.XX.XX something.com - - [22/Mar/2017:16:05:04 +0100] "POST /rest/default/V1/guest-carts/xxxxxxxxxxxxxxxxxxxxxxxxxxxx/payment-information HTTP/1.1" 400 640 "https://something.com/checkout/" "Mozilla/5.0 (iPad; CPU OS 9_3_5 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13G36 Safari/601.1"

With this client using Edge :


xx.xx.xx.xx something.com - - [21/Mar/2017:18:12:35 +0100] "POST /rest/default/V1/carts/mine/payment-information HTTP/1.1" 400 4018 "https://something.com/checkout/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Edge/14.14393"
xx.xx.xx.xx something.com - - [21/Mar/2017:18:13:46 +0100] "POST /rest/default/V1/carts/mine/payment-information HTTP/1.1" 400 610 "https://something.com/checkout/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Edge/14.14393"
xx.xx.xx.xx something.com - - [21/Mar/2017:18:14:58 +0100] "POST /rest/default/V1/carts/mine/payment-information HTTP/1.1" 400 610 "https://something.com/checkout/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Edge/14.14393"
xx.xx.xx.xx something.com - - [21/Mar/2017:18:15:28 +0100] "POST /rest/default/V1/carts/mine/payment-information HTTP/1.1" 400 610 "https://something.com/checkout/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Edge/14.14393"

4 unsuccessfull payment

Here the client tried to close the browser window, reopen it, re log and retry payment : xx.xx.xx.xx something.com - - [21/Mar/2017:18:18:34 +0100] "POST /rest/default/V1/carts/mine/payment-information HTTP/1.1" 200 501 "https://something.com/checkout/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Edge/14.14393" This time it was good.

Preconditions

Environement : Debian 8 / PHP 7 / Magento 2.1.2 / Redis for sessions and FPC / Opcache
Mysql : mysqlnd 5.0.12-dev / mysqld 5.7.16 Apache : Server version: Apache/2.4.10 (Debian)

Steps to reproduce

As you can see in the log, this happend when the client click on the “Proceed payment button”, but it’s really hard for us to reproduce it, its random.

Expected result

  1. Payment OK or KO

Actual result

  1. Logs as written here, no exceptions, no i/o with the braintree servers/

Thanks for your help.

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 17 (15 by maintainers)

Most upvoted comments

Agreed - that’s no ok to lose exceptions if the order cannot be save, specially after payment.

Actually the logs @joni-jones is suggesting (which are today the only way to know what’s going on besides xdebug) are in develop branch, apparently part of a 2.2-dev ticket (MAGETWO-60073). https://github.com/magento/magento2/blame/develop/app/code/Magento/Checkout/Model/GuestPaymentInformationManagement.php#L96 https://github.com/magento/magento2/blame/develop/app/code/Magento/Checkout/Model/PaymentInformationManagement.php#L90

That’s a good candidate for 2.1.7 or a patch, seeing the number of different bugs where people are puzzled with similar “400”, and no exceptions in log : https://github.com/magento/magento2/issues/8488 https://github.com/magento/magento2/issues/6929 https://github.com/magento/magento2/issues/5902 https://github.com/magento/magento2/issues/6125 https://github.com/magento/magento2/issues/6522 https://github.com/magento/magento2/issues/9116

@scottsb I understand your point of view, but this kind of situations are critical, because you need to check every transactions in order to see if one of them has been “forgotten” in the sales list. I think that once the payment has been accepted, even if there is an exception in the process, an order should be created (even with minimal informations), or notified (mail if it’s not possible to write in db).

To the latter point, this is an architectural concern I also have: if there is an exception in processing the payment after it is captured, the handling structure causes the order not to be created and the user to be taken back to the payment form. This is obviously a major customer service issue, but since exceptions should be, well, exceptional, it’s hard to argue it’s strictly a bug.

OK, I added " $this->getLogger()->critical($e);" at : https://github.com/magento/magento2/blob/2.1/app/code/Magento/Checkout/Model/GuestPaymentInformationManagement.php#L83 and https://github.com/magento/magento2/blob/2.1/app/code/Magento/Checkout/Model/PaymentInformationManagement.php#L71

Today, a lot of errors, this time the script exited 3 times between this line : $order = $this->orderFactory->create(); and this line : $this->quoteValidator->validateBeforeSubmit($quote) ; in the submitQuote function (QuoteManagement.php), without exception in the exception.log / or line in debug.log.

Another bug (not the same) is present in the checkout process, but it trigger rarely. In this other bug, the payment is OK and appear in the braintree history but the order is not present in the sale history. In that case, there is nothing in the exception.log, but there is lines in the debug.log. It happend in the try/catch block of the submmitQuote function in QuoteManagement.php. I added a logger in this section too, will propably get more informations on this next time.