Protx Confirmation Email

Hey all,

A colleague of mine is having trouble with his protx form and I'm just wondering if you know whether or not this is a local or protx system problem.

Put simply, sometimes zen cart doesnt send him confirmation emails once someone makes an order. Thats what makes this problem all the more annoying.

Basically, per order, he's supposed to recieve an email from protx, which he always does and an email from zen cart which he sometimes does.

According to the customers in question, they aren't taken to the confirmation page, which leads them to put an order through several times. Not too pleasant!

Can anyone help out at all? It's a worry!

Thanks in advance,
Tom

Hi,

thomasharding:

Can anyone help out at all? It's a worry!

That is a serious problem.

Unfortunately the only known solution is to move servers as it is a problem with the server not responding to Protx's callback for some reason.

I really don't know of any other way to fix this and if he's serious about his business he'll upgrade to a better host or server.

Sorry I can't be of more help than that! :(

All the best...

Conor
Ceon

conor:

Hi,

That is a serious problem.

Unfortunately the only known solution is to move servers as it is a problem with the server not responding to Protx's callback for some reason.

I really don't know of any other way to fix this and if he's serious about his business he'll upgrade to a better host or server.

Sorry I can't be of more help than that! :(

All the best...

Conor
Ceon

Thanks for the swift reply, Conor.

Luckily, we have another server available right now :clap:

Humph, actually it was already on that server.

This is really really strange. I've done like 50 test purchases with absolutely no error at all.

The debug mode brings up the correct address to be sent as well. I really can't understand how the customers are going through protx and then just going back to zen cart without any confirmation page.

Would it have anything to do with the PHP version (4.3)? Somehow I can't see it being the problem but you never know :yuck:.

Thanks again!

Hi Thomas,

thomasharding:

This is really really strange. I've done like 50 test purchases with absolutely no error at all.

That's what I was saying... it's completely random and server related. You could do 1000 tests and it works fine because the server is performing properly but the only thing that can cause this error is the server not responding... so if that happens more than once or twice it isn't a reliable server and therefore the only known solution is to move to a different server or webhost.

I wish I had better news but I've seen this several times and there's no programmatical reason or fix, it's a hardware/network issue.

All the best...

Conor

conor:

Hi Thomas,

That's what I was saying... it's completely random and server related. You could do 1000 tests and it works fine because the server is performing properly but the only thing that can cause this error is the server not responding... so if that happens more than once or twice it isn't a reliable server and therefore the only known solution is to move to a different server or webhost.

I wish I had better news but I've seen this several times and there's no programmatical reason or fix, it's a hardware/network issue.

All the best...

Conor

Alrighty, thanks man.

Your advice is much appreciated!!

Thats a bit of a worry actually now since the company I work for recently migrated all their clients to this new server.

Im looking forward to breaking that news to my boss!

Thanks again Conor!

Tom

Hello

I can't be 100% sure but I have come across this problem with other shops I've worked on (non Zen Cart).

The cause of the problem is that the crypt value returned from Protx isn't correctly decrypted, this means that the confirmation emails aren't sent.

The solution I've used elsewhere is to add the following line towards the top of the script that processes the callback from Protx

$crypt = str_replace(" ", "+", $_REQUEST['crypt']);

So, any spaces in the crypt are replaced with a + rather than %20

This seemed to cure the problem elsewhere.

Chris

Hi,

shippingmanager:

The solution I've used elsewhere is to add the following line towards the top of the script that processes the callback from Protx

$crypt = str_replace(" ", "+", $_REQUEST['crypt']);

Thanks but the module already uses the following code in a helper method:

