Square WebPay support thread.

[dbltoe]

Now, those notes make reference to Version 1.0.1 of Square Web Payments requires API Version 2022-02-16, so my first question is, "Is this still true for version 1.0.4 of the SquareWebPay module? Or should I just leave it on the latest which it defaults to? (which is 16 versions ahead so this seems unlikely).

Square is constantly updating the API and, one of the newer could affect the way WebPay works. Stick with the suggested API until told different. Subscribe to this thread to make sure you receive any updates.

the edits were:
define('DIR_WS_CATALOG', '/JPV3/');
define('DIR_WS_HTTPS_CATALOG', '/JPV3');

It appears you have a missing / in the HTTPS setting. It should be

the edits were:
define('DIR_WS_CATALOG', '/JPV3/');
define('DIR_WS_HTTPS_CATALOG', '/JPV3/');

Also, this is where it would help to see the entire config file (with sensitive info eliminated) but, do so in a different thread as it's off topic for WebPay.

Open the new thread, answer all the posting tips and let us know how the internet is "told" to go to your subfoder.

[georgemurcott]

Hi thanks dbltoe for the help. I have left the API version on the one instructed. I retried with the update to the config files but it still goes wrong. In the help files it mentions properly defining in the config file the "DIR_WS_HTTPS_CATALOGUE constant", now we haven't, so
I made the change in both files (configure.php in both admin and store) - but only those two lines and it broke the site! the edits were:
define('DIR_WS_CATALOG', '/JPV3/');
define('DIR_WS_HTTPS_CATALOG', '/JPV3/');
(the store is in a folder called JPV3) - i have now changed it back and its working fine. Now i believe these are added to the https info and so maybe i just needed to reissue/renew the SSL cert? It broke the storefront not the admin side. The storefront wound up looking like this:

Any further help would be greatly appreciated. I know you mentioned starting this again in a new new thread but this does still relate to webpay as that won't show up in Admin and everything was/is fine in other respects and its the webpay specific instructions saying to do this. Thanks, George

[dbltoe]

Sorry, it doesn't relate in that WebPay would work if your settings were correct. It may take a few back and forths to get all corect and that shouldn't be done here.

Please open another thread and provide copies of your two config files with admin folder, database user/password/name blanked out using the # abovve.

[swguy]

Note also that the constant "DIR_WS_HTTPS_CATALOGUE" doesn't exist - it's "DIR_WS_HTTPS_CATALOG"

[johnjlarge]

Having a weird one.

Have been using the squrewebpay add on since Calrwhat first released it. I recently upgraded to 1.0.4 and have been seeing a few of these in my logs folder debugs

"should not get here. check that you have the latest jscript_square_webpay file and that you are not having javascript errors in the console."

The thing is, many payments with square are going through just fine, yet the odd customer says the payment form won't load to enter their card details. I can have 10 or 20 square payments in a row without issue, and then this will happen to a random customer. Is this something to do with the setup of the customers browsers/ad blockers/cookies, or is it something on my site which I can fix?

Zen Cart 1.5.6c running on php 7.3.33

Any help much appreciated.

[carlwhat]

Having a weird one.

Have been using the squrewebpay add on since Calrwhat first released it. I recently upgraded to 1.0.4 and have been seeing a few of these in my logs folder debugs

"should not get here. check that you have the latest jscript_square_webpay file and that you are not having javascript errors in the console."

The thing is, many payments with square are going through just fine, yet the odd customer says the payment form won't load to enter their card details. I can have 10 or 20 square payments in a row without issue, and then this will happen to a random customer. Is this something to do with the setup of the customers browsers/ad blockers/cookies, or is it something on my site which I can fix?

Zen Cart 1.5.6c running on php 7.3.33

Any help much appreciated.

some other javascript code is hick-jacking your submit your submit form button.

are you using OPC?

[johnjlarge]

some other javascript code is hick-jacking your submit your submit form button.

are you using OPC?

No, just using the standard zen cart payflow of checkout_shipping, checkout_payment and checkout_confirmation. It works for most customers, but for some this error throws. I can put through as many test payments & live payments using all sorts of different browsers & I can't replicate it. With some customers, no matter how many times they try, the payment form just won't load.

[johnjlarge]

Just thinking out loud, is it possible an ad blocker or privacy extension is blocking the javascript from loading via https://web.squarecdn.com/v1/square.js and then the subsequent https://web.squarecdn.com/v1/square.js which is loaded via the square.js file? If that was the case, would the error be the same? The only reason I ask is that I’ve had it from two school teachers of late, both of whom couldn't load the payment form. If an extension or IT network policy blocked the loading of those third party .js files, would the error/outcome be the same?

If that's the case, perhaps serving those JS files locally would be better, or showing an error on screen if those resources are blocked. Asking general users/customers what browser extensions, versions & network policies they are running is pretty futile as they generally don't know. But I am seeing this more & more, which may suggest it's in a blocklist or privacy extension of some sort as a false positive.

[carlwhat]

Just thinking out loud, is it possible an ad blocker or privacy extension is blocking the javascript from loading via https://web.squarecdn.com/v1/square.js and then the subsequent https://web.squarecdn.com/v1/square.js which is loaded via the square.js file? If that was the case, would the error be the same? The only reason I ask is that I’ve had it from two school teachers of late, both of whom couldn't load the payment form. If an extension or IT network policy blocked the loading of those third party .js files, would the error/outcome be the same?

If that's the case, perhaps serving those JS files locally would be better, or showing an error on screen if those resources are blocked. Asking general users/customers what browser extensions, versions & network policies they are running is pretty futile as they generally don't know. But I am seeing this more & more, which may suggest it's in a blocklist or privacy extension of some sort as a false positive.

if that file was blocked, you would never see the entry of the credit card fields. if you are seeing the credit card number entry form, then the square js has loaded correctly.

what is your website address?

[johnjlarge]

Website is www.koolbadges.co.uk

One of the teachers who emailed me said just that

"Hello, we are trying to place an order online but there seems to be a problem with the website as when we click on the option to pay by debit or credit card, it doesn't do anything. Can you please contact us about this?"

And another just this morning said
"I am trying to purchase these five badges but your website won’t allow me to enter my credit card??"

However, the payment form did load for others who have checked out perfectly fine via square .