Square WebPay support thread.

[Valencia]

Hi,
Is there a fix for this.
I have just upgraded my cart.

157d
bootstrap template
OPC
Square Webpay
SitemapXML
PHP 7.4

Everything is working fine, regular orders 50% Square Webpay versus Paypal and no error logs until yesterday, when a purchasing customer emailed me to say they get the following message.
So Sorry! Please report this error to the Store Owner: SQ-MISSING-TOKEN.
I told them to try again, but again the message above came up and again they where unable to complete their transaction.
The error logs show the following.
[26-Jun-2022 15:40:02 UTC] 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 /home/sweetmomentsuk1/public_html/includes/modules/payment/square_webPay.php on line 234.
I don't seem to be getting any conflicts when viewing the browser console while running test transactions.
It's the first time i have had this since I upgraded on the 11th June (many successful WepPay transactions).
It just seems completely random looking at previous posts.
The latest OPC accomadates Square WebPay to work smoothly when the confirm order button is selected.

Should I try upgrading my API version from 2022-02-16 (Webpay was developed using this) to the latest.

www.sweetmomentsuk.co.uk

[carlwhat]

Hi,
Is there a fix for this.
I have just upgraded my cart.

157d
bootstrap template
OPC
Square Webpay
SitemapXML
PHP 7.4

Everything is working fine, regular orders 50% Square Webpay versus Paypal and no error logs until yesterday, when a purchasing customer emailed me to say they get the following message.
So Sorry! Please report this error to the Store Owner: SQ-MISSING-TOKEN.
I told them to try again, but again the message above came up and again they where unable to complete their transaction.
The error logs show the following.
[26-Jun-2022 15:40:02 UTC] 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 /home/sweetmomentsuk1/public_html/includes/modules/payment/square_webPay.php on line 234.
I don't seem to be getting any conflicts when viewing the browser console while running test transactions.
It's the first time i have had this since I upgraded on the 11th June (many successful WepPay transactions).
It just seems completely random looking at previous posts.
The latest OPC accomadates Square WebPay to work smoothly when the confirm order button is selected.

Should I try upgrading my API version from 2022-02-16 (Webpay was developed using this) to the latest.

www.sweetmomentsuk.co.uk

i think you need to manually run the handler to renew your token. which i did. when i tried to buy something, i am definitely getting a response back from square, which you can see here:

https://www.dropbox.com/s/olpefpckug...ments.png?dl=0

one can manually renew the OAuth by going here:

https://www.sweetmomentsuk.co.uk/squ...ay_handler.php

best.

[dbltoe]

Still can find no rhyme or reason for the 239 error (in the current GitHub version)

Since the 20th of June, the site has had 273 successful payments with WebPay.

Still, during the same period,

[27-Jun-2022 21:03:42 UTC] 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 239

reared its ugly head only 15 times and I have not been able to catch anything in the consol.

[Valencia]

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

I have been trying to find why sometimes a customer gets the error above when trying to make a payment with Webpay. This is what I have found.

I have Square and Paypal as the payment options for my site. When a customer logs into their store account and goes to the OPC screen they have the two payment options with the corresponding radio buttons (neither is selected at this time).

The normal procedure would be to select the payment method (Square Webpay) by selecting the radio button then entering the card details, then Confirm Order. This seems to produce a positive checkout without errors.

However if the customer was to get to the OPC page and enter their card details directly into the Square payment fields, the radio button then becomes highlighted after a couple of digits are entered and the card type is recognized. But when the confirm order button is selected to checkout, the SQ-MISSING-TOKEN error shows up.

It's the same situation if a customer selects Paypal first then stupidly starts entering their card data into the Square fields, Square then becomes highlighted but invariably shows SQ-MISSING-TOKEN error.

So it looks to me if you positively select the radio button for the Square Payments first, then enter card details a checkout without SQ-MISSING-TOKEN error will occur. and you don't get the following error log.

[04-Jul-2022 21:43:05 UTC] 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 /home/sweetmomentsuk1/public_html/includes/modules/payment/square_webPay.php on line 234.

If this is the case and because we have to think like a customer (not always perfect in the nicest possible way), it might help if the moment the Webpay card fields are selected, the payment option is actually selected at that point along with the radio button.

To me (and I am just a store owner who muddles through) it's a little strange. I am sure the previous standard Square module used to select square the moment you touched the input fields.

Sorry to waffle. Just some thoughts, please take a look if you wish. I have lost a couple of customers recently because of this.

https://www.sweetmomentsuk.co.uk

[carlwhat]

...
However if the customer was to get to the OPC page and enter their card details directly into the Square payment fields, the radio button then becomes highlighted after a couple of digits are entered and the card type is recognized. But when the confirm order button is selected to checkout, the SQ-MISSING-TOKEN error shows up.

It's the same situation if a customer selects Paypal first then stupidly starts entering their card data into the Square fields, Square then becomes highlighted but invariably shows SQ-MISSING-TOKEN error.

So it looks to me if you positively select the radio button for the Square Payments first, then enter card details a checkout without SQ-MISSING-TOKEN error will occur. and you don't get the following error log.

