Jump to content



Photo

SagePay Server Integration - RESOLVED


  • Please log in to reply
23 replies to this topic

#1   TonyBunney

TonyBunney
  • Members
  • 33 posts
  • Real Name:Tony Bunney

Posted 11 December 2010 - 11:24

I thought that I would just give an insight into my problematic integration of SagePay Server into an OsCommerce site.
I will not bore you with all of the details, after all it has taken me 5 days to nail this sucker down.
My problem was (Simulator and test servers) that when a user (me in this case) supplied the credit card details and clicked "Proceed" I was receiving the following message:-
HTTP Status Code: 500
HTTP Status Message: The request was unsuccessful due to an unexpected condition encountered by the server.
Error Code : 5006
Error Description : Unable to redirect to Vendor's web site. The Vendor failed to provide a RedirectionURL.

What I was expecting was that the order was processed by the OsCommerce Software and the user taken to the checkout_success.php screen.
What I eventually found was that although the simulator was telling me that my RedirectURL was
http://www.mydomain....k=SERVER
=12175a21d73728a4e9f94b8a34be9f4e
when I actually analysed the $_GET parameters I found that $_GET['check'] was fine but the "osCsid" parameter was actually being passed as "amposCsid".
This meant that when the checkout_process.php process tried to identify the visitor using the session id, it could not and subsequent processing in the checkout_process.php function states that " if (!tep_session_is_registered('customer_id'))" then redirect to the logon screen.
The following fix to the checkout_process.php (before " include('includes/application_top.php');") seemed to resolve the issue.
if (isset($_GET['amposCsid']) && $_GET['amposCsid'] !='')
{$_GET['osCsid'] = $_GET['amposCsid'];}

I can now continue testing and if I find any other issues, I will post again.

#2   TonyBunney

TonyBunney
  • Members
  • 33 posts
  • Real Name:Tony Bunney

Posted 11 December 2010 - 12:50

Just noticed something similar with the final response
The simulator is responding with the following $_GET variables.
[check] => PROCESS
[amp;key] => d41d8cd98f00b204e9800998ecf8427e
[amp;VPSTxId] => {E19729E3-AB62-477A-A367-2C3E6BFB2AF5}
[amp;osCsid] => 12175a21d73728a4e9f94b8a34be9f4e

I can always raise a bug against SagePay but I am not too sure how long they will take to fix this so just add the following to checkout_process.php before "include('includes/application_top.php');"
if (isset($_GET['amp;key']) && $_GET['amp;key'] !=''){$_GET['key'] = $_GET['amp;key'];}
if (isset($_GET['amp;VPSTxId']) && $_GET['amp;VPSTxId'] !=''){$_GET['VPSTxId'] = $_GET['amp;VPSTxId'];}
if (isset($_GET['amp;osCsid']) && $_GET['amp;osCsid'] !=''){$_GET['osCsid'] = $_GET['amp;osCsid'];}

So you should now have four replacements at the top of checkout_process.php

NB I mention $_GET variables here as all references to $HTTP_GET_VARS and $HTTP_PUT_VARS should be replaced with $_GET and $_PUT respectively as the old $HTTP_XXX_VARS are redundant. See http://php.net/manua....predefined.php for details.

#3   TonyBunney

TonyBunney
  • Members
  • 33 posts
  • Real Name:Tony Bunney

Posted 11 December 2010 - 13:10

Sorry, of course I meant to say $HTTP_POST_VARS replaced with $_POST

#4   TonyBunney

TonyBunney
  • Members
  • 33 posts
  • Real Name:Tony Bunney

Posted 11 December 2010 - 13:38

Simulator now working perfectly.
A note to you all that if you want to use the SagePay simulator, you have to sign up for it but it looks like you can either have a Simulator OR a live account.
I had to apply for a simulator account using different credentials but you can link any site to a simulator account, so you can still use the simulator on a live system (which is what I was doing).
If you do sign up for a simulator in a different name you will have to make sure that the Vendor field is set to your simulator account name and not the one that is define in MODULE_PAYMENT_SAGE_PAY_SERVER_VENDOR_LOGIN_NAME.
So add the following line to the sage_pay_server.php script (before initial message is built)
if (MODULE_PAYMENT_SAGE_PAY_SERVER_TRANSACTION_SERVER == 'Simulator')
{$SPMerchant = 'simulatorloginname';}
else {$SPMerchant = substr(MODULE_PAYMENT_SAGE_PAY_SERVER_VENDOR_LOGIN_NAME, 0, 15);}
Remember to replace simulatorloginname to your own simulator login id.
And then change the setting of the Vendor value (where the $params array is built) to 'Vendor' => $SPMerchant,

Although I have the simulator working perfectly now, I did receive this warning
"WARNING: The Simulated Server was able to decode the response from your site (shown in the box above) to obtain the following fields. The Test and Live Servers are NOT as forgiving as the Simulator when the positions of the fields in your response are taken into account.

In front of your "Status=" value are extra characters that should not be present. Blank spaces, lines, comments etc. will all cause the real Server system to fail to read the Status correctly.

