First Data GGe4 Configuration

Good afternoon. I am using Joomla 3.4.8 and HikaShop Essential 2.6.1 with version 2.6.1 of the Authorize.net plugin.

I've got everything working with the firstdata payment pages except the relay response url ...

What I'm using is : www.websitename.com/index.php?option=com...pl=component&lang=en

(obviously I've changed 'websitename' to my websites name)

What happens when it 'returns' back to the website is just a white screen. When I tried turning on error reporting in Joomla I don't get any errors.

Any idea what is wrong with my relay response url? Note that I'm using SEF urls with rewriting if that makes a difference.

Hello and sorry for the late reply,

If you want more information about your issue, the solution will probably be to :
- Check that the debug mode option is ON through your Authorize.net payment configuration page
- Test it again
- Check your Payment log file content through "Hikashop->System->Configuration->Main" by using the "See the report" button of your Payment log file option.

By doing it you'll find which value are returned from the payment platform and understand why you are redirected through a black page and not a "thank you" page.

Thanks for getting back to me. I eventually got this to resolve on my own through trial and error.

And its broken again. When I went to go live it started giving me a "Invalid Notification" error.

I looked in the payment log and it says bad MD5 ... I double checked that I'm using the right MD5 hash ... I'm using the 'response key' that is in my payeezy account on the 'security' page. Which is what other people here are saying I should use.

Just to be extra thorough ... I used the payeezy hash calculator and input the values that the authorize.net plugin was sending to payeezy ... and the hash their calculator generates matches the hash that is being sent by the authorize.net plugin ... so ...

I'm very confused as to what could be going on. Everything SEEMS correct.

I did note that the MD5 hash that is in the payment log does not match the x_fp_hash that the authorize.net plugin is sending out ... should it?

Hi,

The MD5 hash in the payment log is for the payment notification security, not for the redirect to the payment gateway.
So it's normal that they are different as they are for two different thing.

If the x_fp_hash added to the redirection form is correct but that the payment gateway says "Invalid Notification" when you get redirected to it, it's highly probable that the MD5 in the merchant account doesn't match.

The error "Invalid Notification" is quite vague. Could you contact the support of Payeezy so that they could check on their end what's wrong with the parameters sent to the payeezy by the authorize.net payment plugin ?

I've contacted Payeezy and we'll see. I'm not particularly hopeful - the last time I asked them a question, they simply told me that if I have any questions I should read the documentation. Which I had already done and not found my answer - otherwise I wouldn't have contacted them!

As far as I can tell they don't have any debug information or features within their setup - which makes it very difficult to troubleshoot issues while integrating. Maybe I've missed something though ... honestly, I have not been pleased with their interface or their documentation ... its hard to find what your looking for and much of it seems undocumented ... particularly when it comes to shopping cart integration.

So ... assuming that they don't end up being very helpful ... when the payeezy payment pages send the hash to hikashop as part of the relay response ... is the hash that Hikashop receives from Payeezy recorded anywhere in the payment logs? If so, what is it called?

I think if I knew what payeezy was sending to HIka, I could figure out where the issue is.

Hi,

If the debug option of the payment method is activated, all the data received by HikaShop and the calculated hash are added in the payment log available in the Files section of the HikaShop configuration. An error message is also displayed in there if the relay response cannot be processed. And normally a notification email is also sent to you with the error in that case.

So, I initially got a message from Payeezy support telling me they were forwarding me to tech support ... but I have not heard from tech support at all. So its not looking like we will get much in the way of support from them.

I have my debug set on ... and I have a whole mess of information recorded by the log ... but I don't know what is relevant to this issue and what isn't. Do you have any idea what name the MD5 hash sent by payeezy would be recorded as?

Alternately, would it be easier if I simply posted the debug log?

Thank you for your help.

I was actually able to solve this myself.

Just a couple of notes :

1. The 'invalid notification' error that you asked me to ask payeezy about ... actually came from the hikashop authorize.net payment plugin. After I dug into the authorize.net payment plugin code, I found it where hikashop processes the md5 code. When that fails the message hikashop gives is 'invalid notification'.

2. The issue is that the authorize.net payment plugin and payeezy use different MD5 processes. I was able to use code from an older version of the hikashop payment plugin to update the current one to work with Payeezy.

My guess is that authorize.net has changed how they do their MD5 hash ... and Payeezy hasn't adjusted to match the current Authorize.net method ... since the Hikashop authorize.net plugin is built to work with authorize.net and not payeezy ... the code was off. However, the old process still works. So there you go.

If there is interest, I can upload my modified authorize.net plugin that works with payeezy.

Thanks for your help.

Hi,

Yes I'm curious. What was the change you had to make ?

I am having the same EXACT issue and I have gone thru the same EXACT steps as totter3. The same resposne for Payeezy, the URL being sent from the Hikashop plugin is appending "&lang=en&Itemid=xxx" (the xxx being the product id of the order. So with that appended, the url does not match and there is no place for the return to go, so it just ends up a blank page and the "Invlaid Notification" Something is getting lost in the translation and the Plugin is NOT using the correct URL for the rutrn page.

Can SOMEONE tell me how to fix this?

Just so you know, the 'itemid' in the relay url has NOTHING to do with hikashop or the product id ... its an artifact of the joomla menu system. Its how Joomla keeps track of which menu item the user is currently accessing so that multiple pages within a given application can share certain things like modules. So when Hikashop sends the relay url to Payeezy the itemid will remain the same.

Assuming you've set up the relay url in Payeezy, if there was a problem with it then you'd get a message from payeezy when Joomla went to the payment pages saying that relay url sent from joomla did not match the relay url you have set in payeezy. The way to solve that is to copy the url that is in the email payeezy sent you and then put that into the relay url in payeezy.

As for the 'invalid notification' ... here is my version of the authorize.net plugin so it should solve the relay issue for you. You'll need to upload it to the plugins/hikashoppayment/authorize directory of your joomla install. I recommend backing up the original authorize.php file first ... in case for some reason this plugin causes a problem, you can at least return to what your originally had.

As to why the invalid notification happens in the first place ... the hash is different in the current version of authorize.net plugin versus the payeezy hash. One of the biggest differences is that the authorize.net plugin changes the variable string to all caps before running the md5 hash on it and payeezy does not. That change that alone was not enough, so I made several other tweaks to the information that was sent to payeezy that was used to create the hashed string ... I based my changes on an older version of the authorize.net plugin that still worked. I'm not entirely certain every change I made was necessary ... the project I was using this for was overbudget on time so I just needed to get it to work. I wasn't testing the affect of every tweak.

ALSO note ... in talking to Payeezy I was told that Payeezy does NOT have any kind of debug information or any way to get debug information on transactions or what happens during transactions.

Thanks!! That solved almost all of the problems. Getting back to the website works, BUT it loses all of the template style and layout. So there is still a "gotcha" in the return URL to figure out. It has something to do with the SEF formation of the URLS in Joomla and the detail needed by the response URL. I will have to tinker with that some.
But I am ahead of where I was an hour ago.

Backagain. After testing your plugin, there are a couple of issues and I thought you might be able to tell me where to look to correct them. I am using the demo account at First Data.
1. When I turn on "Allow payment notifications from %s" the checkout fails and I get a form submission error email from First Data with the error "x_relay_url : Invalid x_relay_url. Must be the same as configured for the payment page". Ifm I turn it off, the error goes away and the transaction completes, EXCEPT:

2. When the transaction completes, and I get to the Thank You page and click the link to return, the order shows created but it is not confirmed. It appears that nothing is coming back that tells Hikashop to confirm the order. I get all of the completion emails that show the card was authorized and payment made. I see in your plug in at line 289 that you are setting a confirmation function if the api is AIM, but I don't find anything that would set the confirmation if we are using SIM. In the default plugin there are some functions to deal with aim, sim and dpm. Since we are using the SIM api, it looks like your plugin is not returning a payment confirmation for that API. Any ideas where I can add it? I am not a real good coder, especially hacking someone elses work.

You need the "Allow payment notifications from %s" on. You just need to configure the x_relay_url.

To do that - look at the form submission error email you are getting and find the 'x_relay_url' in the list. Then copy just the URL.

Now, go to your Payeezy Demo Account and go to the payment pages. The 4th page is "Receipt Page". Go to that.

Halfway down the page is the label "Authorize.Net Protocol - Relay Response Settings" ...

Make sure the "Allow Relay Response" is checked.

Now, paste the url you got from the error submission email into the "Relay Response" field.

Make sure you hit the 'save changes' button at the bottom of the page before continuing.

Their you go. Your relay response url is configured.

This may not entirely solve your problem, however. Unfortunately, Payeezy wants the url to be THAT and ONLY THAT ... but a normal website is dynamic and can handle a lot of different url variations ... for instance someone might access your site from www.mydomain.com or simply mydomain.com ... if they do that, that will send a different url to payeezy and it will be rejected.

I had to solve it by modifying my authorize.php plugin so that the relay url it sends isn't dynamically generated but is the single url no matter what. I don't really know of a better solution.

Using payeezy is not a simple thing and honestly I recommend not using it if at all possible. Generally the best practice is to stick with a payment processor that has a payment plugin designed specifically for it whenever possible.

BTW - the answer to your x_relay_url question can be found in earlier posts on this thread, so I would recommend reading the whole thread. You probably can find a lot of your questions answered there.

Good luck.

I have all of that setup and as long as "Allow payment notifications from %s" is off, things work fine, EXCEPT that the payment status is not getting back to hikashop to "confirm" the payment and change the order status. As soon as I turn it on, I get the relay url error. I change nothing else, so if the relay urls were not matching I would not be able to get to the payment page. My guess is that in need that swithc set to YES in order for that to happen
My relay url in the plugin and in Payeezy are identical, so what is the allow payment notifications setting have to do with that?
With it turned on, what is the plugin sending to Payeezy that it does not like? How can I find that information?
I would prefer not to use the Payeezy option either, but my client is set on using it. Their rates are significantly better than anyone else.
Anyway, help with figuring out getting the order to update would be the biggest help.
Thanks again!

ok. more trial and error! again, using your plug in, I started getting the error message on return to the site the the payeezy hash and the expect hash were not matching. talked to FD support and they said that the hashes did not match because i was not passing a currency code. ok, I overrode the x_currency_code in the plugin to USD. problem still there, then I reread some other posts here (there are a LOT) and found that I should use the response key from FD and NOT the md5 hash, so I tried that. The invalid notification/mismatched has seems to go away BUT now when I click the link to return to the website ( the relay response URL)
I now just get a blank page. The order HAS been confirmed, so the details are now being passed, just need to figure out the blank paqe issue. Any ideas?

Hi,

The default version of the plugin strtoupper the generated hash but compare it with a case insensitive function so between by default and the code in the modified version provided by totter3, it's actually the same check.
The currency code is already sent to the server with the default version of the plugin. And the currency is used in the hash calculation too, so it should work fine.

Also, Authorize.net doesn't have a "response key" but a "md5 hash". The name is different, but it's used in the same way. So you can just enter your response key in the md5 hash field.

Regarding your last issue, I see that there is an option "Validate Relay Response HTML" in Payeezy to handle the HTML response from your website after the relay response. So it might be linked to that.
Try to switch that setting.