Authorize.net - Invalid Notification

  • Posts: 142
  • Thank you received: 9
  • Hikaserial Standard Hikashop Business
2 weeks 6 days ago #370932

-- HikaShop version -- : 6.4.0
-- Joomla version -- : 5.4.3
-- PHP version -- : 8.2.30
-- Browser(s) name and version -- : Firefox 148.0.2
-- Error-message(debug-mod must be tuned on) -- : Invalid notification

On occasion we have a credit card transaction that is authorized via Authorize.net SIM, but shows up as declined in the backend. For the most recent case of this, the customer reported that they got an "Invalid notification" error when they made the payment. We were on Business 6.1.0 at the time and have just upgraded to 6.4.0. Maybe that issue has been corrected since 6.1.0, but I wanted to report the issue just in case it hasn't. We've seen this issue for some time with the Authorize.net SIM, but the vast majority of transactions don't have this issue.

Please Log in or Create an account to join the conversation.

  • Posts: 85428
  • Thank you received: 13965
  • MODERATOR
2 weeks 6 days ago #370937

Hi,

The "Invalid notification" error means that the hash validation between Authorize.net and HikaShop failed. The plugin compares a hash calculated from the notification data with the hash sent by Authorize.net to verify authenticity.

Since you mentioned that most transactions work fine and this is intermittent, it is likely related to special characters in the customer's name or address. The SHA-512 signature hash includes customer data fields (name, address, city, state, zip, etc.) and if any character is encoded differently between what Authorize.net sends and what PHP receives, the hash will not match.

Could you check: do you have a Signature Key configured in the plugin settings? This is different from the MD5 Hash field. Authorize.net deprecated the MD5 method back in 2019, so you should be using the Signature Key (SHA-512) instead. You can find/generate your Signature Key in your Authorize.net merchant account under Account > Settings > Security Settings > General Security Settings > API Credentials & Keys.

Also, could you check if the affected transactions have something in common? For example, customers with accented characters in their names, special characters in their addresses, or non-US addresses? That would help confirm whether this is a character encoding issue in the hash calculation.

If you have debug mode enabled in the payment method settings, you should also be able to get more information about the problem in the "Payment log file" under the HikaShop configuration page. The details there will help us pinpoint the exact cause.

Please Log in or Create an account to join the conversation.

  • Posts: 142
  • Thank you received: 9
  • Hikaserial Standard Hikashop Business
2 weeks 5 days ago #370951

There is a Authorize Signature Key in use. Should I clear out the MD5 Hash box?

For the recent customer with the problem, there was no special characters with the customer's info or address. I did not make note of other customers with that issue. I will if that happens in the future.

I'll enable the payment debug feature.

Please Log in or Create an account to join the conversation.

  • Posts: 85428
  • Thank you received: 13965
  • MODERATOR
2 weeks 5 days ago #370954

Hi,

You don't need to clear out the MD5 Hash box, but you can if you want. It won't change anything.
Report to us once you get the issue again with the debug turned on so that we can check the payment log file.

Please Log in or Create an account to join the conversation.

  • Posts: 142
  • Thank you received: 9
  • Hikaserial Standard Hikashop Business
2 weeks 18 hours ago #371043

We just had that issue happen again.

When I scan through the payment log, I notice unprintable characters in the phone number for the shipping and billing address. See attached screenshot. This customer had 3 invalid transactions. All 3 had this telephone number issue. This was for a recently created user account.

I will use your contact form to submit login credentials and the affected order#'s, if you need to check on this firsthand.

Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 85428
  • Thank you received: 13965
  • MODERATOR
2 weeks 5 hours ago #371045

Hi,

Thank you for enabling debug and providing the details. The screenshot confirms the issue: the customer's phone number contains invisible Unicode control characters. Specifically, it has a LEFT-TO-RIGHT EMBEDDING character (U+202A) at the beginning and a POP DIRECTIONAL FORMATTING character (U+202C) at the end. These are invisible in normal display but they are included in the data sent to Authorize.net, and they cause the SHA-512 hash to not match.

This typically happens when a customer copies and pastes their phone number from a source that includes bidirectional text formatting (for example, from certain mobile apps, contacts, or web pages).

To fix this customer's account, edit their billing and shipping addresses in HikaShop and clear the phone number field, then re-type it manually. That will remove the hidden characters.

To prevent this from happening in the future, you can add a regex validation to the phone field. Go to HikaShop > Display > Custom fields, edit the "address_telephone" field, and in the Options tab, set the regex to:

^[0-9\s\+\-\.\(\)]+$

This will only allow numbers, spaces, plus signs, dashes, dots, and parentheses in the phone number, and will reject any invisible characters or letters.

Please Log in or Create an account to join the conversation.

  • Posts: 142
  • Thank you received: 9
  • Hikaserial Standard Hikashop Business
1 week 5 days ago #371060

The problem that I see with the regex solution is that the customer will get an error message about invalid data entered. Yet they won't be able to see those control characters to see what to fix.

There are other accounts that are affected with this issue. We didn't note every customer that had this issue. So, next time they go to place an order with us, they will run into the same problem. It would seem the best solution would be for HikaShop to filter out any control characters when retrieving any customer entered data (first name, last name, address, telephone#, etc.) from the dBase with respect to the credit card transaction process.

Please Log in or Create an account to join the conversation.

  • Posts: 85428
  • Thank you received: 13965
  • MODERATOR
1 week 5 days ago #371062

Hi,

We'll be adding a patch in the Authorize.net payment plugin with the next release for this.

However, note that the SIM API is legacy. Authorize.net will discontinue it completely sooner or later. I would recommend looking into migrating to www.hikashop.com/marketplace/product/150...e-js-by-obsidev.html

Please Log in or Create an account to join the conversation.

  • Posts: 142
  • Thank you received: 9
  • Hikaserial Standard Hikashop Business
1 week 4 days ago #371082

nicolas wrote: We'll be adding a patch in the Authorize.net payment plugin with the next release for this.

So, just wait for the next release of HikaShop or is that plugin released separately?

Please Log in or Create an account to join the conversation.

  • Posts: 85428
  • Thank you received: 13965
  • MODERATOR
1 week 4 days ago #371083

The plugin is included in HikaShop. So it will be updated automatically when you update HikaShop.

The following user(s) said Thank You: gpraceman

Please Log in or Create an account to join the conversation.

Time to create page: 0.064 seconds
Powered by Kunena Forum