Square Payment Module for Zen Cart [Support Thread]

[g2ktcf]

Thanks.

Looks like you're using the standard Square module, and it appears that the issue only occurs after the order total changes (e.g. after changing the shipping method) - correct?

You are correct. I logged back in as the customer, emptied the cart. Then added a different item and went to checkout. The fields were there. Once I clicked the shipping type, the fields went away.

[todoonada]

Hello,
sometimes I get an error mail when a customer wants to pay by Square:

Error Dump: stdClass Object
(
[errors] => Array
(
[0] => stdClass Object
(
[code] => VALUE_EMPTY
[detail] => Field must not be blank
[field] => source_id
[category] => INVALID_REQUEST_ERROR
)


[1] => stdClass Object
(
[code] => VALUE_EMPTY
[detail] => Field must not be blank
[field] => idempotency_key
[category] => INVALID_REQUEST_ERROR
)


[2] => stdClass Object
(
[code] => MISSING_REQUIRED_PARAMETER
[detail] => Field must be set
[field] => amount_money
[category] => INVALID_REQUEST_ERROR
)
)
)

I can not find out what the reason is. Minutes before and after people paid successfully.
Zen Cart version 1.5.5f
Square module: 1.5
php-version 7.3.28

I got another error now.

[errors] => Array ( [0] => stdClass Object ( [code] => INVALID_ACCOUNT [detail] => Authorization error: 'INVALID_ACCOUNT' [category] => PAYMENT_METHOD_ERROR ) )

The same customer ordered the day before without any problem.

[MrPix]

That could be part of the problem; there are significant updates to the core from v1.5.7 to v1.5.7c.

If you go to https://github.com/zencart/zencart/releases and click on the 'Assets' associated with the v1.5.7b and v1.5.7c releases, you'll find zip-files that contain only the changed files (no database changes required) to make the upgrade easier. You'll need to do two updates going from v1.5.7 to v1.5.7c, first from v1.5.7 to v1.5.7b then from v1.5.7b to 1.5.7c.

Thanks for the info, new to Zencart and not had to do any updates yet.

I did try to update, but after uploading the 1.5.7>1.5.7b files (after renaming the admin folder) I just get a blank screen (admin only) so I need to work out what needs to happen to rectify that I guess before proceeding.

I'll be in touch once I've worked the update(s) out and tested it with the new files.

[g2ktcf]

Thanks.

Looks like you're using the standard Square module, and it appears that the issue only occurs after the order total changes (e.g. after changing the shipping method) - correct?

Okay, so first off, I move the site from www.example.com/test to a www.example.com as there were several smaller issues that were driving me nuts. That move solved many of the nagging issues. However, this one is now reproducible at www.wlcartistrydesign.com. I have gone into the Chrome Developer console to get the CC field info AFTER selecting the shipping method. The CC fields were visible (although not in a visually appealing way.) Here is the data in the console for the elements.


Notice that all the div IDs have no content...

When I go back and ADD an item, the fields are back...



What is going on here?

Here is the element details when the fields are visible. Completely different that the first time.

[g2ktcf]

Sorry to bomb this thread with info today. Further testing has revealed more details. I spent the last hour working on my shipping modules. I have finally decided to stay with a straight up Table Shipping model. Once I got that configured, there is only one shipping method showing and it is auto selected. Now the CC fields show with the shipping method enabled. HOWEVER, if I click on that auto selected shipping radio button, all those fields instantly disappear.

[dbltoe]

Several of our customers use their ZC as an online catalog of their products with 90+% of their business being face to face versus online.

They are traveling booths that do state fairs, rodeos, home shows, etc. Most online sales happen within days after the store owner has had their booth set up at one of those events. Someone liked an item and decided later to get it is the usual scenario behind the purchase.

Due to the pandemic, many of those have not had face to face with any customer for over a year.

One such customer got an e-mail today that there was a critical error with the module.

This is an alert from your Zen Cart store.

Your Square Payment Module access-token has expired, or cannot be refreshed automatically. Please login to your store Admin, go to the Payment Module settings, click on the Square module, and click the button to Re/Authorize your account.


Square Payments are disabled until a new valid token can be established.


The token expired on 2021-04-23T16:02:17Z

That was a long time ago. Over 90 days. But, it is not uncommon for this store to go over 90 days between orders.

