Square Payment Module for Zen Cart [Support Thread]

Quote:

---

Originally Posted by twitchtoo

First I would remove the module and check the db it has been removed properly Admin > Modules > Payment > Square... then remove the files and make sure they are not on the server... then reinstall everything.

Test the install.

Get errors again...
I would have to look at what is going wrong to see if there was a non generic tracer in the error log perhaps. Or force an error to see if there is an old reference on the server. Next I would try an older API version just in case the 'newest' one had a bug. And then start checking if the server version and PHP version mismatch along with the older PHP bridge these servers use is faulty.

You could post the error log get more eyes on it or hire that Twitchtoo guy to have a look - coffee is always a good place to start!
:cheers:

---

Thank you for taking the time! So last night after business hours, I did as you suggested, and nothing changed. I deleted the module, reinstalled the module, I changed the API versions (went through each and everyone of them testing for errors along the way), nothing. Entering the wrong CC data triggers the error as it should, once the CC data is reentered correctly the error message is not removed, the customer cannot move forward with checkout. No log errors generated either. Refreshing the page is the only way to get rid of the error message generated however customers wouldn't know that and instead walked away. I've had months of abandoned shopping bags I had no idea about, until one customer finally brought it up a few days ago. And I was all these months wondering why my sales had tanked.

I will definitely upgrade ZC after the holiday season is over (heavily modified store www.byvalenti.com, so not an easy task to accomplish before Christmas :no:)

PHP Version on my server is 7.3.33, which should be ok for ZC1.5.6c.

The other thing that I can think of as a "patch" of sort, is to auto-refresh the page after the message is generated (?) I know I'm making you cringe right about now, I apologize about that. With my very limited knowledge of php, I've made quite a few here cringe over the years.

Can I invite you for coffee to take a look see if you could figure out a temporary solution? No emoji for coffee but this would do :cheers:

Agreed, it's not as cringy as it sounds lately... forcing the page to reload on error is a functional line of code that could be added and if I do spend time on it I may prove it should have had one anyways :)

Quote:

---

Originally Posted by twitchtoo

Agreed, it's not as cringy as it sounds lately... forcing the page to reload on error is a functional line of code that could be added and if I do spend time on it I may prove it should have had one anyways :)

---

Ha! And here I thought my idea would be frowned upon! :D What would you need from me to get this patch sorted out?... Thanks!

Recent E-mail from square

Quote:

---

We are making a change to how our OAuth service handles the redirect URL. Currently the redirect URL configured in the Developer Dashboard only needs to match a subset of the URL passed in the authorization request.

Current State Example

If the redirect URL in the Developer Dashboard is configured to: https://example.com/

And the redirect_uri parameter in the authorization request is: https://connect.squareup.com/oauth2/...oauth-redirect

Then the request succeeds because the first part of the redirect_uri parameter matches the configured redirect URL.

After February 14th, 2022, the redirect URL sent in the authorization request must exactly match the redirect URL in the Developer Dashboard or it will error.

Exact Match Example

If the redirect_uri parameter in the authorization request is:

https://connect.squareup.com/oauth2/...oauth-redirect

Then the redirect URl in the Developer Dashboard must be configured to:

https://example.com/oauth-redirect

---

*************************

Assume as long as we have correctly set up our "Redirect URL" field on square, to https://your_store_url.com/square_handler.php including any subdirectories then all will be well.

Interesting. Have a client who uses three URLs to redirect to their main site. One of them is supposedly getting nothing but declines from Square.

Looks like a little more investigating is in order.

Quote:

---

Originally Posted by brittainmark

Recent E-mail from square
*************************

Assume as long as we have correctly set up our "Redirect URL" field on square, to https://your_store_url.com/square_handler.php including any subdirectories then all will be well.

---

The mail I received from Square reads differently. I wonder if anything has to be changed on Zen Cart code.

Current State Example
If the redirect URL in the Developer Dashboard is configured to: https://example.com/

And the redirect_uri parameter in the authorization request is: https://connect.squareup.com/oauth2/...oauth-redirect

Then the request succeeds because the first part of the redirect_uri parameter matches the configured redirect URL.

After February 14th, 2022, the redirect URL sent in the Authorization request must exactly match the redirect URL in the Developer Dashboard or it will error.

Exact Match Example
If the redirect_uri parameter in the authorization request is:
https://connect.squareup.com/oauth2/...oauth-redirect

Then the redirect URl in the Developer Dashboard must be configured to:
https://connect.squareup.com/oauth2/...oauth-redirect

Quote:

---

Originally Posted by brittainmark

Recent E-mail from square <br>
*************************<br>
<br>
Assume as long as we have correctly set up our "Redirect URL" field on square, to <a href="https://your_store_url.com/square_handler.php" target="_blank" rel="nofollow noopener">https://your_store_url.com/square_handler.php</a> including any subdirectories then all will be well.

---

The mail I received from Square reads differently. I wonder if anything has to be changed on Zen Cart code.
At the mail I received the redirect URI must match exactly. On the mail brittainmark received, it does not match exactly.

Current State Example
If the redirect URL in the Developer Dashboard is configured to: https://example.com/

And the redirect_uri parameter in the authorization request is: https://connect.squareup.com/oauth2/...oauth-redirect

Then the request succeeds because the first part of the redirect_uri parameter matches the configured redirect URL.

After February 14th, 2022, the redirect URL sent in the Authorization request must exactly match the redirect URL in the Developer Dashboard or it will error.

Exact Match Example
If the redirect_uri parameter in the authorization request is:
https://connect.squareup.com/oauth2/...oauth-redirect

Then the redirect URl in the Developer Dashboard must be configured to:
https://connect.squareup.com/oauth2/...oauth-redirect

Quote:

---

Originally Posted by mvstudio

Ha! And here I thought my idea would be frowned upon! :D What would you need from me to get this patch sorted out?... Thanks!

---

Anyone knows of a temporary fix I could implement? I need either the square module or the payment page to refresh after error. Also let me know where to donate/pay. Thank you!

By bypassing the sandbox page and going directly to the production page, I managed to get four of our six ZenCart sites to accept the application IDs and access tokens, though I kept having to experiment with the access tokens on the credentials page and the OAuth page. Some sites accepted one code, and the other sites insisted on using the other code.

I'm still having problems with two of the sites, though. One of them (www.timelesserotica.com) won't accept either access token, and when I click the button to authorize the account, it gives me an error message that says the page isn't working; it's currently unable to handle this request; http error 500.

The sixth site (www.alanachurch.com) is even more baffling. I've uploaded the square_handler.php file and the new' includes' folder multiple times and verified that they're there in the right place, but ZenCart's payment modules page refuses to show Square as a payment option.

Added to that, none of the sites will actually process a transaction. When I get to the Payment Information page, it highlights the Credit Card option, but all the fill-in fields are missing (card number, cvv number, expiry date, and postal code). www.book-oasis.com is a perfect example. I selected a book, logged in, and tried to purchase the book using a real credit card. I can't because the credit card fields are missing.

Square flatly refuses to help, and said I had to talk to you. Can someone please help me?? We're rather desperate to change these sites away from Paypal, and need to get your Square module up and running asap. Thank you!

Someone? Anyone? Please??