Square WebPay support thread.

Make sure the module settings have "Purchase" selected under Transaction Type.

Thank you, I wish many things in life to be so simple to fix :-)

I have to come back to the error I already posted at #356 in this thread.

I find this error more often now in the log files. It is an error in the source files of Square. I can not recreate this error and don't understand what could cause this error.

--> PHP Fatal error: Uncaught TypeError: Square\ApiHelper::serialize(): Return value must be of type string, bool returned in /includes/modules/payment/square_webPay/square/square/src/ApiHelper.php:113

I did not receive any Square Alert mail about this error.
I use Zen Cart v1.5.7d and php 8.0.25

Has anybody any idea what could cause this error?

todoonada:

I have to come back to the error I already posted at #356 in this thread.

I find this error more often now in the log files. It is an error in the source files of Square. I can not recreate this error and don't understand what could cause this error.

--> PHP Fatal error: Uncaught TypeError: Square\ApiHelper::serialize(): Return value must be of type string, bool returned in /includes/modules/payment/square_webPay/square/square/src/ApiHelper.php:113

I did not receive any Square Alert mail about this error.
I use Zen Cart v1.5.7d and php 8.0.25

Some additional information about this problem.
I have my product names in this style: Japanese Name of Product <br /> English Name of the Product
So it looks like this: **プラスティックボトル 1000ml<br />Plastic Bottle 1000ml ** in the input field of the product manager.

Yesterday I saw a customer who had this problem in the "Whos Online" list of the backend. Since the error happened in the serialize function, I somehow had a feeling it has something to do with the product name or the html tag in the product name.
So I made notes of the items the customer had in the cart and changed the product names of those items to Japanese Name of Product (I removed <br /> English Name of the Product ).
The customer tried a while later to check out again and it worked. Of course I do not know if the customer changed something on his side. Japanese has some different input methods and it might be a certain input method caused the error.

Also it does not explain why most customers can check out without any problem and with the full product name (Japanese Name of Product <br /> English Name of the Product) .

I also asked in the Square developer forum, but they thought it is a problem of the Zen Cart API.

todoonada:

Some additional information about this problem.
I have my product names in this style: Japanese Name of Product <br /> English Name of the Product
So it looks like this: **プラスティックボトル 1000ml<br />Plastic Bottle 1000ml ** in the input field of the product manager.

Yesterday I saw a customer who had this problem in the "Whos Online" list of the backend. Since the error happened in the serialize function, I somehow had a feeling it has something to do with the product name or the html tag in the product name.
So I made notes of the items the customer had in the cart and changed the product names of those items to Japanese Name of Product (I removed <br /> English Name of the Product ).
The customer tried a while later to check out again and it worked. Of course I do not know if the customer changed something on his side. Japanese has some different input methods and it might be a certain input method caused the error.

Also it does not explain why most customers can check out without any problem and with the full product name (Japanese Name of Product <br /> English Name of the Product) .

I also asked in the Square developer forum, but they thought it is a problem of the Zen Cart API.

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

best.

carlwhat:

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

best.

Thank you.
I have another question: How can I test the Square WebPay module without doing any cc transfers? I would like to reproduce the error, but do not want to make lots of payments and later cancel all. Square would probably also not like this.

todoonada:

Thank you.
I have another question: How can I test the Square WebPay module without doing any cc transfers? I would like to reproduce the error, but do not want to make lots of payments and later cancel all. Square would probably also not like this.

you need to create sandbox credentials and enter them in the admin.

one should have a development site to do sandboxing, else you should put your site into maintenance mode.

hope that helps.

todoonada:

....

I also asked in the Square developer forum, but they thought it is a problem of the Zen Cart API.

can you please provide a link to where you were asking this question in the square developer forum?

thanks in advance.

carlwhat:

i have not seen this error.

it will be a tricky one to figure out as the error is coming from the square SDK.

you could try changing line 108 from includes/modules/payment/square_webPay/square/square/src/ApiHelper.php as below, but it is a pure guess on my part.

//from
public static function serialize($value): string
//to
public static function serialize($value): ?string

> and i'm unsure what else that might affect.
> 
> best.

i am also coming back to my attempted solution here.  have you tried it?

i have done some debugging, and it looks like the serialize function is taking the array of the whole order.

the problem is something in the array is not in utf8 encoding.  so the most likely culprit is the japanese product name.  it is NOT the <br /> in the product name string.

i would check the encoding of the product name that you think is causing the problem.  i am not the character encoding king, nor do i fully understand it.  but that's my guess.

we could add some checking to get the last error if you are so inclined.  but i am curious about my other questions on this issue.

best.

carlwhat:

can you please provide a link to where you were asking this question in the square developer forum?

Thanks for your help!

This is the link: https://developer.squareup.com/forums/t/php-fatal-error-uncaught-typeerror-square-apihelper-serialize/8224/4

