views:

166

answers:

4

Hi, the question's in the title really.

I have an online form where, after a series of stages, the user is sent off to a payment gateway on another server, then back again after completing their details there (no card or personal info is sent, just encrypted tokens, that's the point).

So can I rely on the session data still being available when they are sent back (via POST?), and also should I do so?

My testing would seem to indicate yes, but this is the first time I've tried to do anything like this. The alternative is to save form progress before the redirect & then reinstate it when they return. Would that be better & why if so?

TIA :)

A: 

It depends on the timeout of the session and whether or not the apache crashes/restarts. If you need a failsafe way then persist the session info back into a database.

JD
Thanks JD, this was my overall feeling before I asked the question. I'm definitely going to save the session.
da5id
A: 

Depends. chances are your PHP sessions are handled by using a cookie storing the session id, however if your customer has cookies turned off, then (depending on configuration/use of SID) it can be added to the query string. In the case of cookies, it should be a non-issue -- the session should continue. If cookies are disabled then you are reliant on your payment gateway provider to provide the session id when it returns the customer

edit: just to add, if the customer isn't being logged out (session ended), storing the form data in session variables should not be a problem.

As to security, you may want to ensure that the session is somehow restricted to an ip (checked on every page load to make sure it matches) to ensure the session isn't being hijacked by the payment gateway or other unscrupulous man in the middle (only really a concern if cookies are turned off and the query string includes the PHPSESSID).

Jonathan Fingland
+1  A: 

Yes, you can generally rely on this working.

Your session will still time out in the normal way, so as long as you expect your customer to spend less time in the third party site than it takes for the session to time out, you should be fine.

I do exactly what you are suggesting with some sites I maintain, and there are no serious problems. I guess it might be more complicated if a large percentage of your customers are expected to have cookies disabled, but if you are dealing with the public, this is really not an issue.

However, most payment gateways let you pass them additional information that they will send on to you when they return the customer to your site. Even if they don't have a built in way of doing this, you add GET params to the URL they use to return the customer to you. It is well worth adding an ID or order number here, so you can do something even if the session has died.

NOTE: Some payment services don't actually return the customer to your site at the end of the transaction, but instead just make a call to your server to let you know that a particular payment completed. In this situation your session will be not intact, as it is not the customer making the request from your web server.

rikh
Cheers rikh, good advice for Payment Gateways in general. This is a custom implementation though - the first time they (and I) have done it this way. I feel like I would be reasonably safe to rely on the session, but I think I'm going to save it anyway.
da5id
A: 

If you want to make sure that the session is available, you can edit the session cookie timeout like so:

session_set_cookie_params(604800);
session_start();

That will make the cookie expire one week after its created. The default is it expires when the browser is closed.

You can read more about it here

http:// uk3.php.net/manual/en/function.session-set-cookie-params.php

Ozzy