Please modify your Notification Page code to empty the response buffer before writing out the "Status=" value. "Status=" should be the very first characters in the response, followed by a Carraige Return and line feed, followed by "RedirectURL=" and the redirection URL.

This simulator will allow you to continue, but you must correct this problem before attempting to use your code against the Test or Live Server systems. "

And when I switched over to the test server I got the dreaded
HTTP Status Code: 500
HTTP Status Message: The request was unsuccessful due to an unexpected condition encountered by the server.
Error Code : 5006
Error Description : Unable to redirect to Vendor's web site. The Vendor failed to provide a RedirectionURL.

But when I looked at the code that details what are sent in reply to the final SagePay message, all I could find is:-
$result = 'Status=OK' . chr(13) . chr(10) .
'RedirectURL=' . tep_href_link(FILENAME_CHECKOUT_PROCESS, 'check=PROCESS&key=' . md5($sage_pay_server_securitykey) . '&VPSTxId=' .
$_POST['VPSTxId'] . '&' . tep_session_name() . '=' . tep_session_id(), 'NONSSL', false);
The $results variable is simpley echoed (echo $result;) later on in the script, which is all that is required to satisfy SagePay's requirement for a response.
So I need to look into this further.

#5   TonyBunney

TonyBunney
  • Members
  • 33 posts
  • Real Name:Tony Bunney

Posted 11 December 2010 - 13:43

Just tried the LOW profile option on the TEST server and received
HTTP Status Code: 408
HTTP Status Message: The client failed to send a request in the time allowed by the server.
Error Code : 5999
Error Description : The Session is invalid or has expired.

What is going on.
I will find out what is wrong and get back to you.

Who said that integrating SagePay Server with OsCommerce was easy!!

#6   TonyBunney

TonyBunney
  • Members
  • 33 posts
  • Real Name:Tony Bunney

Posted 11 December 2010 - 14:10

Beginning to think that the word "RESOLVED" was used a bit prematurely.
Apologies.

#7   TonyBunney

TonyBunney
  • Members
  • 33 posts
  • Real Name:Tony Bunney

Posted 19 December 2010 - 10:19

Well, here we are over a week later and still no success with the SagePay Integration although, I have now nailed down where the issue lies.
After much debugging, I found that the test system had the same problem with the $_GET parameters it was returning, i.e. the test system also requires
if (isset($_GET['amp;osCsid']) && $_GET['amp;osCsid'] !=''){$_GET['osCsid'] = $_GET['amp;osCsid'];}

But the problem seems to that the session is not being re-established when using the SagePay TEST system, although it is established when using the simulator.
The responses I receive from the simulator are the same as the responses I receive from the TEST system, so I am not too sure what is happening.
I thought that if an Key=osCsid Value=c09e1bdd9f3b9ae4e674a04fe36b07fd pair in the $_GET parameters, OSC would re-establish the session for me but it does not and so the checkout_process.php tries to redirect the client to the login page.
I really do not want to debug all of the session stuff, so I will have a look around the forums to see how a session is re-established.

#8   parma

parma
  • Members
  • 136 posts
  • Real Name:Manoj
  • Gender:Male
  • Location:London

Posted 03 January 2011 - 18:17

good luck, thanks for keeping us updated!!

#9   TonyBunney

TonyBunney
  • Members
  • 33 posts
  • Real Name:Tony Bunney

Posted 04 January 2011 - 01:02

At last all is working perfectly.
The issue with the characters in front of the response was resolved by adding ob_clean(); before echoing the response back to SagePay.
The next issue I hit was that the response from SagePay to indicate that the payment was successful was not sending the correct response and that was because I had SESSION_BLOCK_SPIDERS set to true and HTTP_USER_AGENT from SagePay was set to an entry in DIR_WS_INCLUDES . 'spiders.txt' file, which was causing the software to not start the session properly and this redirecting the SagePay response to the login screen.

The next little issue that you should be aware of is that when I added the static IP address to the SagePay settings, the subnet mask had to be set to 255.255.255.000 and not 255.255.255.255.

With all of that done. All is working perfectly.

#10   parma

parma
  • Members
  • 136 posts
  • Real Name:Manoj
  • Gender:Male
  • Location:London

Posted 07 January 2011 - 14:38

At last all is working perfectly.
The issue with the characters in front of the response was resolved by adding ob_clean(); before echoing the response back to SagePay.
The next issue I hit was that the response from SagePay to indicate that the payment was successful was not sending the correct response and that was because I had SESSION_BLOCK_SPIDERS set to true and HTTP_USER_AGENT from SagePay was set to an entry in DIR_WS_INCLUDES . 'spiders.txt' file, which was causing the software to not start the session properly and this redirecting the SagePay response to the login screen.

The next little issue that you should be aware of is that when I added the static IP address to the SagePay settings, the subnet mask had to be set to 255.255.255.000 and not 255.255.255.255.

With all of that done. All is working perfectly.


You genious, I will try this out on my setup. Thanks a lot, its a shame SagePage didnt help!

#11   TonyBunney

