wbrubaker.a11n

I’m not so sure myself what difference any of that makes. You’re right that the order shouldn’t be able to be placed without that being entered.

Do you happen to have server access logs for the day that this order was placed? You may need to contact your host to help locate those. If you do, those logs, coupled with the Customer I.P. address that is stored with the order can be used to put together a picture of the steps that this customer may have taken to place this order.

Link to image: https://d.pr/i/SFPQPI

I’m not able to reproduce this on a testing site here: https://wctesting.tk/shop nor am I able to find any reports of this caused by WooCommerce Stripe in the issue tracker here: https://github.com/woocommerce/woocommerce-gateway-stripe/issues

This leads me to believe that the behavior that you are experiencing is caused by something external to WooCommerce and Stripe.

If you are able to reproduce this under the following conditions:

1. An unmodified, default WordPress theme such as Twenty Twenty or Storefront active.
2. No other plugins except for WooCommerce and Stripe active.

Please do let us know and we can take a closer look.

We do understand that placing a site under those conditions may be disruptive. Many people maintain a staging copy of their site for exactly this purpose. That way, testing, and troubleshooting can be done on the staging copy without disrupting the operation of the live site. If your host does not provide an easy way to set up a staging site, you might want to use something like the WP Staging plugin for this purpose.

Thanks for that feedback.

I’d like to ask you to enable debugging for the PayPal checkout plugin. There’s some documentation on that here: Please see **Enable Logging** under Advanced Options

With that done, the next time this happens, can you then check the log to determine what street address is entered. You can find the logs under WooCommerce -> Status -> Logs. In the dropdown selector near the top right, look for any logs where the name begins with wc_gateway_ppec, followed by a date, followed by some random letters/numbers. The values you’re interested in are PAYMENTREQUEST_0_SHIPTOSTREET, PAYMENTREQUEST_0_SHIPTOSTREET2, PAYMENTREQUEST_0_SHIPTOCITY, PAYMENTREQUEST_0_SHIPTOSTATE, PAYMENTREQUEST_0_SHIPTOZIP, and PAYMENTREQUEST_0_SHIPTOPHONENUM

Once you have that, is it a valid address? If so, please do contact PayPal for an explanation of why the address doesn’t validate on their system. If it is not a valid address, inform the user that they will need to enter a valid address to checkout.

I’d like to ask you to disable script concatenation. At least temporarily. It’s hard to say how that might be enabled, but I’d suggest you look in your wp-config.php. Search for something like define( 'CONCATENATE_SCRIPTS', true ); If you find that, or if there’s nothing at all for it, change it to (or add) define( 'CONCATENATE_SCRIPTS', false ); .

It’s possible that action alone will get things working for you. If it does, please take that information to your host. If you are still getting a JavaScript error referencing …”h(…) .block is not a function” can you open up the “sources” tab of your browser developer tools and expand the directory tree of wp-content/plugins/woocommerce/js/jquery-blockui and get us a screenshot of that (or whatever you can if you can’t expand it out that far).

example:

Link to image: https://d.pr/i/qTvhJU

If the error is different now, can you let us know what you’re seeing?

• This reply was modified 3 years, 6 months ago by wbrubaker.a11n.

Please contact us at WooCommerce.com > My Account > Support. You may need to create an account before you can access that page.

Please include a link to this forum thread, so that we can keep track of what’s already been done.

Also, please include your site URL and the email address of the WooCommerce Payment registered account.

We will be able to help you further there.

You don’t need WooCommerce Memberships, there are other membership type plugins that can be used and it would be completely independent of the payment gateway.

Have you tried updating Divi?

The Facebook for WooCommerce plugin does provide a filter named wc_facebook_product_price that could be used for that purpose. You can see that in code here: https://github.com/woocommerce/facebook-for-woocommerce/blob/2.6.1/includes/Products.php#L395 so you can use that hook to filter the price that is synced to Facebook.

The best place for feature requests would be the WooCommerce Ideas board here: https://ideas.woocommerce.com/forums/133476-woocommerce Ideas there are reviewed by our developers and product managers and prioritized according to demand.

Alternatively, if the Yith Role Based Prices plugin developer wants to submit a compatibility patch or a bug report, the repository for the Facebook for WooCommerce plugin can be found here: https://github.com/woocommerce/facebook-for-woocommerce/

We’ll communicate with you in the ticket you have open with us. Thanks.

What do you mean by “catalogue page”?

What do you mean by “make more than one row”?

Thanks for that. I see you are using the most recent version of the Stripe plugin. I have tested against the same version on my test site here: https://wctesting.tk/shop/clothing/accessories-clothing/cap/ and the payment worked successfully:

Link to image: https://d.pr/i/udGtMd

I’m also unable to find any reports of this type of behavior caused by Stripe on the issue tracker here: https://github.com/woocommerce/woocommerce-gateway-stripe/issues so the plugin seems to be working as expected.

My first suggestion would be to have a look at the Stripe debug logs if they are enabled, as well as fatal error logs to see if you can find any clues there about why the payment was not completed. If you are able to reproduce this same behavior consistently, then it is possible that it is caused by a conflict with another piece of software on your site and I would suggest doing a conflict test. There is some documentation covering that here: https://docs.woocommerce.com/document/how-to-test-for-conflicts/

The only “trace” that would exist would be if you have debug logging enabled for Stripe and I imagine that if you do, you will find in the logs that what Stripe is telling you is accurate and this is the amount that was sent to Stripe.

Are you able to reproduce this on a testing/staging site with Stripe in test mode?

I’d like to ask you all to check the debug logs for any extra information about this. WooCommerce -> Status -> Logs and then in the dropdown selector, look for any logs where the name begins with google-listings-and-ads, followed by a date/time, followed by random letters/numbers.

What do you find there relating to this error?

Hey, thanks for posting what you did to work around this. I’ve opened an issue here: https://github.com/Automattic/woocommerce-payments/issues/2688 I expect this will be fixed in a future version of WooCommerce Payments.