I did not try your suggested solution yet, because I do not like to change anything while not knowing the reason. I also checked the product names the people who had problems checking out, had in their cart, but could not find any pattern.
There is also the possibility, that the people use some unexpected encoding for the data they provide. This whole encoding stuff in Japanese is quite annoying and I am not very familiar with it.
On a side note, not connected with the payment problem: very rarely some Kanji are shown with a placeholder in the backend of Zen Cart. On the invoice the same Kanji is displayed correctly, though.
First step for me would be to find out what causes the error. Of course I have a test shop running on a local Apache, but I did not do the Square sandbox setup yet. I have a feeling, it might be some combination of circumstances which lead to the error.

todoonada:

...
I did not try your suggested solution yet, because I do not like to change anything while not knowing the reason. ...

it is hard for me to help you find a solution if you do not try the solutions i have already provided.

the error is coming from a call to json_encode. that method will return false if it can not properly encode the data provided to it. which most likely means that the data is not utf8 encoded.

i agree that i would be reluctant to implement a solution until i can accurately reproduce a problem; but given the frequency of your issue, i am not really sure what the downside is.

best.

carlwhat:

it is hard for me to help you find a solution if you do not try the solutions i have already provided.

the error is coming from a call to json_encode. that method will return false if it can not properly encode the data provided to it. which most likely means that the data is not utf8 encoded.

i agree that i would be reluctant to implement a solution until i can accurately reproduce a problem; but given the frequency of your issue, i am not really sure what the downside is.

best.

The error is not very frequent. It happens from time to time.
The downside is that I do not want to potentially increase errors by changing code without knowing what causes the error.
What does the question mark do in ```
[I]serialize[/I]I: ?[/I][I]string [/I]

It does not solve the UTF8 error (if it is one).

I know you already mentioned that you think the <br /> tag is not the problem. I changed the tag -before I read your comment- to a hyphen.

I suspect that I know the answer to this but I will ask anyway...will this Square module work with zen 1.5.4?

Thanks

Rich

rstar23:

I suspect that I know the answer to this but I will ask anyway...will this Square module work with zen 1.5.4?

Thanks

Rich

no.

apologies.

carlwhat:

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

best.

Hello carlwhat,
I could not reproduce the error. I made some observations while checking the "Whos online" page of the shop.
I saw a customer checking out and it stayed awfully long at the squareWebPay_handler.php file. I expected another error of the same kind I described before, but after 20 seconds the file switched to checkout_success and there was no error and the order was successful.
A few days later I saw the same again, but even after 15 minutes, the file was still squareWebPay_handler.php. After this the customer was not visible on the "Whos online" page, because after 15 mins of inactivity, they are removed from the list. There was no error file in the log folder for this transaction and no successful order.

I checked the encoding of customer's data and the item he wanted to order, but could not find anything strange.

So I think that the error might come from people trying to reload the page or clicking the browser's back button, when it takes too long to show the checkout_success page and only a white page is displayed.

158
PHP 8.1
bootstrap clone
OPC

[13-Feb-2023 15:20:02 UTC] Request URI: /index.php?main_page=checkout_one, IP address: 471.642.591.531, Language id 1#0 /includes/modules/payment/square_webPay/square/square/src/Models/Location.php(12): zen_debug_error_handler()
#1 /laravel/vendor/composer/ClassLoader.php(571): include('/home/haremark/...')
#2 /laravel/vendor/composer/ClassLoader.php(428): Composer\Autoload\includeFile()
#3 /includes/modules/payment/square_webPay.php(795): Composer\Autoload\ClassLoader->loadClass()
#4 /includes/modules/pages/checkout_payment/jscript_square_webPay.php(36): square_webPay->getLocationDetails()
#5 /includes/modules/pages/checkout_one/jscript_square_webPay.php(22): require('/home/frammer/...')
#6 /includes/templates/boot_clone/common/html_header.php(224): require('/home/frammer/...')
#7 /index.php(42): require('/home/frammer/...')
--> PHP Deprecated: Return type of Square\Models\Location::jsonSerialize(bool $asArrayWhenEmpty = false) should either be compatible with JsonSerializable::jsonSerialize(): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /includes/modules/payment/square_webPay/square/square/src/Models/Location.php on line 807.

Should line 807 go from public function jsonSerialize(bool $asArrayWhenEmpty = false)to #[\ReturnTypeWillChange] public function jsonSerialize(bool $asArrayWhenEmpty = false)or```
public function jsonSerialize(bool $asArrayWhenEmpty = false):mixed

none of the above?

on the downloads page:

-- The square SDK has NOT changed (17.2.0.20220216), and only supports up to php 8.0.

Other than logs complaining about deprecation, it works.

Just FYI

carlwhat:

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.

todoonada:

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?