If memory serves me correctly, the need for a cron job to maintain the connection to Square was eliminated with the latest version of this mod. (using 1.5)

Is that true still? Why did the error notice not arrive until a customer attempted to check out? Which system recorded the expiration? If ZC, why did the store owner not receive any notice? Debug is set to log and e-mail on failures. If the date came from Square, is there some way to have them let the store owner know when the token expires?

I realize the last is a question for the Square folks but, I need to gather more information before a fight past the script-reader who keeps telling me we need to use their website and gateway.

Is there some debug setting that will allow the token expiration to trigger the log and e-mail at the time it happens versus when someone tries to checkout later?

[dbltoe]

1.5.7c with PHP 7.2 and 1.5.6c with PHP 7.2
Both with latest version of Square and OPC

Interesting activity found while looking into the token expiration situation.

Orders placed through Guest Checkout of OPC.

Using a valid CC number and CVV, the system accepts any other information and captures the transaction.

Deliberately setting the billing address and zip code to totally bogus settings does not fail and square does the capture.

This is scary in that any card that arrives in someone's possession by any means will have three things on the card minimum. The CC number, expiration date, and the CVV number. There are other items on the card depending on the type, but those seem to be the only things Square is evaluating in order to capture.

This is leading to chargebacks as Square eventually finds out the other information on the billing address is bogus.

On at least two occasions for one shop owner, Square accepted and captured a bogus order with code in the Address Line 2 block of the billing address.

Is anyone else experiencing this? When I get gas with a credit card, I am often prompted to enter a "Valid Zip Code" for the card. With the Square module setup on these two stores, Square does a capture no matter what Zip Code is used.

When the customer tries to talk to Square about their fraud check process, they get nothing but an attempted upsell to Square's platform.

Below is the billing address for one order. The name is bogus, of course. The address and zip are legit. The phone # is from LA. The e-mail seems to be valid and is pronounced OK by several checkers.

Attachment 19659

[carlwhat]

avs validation attempts to validate the address. in general, it should be a config switch on the merchants dashboard at square (although i have not used square).

some info on avs:

https://www.signifyd.com/resources/f...-how-it-works/

the merchant has the option to decline transactions based on the avs code response. but again, i'm guessing this would be on the square dashboard.

that said, i have seen chargeback and fraudulent transactions even with a full match (avs code Y).

best.

[dbltoe]

Square has apparently "adjusted" the free fraud prevention to allow any transaction with:

1. A valid CC number
2. The CVV matching the CC number
3. An expiration date at least ?? days from the transaction date

All are They are no longer checking any other items UNLESS you subscribe to their Risk Manager.

I tried it out and it allows you to make your own rules. Alerts or Blocks. Even blocking based on the shipping information.

The alerts are long, detailed, and don't really point out what went wrong. The one I tried with a bad billing zip just said "GENERIC_DECLINE" "PAYMENT_METHOD_ERROR".

Fee (of course) is .06 per transaction BUT, with PayPal's new rates, that will still be ~$0.13 cheaper than PayPal. PayPal will be going to 2.99% and $0.491 per if you get PayPal's chargeback protection.

The unknown is the "per transaction" statement in the fee. I'm still trying to find out if they consider a block as a transaction. Don't want to pay for thieves to test their stolen cards.

[g2ktcf]

Square has apparently "adjusted" the free fraud prevention to allow any transaction with:

1. A valid CC number
2. The CVV matching the CC number
3. An expiration date at least ?? days from the transaction date

All are They are no longer checking any other items UNLESS you subscribe to their Risk Manager.

I tried it out and it allows you to make your own rules. Alerts or Blocks. Even blocking based on the shipping information.

The alerts are long, detailed, and don't really point out what went wrong. The one I tried with a bad billing zip just said "GENERIC_DECLINE" "PAYMENT_METHOD_ERROR".

Fee (of course) is .06 per transaction BUT, with PayPal's new rates, that will still be ~$0.13 cheaper than PayPal. PayPal will be going to 2.99% and $0.491 per if you get PayPal's chargeback protection.

The unknown is the "per transaction" statement in the fee. I'm still trying to find out if they consider a block as a transaction. Don't want to pay for thieves to test their stolen cards.

Please let me know what you find out. I am not liking what I am seeing on this one bit.