// Fix plus/space conversion issue
$scrambled = str_replace(" ", "+", $scrambled);
```where $scrambled is the value of $_GET['crypt']

I wish it was a simple problem with the program logic but it does appear to be a server/network issue. The only way to identify otherwise would be to record every transaction going out and the response coming back.

However, the module displays an error message if any error occurs... if the data can't be decoded the user is alerted to the problem and told to contact the shop immediately (via a handy link to the contact us page).

(I like to cover all situations possible in any software I write ;) ).

Thanks very much for the input though. As I said above, I only wish it had been a magic solution but I'm afraid it looks like server/network problems... something no-one wants to hear but a warning which must be heeded in this case! :)

All the best...

Conor
[Ceon](http://ceon.net)

Hey Conor,

I don't want to undermine you cause you've been such a helpful bloke, but I believe I've found the root of this problem - IE 6!

When I test the module in Firefox, I return to the confirmation screen on zen cart. All is well there.

When i test it in IE6, I get the following message when I return -

Whoops! Sorry, but you are not allowed to perform the action requested.
You are still logged in to your account and may continue shopping. Please choose a destination from a menu.

Now I've tested the module on that browser on 2 installations which appear to be hosted seperately (one with php5 and the other with php4) and both times the message appears.

If it helps, the address in the bar is (in the php5):

index.php?main_page=time_out&zenid=trij7aobcr3ch3kh8aq1p3v0s3&crypt=GC5bDh9GBj0WKlIfVFtKeH98DF5CAmRoZHAbMggYHCEgLBM8IGcGPRwhCwFaUzl9D3MCXl0MFHwWaHBMLylVcHh7B0cxdRN3FHYHOC8pSHgzbWYeEUAnNmgKfVw6Hhk8OzhxDwRVOylodQZKWUpCaBojUEoxQSYtOjdfCQgeEScga0ILAxQBMDYmUwkaDA0kYG1hEjFBJi0bKgtJX1NNcXl9EysmZxETZ3hlPyo

Not sure what the one in php4 was, but I remember it being a jumble of letters.

Sorry to keep pestering you with this, but I take back my original agreement with you about it being a server problem :P

Again, thanks for all your help - it goes much appreciated.

Thanks

Tom

EDIT:
Yeah, actually I'm getting problems with IE7 too. Quite similar as well.

No doubt that you've tested this in both browsers, so I can only blame my hacked-to-pieces zen cart we own right now.

Do you have any idea what would be the reason for this, haha?

Sorry again.

Thanks

Hi Thomas,

thomasharding:

No doubt that you've tested this in both browsers, so I can only blame my hacked-to-pieces zen cart we own right now.

Do you have any idea what would be the reason for this, haha?

I tried to put through an order in IE to see if I could see what you are seeing and it went through fine.

Please delete order #6 and VOID my card before 12 tonight (otherwise it will cost you to refund! ;) ).

Unfortunately the issue you are having with IE - "Session Timeout" - is probably a cookie blocking problem, with a firewall or your settings or something. It's not likely to be the cause of the inability of Zen Cart to create the order, it's just unlikely that anyone would not be able to put their card details in on time before the session times out.

I wish I could be of more help but I really don't know what else to say. :|

All the best...

Conor

I am having a problem with this too.

I have checked in the Protx admin and the problem seems to be caused by a zenid being added to the success/failure urls. This would appear to prevent Protx Form sending the authorisation signal back to the Zen Cart website.

Any suggestions about how to prevent the zenid being added to the url? I'm pretty sure this will solve the problem.

Hi,

keiran:

I am having a problem with this too.

I don't think you are, as adding the zenid wasn't the problem and no one has ever reported it being a problem before you!

keiran:

I have checked in the Protx admin and the problem seems to be caused by a zenid being added to the success/failure urls. This would appear to prevent Protx Form sending the authorisation signal back to the Zen Cart website.

I don't understand what you mean here... how could you possibly determine what was causing a failure by looking at the Protx admin? It simply tells you whether something's failed or not, but not how!

keiran:

Any suggestions about how to prevent the zenid being added to the url? I'm pretty sure this will solve the problem.

You could change line 515 from:

$plain .= "SuccessURL=" . zen_href_link(FILENAME_CHECKOUT_PROCESS, '', 'SSL', true) . '&';

to

$plain .= "SuccessURL=" . zen_href_link(FILENAME_CHECKOUT_PROCESS, '', 'SSL', false) . '&';

but I think that all orders would fail then... I'm not sure but I think that without the zenid Zen Cart can't tell that the call is coming from a logged in user so it would redirect to the login page instead of completing the order.

All the best...

Conor

Hi,

conor:

I don't understand what you mean here... how could you possibly determine what was causing a failure by looking at the Protx admin? It simply tells you whether something's failed or not, but not how!

Okay, I now see what you are saying.. URIs with the zenid fail, ones without it don't.

The module requests that Zen Cart adds the ID if necessary, and everything works fine here so I can't test if Zen Cart is failing to parse the ID or something.

I'm afraid I just don't know what's going on here and without being able to replicate the problem don't know what I can do other than to ask you to get back to me with some feedback about what happens if you change the "true" to "false" for the zen_href_link calls for the successurl and failureurl.

Thanks!

All the best...

Conor