How to migrate from Authorize.net SIM to Authorize JS?

-- url of the page with the problem -- : grandprix-software-central.com/
-- HikaShop version -- : 6.4.0
-- Joomla version -- : 6.1.0
-- PHP version -- : 8.4
-- Browser(s) name and version -- : Firefox 149.0.2

I just purchased the Authorize JS plugin but am unsure how to migrate from the current plugin. I have installed and enabled the plugin. Just change API to DPM instead of SIM?

Hi,

It's a new plugin so you can't edit your existing payment method based on the old plugin to configure it.
Once installed, go to the System>Payment methods menu. There, click on the "new" button. Then, select the Authorize accept JS payment plugin and configure it.
That will add another payment method to your checkout. That way, you can test it on the side of your authorize SIM payment method, and switch between them with the published toggles.

Clicking on the Help button yields "Documentation currently not available : payment-authorizejs-form". I would think that a paid plugin would come with help documentation.

What to use for Cancel url and Return url? Neither of those were part of the previous plugin.

How is this PCI-DSS compliant when the customer enters their credit card information into our web page?

I tried a transaction and got an error "E00027 - The transaction was unsuccessful." No order even shows up in our list of orders nor is there a transaction on the Authorize.net website.

Hi,

The Authorize JS plugin is developed by a third party developer and sold on our website. It's up to him to provide documentation for his plugin.

The cancel and return URL can be left empty.

While the credit card information is indeed entered on your website page, it doesn't go to your server. The javascript of Authorize in the browser of the user picks it up and directly sends it to Authorize's servers. Your website's server only sees a corresponding token, which it can then use when the order is being created to process the payment with Authorize. That's how it can be compliant with PCI-DSS. That's a common way of processing payments with credit cards nowadays.

Activate the debug setting of the payment method. Then, try again. Then, look at the "payment log file" of the HikaShop configuration:
www.hikashop.com/support/documentation/5...nfig.html#main_files
It should hopefully provide information on what's going on.

Regarding the "E00027 - The transaction was unsuccessful.", that's the first time it is getting reported by someone on our end. However, searching online, I can see that many people got it in the past but it's not clear what the problem could be:
www.drupal.org/project/commerce_authnet/issues/3421220

nicolas wrote: The Authorize JS plugin is developed by a third party developer and sold on our website. It's up to him to provide documentation for his plugin.

You guys need to do a better job of vetting the plugins that you are selling on your website. No excuse for the author to not to include help documentation, especially on a paid product. This is the 2nd plugin that I have bought from your company and both did not work initially nor have help documentation. These plugins have been a big disappointment.

nicolas wrote: Activate the debug setting of the payment method. Then, try again. Then, look at the "payment log file" of the HikaShop configuration:
www.hikashop.com/support/documentation/5...nfig.html#main_files
It should hopefully provide information on what's going on.

I got this from the payment log. Looks to be complaining about phone number being required.

Found this on one website:

'E00027' is thrown up irrespective of which filter has vetoed the payment (it is also thrown when form fields are marked as required), but Authorize.Net will send you an email with details on which filter was triggered. You can also check with the Authorize.Net web interface for specifics and reports on which filter stopped the payment from going through at Reports >> Transaction Detail Reports or Search >> Suspicious/Unsettled transactions.

Not sure why the phone number isn't being transmitted for the transaction. We do require a phone number when the customer enters an address in HikaShop, so that information is available. That field is flagged as required in the Authorize.net console. Even when I change that to optional, the transaction still fails ('E00027' and 'Phone is required.' messages still).

Hi,

If you have the debug setting of the payment method activated, just before the log of the _sendRequest you should also have all the data sent by the plugin to Authorize.net
There, you should normally find "x_phone" with the phone number you entered in the billing address associated with the order.

Since Authorize.net is complaining about this, there must be a problem with that parameter.

Phone number is not being sent at all.

Extracted from "createTransactionRequest" with redactions.

