Square WebPay support thread.

carlwhat:

i would have to run some more transactions. i am not sure why a customer would be stuck at the handler for 30s.
Another one was stuck for 15 mins until he disappeared from the Whos online-list.

carlwhat:

remind me of your setup with regards to OAuth renewal? specifically do you have an automated job set up like in the docs?

if you do not have a cronjob set up, i would set that up. if you do already have it set up, set $verbose to true, to see the results of it.

I do not have a cronjob setup. My understanding is that a cronjob is only necessary if very few payments (meaning several days of inactivity) are made by Square. The error also happened when another person ordered successfully one hour before.

carlwhat:

and how many orders paid by square are you getting each week?
By Square around 30.

todoonada:

Another one was stuck for 15 mins until he disappeared from the Whos online-list.

I do not have a cronjob setup. My understanding is that a cronjob is only necessary if very few payments (meaning several days of inactivity) are made by Square. The error also happened when another person ordered successfully one hour before.

By Square around 30.

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.

carlwhat:

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.

OK, I set it up. Let's see what happens.
Thank you for your advice.

Maybe this is a known issue but I didn't find it when I searched. I'm running 1.5.7c and if I make a test order and get to the payment page and do not put anything in the credit card/exp/zip and just click continue on the cart I get:

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

I am just trying to recreate what a customer will eventually do and then email me. LoL. Seems like it should have a different error for blank fields or do a check somewhere.

Has anyone modified the code to address this?

Thanks!

spyderrobotics:

Maybe this is a known issue but I didn't find it when I searched. I'm running 1.5.7c and if I make a test order and get to the payment page and do not put anything in the credit card/exp/zip and just click continue on the cart I get:

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

I am just trying to recreate what a customer will eventually do and then email me. LoL. Seems like it should have a different error for blank fields or do a check somewhere.

Has anyone modified the code to address this?

Thanks!

are you using one page checkout? if so, what version.

do you have this key in your version of OPC:

Key: CHECKOUT_ONE_PAYMENT_METHODS_THAT_SUBMIT

and if so, what is it set to.

if you do not have that key, you need to upgrade your version of OPC.

Thanks for the response. I am not using OPC.

More info:

Just found this. So if I have the paypal module enabled it works and flags it. However, if the square webpay module is the only payment module then it has the error.

spyderrobotics:

More info:

Just found this. So if I have the paypal module enabled it works and flags it. However, if the square webpay module is the only payment module then it has the error.

i am not able to reproduce this on my test system.

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.

spyderrobotics:

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.

if a customer tries to hit continue without entering any credit card data, one certainly gets that error message.

that is reproducible on my test system.

perhaps, it may be of value to change that error message. i will give it some thought...

best.

Thanks for the support!

spyderrobotics:

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

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.

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:
> 
> ```php
$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.
:smile:

VDecalS:

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.
:smile:

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.

carlwhat:

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.

todoonada:

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.

carlwhat:

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.

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());

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;                 
[B]                    let isFormValid = document.forms["checkout_payment"].checkValidity();
                    if (isFormValid) {[/B]
                        document.forms["checkout_payment"].submit();
[B]                    } else {
                        document.forms["checkout_payment"].reportValidity();
                    }[/B]

Something similar may be required for one page checkout!