lofkwprowsm

I found the problem!! (but not so much the solution)

Customers’ browsers must be set to ALWAYS accept “third party cookies”, otherwise the connection does not go through.

Most browsers have 3 different settings regarding third party cookies – always accept, never accept, or accept from “sites you visit”. My own was set to accept from sites I visit, but it was not enough and the connection still failed when I was doing all these tests. It looks like it has to be always.

Some browsers like Chrome default to always accept, others like Safari default to never accept third party cookies. Since most users will never change the defaults, it does more or less depend on which browser people use like dbriones suggested above. But of course some users will alter the settings manually too.

I do not know how to fix this, so I cannot mark this as resolved. I do not know if even Woocommerce and/or Simplify are capable of altering cookie behavior in their code, or if that is just necessary for hosted payments to work at all since we are in fact sending customers to a third party site to complete the payment. We have not tried other payment gateways to see if they experience a similar problem.

So some percentage of our users will have this problem if we proceed with hosted payments (i.e. sending customers off our site to Simplify’s site to pay). I did a search for browser statistics relating to third party cookies, and found reports of anywhere from 10%-40% of users block third party cookies in their browser settings, either manually or from the browser’s defaults.

This is a significant enough loss of potential customers that investing in a SSL certificate and PCI compliance may be worthwhile after all, but we have not decided yet. There are many small businesses who may wish to avoid this burden, which is why we went with Simplify in the first place. Hopefully either Woocommerce or Simplify can figure something out.

But for now having credit cards go through your own site with a SSL, etc. is the only true solution I can see at least for Woocommerce + Simplify. Either that or accepting that a certain percentage of customers will encounter this error.

If the transaction is being handled on your own site, then yes, you need an SSL. But we are using the hosted payments method, where users are taken to Simplify’s site to complete the transaction. So the encryption, PCI requirements, etc. are handled by them. No credit card info passes through our own site.

The Simplify tech support says it went through for him on the order2 page (something unrelated went wrong with the shipping options on the main page). At least that proves it’s possible to make payments, as it was with a logged in user.

Unfortunately it does not help much. It means the error comes and goes, which is just that much harder to track down. Maybe it’s related to os and/or browser like the poster above mentioned.

I’m asking others to do some tests on it and report their results along with which os/browsers they used. I’ll report their findings when they finish the tests.

Also, I did the Woocommerce update today but the error remains. I didn’t see anything jump out in the changelog related to this anyway, just documenting my steps here.

I e-mailed him my guess on a fix and it worked (not for payment, that was just an expression of frustration from the user; he also said he would poke his eye with chopsticks, similarly sarcastic).

The problem was with the code that generates that url.

The url sent to the user was something like:
https://domain.com/my-account/key=blahlogin=whatever

But it SHOULD have been:
https://domain.com/my-account/lost-password/key=blahlogin=whatever

The /lost-password/ failed to get generated in the url in the reset password e-mail to the user.

See Woocommerce > settings > emails > reset password, and click “View Template” near the bottom. That’s the default code that generates the e-mail, and this is the relevant section that creates the link:

<a href="<?php echo esc_url( add_query_arg( array( 'key' => $reset_key, 'login' => rawurlencode( $user_login ) ), wc_get_endpoint_url( 'lost-password', '', wc_get_page_permalink( 'myaccount' ) ) ) ); ?>">
			<?php _e( 'Click here to reset your password', 'woocommerce' ); ?></a>

This default e-mail template is located in:
woocommerce/templates/emails/customer-reset-password.php

But you can modify the template to make it match the theme to your site. yourtheme/woocommerce/emails/customer-reset-password.php overrides the default, where yourtheme is the name of the theme your site uses. This critical code section somehow got altered or removed and was not correct in the modified version made to match the theme, so copying this correct default code back in there fixed it.

I contacted GoDaddy and here is the core part of our conversation, this is their comments:

“Well, we have seen issues with Authorize.net processing, and we have advised customers to contact them regarding the issue. non standard security, would be a reference to optional SSL Certificates. It is true that we do not force you to purchase an SSL Certificate to have a website.

This seems like the exact type of situation that their type of processing is set up for.

We do have different servers, enabling an SSL Certificate would get your site migrated to a server with all sites secured with an SSL Certificate and it would provide you with a Dedicated IP Address. This may be what they are wanting or needing you to have for their system to work with your site.

I know that the issue does not happen with all sites on our servers, and this issue does not seem to have a common variable. This is why it is still an issue for Authoize.net and the other payment gateways.”

So, I don’t know. My understanding was that Simplify would work without our site having an SSL, that would happen on their end by taking the customer to their own site. It’s also still weird that it goes through when logged in, like why wouldn’t they block that without an SSL or some other requirement from our site (I worry about losing customers who don’t want to create an account, so I’m hoping that guest checkouts can work).

My next step is seeing what Simplify says about all this. I’ll post again with their response.

I did a completely fresh install on:
https://order2.freemandallas.com

No extra plugins, no special theme, just minimal settings changes in WordPress and Woocommerce (like time zone, $, etc), one dummy product, and the payment still failed with the same timeout error.

I’m contacting GoDaddy at this point to see if they can shed any light on this problem from their end.

I have experienced this on Windows 7 in both Firefox and IE, as well as Linux in Firefox and Opera. That’s every browser/OS combo I have.

I found this page about conflicts with Woocommerce, and it specifically mentions GoDaddy:

“Some users have problems with GoDaddy and PayPal IPN/other gateways such as Authorize DPM. This is purely a hosting problem and it due to their non-standard security measures. These issues need to be worked out with GoDaddy themselves as it is out of our hands.”
https://docs.woothemes.com/document/known-conflicts/

I don’t know what security measures they are referring to, or if that’s even the problem. But process of elimination is starting to make GoDaddy look more likely as a suspect for the problem, though the payment system does work for a logged in user so maybe not…

It also mentions SEO from Yoast:
“The setting “Redirect ugly URL’s to clean permalinks” in SEO > Permalinks is known to break the checkout process since it strips the query string. Turn this option off.”

I had originally installed this plugin, just as I do on many sites. But as part of troubleshooting this problem I deactivated and even deleted it and several other plugins without success.

Nevertheless, I wonder if plugins leave data or code behind, so I plan to backup my WordPress and reinstall it from scratch tonight. I want to see if this problem exists with no extra plugins or theme changes on a clean install. I’ll update here once I see how that goes.

I got some space on my home page by adding a text widget to the header widget area. I did not type any text in there, just dragged the text widget into the header area in the widgets menu. Now the title no longer bumps the header boundary. May not work for everyone or every page but it’s easy to try.

I apologize, I needed to add more details.

I am using the product display box shortcode in a 2 column, 3 row table so all the memberships appear on one page together with the same button, text style, and picture size for each one. I was hoping to use a product display box for the free one too, so that it matches the rest.

But with the product display box I do not have any individual control over where the buy button links to. I can only designate a single external checkout page that applies to all. Is there a way I can change the target of the buy button for just one of them when using the product display boxes?

Thanks, and I am sorry again for not being clearer initially.