Square WebPay support thread.

[spyderrobotics]

Thanks for the support!

[VDecalS]

Thanks for looking into it. I am not sure where to go from here. Maybe I can change the error message to just tell the customer to check that the fields are not blank. If you wanted to check it out my site is spyderrobotics.com

I have paypal turned off at the moment so it can recreate the error. You can make a fake account and try the checkout.

I get the same error with PayPal turned off:

"We have a problem on our end. So Sorry! Please report this error to the Store Owner: SQ-MISSING-TOKEN"

If PayPal is turned ON and credit card is checked, but not entered, I get a friendly reminder to enter credit card number before proceeding to page 3 of checkout.

Friendly reminder is much nicer than error on store end.

[16-Feb-2023 14:23:08 America/Chicago] PHP Notice: missing token result: check if card button is disabled on dev console using: document.getElementById('card-button'); else look for javascript error in console. in /includes/modules/payment/square_webPay.php on line 234

[carlwhat]

ok, a few changes coming.

for those of you who use square as the only payment method, and want to prevent the funny message, the cool kids way is here:

this file here:
includes/modules/pages/checkout_payment/jscript_square_webPay.php

//line 39 was:
if (document.querySelector('#pmt-square_webPay').checked)  {

//change it to:
if ((document.querySelector('#pmt-square_webPay').checked) || (document.querySelector('#pmt-square_webPay').getAttribute('type') == 'hidden')) {

also, with that change, i do not think we will ever get here, but in:

includes/modules/payment/square_webPay.php

line 266, should be changed to something like:

$messageStack->add_session('checkout_payment', 'uh...  looks like you did not input a credit card number!', 'error'); 

these changes will be incorporated into a new release.

thank you to those who support me.

[VDecalS]

ok, a few changes coming.

for those of you who use square as the only payment method, and want to prevent the funny message, the cool kids way is here:

this file here:
includes/modules/pages/checkout_payment/jscript_square_webPay.php

//line 39 was:
if (document.querySelector('#pmt-square_webPay').checked)  {

//change it to:
if ((document.querySelector('#pmt-square_webPay').checked) || (document.querySelector('#pmt-square_webPay').getAttribute('type') == 'hidden')) {

also, with that change, i do not think we will ever get here, but in:

includes/modules/payment/square_webPay.php

line 266, should be changed to something like:

$messageStack->add_session('checkout_payment', 'uh...  looks like you did not input a credit card number!', 'error'); 

these changes will be incorporated into a new release.

thank you to those who support me.

Thanks carlwhat.

square_webPay-master from 7/26/2022. My code line was actually line 179 instead of 39, and there's an extra space before { on the example (which made finding it weird), but it works now!

I didn't change the messageStack, because I couldn't determine which line needed changing, but agree we probably won't get there.

[carlwhat]

Thanks carlwhat.

square_webPay-master from 7/26/2022. My code line was actually line 179 instead of 39, and there's an extra space before { on the example (which made finding it weird), but it works now!

I didn't change the messageStack, because I couldn't determine which line needed changing, but agree we probably won't get there.

my apologies. it was late, and i was looking at the wrong file for the line number.

it is ~around line 180, and according to my code, line 185 on v1.0.3.

thanks for confirming the fix.

best.

[todoonada]

i would setup the cron job. and then keep on monitoring.

i think the holdup on the handler is due to a renew of the OAuth. if the cronjob automatically renews it, then the customer will not be waiting on it.

i am not sure that is your answer. but it is DEFINITELY worth a shot.

best.

The cronjob was no success. I just had someone get stuck several times at squareWebPay_handler.php again. The squareWebPay_handler.php displayed "not expired" because I had verbose set to true. The order finally came through, but of course I do not know why.

[carlwhat]

The cronjob was no success. I just had someone get stuck several times at squareWebPay_handler.php again. The squareWebPay_handler.php displayed "not expired" because I had verbose set to true. The order finally came through, but of course I do not know why.

of course, i do not know why either.

that said, here is my new working theory... this has nothing to do with square.... or at least nothing to do with the handler...

the handler comes back with "not expired". in looking at that part of the code, if that is the return, getting to that return should not take any time at all. or at least nothing associated with the kind of delays that you seeing. "not expired" means we looked at the OAuth, and it is fine, and lets go back to our normal scheduled programming. now whether square itself is having an issue in communicating within japan, i can not say.

what your user is waiting for is up for anyone's guess. the fact that you are looking at who's online, and a user is stuck at the handler, is not definitive evidence that the handler is what is causing the problem. the only thing that tells me is that who's online is reporting that the last place i have seen this customer is at the handler. i have not dug deep into that code, but again, i do not have completer confidence that is where the last point is.

have you tried contacting the user after this experience to see what their experience is?

given that this situation is only happening for you, i find it hard to imagine that it is my code that is causing this problem. no one else is having these issues. might you have some sort of order conversion tracking on your website? something else may entirely be holding this order up... or not...

i appreciate you reporting this issue, but i am now not sure what your expectation is from me or from anyone on the zen-cart boards.

[todoonada]

of course, i do not know why either.

that said, here is my new working theory... this has nothing to do with square.... or at least nothing to do with the handler...

the handler comes back with "not expired". in looking at that part of the code, if that is the return, getting to that return should not take any time at all. or at least nothing associated with the kind of delays that you seeing. "not expired" means we looked at the OAuth, and it is fine, and lets go back to our normal scheduled programming. now whether square itself is having an issue in communicating within japan, i can not say.

what your user is waiting for is up for anyone's guess. the fact that you are looking at who's online, and a user is stuck at the handler, is not definitive evidence that the handler is what is causing the problem. the only thing that tells me is that who's online is reporting that the last place i have seen this customer is at the handler. i have not dug deep into that code, but again, i do not have completer confidence that is where the last point is.

have you tried contacting the user after this experience to see what their experience is?

given that this situation is only happening for you, i find it hard to imagine that it is my code that is causing this problem. no one else is having these issues. might you have some sort of order conversion tracking on your website? something else may entirely be holding this order up... or not...

i appreciate you reporting this issue, but i am now not sure what your expectation is from me or from anyone on the zen-cart boards.

I do not contact the customer, because it makes no good impression to let them know they are followed in their activities in the shop (I know big players are doing much creepier stuff, but you get the point). Also I would have to explain why I can not find the error myself and it just seems too much hassle to bother the customer with.
I thought about a slow Square server, too. However I had customers who tried to checkout hours later and still had the same error. So a slow server seems not to be the reason.
I don't think the error is connected to your code. Since you are very familiar how Square functions, my initial thought was, that you might have an idea what the problem might be.

[rjhancock]

While setting this up for a client, ran into a few bugs that I did manage to fix. 2 seem to be related to an error condition that shouldn't happen (but somehow managed to make it happen) and the third is related to said situation. All are in the same file `includes/modules/payment/square_webPay.php`

in `admin_notification` around line 530 change to :

$transaction = is_array($records) ? $records[0] : $records;

in `lookupOrderDetails` there are two instances of calling `return new Models\Order;` that will fail as it expects a Location ID. One around line 897 and the other around 915. Both should be changed to the following:

$location = $this->getLocationDetails();
return new Models\Order($location->getId());

[brittainmark]

zen cart 1.5.8
square web pay 1.0.4
bootstrap 3.5.2

I have an issue where the terms and conditions do not need to be ticked for an order to go through. I think it is connected to JavaScript and using preventDefault method. I believe that this means that required fields are not checked when the form is submitted. I have resolved the issue by adding the following to includes/modules/pages/checkout_payment/jscript_square_webPay.php

original starting line 157

                    var verifyBuyerResult = document.createElement("input");
                    verifyBuyerResult.setAttribute("type", "hidden");
                    verifyBuyerResult.setAttribute("name", "verifyBuyerResult");
                    verifyBuyerResult.setAttribute("value", JSON.stringify(verificationToken));
                    document.querySelector('[name="checkout_payment"]').appendChild(verifyBuyerResult);
                    cardButton.disabled = false;                 
                    document.forms["checkout_payment"].submit();

new

                    var verifyBuyerResult = document.createElement("input");
                    verifyBuyerResult.setAttribute("type", "hidden");
                    verifyBuyerResult.setAttribute("name", "verifyBuyerResult");
                    verifyBuyerResult.setAttribute("value", JSON.stringify(verificationToken));
                    document.querySelector('[name="checkout_payment"]').appendChild(verifyBuyerResult);
                    cardButton.disabled = false;                 
                    let isFormValid = document.forms["checkout_payment"].checkValidity();
                    if (isFormValid) {
                        document.forms["checkout_payment"].submit();
                    } else {
                        document.forms["checkout_payment"].reportValidity();
                    }

Something similar may be required for one page checkout!