Square Payment Module for Zen Cart [Support Thread]

Thanks!
Got rid of those and the error message is gone. But the accesse token error is still there

I really do appreciate your help

Quote:

---

Originally Posted by DrByte

To get descriptive output for debugging, you can TEMPORARILY edit square_handler.php and change line 11, which says:

Code:

---

$verbose = false;

---

and change false to true.
NOTE that this may prevent normal transactions from operating properly until you put it back to false.

With $verbose=true, it will give output with one of:
not configured = module doesn't have an Application ID set
failure = token expired more than 15 days ago, or no token available to refresh
refreshed = the job refreshed the token
not refreshed = a refresh was attempted, but did not complete properly
not expired = a token exists but it is younger than 3 weeks old, so no need to refresh

---

Thanks for that info and your other replies, Dr Byte. Apologies for my delayed reply: I've been away.

Changing line 11 unfortunately resulted no output produced (i.e. no error log or email received).

So I experimented further. By adding simple echo requests at different points in the square_handler.php file I found that it did produce output - but only when added BEFORE the 2 'require....' statements at lines 12 & 13 (i.e. I gather output was produced in the header). After that point, no output was produced.

To be clear, my amended code from line 11:

Quote:

---

$verbose = true; //GM Changed from false for testing
echo $verbose . ' ' . $mode . ' ' . '- results when echo placed BEFORE require statements'; //GM Line added for testing
require 'includes/application_top.php';
require DIR_WS_CLASSES . 'payment.php';
echo $verbose . ' ' . $mode . ' ' . '- results when echo placed after require statements'; //GM Line added for testing

---

produced this output in the email and no error log:

Quote:

---

1 cli - results when echo placed BEFORE require statements

---

Despite more experimenting, I couldn't work out why output didn't include the messages you cited nor the later echo statements - and more importantly, whether this meant the cron job did not successfully complete its task to refresh the token. Any ideas? Thanks.

Anyone know this is for UK banks, cant find the RBS Routing number?

Attachment 18066

Getting this error when testing the module

"YOUR TRANSACTION COULD NOT BE COMPLETED DUE TO A MISCONFIGURATION IN OUR STORE. PLEASE REPORT THIS ERROR TO THE STORE OWNER: SQ-MISCONF"

Any idea why?

I got rid of the error messages in admin. But when I test it by trying to buy something I get this:

Error We could not initiate your transaction because of a problem with the card data you entered. Please correct the card data, or report this error to the Store Owner: SQ-NONCE-FAILURE

Quote:

---

Originally Posted by JoeH

I got rid of the error messages in admin. But when I test it by trying to buy something I get this:

Error We could not initiate your transaction because of a problem with the card data you entered. Please correct the card data, or report this error to the Store Owner: SQ-NONCE-FAILURE

---

SQ-NONCE-FAILURE appears when the javascript code in your template has errors and is preventing the javascript for the module from executing properly.
This is often caused by other plugins that are using outdated javascript or old versions of jQuery. It can also happen if you're using a template designed for an older version of Zen Cart and therefore have an old jscript_framework.php file in your template's jscript folder.

Quote:

---

Originally Posted by JakeLawless

Anyone know this is for UK banks, cant find the RBS Routing number?

Attachment 18066

---

Best to ask your Bank, or contact Square Support for help in filling in banking details inside your Square account.

Quote:

---

Originally Posted by JakeLawless

Getting this error when testing the module

"YOUR TRANSACTION COULD NOT BE COMPLETED DUE TO A MISCONFIGURATION IN OUR STORE. PLEASE REPORT THIS ERROR TO THE STORE OWNER: SQ-MISCONF"

Any idea why?

---

SQ-MISCONF appears when your attempted transaction triggers the "INVALID_REQUEST_ERROR" response from Square's servers.
There are two steps to take for sorting this out:
1. Look at the debug log that was generated in your server's /logs folder, as it will contain more details about the complete communication between your server and Square.
2. Contact Square Support and tell them the information in the log file from #1 above. Their servers will contain all your transaction attempt history and their techs will be able to explain what's gone wrong with your specific transaction attempts.

Quote:

---

Originally Posted by GerriM

Quote:

---

Originally Posted by DrByte

To get descriptive output for debugging, you can TEMPORARILY edit square_handler.php and change line 11, which says:

Code:

---

$verbose = false;

---

and change false to true.
NOTE that this may prevent normal transactions from operating properly until you put it back to false.

With $verbose=true, it will give output with one of:
not configured = module doesn't have an Application ID set
failure = token expired more than 15 days ago, or no token available to refresh
refreshed = the job refreshed the token
not refreshed = a refresh was attempted, but did not complete properly
not expired = a token exists but it is younger than 3 weeks old, so no need to refresh

---

Thanks for that info and your other replies, Dr Byte. Apologies for my delayed reply: I've been away.

Changing line 11 unfortunately resulted no output produced (i.e. no error log or email received).

So I experimented further. By adding simple echo requests at different points in the square_handler.php file I found that it did produce output - but only when added BEFORE the 2 'require....' statements at lines 12 & 13 (i.e. I gather output was produced in the header). After that point, no output was produced.

To be clear, my amended code from line 11:

Quote:

---

$verbose = true; //GM Changed from false for testing
echo $verbose . ' ' . $mode . ' ' . '- results when echo placed BEFORE require statements'; //GM Line added for testing
require 'includes/application_top.php';
require DIR_WS_CLASSES . 'payment.php';
echo $verbose . ' ' . $mode . ' ' . '- results when echo placed after require statements'; //GM Line added for testing

---

produced this output in the email and no error log:

Quote:

---

1 cli - results when echo placed BEFORE require statements

---

Despite more experimenting, I couldn't work out why output didn't include the messages you cited nor the later echo statements - and more importantly, whether this meant the cron job did not successfully complete its task to refresh the token. Any ideas? Thanks.

---

The fact that your 2nd echo does not appear means the code before it is failing with fatal errors. Your server's PHP error-logs will contain more information. Clearly something's unusual about your server config which is preventing this from operating normally.

Quote:

---

Originally Posted by DrByte

SQ-NONCE-FAILURE appears when the javascript code in your template has errors and is preventing the javascript for the module from executing properly.
This is often caused by other plugins that are using outdated javascript or old versions of jQuery. It can also happen if you're using a template designed for an older version of Zen Cart and therefore have an old jscript_framework.php file in your template's jscript folder.

---

Thanks!
But how do I find out how to fix it?

Quote:

---

Originally Posted by JoeH

Quote:

---

Originally Posted by DrByte

SQ-NONCE-FAILURE appears when the javascript code in your template has errors and is preventing the javascript for the module from executing properly.
This is often caused by other plugins that are using outdated javascript or old versions of jQuery. It can also happen if you're using a template designed for an older version of Zen Cart and therefore have an old jscript_framework.php file in your template's jscript folder.

---

Thanks!
But how do I find out how to fix it?

---

Ya, that's the challenging part. Teaching someone javascript-debugging is hard to do in a single post! Can't really do that here. There are a dozen discussions of the same issue earlier in this thread, all with varying examples of the same situation as yours. So I'd start there.
Additionally, you can use your browser's "console log" to inspect the actual javascript errors that are occurring when the checkout_payment page is being loaded, and when the submit button is clicked. Using the information reported there can help you understand what javascript conflicts might exist and need fixing.