hi vic,
i wish these situations were the case. i am not able to reproduce it on your site. i am only able to fix what i can reproduce.

allow me to explain a little bit about this process: it is a 2-step process; the first step sends the credit card data to square, it returns a token. square_webPay takes this token, adds it onto the html form on the OPC page, and then submits the whole form to your zen-cart installation. at that point, ZC has control, and then ZC submits that token to square.

if for whatever reason that token does NOT make it onto the html form, you see the error that you are getting.

with regards to the 2 situations you mention above, i have a couple of videos. a GENERIC DECLINE is coming back from square. the SQ-MISSING-TOKEN error is an error from square_webPay as we are not submitting anything to square as we do not have the result from the first step of the process:

https://www.dropbox.com/s/i3zc3t5diu...20PM.webm?dl=0
https://www.dropbox.com/s/6mc9y5gvf3...20PM.webm?dl=0

...
If this is the case and because we have to think like a customer (not always perfect in the nicest possible way), it might help if the moment the Webpay card fields are selected, the payment option is actually selected at that point along with the radio button.

To me (and I am just a store owner who muddles through) it's a little strange. I am sure the previous standard Square module used to select square the moment you touched the input fields.

you are correct here. the previous module selected the radio button the moment you touched the input fields. the webPay module selects the radio button after the first input, and NOT when a field gets focused.

unfortunately that is impossible to change due to the architecture of the new square infrastructure. it was something that i remember looking at rather closely. but again this is not the problem as one can see from my videos.

that said, i DO appreciate the troubleshooting with the specific keystrokes that you think are causing the problem. if we are able to reproduce it, we can then fix it.

best.

[Valencia]

hi vic,
i wish these situations were the case. i am not able to reproduce it on your site. i am only able to fix what i can reproduce.

allow me to explain a little bit about this process: it is a 2-step process; the first step sends the credit card data to square, it returns a token. square_webPay takes this token, adds it onto the html form on the OPC page, and then submits the whole form to your zen-cart installation. at that point, ZC has control, and then ZC submits that token to square.

if for whatever reason that token does NOT make it onto the html form, you see the error that you are getting.

with regards to the 2 situations you mention above, i have a couple of videos. a GENERIC DECLINE is coming back from square. the SQ-MISSING-TOKEN error is an error from square_webPay as we are not submitting anything to square as we do not have the result from the first step of the process:

https://www.dropbox.com/s/i3zc3t5diu...20PM.webm?dl=0
https://www.dropbox.com/s/6mc9y5gvf3...20PM.webm?dl=0




you are correct here. the previous module selected the radio button the moment you touched the input fields. the webPay module selects the radio button after the first input, and NOT when a field gets focused.

unfortunately that is impossible to change due to the architecture of the new square infrastructure. it was something that i remember looking at rather closely. but again this is not the problem as one can see from my videos.

that said, i DO appreciate the troubleshooting with the specific keystrokes that you think are causing the problem. if we are able to reproduce it, we can then fix it.

best.

Hi Carl,

Thanks for the video showing the two scenarios, testing out my concerns.

I went through the exact same two scenarios as yourself earlier today, without touching the Square radio button first, and I get SQ-MISSING-TOKEN each time. (I even used the same card data).

If I then immediately entered the card details again without touching anything else, (the Square radio button is already highlighted at this stage)
when I selected Confirm Order I would get the please wait symbol then GENERIC DECLINE, so potentially all good!

The only way I could make sure the system produced a potential successful procedure and show GENERIC DECLINE was to make sure I had selected the Square radio button before entering the card details, and then this was successful repeatedly.

I then decided to try different browsers (Edge and Chrome) as I mainly use Firefox, but the same results persisted.

I am slightly perplexed now and thinking the only thing different between your testing and mine is the location.