TonyBunney
  • Members
  • 33 posts
  • Real Name:Tony Bunney

Posted 07 January 2011 - 15:06

You genious, I will try this out on my setup. Thanks a lot, its a shame SagePage didnt help!


Thanks parma. Let me know how you get on as I have this feeling that I missed something out when I was documenting all the changes.

#12   parma

parma
  • Members
  • 136 posts
  • Real Name:Manoj
  • Gender:Male
  • Location:London

Posted 13 January 2011 - 10:40

Thanks parma. Let me know how you get on as I have this feeling that I missed something out when I was documenting all the changes.


I'm going to give this a go on the weekend so I'll let you know how it goes.

#13   TonyBunney

TonyBunney
  • Members
  • 33 posts
  • Real Name:Tony Bunney

Posted 13 January 2011 - 11:25

I'm going to give this a go on the weekend so I'll let you know how it goes.


Good luck.

#14   Kambho

Kambho
  • Members
  • 1 posts
  • Real Name:Kam

Posted 01 June 2011 - 21:59

Hey all,

Just wanted to say it was the Secret Key in URLs flag that got it working for me in the end.

After all the other the stuff that is.... Hope this helps!

KamBho

#15   rhubarb

rhubarb
  • Members
  • 177 posts
  • Real Name:Nick
  • Location:Southampton UK

Posted 11 November 2011 - 12:36

I can't seem to get off first base with this module. So far I've done the following:

1) installed the module
2) created a simulator account
3) set the vendor name to be the same as my simulator account name
4) set the transaction server to be 'Simulator'
5) set the Profile payment page to be 'Low'
6) changed the code in checkout_process.php as per https://github.com/o...7345cc91145862a

How is it meant to work? I was told it uses an iframe, do we have to create and add a php page with an iframe or does this automatically appear in the checkout_confirmation page? I'm seeing everything as normal and when I click confirm in checkout_confirmation it returns to the payment page with a general error.

Why do they say it will not work in conjunction with Paypal, is it because of the code change in checkout_process.php (my point 6)?

Any advice please?

#16   rhubarb

rhubarb
  • Members
  • 177 posts
  • Real Name:Nick
  • Location:Southampton UK

Posted 11 November 2011 - 13:24

Now I've added the webserver's dedicated ip address in the simulator admin, I see that form checkout_confirmation posts to checkout_process.php which loads page /ext/modules/payment/sage_pay/checkout.php and this is the page with the iframe.

#17   achieve

achieve
  • Members
  • 37 posts
  • Real Name:Declan Connolly

Posted 09 December 2011 - 22:08

Did this solution work? I would love to get easy step by step instructions, as I'm now triyng to integrate Server, as I was getting missing orders in OSC using Form

#18   JohnPark

JohnPark
  • Members
  • 2 posts

Posted 14 December 2011 - 02:48

thanks to everyone who posted here and some other threads too as it helped me get this working at last.

as we where not using SSL during testing it kept failing as it was not picking up the session during the notification event
i had a look at the application_top file and found that if your not using ssl it will only pick the session up from a $_post['osCid'] variable.

// set the session ID if it exists
if (isset($_POST[tep_session_name()])) {
tep_session_id($_POST[tep_session_name()]);
} elseif ( ($request_type == 'SSL') && isset($_GET[tep_session_name()]) ) {
tep_session_id($_GET[tep_session_name()]);
}

i change the code which i found in this thread to the following to get it working. /whistling.gif' class='bbc_emoticon' alt=':-' />)


if (isset($_GET['amp;key']) && $_GET['amp;key'] !=''){$_GET['key'] = $_GET['amp;key'];}
if (isset($_GET['amp;VPSTxId']) && $_GET['amp;VPSTxId'] !=''){$_GET['VPSTxId'] = $_GET['amp;VPSTxId'];}
if (isset($_GET['amp;osCsid']) && $_GET['amp;osCsid'] !=''){$_GET['osCsid'] = $_GET['amp;osCsid']; $_POST['osCsid']=$_GET['osCsid']; }

i thought i would post it in case it helped anyone too

thanks again for everyone who posted previously coz they helped loads
John

#19   achieve

achieve
  • Members
  • 37 posts
  • Real Name:Declan Connolly

Posted 14 December 2011 - 09:32

Afraid that didn't work for me also. In fact, I had sent an email to a contributor on this forum who has posted 1000's of times and who has created some very widely used contributions, asking for some professional help on this issue.

Basically word back from this person is that there is a long standing incompatibility issue with Sagepay's servers and OSC. Say that only fix is to post the order to the osCommerce database before sending the data to Sagepay.

I think I will simply choose a different Payment Processor provider.

#20   JohnPark

JohnPark
  • Members
  • 2 posts

Posted 14 December 2011 - 23:53

i dont know about any incompatilities tbh ... i just know what i had to change to get it working and thought it may help some one else.

i set up some logging so i could see the responses and had some great help from sage support so i may have just been lucky but i have not experianced any server incompatilities and i am running a vsp which i had to set up myself! What problem did you have with it?