|
Tuesday 26 February 2008 5:05:05 am
Hello, I've got a site which uses the protx payment extension to process the payments. It used to work on another server, but since being moved from other hosts to the our server, something goes wrong.
<b>Here's what works:</b>
1) details entered on site of order and information regarding the order
2) redirection to protx and payment successfully taken
<b>What should happen</b>
protx returns details to the site, and then the site (example url below), and then the user is redirected to www.site.com/index.php/site/order/123 where 123 is an order name
<b>Failure occurs in the next step.</b>
when protx redirects back to the main site, it goes to www.site.com/index.php/site/protx/callback?crypt=some_really_long_string
<i>As far as I can tell, this is correct behaviour</i>. Given that /index.php/* redirects internally to /index.php?/* I've had to add the following code to get it to refresh so that the crypt variable is available as $_GET['CRYPT']. The following is placed as the first item of code to be run in /extension/protx/modules/protx/callback.php
// in case the url was returned in an unsuitable fashion. Don't even bother processing further:
if(!isset($_GET['crypt'])){
// replace the '?' with '&' and cause an HTTP redirect to the correct url which will work
@header("Location: ".preg_replace("/(callback)\?(crypt)/i","\\1&\\2",$_SERVER['REQUEST_URI']));
}
that gives www.site.com/index.php/site/protx/callback<b>&</b>crypt=some_really_long_string However, It's still failing, and from what I can tell it's something to do with 'simplestockcheck' (it complains sometimes of not having a correct orderid (which is determined from the decrypted crypt once looked up in the database. has anyone had experience with this and figured out a resolution. I think it must be some configuration option I'm missing
|
