error message from payment module

Hi Guys,
I’ve had a long running problem I’m hoping you can give me some insight into. I’ve been using paypoint on 2 sites for years and as far as I can tell they are both identical. Both on the same server and both running 139h, all the files in the mod compare perfectly and the host and paypoint can’t find anything different between the 2 sites except one works fine and the other fails and returns the customer to the last page of the checkout with a generic error message and doesn’t send them to the confirmation page. The payment is taken at paypoint but no emails are sent to the customer.
Anyway apart from any insight I really need to know the files that are involved in the call back process.
Thanks as all ways

Follow up
Got this from a very helpful tech at paypoint

It might be useful to list the callback urls. On Cuepower it’s:
http://www.cuepower.co.uk/paypointnet_callback.php?main_page=checkout_process;http://www.cuepower.co.uk/paypointnet_callback.php?main_page=checkout_payment&payment_error=paypointnet_hosted

Dartspower:

https://www.dartspower.co.uk/paypointnet_callback.php?main_page=checkout_process;https://www.dartspower.co.uk/paypointnet_callback.php?main_page=checkout_payment&payment_error=paypointnet_hosted

So it looks like they’re both following the same protocol. The success and failure options have both been specified (separated by a semi-colon) – my point is that on the cuepower website, it’s returning to the failure url (…&[payment_error=paypointnet_hosted ).

I'd be very grateful for any insight

Does the customer get sent to paypoint at all? Or just to an error before being sent over to their site?

How does the Zen Cart code differ between the two sites? http://www.zen-cart.com/wiki/index.php/Troubleshoot_-_Diagnosing_Obscure_Issues

Hi, well that’s really my problem, all the mod files compare completely, I’ve had the host check every error log and security log and php.ini files at their end. I have checked the confirmation pages and they are the same both sites have all the same mods and zencart version so I’m thinking I have corrupted or a file has been corrupted at some point but I have no idea where to look.
But because the callback is the obvious place I was hoping to find a file or set of files I could compare to the other site. I guess it could be at any point in the checkout but I have no ideas where to start.

I really do need to just compare every template file don’t I.
Bad times

I wouldn't limit it to just template files.

Remember, using a tool like WinMerge makes the task very fast and easy.

DrByte:

Does the customer get sent to paypoint at all? Or just to an error before being sent over to their site?
I didn't see an answer to this question.

If it's happening on their way back from the Paypoint site, then the module might be triggering Zen Cart's spam detection code. More detail required to determine for sure, including what the URL looks like in the browser address bar when the problem occurs.

Downloaded winmerge (was using Beyond compare 2). Did a fantastic job because it compares all the files at once, fantastic. But no help couldn’t find anything out of place.
The returned URL is-
https://www.cuepower.co.uk/index.php?main_page=checkout_payment&zenid=ID-REMOVED&payment_error=paypointnet_hosted
the emails are odd, we get one email from paypoint but the customer doesn’t but obviously nothing from the site.
I’m back to zero ideas

Looks like your PayPoint Digest setting is wrong in your Admin->Modules->Payment settings.

The Digest password was checked by them.
Would that not show a fault at the paypoint end?

Based on the URL you said is showing in the address bar when the problem occurs, it indicates that the hash that's regenerated using the digest/key isn't matching the expected hash and thus the validation of the transaction (on your store's end, to prevent fraudulent spoofing of approvals) is failing. Hence your store is refusing to complete the transaction.
Perhaps their tech support people need to do some specific debugging and troubleshooting in the code used in the after_process() function, on your store that's encountering these problems.

thanks for the info,
I got that before...
It is going to make me crazy...

After some double or treble checking they found a letter not capitalized it the hash and that’s fixed it.
Thanks very much for your help as all ways

whew, glad they found the problem