Somehow I will have to force (tell my customers nicely) to make sure they select the Square Payments radio button before entering their card details ( There will be customers that read instructions and customers that don't, and they are the ones that will get an SQ-MISSING-TOKEN).

The ideal situation would be that the radio button gets selected in unison with selecting the data entry fields but I understand you have already mentioned the complexities of trying to do this.

This rather testing problem aside, Webpay is awesome.

Vic

[Nick1973]

Hi Carl,

Thanks for the video showing the two scenarios, testing out my concerns.

I went through the exact same two scenarios as yourself earlier today, without touching the Square radio button first, and I get SQ-MISSING-TOKEN each time. (I even used the same card data).

If I then immediately entered the card details again without touching anything else, (the Square radio button is already highlighted at this stage)
when I selected Confirm Order I would get the please wait symbol then GENERIC DECLINE, so potentially all good!

The only way I could make sure the system produced a potential successful procedure and show GENERIC DECLINE was to make sure I had selected the Square radio button before entering the card details, and then this was successful repeatedly.

I then decided to try different browsers (Edge and Chrome) as I mainly use Firefox, but the same results persisted.

I am slightly perplexed now and thinking the only thing different between your testing and mine is the location.

Somehow I will have to force (tell my customers nicely) to make sure they select the Square Payments radio button before entering their card details ( There will be customers that read instructions and customers that don't, and they are the ones that will get an SQ-MISSING-TOKEN).

The ideal situation would be that the radio button gets selected in unison with selecting the data entry fields but I understand you have already mentioned the complexities of trying to do this.

This rather testing problem aside, Webpay is awesome.

Vic

Agreed Vic, if I do the same on the standard checkout (enter card details without checking the radio button) it takes the payment. On OPC it doesn't. This is a problem, as like you say, some will click it, some won't. Some will read instructions, some won't. It is a real shame I am having to revert to the standard checkout as a solution until this issue is fixed.

[Nick1973]

Hi Carl,

Thanks for the video showing the two scenarios, testing out my concerns.

I went through the exact same two scenarios as yourself earlier today, without touching the Square radio button first, and I get SQ-MISSING-TOKEN each time. (I even used the same card data).

If I then immediately entered the card details again without touching anything else, (the Square radio button is already highlighted at this stage)
when I selected Confirm Order I would get the please wait symbol then GENERIC DECLINE, so potentially all good!

The only way I could make sure the system produced a potential successful procedure and show GENERIC DECLINE was to make sure I had selected the Square radio button before entering the card details, and then this was successful repeatedly.

I then decided to try different browsers (Edge and Chrome) as I mainly use Firefox, but the same results persisted.

I am slightly perplexed now and thinking the only thing different between your testing and mine is the location.

Somehow I will have to force (tell my customers nicely) to make sure they select the Square Payments radio button before entering their card details ( There will be customers that read instructions and customers that don't, and they are the ones that will get an SQ-MISSING-TOKEN).

The ideal situation would be that the radio button gets selected in unison with selecting the data entry fields but I understand you have already mentioned the complexities of trying to do this.

This rather testing problem aside, Webpay is awesome.

Vic

The minute I turned OPC OFF, an order came through. It kind of confirms it. Since installing both of these modules around mid June, I have had hardly any orders :-(

[Valencia]

hi vic,
i wish these situations were the case. i am not able to reproduce it on your site. i am only able to fix what i can reproduce.

allow me to explain a little bit about this process: it is a 2-step process; the first step sends the credit card data to square, it returns a token. square_webPay takes this token, adds it onto the html form on the OPC page, and then submits the whole form to your zen-cart installation. at that point, ZC has control, and then ZC submits that token to square.

if for whatever reason that token does NOT make it onto the html form, you see the error that you are getting.

with regards to the 2 situations you mention above, i have a couple of videos. a GENERIC DECLINE is coming back from square. the SQ-MISSING-TOKEN error is an error from square_webPay as we are not submitting anything to square as we do not have the result from the first step of the process:

https://www.dropbox.com/s/i3zc3t5diu...20PM.webm?dl=0
https://www.dropbox.com/s/6mc9y5gvf3...20PM.webm?dl=0




you are correct here. the previous module selected the radio button the moment you touched the input fields. the webPay module selects the radio button after the first input, and NOT when a field gets focused.

unfortunately that is impossible to change due to the architecture of the new square infrastructure. it was something that i remember looking at rather closely. but again this is not the problem as one can see from my videos.

that said, i DO appreciate the troubleshooting with the specific keystrokes that you think are causing the problem. if we are able to reproduce it, we can then fix it.

best.

Hi Carl,

I have posted three videos of the following scenarios that I hope might help. They are from the same live site you tested on and unchanged in any way.

No Radio button selected, card data entered directly. returns SQ_Missing_Token
https://drive.google.com/file/d/16Bi...ew?usp=sharing


Radio Button Selected by user then card data entered returns Generic_Decline
https://drive.google.com/file/d/1mrO...ew?usp=sharing


After getting SQ_Missing_Token card data entered immediately again giving Generic_Decline
https://drive.google.com/file/d/1RpE...ew?usp=sharing

I hope it can be of help to visually see the results.

Also when I turn off OPC and have the standard checkout process, entering the card details directly into the card fields without selecting the radio button, gives the positive result the Generic_Decline.

Hope the results are useful.

Kind regards

Vic

[Nick1973]

Hi Carl,

I have posted three videos of the following scenarios that I hope might help. They are from the same live site you tested on and unchanged in any way.

No Radio button selected, card data entered directly. returns SQ_Missing_Token
https://drive.google.com/file/d/16Bi...ew?usp=sharing


Radio Button Selected by user then card data entered returns Generic_Decline
https://drive.google.com/file/d/1mrO...ew?usp=sharing


After getting SQ_Missing_Token card data entered immediately again giving Generic_Decline
https://drive.google.com/file/d/1RpE...ew?usp=sharing

I hope it can be of help to visually see the results.

Also when I turn off OPC and have the standard checkout process, entering the card details directly into the card fields without selecting the radio button, gives the positive result the Generic_Decline.

Hope the results are useful.

Kind regards

Vic

This is what I am getting with OPC:

No Radio button selected, card data entered directly. returns SQ_Missing_Token
https://drive.google.com/file/d/16Bi...ew?usp=sharing

If the radio button is checked before entering the card details, the payment works. If it isn't checked, it doesn't work. Your video highlights the this scenario.

If you do the the same process on the standard checkout, it works perfectly as it should.