Callback to Drupal site after curl call to 3rd party site doesn't resume authenticated session if more than 120 seconds elapsed since authentication

Question

UPDATED SITUATION:

• A user authenticates on my site.
• The user selects items to purchase and is sent via curl call (see below) to a payment site.
• The payment site does its thing and returns to my site via a callback URL I posted to it. I assume it is also a curl call, since data is posted back.
• Upon return, if less than 120 seconds has elapsed since the user originally authenticated on my site, the user's authenticated session is resumed (good).
• Upon return, if more than 120 seconds has elapsed since the user originally authenticated on my site, a new session is started (bad). The user is effectively signed out.

This behavior is 100% consistent. I can call the 3rd party site and return any number of times within the 120 second window after authentication and the authenticated session is always resumed. But as soon as I return after 120 seconds, a new session is started.

It doesn't matter whether I authenticate, immediately go to the 3rd party site, and then wait there 120 seconds, or if I authenticate, wait at my site 120 seconds, and then go to the 3rd party site, if the return to my site happens more than 120 seconds after original authentication on my site, a new session is started instead of resuming the authenticated session.

What could cause this? Some kind of timer setting, cache setting, etc.? Maybe a module? I'm asking before I begin the process of disabling modules one by one.

My curl call:

$ch = curl_init('https://commerce.cashnet.com/404Handler/pageredirpost.aspx');
curl_setopt($ch, CURLOPT_POSTFIELDS, $data); // $data includes the callback URL
curl_exec($ch);
curl_close($ch);
exit;

AN EARLIER VERSION OF THE PROBLEM DESCRIPTION talked about session ids changing, information passed, etc. I removed all that to simplify, as it got too long to leave it in. The original set of comments below are based on that earlier description, which is why they don't seem to make sense now. But they were helpful in guiding me to further testing that revealed the 120-second issue.

Answer 1

A callback from a credit card processing site to your Drupal server should never have the same session as the paying customer. If it does, then you have a problem.

But I'm not sure that's what you're saying - you are vague when you talk about session ID. If you mean that the paying customer's session ID shouldn't change when your server sends the payment information to the credit card processing site then receives the response, then you are correct. But why even mention credit card processing and posting back in this case, as it's not very relevant? If the paying customer's session ID changes, then you need to investigate how the session ID is invalidated and what your session timeout is. Perhaps your callback is invalidating a cache tag that forces a new session to be generated for that user.