Just did a test order on the site with the fatal error. Got the same error BUT, the order processed.
Printable View
Just did a test order on the site with the fatal error. Got the same error BUT, the order processed.
i have just submitted version 1.0.3 for review.
i'm of the opinion that the small bug previously documented warranted a new release.
best.
Approved.
Here's the scenario:
- Site uses One Page Checkout and Square WebPay
- Customer selects product, adds to cart, and selects Guest Checkout
- If the customer's browser offers them a remembered card for use, they select that card
- Most systems ask the customer for their CVV to verify and add the card to the form.
- Often the Zip Code is left to be filled in by the customer.
- If the customer does not click on enter or tab to the next box but, instead, scrolls down and clicks on Confirm Order, they will get the invalid token notice.
- What has happened is that the customer has asked the cart to submit the order BEFORE the CC form is completed correctly. Essentially transmitting the transaction without a Zip Code.
- So, anytime a customer is using Square and clicks on the Confirm Order button without the CC form properly filled out will get the Token error.
Thus the error received isBy not finishing the entry process on the CC form before clicking on the Confirm Order button, the customer is forcing OPC to submit an invalid CC form.Code:[30-Oct-2022 12:54:58 America/Los_Angeles] 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 261
The answer may be totally in OPC's court but at least I can see why the token errors have been so random.
I don't use OPC and got the same warning so you may be able to rule that out.
At the time I was not running V1.0.2 though but a test version carlwhat gave me that fixed the issues when the store is hosted in a subfolder. The only modified file was /includes/modules/pages/checkout_payment/jscript_square_webPay.phpCode:[27-Oct-2022 14:38:53 Europe/London] 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
I don't think there is an error with OPC. I think the problem is with the customer who enters the last bit off CC info without hitting enter or tabbing out of the CC form and clicking on the confirm order button.
My thought for a fix would work for either one. Make the confirm button disabled until the payment form is fully completed.
Just my WAG:P
I'll leave it up to Paul, Cindy and Scott et al to work it out. I stand ready to test any possible solutions.
In the past (and also these days), I have added written instructions to the payment selection area on the checkout page.
Generally, these are coloured RED and in BOLD text - so the idiots who do online shopping (that's me too), are instructed what to do before hit "Confirm Order".
EG: Above the option for CARD PAYMENTS I have;
Make sure to enter your card details manually! All fields are needed - CARD NUMBER, EXPIRY DATE, CVV
How to change the card entry form to dark mode? our website is black background and some section of the card input can not display clearly. Square told us that web pay SDK can Customize the Card Entry Form and they have as dark mode.
Thanks.
@swguy, i am finally looking at this error.
i think the way to solve this problem is returning an empty array. corrected code for that 1 method:
thanks for pointing it out.PHP Code:
protected function lookupOrderDetails($order_id)
{
global $db;
$sql = "SELECT * from " . TABLE_SQUARE_PAYMENTS . " WHERE order_id = " . (int)$order_id;
$order = $db->Execute($sql);
if ($order->EOF) {
return [];
}
$ids = [];
// foreach (['tender_id', 'transaction_id', 'payment_id', 'sq_order'] as $key) {
foreach (['tender_id', 'transaction_id', 'sq_order'] as $key) {
if (!empty($order->fields[$key])) {
$ids[] = $order->fields[$key];
}
}
$request = new Models\BatchRetrieveOrdersRequest($ids);
try {
$apiResponse = $this->client->getOrdersApi()->batchRetrieveOrders($request);
$response = $this->processResult($apiResponse, $request);
return $response['results']->getOrders();
} catch (\SquareConnect\ApiException $e) {
return [];
}
}
I have been using square_handler_cron.php from swguy to automatically refresh the Square token. Do I need to make any changes to it to work with Square_webPay? I can't find his code anymore to see if it has been updated. The key statements in his code are:
Thank you.Code:if (IS_CLI == 'VERBOSE') echo 'Starting token refresh... ' . "\n\n";
require DIR_WS_CLASSES . 'payment.php';
$module = new payment('square');
$square = new square;
$result = $square->token_refresh_check();
if ($result === 'failure') {
if (IS_CLI == 'VERBOSE') echo 'Square Token Refresh Failure. See logs.' . "\n";
if (IS_CLI == 'VERBOSE') echo 'Done.' . "\n\n";
exit(1);
} else {
if (IS_CLI == 'VERBOSE') echo $result . "\n";
if (IS_CLI == 'VERBOSE') echo 'Done.' . "\n\n";
exit(0); // returns 0 status code, which means successful
}
> i think the way to solve this problem is returning an empty array. corrected code for that 1 method ...
Much obliged, sir!
dave,
i can not say whether this handler will work. i have a feeling it will not. but i can not say.
the latest version of my handler does verbose logging if you set $verbose to true in the handler. furthermore, i have improved the logging so that in the case of a failed refresh, the error message is much specific. in addition it can be set up as a cron job as well.
i would look at the docs on it.
best.
Should update the version when the version is updated...
public $moduleVersion = '1.0.2';
public $moduleVersion = '1.0.3';
modules/payment/square_webPay.php
should?
everybody makes mistakes.
i'm reminded of your comment here:
https://www.zen-cart.com/showthread....99#post1389299
and lack of any real follow up.
so just go bugger off, unless you have anything of any real value to add.
best.
https://docs.zen-cart.com/user/payme..._token_expiry/
Like @carlwhat said - always check the docs!
Thanks for the updated release... got an issue I can't resolve: I've installed and after I enter the Application Secret(OAuth) and save. When I click edit to go in and set the location. The drop down is blankAttachment 20153
Any suggestions on what might be causing this? I do have 2 locations set in square. The one I need to use is the MAIN location set in square.
For domain needtoorder.com
Does anyone know if this new Square payment module will work with the slightly older ZenCart version Zen Cart 1.5.5f (on PHP 7.1.33)?
(We are currently using the DrByte Square module version 1.1, but the credit card fields greyed out this week. I assume this is because of a deprecated module. We have to urgently fix this to continue processing payments but can't upgrade the ZenCart to 1.5.6+ at the moment, in order to maintain template system compatibility.)
> We ... can't upgrade the ZenCart to 1.5.6+ at the moment, in order to maintain template system compatibility.
This is not true at all. Upgrade your cart, upgrade your template, voila you're current.
You are running an old, unsupported PHP and an old, unsupported Zen Cart. It's way past time to upgrade.
i think something is wrong with your configuration; and specifically you do not have a proper merchant access token.
here is a new trick for you. go to your admin, and to the end of your URL, add sandbox=anything, ie:
https://zcdev.com/zcdev/admin/index....ndbox=anything
you can now see your Live Merchant Token. if that is blank, then that is your problem.
if that is not your problem, you can try the following:
create a test.php file in your root directory with the following code:
when you go to:PHP Code:
<?php
require('includes/application_top.php');
include_once DIR_FS_CATALOG . DIR_WS_MODULES . 'payment/square_webPay.php';
include_once DIR_FS_CATALOG . DIR_WS_LANGUAGES . 'english/modules/payment/square_webPay.php';
$test = new square_webPay();
$pulldown = $test->getLocationsPulldownArray();
print_r($pulldown);
die(__FILE__ . ':' . __LINE__);
yoursite.com/test.php
you should see your locations in an array format.
currently that is coming back as blank.
if your Live Merchant Token is not blank, and the test is coming back with your locations array, and you are still seeing the image you have referenced, let me know and we can further troubleshoot. but i do not think that is the case.
best.
When I click the green button
"click her to authorize..."
It takes me with a redirect back to my site, but doesnt actually do an authorize.... url (parts redacted):https://www.needtoorder.com/?code=sq...xxxxxxxxxx#_=_
When I go into edit the payment module, the drop down for location doesnt display locations to choose from.
It says I have 2 active access tokens in my square account under OAuth... so I'm confused as to next steps.
changed the OAuth Redirect URL to:https://needtoorder.com/squareWebPay_handler.php and tried to auth and the page gives me a
This page isn’t working
needtoorder.com is currently unable to handle this request.[COLOR=var(--error-code-color)]HTTP ERROR 500
[/COLOR]
Payment Module installed DID A RE-UPLOAD OF THE UPLOAD FOLDER, worked perfectly after that.
**BUT**
Every order that used the previous square mod wont display ANY of the order details!! ??
Attachment 20157
It's completely blank under and after the payment details.
Code:UPDATE orders
SET payment_module_code = 'square_webPay'
WHERE payment_module_code = 'square';
It's throwing a error log:
[19-Nov-2022 20:17:11 America/Chicago] Request URI: /XXkcaz00/index.php?cmd=orders&page=1&oID=90795&action=edit, IP address: 184.170.174.172
#1 square->token_refresh_check() called at [/includes/modules/payment/square.php:505]
#2 square->getAccessToken() called at [/includes/modules/payment/square.php:816]
#3 square->lookupOrderDetails() called at [/includes/modules/payment/square.php:456]
#4 square->admin_notification() called at [/XXkcaz00/orders.php:881]
#5 require(/XXkcaz00/orders.php) called at [/XXkcaz00/index.php:11]
--> PHP Warning: Use of undefined constant MODULE_PAYMENT_SQUARE_APPLICATION_ID - assumed 'MODULE_PAYMENT_SQUARE_APPLICATION_ID' (this will throw an Error in a future version of PHP) in /includes/modules/payment/square.php on line 544.
[19-Nov-2022 20:17:11 America/Chicago] Request URI: /XXkcaz00/index.php?cmd=orders&page=1&oID=90795&action=edit, IP address: 184.170.174.172
#1 square->token_refresh_check() called at [/includes/modules/payment/square.php:505]
#2 square->getAccessToken() called at [/includes/modules/payment/square.php:816]
#3 square->lookupOrderDetails() called at [/includes/modules/payment/square.php:456]
#4 square->admin_notification() called at [/XXkcaz00/orders.php:881]
#5 require(/XXkcaz00/orders.php) called at [/XXkcaz00/index.php:11]
--> PHP Warning: Use of undefined constant MODULE_PAYMENT_SQUARE_ACCESS_TOKEN - assumed 'MODULE_PAYMENT_SQUARE_ACCESS_TOKEN' (this will throw an Error in a future version of PHP) in /includes/modules/payment/square.php on line 546.
[19-Nov-2022 20:17:11 America/Chicago] Request URI: /XXkcaz00/index.php?cmd=orders&page=1&oID=90795&action=edit, IP address: 184.170.174.172
#1 square->isTokenExpired() called at [/includes/modules/payment/square.php:559]
#2 square->token_refresh_check() called at [/includes/modules/payment/square.php:505]
#3 square->getAccessToken() called at [/includes/modules/payment/square.php:816]
#4 square->lookupOrderDetails() called at [/includes/modules/payment/square.php:456]
#5 square->admin_notification() called at [/XXkcaz00/orders.php:881]
#6 require(/XXkcaz00/orders.php) called at [/XXkcaz00/index.php:11]
--> PHP Warning: Use of undefined constant MODULE_PAYMENT_SQUARE_TOKEN_EXPIRES_AT - assumed 'MODULE_PAYMENT_SQUARE_TOKEN_EXPIRES_AT' (this will throw an Error in a future version of PHP) in /includes/modules/payment/square.php on line 525.
[19-Nov-2022 20:17:11 America/Chicago] Request URI: /XXkcaz00/index.php?cmd=orders&page=1&oID=90795&action=edit, IP address: 184.170.174.172
#1 square->isTokenExpired() called at [/includes/modules/payment/square.php:559]
#2 square->token_refresh_check() called at [/includes/modules/payment/square.php:505]
#3 square->getAccessToken() called at [/includes/modules/payment/square.php:816]
#4 square->lookupOrderDetails() called at [/includes/modules/payment/square.php:456]
#5 square->admin_notification() called at [/XXkcaz00/orders.php:881]
#6 require(/XXkcaz00/orders.php) called at [/XXkcaz00/index.php:11]
--> PHP Warning: Use of undefined constant MODULE_PAYMENT_SQUARE_TOKEN_EXPIRES_AT - assumed 'MODULE_PAYMENT_SQUARE_TOKEN_EXPIRES_AT' (this will throw an Error in a future version of PHP) in /includes/modules/payment/square.php on line 526.
[19-Nov-2022 20:17:11 America/Chicago] PHP Fatal error: Uncaught Exception: DateTime::__construct(): Failed to parse time string (MODULE_PAYMENT_SQUARE_TOKEN_EXPIRES_AT) at position 0 (M): The timezone could not be found in the database in /includes/modules/payment/square.php:526
Stack trace:
#0 /includes/modules/payment/square.php(526): DateTime->__construct('MODULE_PAYMENT_...')
#1 /includes/modules/payment/square.php(559): square->isTokenExpired('-15 days')
#2 /includes/modules/payment/square.php(505): square->token_refresh_check()
#3 /includes/modules/payment/square.php(816): square->getAccessToken()
#4 /includes/modules/payment/square.php(456): square->lookupOrderDetails('90795')
#5 /XXkcaz00/orders.php(881): square->admin_notification('90795')
#6 /XXkcaz00/index.php(11): require('/home/feadmin/p...')
#7 {main}
thrown in /includes/modules/payment/square.php on line 526
[19-Nov-2022 20:17:11 America/Chicago] Request URI: /XXkcaz00/index.php?cmd=orders&page=1&oID=90795&action=edit, IP address: 184.170.174.172
--> PHP Fatal error: Uncaught Exception: DateTime::__construct(): Failed to parse time string (MODULE_PAYMENT_SQUARE_TOKEN_EXPIRES_AT) at position 0 (M): The timezone could not be found in the database in /includes/modules/payment/square.php:526
Stack trace:
#0 /includes/modules/payment/square.php(526): DateTime->__construct('MODULE_PAYMENT_...')
#1 /includes/modules/payment/square.php(559): square->isTokenExpired('-15 days')
#2 /includes/modules/payment/square.php(505): square->token_refresh_check()
#3 /includes/modules/payment/square.php(816): square->getAccessToken()
#4 /includes/modules/payment/square.php(456): square->lookupOrderDetails('90795')
#5 /XXkcaz00/orders.php(881): square->admin_notification('90795')
#6 /XXkcaz00/index.php(11): require('/home/feadmin/p...')
#7 {main}
thrown in /includes/modules/payment/square.php on line 526.
barco57 - Where would this be resolved at? Appreciate your feedback.
wait... I need to run a query to change the previous.... correct?
admin > tools > install SQL Patches
Thank You! Appreciate your quick response and direction. Jumping in for the guy that usually does that, and I'm not as familiar.
Anyone using this with Numinix FEC? I have a client with FEC 2.4.1 and Zen Cart 1.5.6c
I installed this new plugin and now get this: https://screenrec.com/share/jA5gWp0aSb
One error in the console but about a missing flexslider function
I tried putting jscript_square_webPay.php in /public_html/includes/modules/pages/checkout When I do, this button disappears.
When I turn off FEC, it seems to work fine.
Installed the App and I am currently testing. Getting a speed bump.
Each time I enter the cc info and click to confirm, the page refreshes and displays a message "Your order's details have changed. Please review the current values and re-submit." The url is for one page checkout: https://needtoorder.com/index.php?ma...e=checkout_one.
that error is coming from OPC. it's basically saying the hash has changed and i need to reload everything.
why it is doing that is anyone's guess.
empirical data suggests the square webPay and OPC do play nice together when properly configured. so why OPC is telling you that your order details have changed, perhaps may be better served over on the forum over there. i am not the OPC expert by any stretch.
best.
YEP! You were right. It was a OPC configuration. Thank you so much!
> YEP! You were right. It was a OPC configuration. Thank you so much!
What was the required change ?
Changing the OPC accepted payment method from “square” to “square_webPay” after I installed the new Square Web Pay mod.
Sorry for the misunderstanding carlwhat. I quoted you because you said IT'S NOT COMPATIBLE and I thought that on the module downloads area said 1.5.5 compatible but I just rechecked and it says 1.5.6. This is a combination of not using glasses and lack of sleep these days.... I apologize for not checking 5 times instead of 2 times before my post. :blush:
ok.
based on what you said, you should have log files getting generated.
post them if you would like some help.
@ideasgirl 1.5.5 is over 5 years old, and only runs on PHP versions that are no longer supported. Your client needs to upgrade.
:laugh: Thank you! Don't worry.... I uninstalled both plugins and everything is fine now.
Yes, she has been advised but it has been 2 bad years for her in terms of revenue. She's planning to start the transition in the 1stQ of 2023.Quote:
@ideasgirl 1.5.5 is over 5 years old, and only runs on PHP versions that are no longer supported. Your client needs to upgrade.
Don't forget the option of the El-Cheapo Quickie Econo-Upgrade (tm) procedure:
https://docs.zen-cart.com/user/upgra..._only_upgrade/
We are looking after a site where the owner is in a similar cashflow position. (We stopped developing 3rd-party sites over 10 years ago, but the owner of this site is a long-standing business acquaintance).
We agreed to keep the site "current" for him, on the basis of getting a small percentage of sales revenue.
Effectively, it's in our interest therefore, to ensure the site's functionality. The more sales he makes, the greater our commission. It will definitely take a while before we get "fully paid", but at least we're seeing a trickle of revenue, and more importantly, the website is operational and efficient, so our client is scraping by as well.
Perhaps you could discuss a similar arrangement with your customer...
I have Square WebPay logging set to Always and Verbose set to true in the handler. Should I receive a log on successful token refresh when the handler is run from a cron job (the automated token refresh method), and when the manual token refresh approach documented in storeowner docs, i.e., click edit then click update in the admin Square WebPay payment module?
Thank you!
Dave
dave,
i do not run a production site using square. so hard for me to say exactly.
when running a cron job for the handler, you should check how you have the output configured for your cron jobs. there will be output there, but that output is completely handled via cron.
it does NOT look like this module will generate a php log (ie, a zen-cart log) on successful token refresh. but the cron job will have output.
when doing a manual refresh, there will be a php log (ie a zen-cart log) even when there is a successful token refresh.
hope that helps.
best.
Any interest in adding Affirm Afterpay to the premium version of this plugin?
it is not a bad idea. but it looks to be afterpay. see:
https://squareup.com/us/en/buy-now-pay-later
i am not sure which of the three is the best, affirm v afterpay v klarna; or if they are all just similar products from different payment processors.
i will take a look time permitting.
thanks.
yeah, in briefly looking at the code, it's probably best to build a separate payment module to extend square webpay. similar to what i did with auth.net card on file transactions.
the selection method does NOT allow for multiple selections within a payment module. it looks for an array with the keys: id, module, and fields.
little thought for food.
best.
Thanks for that suggestion :smile: I've thought about that before but I'm struggling myself, too. :lookaroun I will give it a thought again and discuss it with her (since she's also a friend). She's been a customer and a ZC user since v1.2.6.
I found this error in the log files after the customer had trouble with payment:
--> PHP Fatal error: Uncaught TypeError: Square\ApiHelper::serialize(): Return value must be of type string, bool returned in /home2/rcracean/public_html/silversalt/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?
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.
and i'm unsure what else that might affect.PHP Code:
//from
public static function serialize($value): string
//to
public static function serialize($value): ?string
best.
Thank you very much for your fast reply. Some hours after I asked the customer what the error message was, he replied. It was an HTTP Error 500.
I tested the payment module and no problem. Other customers also had no problem. So I told him that it seems the error was on his side. After a while he responded that the error comes from some setting on his smartphone (I have no idea what setting could cause this error).
Sorry for the false alarm. Your module works excellent an better than the old one.
Upgraded my Square module to the WebPay module last week, was working great, taking charges with no issue.
Today I got a debug file with this at the end:
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 /usr/www/users/xx/includes/modules/payment/square_webPay.php on line 261.
Customer abandoned their cart at checkout_payment.
I saw some other messages about this, but must have missed the solution. How can I fix this?
Using 1.56c, php 7.3, standard checkout flow, daily cron task for handler update.
many thanks,
Ed
I do not have any active coupons. I have a couple of downloadable products, but not something that usually sells. I got several detailed error messages about "Pan Failure" from what you did on the site, posted to you privately.
a PAN failure is the message that comes back from square. i placed an order with a test credit card, and square properly responded to that test credit card number. it is perfectly fine to post that message here, and no need to PM me that. and frankly i have never understood why users do not want to post their live website URLs on the board. but i suppose i am in the minority.
that message is expected.
your previous message is something different. it means that the information necessary to submit to square was not found. why that is, i can not say. it worked fine for me.
if it happens again, i would try to see what was in the cart and exactly what the customer was doing.
very hard to fix if i can not reproduce.
best.
Thanks very much for your efforts to look into this, much appreciated.
If it happens again, I'll try to get additional info from the customer about what they were buying, and what they saw when they tried to check out.
This was found in troubleshooting today. We loaded the 1.03 files to Zen Cart 1.5.8 and were getting stopped at Confirm Checkout with a token error.
For those wondering about 1.5.8, WebPay works exactly as expected in Zen Cart 1.5.8 WITHOUT One Page Checkout.
If you are going to use WebPay AND One Page Checkout with Zen Cart, you will need to get the OLD square javascript file from includes/modules/pages/checkout_payment/ called jscript_square.php.
Copy or FTP that file to includes/modules/pages/checkout_one/.
The includes/modules/pages/checkout_payment/jscript_square.php is still part of the 1.5.8 distribution zip file. It may not be part of further distros.
this is just wrong.
following this advice is not recommended by me; and i wrote the square webPay module.
the code from that file is here.
looking at it here, one can see that said file will just return false without doing anything.
there is nothing in the jscript_square.php that has anything to do with square webPay.PHP Code:
if (!defined('MODULE_PAYMENT_SQUARE_STATUS') || MODULE_PAYMENT_SQUARE_STATUS != 'True' || (!defined('MODULE_PAYMENT_SQUARE_APPLICATION_ID') || MODULE_PAYMENT_SQUARE_ACCESS_TOKEN == '')) {
return false;
}
if ($payment_modules->in_special_checkout() || empty($square) || !$square->enabled) {
return false;
}
why this situation works for this poster, i can not say; nor will i offer a guess.
best.
Of course you won't offer a guess.
Your abilities as a programmer are bar none,
Your abilities in dealing with a proven problem are either "I don't use that mod with it" or "it should not being doing that".
Thank you Captain Obvious.
After several successful orders on the site this evening, I went in and (again) changed the jscript_square.php to jscript_goofy.php All OPC orders failed with a token error.
Changed it back and orders processed completely.
I had similar problems in 1.5.7d with removed (not uninstalled) files for the old square or I would NEVER have thought to try the jscript_square.php insertion.
Sadly, I expected the denigration and washing of hands but, maybe it just might help someone in the same situation.
please leave this thread. your sarcasm is not appropriate nor appreciated...
your lack of trouble shooting skills on these boards is well documented.
considering my contributions to the ongoing development of zen-cart, your lack of respect for me and my work is quite amazing...
now please go bugger off, and convince someone else of your value while you capitalize on others work.
You're more than welcome to add me to you ignore list.
I would like to point out though,
If the old jscript had nothing in it but a beginning and closing PHP tag, it's merely being required by some other file SOMEWHERE during the process would break the chain if it were not present.
You can consider that possibility or not.
I will have to disagree with that. I have several clients using this plugin (Square WebPay) with OPC and it works like a charm out of the box with the jscript_square_webPay.php provided with the plugin.
@dbltoe - did you go through the tokenization (authentication) process with the new Square WebPay module after installing it? Updated the callback URL in your Square dashboard etc? Did you get the white page that just says "token set" or something like that, can't remember the exact wording now?
+1
First of all, thanks for a civil discourse.
About Square. I have been using and setting up Square even before it was part of Zen Cart. I was the one that confirmed WebPay's operation with 1.5.6c and PHP 7.3. See thread Post #2
Even, the required use of a possibly obsolete API Version, was also entered as mentioned in the docs.
As I stated, we have had no problem running WebPay with 1.5.8. However, with the addition of OPC, we were getting the result below as soon as the confirm order was clicked. This site had never had Square before. 1.5.8 was brought in without anything but old images, old define pages, and the old DB. As a totally wild thought, I added the jscript from drByte's mod to the checkout_one folder for lat9's OPC. It is still mentioned in the compatibility ortion of his install notes. Instant and continuing success from then on.
Again, last night after things setttled down on the new site, we again renamed the old file and got the same error when trying through OPC. While not familiar with the intricacies of code, I can recognize the cause and effect we are getting without the file and with. We have noticed this morning that Edit Orders does not seem to be playing nice (maybe the new languages setup) but I have never known edit orders to affect front-end ordering.
I went as far with it as I was capable and brought it to the forum in an attempt to see if someone else was experiencing it and possibilty some direction to look for a fix. I also placed the same info in the OPC forum.
I agree with Carlwhat in that there is no code in the file that should be needed. Yet, as I mentioned later, if the file is in a require somewhere else, it's absence could easily create the fatal error. This is the first time I have ever seen this error message in all of our setups. I have seen others and spinners that turn for days if you let them but, never this. If the fix works for one other person, that's reaason enough for me to mention it.
Any thoughts on adding a Square hosted payment page option? The new PCI changes are heavy....
~Melanie
i have no idea what you mean.
i am not a lawyer. i do not claim to be an expert on PCI-DSS compliance. nor should anything i write be construed as legal advice; or that one is in or not in pci compliance.
square webPay makes use of the square web payments sdk. i would suggest reading a bit here.
all field inputs (and in fact the form) are handled by square, in a PCI compliant manner (according to them).
using the square checkout api (their hosted payment page solution) does not make you any more or less compliant with the PCI-DSS requirements.
best.
Installed the module back in October. I haven't been able to edit the customer's orders. When I clicked "edit" on a previous order today I got the following in the error log:
/admin/index.php?cmd=orders&page=1&oID=729&action=edit, IP address: xx.xxx.xxx.xx
#1 require() called at [/includes/modules/payment/square_webPay.php:508]
#2 square_webPay->admin_notification() called at [/admin/orders.php:731]
#3 require(/admin/orders.php) called at [/admins/index.php:11]
--> PHP Warning: require(/includes/modules/payment/square_support/square_admin_notification.php): failed to open stream: No such file or directory in /includes/modules/payment/square_webPay.php on line 508.
[07-Jan-2023 14:38:57 America/Boise] PHP Fatal error: require(): Failed opening required '/includes/modules/payment/square_support/square_admin_notification.php' (include_path='.:/opt/cpanel/ea-php74/root/usr/share/pear') in /includes/modules/payment/square_webPay.php on line 508
I should I changed this to not show the name of my admin page or ip address. Any ideas?
(i'm assuming you are running v157...)
look at this link:
https://github.com/zencart/zencart/t...square_support
there are 2 files inside a directory. those files are either missing or they have the wrong permissions on them.
best.
Ver. 1.5.7c Square Web Payments Module 1.0.1 [using SDK: 17.2.0.20220216]
Square does not process the customer purchase unless I go to the "Click for Additional Payment Handling Options" (our admin section), then
Capture Transaction
You may capture previously-authorized funds here:
After I hit "Do Capture" the process is finalized and Square emails me the confirmation of the transaction (Payment received). I did not have to do that while using the old Square module. Is it supposed to work this way now, or I am missing something in the setup? TIA
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?
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.
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.
Thanks for your help!
This is the link: https://developer.squareup.com/forum...rialize/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.
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?Code:serialize($value): ?string
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
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
Should line 807 go fromCode:[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.
toCode:public function jsonSerialize(bool $asArrayWhenEmpty = false)
orCode:#[\ReturnTypeWillChange]
public function jsonSerialize(bool $asArrayWhenEmpty = false)
none of the above?Code:public function jsonSerialize(bool $asArrayWhenEmpty = false):mixed
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
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?