ctmartin2020

Your Header Builder is WORTHLESS and messed up what was once a perfect-looking header and mobile menu for me. That’s what you’ll get when you update the theme. I can’t even fiddle with this thing to reproduce what I had working with much less effort previously. THE WORST.

I agree… this stinks stinks stinks! Updated theme and completely broke my header. ACCIDENTALLY switched to the new “Header Builder” and despite the documentation showing how I could change back to the original, I found no such option. So I’m stuck with a totally mangled header and mobile menu and had to completely rebuild my header. Now the new header loads differently now too and broke my JS that shows or hides a button in the header as well, as it was looking at whether or not there was a particular menu item that applied to authenticated or unauthenticated users. Using setTimeout for 3 seconds is the only option now to wait until the expected items load (which is HORRIBLE for page load speed)… I can’t seem to get a better solution like requestAnimationFrame working either, so I’m screwed. THE WORST.

This is a longshot possibility, but I’ve had all kinds of problems with PayPal transactions while using a VPN. If you are using a VPN, I suggest you try disabling it and see if that helps.

As it turns out, the Webtoffee plugin does NOT work with YITH giftcards. The YITH PayPal plugin DOES work.

But this is not the first time I’m seeing YITH only working with YITH, which frankly stinks.

For instance, with the premium plugin you can specify a discount on the gift card (for example, but a gift card at 20% off the face value). In this case, you must ONLY use the discount mechanism provided by the plugin (which is specifying the discount on the product admin page) — you cannot use discount coupons in connection with the sale of the gift card.

That works ok for giving the discount, but it DOES NOT reflect the original price and the discount reduction in the cart or on the invoice. For example, a $100 card purchased with a 20% off discount will only show as an $80 purchase. There is no indication that this is after a $20 discount (20% on $100). Our accounting department is tearing their hair out trying to identify if there was a discount on the order. They would typically only need to look at the invoice to see the product price, less the itemized discount. But you can’t do this with YITH.

Good plugin, but VERY inflexible and there is almost NO documentation for developers.

I am having this same problem as well. I am using “PayPal Express Checkout Payment Gateway for WooCommerce” by WebToffee. Please help!!

Yes, since putting a warning note on my checkout page telling customers to disable their VPN when making their payment, I am now seeing far fewer instances of “Pending” (failed) transactions. Just a couple, actually… and they did indeed try again with their transaction and were successful the second time around.

I think I found the issue… at least, I hope I did.

When I encountered the problem myself, I realized I was on a VPN. PayPal may be blocking transactions made while connected via a VPN or Proxy.

I’ve had customers ask “What’s wrong with your payment system? I can’t make my payment.” Now I will ask them if they are using a VPN or Proxy. I’m also adding messaging to that effect on my checkout page.

Hoping this may help others who are scratching their heads over an issue similar to mine…

Ok, I know this is a 2 month-old thread but there IS a problem. I just experienced it myself on two consecutive transactions in the PayPal Sandbox.

I get from Checkout to the PayPal page, enter my information and proceed with the order. PayPal spins and spins. Ultimately, after about at least 60-90 seconds, PayPal returns to the PayPal transaction page where I would be entering credit card details and billing address… all fields are still filled.

At this point, there is a Pending transaction in WooCommerce and the log shows exactly what I described in my original post.

I tried to proceed from this PayPal page once again and the transaction succeeded.

So this is NOT just a case of the user closing the window or cancelling the transaction. There is a problem, and the log does not indicate any problem — only that the process just stops at Step 2.

Please help. I continue to get these frequently, and most of the time, the user does NOT try their transaction a second time. I am losing sales.

This reply makes ZERO sense. The OP did not specify whether he was using the premium or free version.

So the question still stands: how to give the customer the ability to send the e-gift card TODAY?

I am having this same problem. I HATE the default styling of the form for Delivery Info on the Product page. I am not using Elementor. However, there seems to be no way for me to style the form. My CSS (I’ve tried writing my new css into the theme’s style.css and elsewhere — nothing works); my CSS is also directly targeting the DOM IDs of the input fields and using !important but the old style persists and it’s very unfriendly… fields are WAY too long (length: 70%;) and should be taller (at least height: 25px;) as they are far too small for mobile users. Very frustrating and a good reason not to even mess with this plugin — too inflexible. Maybe the styles are in-lined?

I really wish people who find a solution would share it with the rest of us. That’s also very frustrating. Is this some sort of “trade secret”, LOL!?

What was the issue here?? Was it resolved? I’m researching whether or not I want to even install this plugin, especially considering its past vulnerabilities. The last thing I need is something to slow down MY WooCommerce site even more…

Unless you have something strange in your HTACCESS file that is restricting access to something it shouldn’t, one thing your web host may need to check for you is the possibility that ModSecurity is blocking your transaction.

I had a similar problem, except mine was a 406 error and occurred on the “?c=finish_express” end of the transaction process. But yours is still something I would look into ModSecurity regarding, and thus the the need to whitelist requests from the server that “look like” this one.

You may want to go into your logs and note the time of the failed transaction, and look into the SSL logs on the server to see at that moment exactly what the request was. You’ll see the error in the log next to the request. Your web host support team should be able to take that request and observe how it may trigger a rule in ModSecurity that may need to be overridden.

Of course, one way to quickly check whether ModSecurity is the culprit is to temporarily disable it. If you have access to cPanel you may at least be able to toggle ModSecurity on or off… I’m pretty sure you won’t have the ability to write/rewrite any of the rules, whitelist, etc., but either you or your web host support team can disable it for your domain… then check if that doesn’t allow the transaction to proceed.

I guess it’s the very definition of an abandoned cart. Get all the way to the payment and then back out…

This is still happening! It is now several months later… using the latest version.

Can you please fix this??