Square WebPay support thread.

[lat9]

Hello Carl,
https://www.proteawines.jp/shop/

While I don't currently have clients using this payment-module, a quick look at the site's HTML source shows:

<script>window.jQuery || document.write(unescape('%3Cscript src="https://code.jquery.com/jquery-3.4.0.min.js" integrity="sha256-BJeo0qm959uMBGb65z40ejJYGSgR7REI4+CW1fNKwOg=" crossorigin="anonymous"%3E%3C/script%3E'));</script>
 <script>window.jQuery || document.write(unescape('%3Cscript src="includes/templates/template_default/jscript/jquery.min.js"%3E%3C/script%3E'));</script>

 <script src="includes/templates/gernotshop/jscript/jscript_imagehover.js"></script>
 <script src="includes/templates/gernotshop/jscript/jscript_jquery-1.7.1.min.js"></script>

The loaded version of jQuery is very ancient (1.7.1) and the fall-back version (3.4.0) is different and also old. I'm just pointing this out since it feels like it might be relevant.

[gernot]

Thank you lat9, I will have a look at the jquery issue now that I am in the process of upgrading to 1.5.7d (as part of upgrading to 1.5.8 and then to 2.0.0).

I also remembered I had set the Square WEbpage module to "false" so I re-enabled it now in case you wish to have a look further.

[carlwhat]

...
since then the "Continue" button to continue to step 3 (confirmation) of the checkout page does nothing, and there is no log file generated. I see the GET in my access log with a 200 HTTP response, but there seems to be no communication to or from Square.

i have spent some time on your site, and i am not seeing the behavior that you are indicating. in fact, the behavior that i am seeing is completely expected.

i am seeing some network blocking errors but i am not seeing it affecting my ability to checkout.

that said, it is entirely possible that someone's browser extensions may be doing something.

i have created a little screencast which can be seen here.

in it, i start with no browser extensions enabled, and we see no errors in the dev tools console. and the square javascript form gets loaded. i then enable a bunch of extensions in my browser and reload the page. at this point, we now see a bunch of errors in the console; however, the square javascript form still loads without problem.

i then proceed to enter a credit card number and the other info requested by square. once complete, i hit the continue button, and i am brought to the checkout confirmation page. all expected behavior.

at this point, i look to see if the token results from square are now embedded on the form on the page. this is again done via the dev tools on my browser. and again those results are there. completely expected behavior.

i then hit confirm, and i get redirected back to the payment page along with an error message that (i think) comes back from square. or i provide it, i can not remember.

so from my standpoint, everything looks to be working correctly.

i am not experiencing the nothing happens that you suggest is happening.

now, whether your users are using other browser extensions that are further blocking the square process, i can not say. if you have an extension that you think is blocking, i can certainly load that into my browser and see if i can reproduce the behavior that you claim your users are experiencing.

not having any orders for over a month is a bit troubling and perhaps indicative of a problem. but i am not seeing it. and it is hard for me to fix something that i can not see.

best.

[gernot]

Hello Carl,
Many many thanks for your efforts. I had a look at the screencast, it is gratifying to see that you get to step 3 successfully (the page *after* the entering of the credit card details). Try as I might, I have been unable to do so. I tried a couple of things, wil try more options.
(1) Firefox (current latest 125.0.2) on linux with extensions, and also in a private window where no extensions are active as far as I can tell.
(2) Google Chrome (current latest 124.0.6367.91) on linux, with no extensions except session buddy: same behaviour.

What I get now when I press the Continue button to proceed to Step 3 after entering card details (and checking the confirmation checkbox and entering an age > 20), is a 200 success request for the squareWebPay_handler.php,

equest URL:
https://www.proteawines.jp/shop/squareWebPay_handler.php?token+result%5Bdetails%5D%5Bcard%5D%5Bbrand%5D=MASTER/snipped the rest/
Request Method:
GET
Status Code:
200 OK
Remote Address:
192.168.1.10:443
Referrer Policy:
strict-origin-when-cross-origin

but thereafter a 400 bad request for the verifications script:

Request URL:
https://connect.squareup.com/v2/analytics/verifications
Request Method:
POST
Status Code:
400 Bad Request
Remote Address:
162.159.140.47:443
Referrer Policy:
strict-origin-when-cross-origin

.
I've tried this with two different users (myself and my wife) with our respective credit cards.
I will try on a Windows platform and my Android phone also for good measure. But at the moment I am not sure where exactly the hiccup is happening.

[gernot]

Same result (no action on Continue to Step 3) on Android phone using Chrome browser, no extensions. I don't have developer tools to see whether there is also a verification errors as above, but I did try with both a MasterCard and a VISA Card.

[carlwhat]

i tested with Chrome Version 124.0.6367.60 (Official Build) (64-bit) on linux, and firefox Version 125.0.2 (64-bit) also on linux. with no problems on either.

i am not sure about this ip address in your 400 response above:

Remote Address:
162.159.140.47:443

do you have any idea where that address comes from?

it is a cloudflare address but has no geo data associated with it.

i am not seeing the verification's script on my square request; but that is completely controlled by square.

as a potential troubleshooting idea, get a free VPN, connect to a US address and see if you can get to the 3rd screen.

the issue is not with the credit card numbers, you can just use 4111111111111111 for testing as you look to be getting blocked at some point prior to that data getting sent to square.

square is only good for specific countries, and while japan looks to be on the list, that cloudflare address does not have any geo data associated with it. i am not sure if that is the problem; but the idea that you are getting blocked while in japan, and i am not while in the US suggests to be a potential geography issue. but i am merely guessing at this point.

i think the VPN test would be a good one to see to rule out the browser and extensions. as it seems we are using very similar setups.

best.

[gernot]

Hello Carl,
Thank you for the followup. I've tried with ProtonVPN, connecting to a US server, and now I get a different (I think) error.
Still a verification error as before, but the error is now clearly understandable: the response says integer expected, and on examining the content of the request for verification, I see that the JPY amount being passed to Square is non-integer: 557.7 JPY in my case.
I am not sure why the amounts are shown like this when in the shop itself they are shown in integers (508 JPY for this test order). I will play around some more and see whether this happens often, and if so, if I can use a rounding function somewhere. The thing is, all amounts are in Yen anyway, and with tax at 10% there should be no way a non-integer amount could even be generated.

[gernot]

And Boom!, success. It turns out that in the product I chose, with the applied discount, for some reason the price has decimals that were not all 0. For other products I checked (still need to do exhaustive checks) that net always shows <something>.0000 (I tried removing the 0000 decimals but they re-occur when I load the inventory page for the product again) in which case integer JPY value results as expected.
So it seems that my test product was faulty, and possibly some production products as well judging by the single customer complaint I had which set off this investigation.
I should have investigated the actual request and response, I did not notive that they were both available in full, not just the 400 HTTP response.
I'll go back to my Japan local IP and see if there are any other errors now or whether the issue is potentially solved.

[gernot]

To add: I have traced out the issue now. Whenever a discounted product price has a price where the least significant digit is not 0 (e.g., 15 rather than 10 or 20 or 30), then the 10% tax results in a fractional number (e.g. 10% of xx5 is xx.5) which while it does not show as such in the shop browser view, does get passed to Square as such, and fails verification.
I've therefore checked that all discounted product prices end in xx0, and where necessary changed the discount to manual from percentage to give a discounted price ending in a 0.
I could I suppose try to change the amount that gets sent to Square, but don't want to make changes ad hoc when this should be handled more systematically within Zen Cart, e.g., on a per product basis rather than in the end amount, etc.