Checkout with iDeal, Bancontact and giropay fails randomly when using the Checkout block

[paulostp]

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".

• The Stripe logs show that a request to confirm a payment intent failed because of Invalid paramater owner [name]. Inspecting the log further, shows that all the customer data is missing from the request:

• This is a random error and the checkout can be successful if you try again.

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:

• 5649128-zen (merchant went for a conflict test and never came back, no transactions in WooCommerce Payments since)
• 5689828-zen (merchant solved the issue by tweaking their checkout page)
• 5747899-zen (merchant reported that they identified that the Checkout block is causing this issue)
• 5683211-zen (merchant made some changes to their site and the error disappeared, no transactions in WooCommerce Payments since)

[jessy-p]

@Automattic/pulsar

[kalessil]

Thanks for the ping @jessy-p! We'll look into details in ~2 weeks - currently, we don't have the needed capacity.

[kaushikasomaiya]

6041100-zen

[kalessil]

👀

[eriklenaerts]

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.

[maxlaf]

6265024-zen

[senff]

6271250-zen

[nagpai]

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 ?

[paulostp]

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.

[nagpai]

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

[nagpai]

Thank you, @eriklenaerts and sorry about missing your comment earlier.

I was able to consistently reproduce the bug with these steps:

1. Open the website in incognito and check out as a guest user, through a checkout pages made using Blocks.
2. Make sure the billing fields, except the prefilled country field, are all empty
3. Select the payment Method ( iDEAL - also reproduced when we try Bancontact )
4. Try to checkout and you will see the error. Invalid parameter owner[name]. Owner name must be at least 3 characters long.
5. Payment Intent confirmation API call shows a payload with all billing fields empty, except country

[eriklenaerts]

@nagpai that's good news ;). thanks for looking into it

[rossviviano]

6751972-zen

[timur27]

I attempted to replicate the issue in two different environments, but I was unsuccessful in both

1. JN site with WooPayments 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.
2. Local environment with deferred intent creation UPE. This is a different type of checkout implementation which performs steps differently and overall, a lot has been changed there compared to the legacy UPE. This could also lead to the point that the issue is not reproducible now.

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.