Square WebPay support thread.

[todoonada]

more information is always better. i will try and take a look at this and see if i can reproduce it.

best.

Since I can not reproduce the error, I can only hope to see the error live on the "Whos online" list of active customers.
I just had another customer who was stuck at squareWebPay_handler.php for 30s.
It seems he went then back to checkout_confirmation and then was able to finish the credit card transaction. No error in the logs.

I think something is wrong on Square's or Square Japan's side.

[carlwhat]

Since I can not reproduce the error, I can only hope to see the error live on the "Whos online" list of active customers.
I just had another customer who was stuck at squareWebPay_handler.php for 30s.
It seems he went then back to checkout_confirmation and then was able to finish the credit card transaction. No error in the logs.

I think something is wrong on Square's or Square Japan's side.

i would have to run some more transactions. i am not sure why a customer would be stuck at the handler for 30s.

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.

and how many orders paid by square are you getting each week?

[todoonada]

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.

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.

and how many orders paid by square are you getting each week?

By Square around 30.

[carlwhat]

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.

[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.

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

[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!

[carlwhat]

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.

[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.