Closed paulostp closed 7 months ago
@Automattic/pulsar
Thanks for the ping @jessy-p! We'll look into details in ~2 weeks - currently, we don't have the needed capacity.
6041100-zen
👀
hey, I have the same issue here with the Bankcontact
payment option. I think the error occurs whenever I skipped the billing details and select that payment option first.
6265024-zen
6271250-zen
I did a test today on my local setup with a Netherlands Account and with iDEAL . I was unable to replicate the error.
It could be a plugin conflict that prevents the fields from being submitted.
Can we ask the users to test this with Storefront / TwentyTwenty three and with all plugins turned off except Woo + WCPay ?
It could be a plugin conflict that prevents the fields from being submitted. Can we ask the users to test this with Storefront / TwentyTwenty three and with all plugins turned off except Woo + WCPay ?
A conflict is always a possibility, but all of these sites are very different. Back then I was able to reproduce once on my test site with Storefront. Due to the random nature of this misbehavior, I wasn't able to see it again, just like the original merchant reported, if you try again it will usually work.
This isn't something that we can ask merchants to experiment with on a live store as most times the merchant's themselves can't reproduce — it's the customers that report it. It would be a different scenario if there was no workaround, but we already gave the merchants a solution by asking them to use the shortcode instead of the checkout block. Their payment problems are solved for now, even if the checkout page isn't looking like they wanted to.
However, the solution for some of these merchants was to stop using WooCommerce Payments, which is a shame.
Back then I was able to reproduce once on my test site with Storefront
Cool. If we are able to reproduce this on a test setup then that proves that the issue is not related to other plugins / theme. As you rightly pointed out, @paulostp , the issue is pretty random and difficult to reproduce. Hence it is difficult to find out accurately what could be the cause of it.
From the screenshots and nature of the issue, it seems the information is blocked at the browser side itself. For future instances, if we are able to reproduce, or if we have contact with the user that is facing the issue, can we get the browser details through a site like whatismybrowser.com
Thank you, @eriklenaerts and sorry about missing your comment earlier.
I was able to consistently reproduce the bug with these steps:
Invalid parameter owner[name]. Owner name must be at least 3 characters long.
@nagpai that's good news ;). thanks for looking into it
6751972-zen
I attempted to replicate the issue in two different environments, but I was unsuccessful in both
5.3.3
. I use this WooPayments version to be sure that the environment runs legacy UPE (this issue describes legacy UPE fields) and is more in line with the timeline the issue was reported. My site is running the latest version of WooCommerce -> Blocks, and I guess that checkout fields are more bulletproof if it goes to validating empty fields. I'm seeing a lot of field validation errors as expected, when trying to reproduce.To sum up, the issue is not reproducible now and I'm closing it. I will follow if there will be new reports and we will re-open it then.
Describe the bug
For some merchants from the Netherlands, using the iDeal payment method, sometimes the checkout will fail with the error:
"Invalid paramater owner [name]. Owner name must be at least 3 characters long"
.Invalid paramater owner [name]
. Inspecting the log further, shows that all the customer data is missing from the request:To Reproduce
Update: steps to reproduce
It seems to be caused by the Checkout block. At some point, we were able to reproduce the behavior on a test site by switching the checkout page from shortcode to block.
However, due to the random nature of the issue, haven't had success in reproducing it further. The merchant does mention this is more frequent with mobile devices.
Actual behavior
The checkout fails, hinting that some information is invalid, even though the the whole checkout form is filled.
Expected behavior
That the merchant gets successfully redirected to iDeal if the checkout form has all the necessary information
Additional context
The latest case is 5802398-zen. Other earlier instances of this same error: