Magento2: 2.3.5-p1 Guest Checkout - Api Call Guest Cart Status 400 Payment method

[wilhelmpa]

Hi there,

I have encountered the fowling bug.

Preconditions (*)
Magento 2.3.5-p1 vanilla
Varnish-5.2.1 revision 67e562482
Redis 4.0.9
Nginx 1.14.0
PHP 7.2.24

Steps to reproduce (*)
Add Something to cart and go to one page checkout as guest and try to redeem a coupon and look in the developer console.

Expected result (*)
Redeem a coupon code in guest checkout with no error

Actual result (*)
In the developer console you can see that the ajax call:

https://www.xyz.de/rest/default/V1/guest-carts/xxxxxx/set-payment-information

return the status 400. So the payment Method isn't set (Testet with Luma Theme and Amazon Pay, Klarna Checkout as well)

It also appears an error message in the frontend, which says that I have to select the payment method. As a result coupons can not be redeemed successfully because a new error appear after coupon redeem which states:

select-payment-method-mixin.min.js:1 Uncaught TypeError: Cannot read property 'method' of null
at select-payment-method-mixin.min.js:1
at wrapper.min.js:2
at Object.setPaymentMethods (payment-service.min.js:2)
at Object. (get-payment-information.min.js:2)
at fire (jquery.min.js:212)
at Object.fireWith [as resolveWith] (jquery.min.js:218)
at done (jquery.min.js:628)
at XMLHttpRequest.callback (jquery.min.js:655)

and the loading Gauge won't disappear anymore.

Best Regards

Patrick

[m2-assistant[bot]]

Hi @wilhelmpa. Thank you for your report.
To help us process this issue please make sure that you provided the following information:

• [ ] Summary of the issue
• [ ] Information on your environment
• [ ] Steps to reproduce
• [ ] Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

For more details, please, review the Magento Contributor Assistant documentation.

@wilhelmpa do you confirm that you were able to reproduce the issue on vanilla Magento instance following steps to reproduce?

• [ ] yes
• [ ] no

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[steved1982]

[Neusta-Hartwig]

This is already fixed in 2.4 (see https://github.com/magento/magento2/commit/e5cd82d87c7254503b4c9b6a7ff17017413dd016)

Greetings,
Christoph

[m2-assistant[bot]]

Hi @swathishs. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

• [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
  Details

  If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.

• [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

• [ ] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• [ ] 4. Verify that the issue is reproducible on 2.4-develop branch

  Details

  - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!

• [ ] 5. Add label Issue: Confirmed once verification is complete.

• [ ] 6. Make sure that automatic system confirms that report has been added to the backlog.

[swathishs]

@magento give me 2.3.5-p1 instance

[magento-engcom-team]

Hi @swathishs. Thank you for your request. I'm working on Magento 2.3.5-p1 instance for you

[magento-engcom-team]

Hi @swathishs, here is your Magento instance.
Admin access: https://i-28161-2-3-5-p1.instances.magento-community.engineering/admin_cf62
Login: 6d989d88 Password: ba282fb04183
Instance will be terminated in up to 3 hours.

[girishanand]

@magento-engcom-team

Since this ticket is still open so I comment here.
There is still an issue since on selecting the payment method on checkout the Api will still be fired which is okay for payment methods like Cash on Delivery, Check / Money order which does not require any input but for Payment method like Purchase Order or Custom payment method Credit Card api call will throw 400 error as they require input from customer.
IMHO payment method on selection should not call API that requires input or the other case is doing validation on any payment method while click on Place Order button.

[speedupmate]

This is already fixed in 2.4 (see e5cd82d)

Can core team just agree that it is a bad practice to do another ajax call after some ajax call is finished , effectively this is what this mixin does . And instead of this mixin create a plugin or observer for backend code to append it to existing results on the ajax call it tries to depend on.

[rhoerr]

Affirming @girishanand 's note -- I do not believe https://github.com/magento/magento2/commit/e5cd82d87c7254503b4c9b6a7ff17017413dd016 fully resolves this issue. It prevents the 'undefined method' JS error but does not prevent payment validation errors from displaying over the coupon form. This is easily reproduced:

• Enable the Purchase Order payment method
• Go to checkout and open the discount form
• Select the Purchase Order payment method
• See how the discount form displays "Purchase order number is a required field.", despite no relevance to the coupon form and no opportunity for the user to have entered one yet.

The underlying cause is exactly the same mixin causing set-payment-information to be fired prematurely, and then displaying resulting error messages where they should not be.

A payment method is selected in this case, so the if (paymentMethod === null) { check added in 2.4.0 does not resolve this.

[speedupmate]

https://github.com/magento/magento2/commit/e5cd82d87c7254503b4c9b6a7ff17017413dd016 will not solve this until every bit of data that this endpoint needs is validated before endpoint is called .

• its still incredibly stupid to evoke the action after one action is finished

This change is so incredibly bad that its almost impossible to disable this ajax call without loosing backwards compatibility (for extension providers) or without just overwriting this file in theme context

[sayanthkoroth]

@magento-engcom-team Is there any update here ? I am using custom payment method in my store and I updated the store to 2.3.5-p2. Now on selecting credit card as payment method, an ajax 'set-payment-information' is triggered with a 400 status code.

[ghost]

@sayanthkoroth you're wasting your time I imagine. Magento won't fix this for 2.3.5 now that 2.4 is out.

[speedupmate]

who really needs to disable this mishap from their own extension can add to their requirejs-config.js file

'Magento_Checkout/js/action/select-payment-method': { 'Magento_SalesRule/js/action/select-payment-method-mixin': false }

be aware that this module adds multiple such mixins to different action calls and you might need to disable those too

[girishanand]

Basically API call on payment method selection needs to be disabled for any payment method.
The other way to disable it like @speedupmate mentioned is using the composer instead.

`"scripts": {

"post-install-cmd": [
    "perl -pi -e \"s|'Magento_SalesRule/js/action/select-payment-method-mixin': true|'Magento_SalesRule/js/action/select-payment-method-mixin': false|\" vendor/magento/module-sales-rule/view/frontend/requirejs-config.js"
],
"post-update-cmd": [
    "perl -pi -e \"s|'Magento_SalesRule/js/action/select-payment-method-mixin': true|'Magento_SalesRule/js/action/select-payment-method-mixin': false|\" vendor/magento/module-sales-rule/view/frontend/requirejs-config.js"
]

}`

[chirag-taraviya]

Here is solution for 2.3.5 Extend select-payment-method-mixin.js to Your Theme app/design/frontend/Vender/Theme/Magento_SalesRule/web/js/action/select-payment-method-mixin.js

Add below code on line NO. 22
if (paymentMethod === null) {
return;
}

[speedupmate]

@chirag-taraviya this is bit useless. Since there can be other params this endpoint needs or payment method needs to send to get a valid response from this endpoint

[rhoerr]

Follow up: The same underlying validation error prevents Purchase Order (and any other payment methods with global field validation or otherwise extending \Magento\Payment\Model\Method\AbstractMethod::validate()) from working for the Cart Price Rule "Payment Method" condition. I believe that condition (added somewhere in 2.3) is what the AJAX call and mixin causing all of this was added for in the first place.

Realistically, it should probably assign the payment method without first validating said payment method. You shouldn't need all payment fields to be filled in before you mark a method as active on the quote.