Hello,

The "Phone is required" error confirms that your Authorize.net account is configured to require a phone number on the billing address, which happens when you turn on that check in the AVS / Fraud settings. The Authorize JS plugin currently does not forward the billing phone number to Authorize.net (I was looking at the old Authorize.net plugin in HikaShop), so the transaction is rejected as soon as that requirement is enabled on the Authorize.net side.

Here is a small patch you can apply to the plugin file on your server. Open this file via FTP:

plugins/hikashoppayment/authorizejs/authorizejs.php

Search for the block that ends with: Right after those two lines, add: Save the file, make sure the customer address you use for the test has a phone number filled in, and try a new transaction. We have also forwarded the fix to the developer of the plugin so that the next update includes it.

That fix worked.

While I was able to make phone number optional in the manual payment form of the Authorize.net console, that did not fix the issue. It seems that the payment interface requires it, so it wasn't until I applied this fix that the issue was resolved.

However, the invoice# is not being transmitted with the transaction. We use this to help match up a credit card transaction in the Authorize.net console with an order. It is showing up blank in the console for these orders. Checking the payment log, it is not being sent with the transaction.

Hi,

To send the order number as invoice number to Authorize.net, open the file plugins/hikashoppayment/authorizejs/authorizejs.php and find these two lines in the processPaymentWithToken function: Add the following code before them : This sends the HikaShop order number as the invoice number in Authorize.net transactions (truncated to 20 characters, which is the field limit).

I'll bring this up to the developer too.

Unfortunately, that didn't work. No order# showed up in the most recent order.

It is labeled as "Invoice number" in the Authorize.net console, if that matters.

invoiceNumber shows as "" in the payment log.

Hi,

The issue is that the onBeforeOrderCreate event runs before the order is persisted in the database, so at that point order_id and order_number are both still empty, which is why the invoiceNumber you see in the request is blank.

In the file plugins/hikashoppayment/authorizejs/authorizejs.php, replace the line you previously added: with: This peeks at the next AUTO_INCREMENT value of the order table to predict the order_id the save will assign, then runs it through hikashop_encode so the resulting order_number matches whatever format you have configured in HikaShop.

A small caveat is that on concurrent checkouts the prediction could be off by one in rare cases.

Sadly, that did not work. Now the order number is showing as "order":[]. Before it was showing as "order":{"invoiceNumber":""}. It should have order# be 26-051547 for this particular order.

Here's what I have in the authorizejs.php file:

Hi,

My previous query used INFORMATION_SCHEMA which some shared hostings can restrict, so it returned nothing and the invoice number would not be set at all in that case (which is why the "order" object came through empty in the JSON).

Let's switch to a plain SELECT on the order table instead. In the file plugins/hikashoppayment/authorizejs/authorizejs.php, replace this line: with: This runs against the hikashop_order table directly so it doesn't need any special database permissions, and the rest of the logic (encoding through hikashop_encode so the number matches your configured format) stays the same.

This should work properly.

That got it working. It is now showing up in the log and on the Authorize.net console. Thanks!

A drawback I see for Authorize JS, over the Authorize SIM plugin, is that we no longer get any notification if a customer has a declined transaction. We can get some customers that have multiple declined transactions. When that happens, we will contact them and let them know the problem. Most often it is a mismatch with their billing address and the address that the credit card company has on file. We do add a message about that in the payment method description (see screenshot), but some customers just don't read when they are in a rush.

Can the plugin be modified to add an option that, when selected, will email the admin when there is a declined transaction?

Also, a bit annoying of an aesthetic issue, is that for the credit card entry fields, the labels are not centered vertically on the text boxes.

Hello,

Thank you for your feedback.
So you want a new setting so the plugin will send you (admin) an email if there is a "decline"?

Regards,

Jerome wrote: Hello,
Thank you for your feedback.
So you want a new setting so the plugin will send you (admin) an email if there is a "decline"?

Correct