Forum Moderators: buckworks
I am using a script page on my site to "make a stop" at my site to check product availability one last time before going to the Paypal checkout page. It's basically a mimick of the same PHP code used to post back the IPN variables the my notify_url script.
Everything works fine in Production (I'm able to see the variables posted in the Paypal checkout page -> amount, item name, shipping, etc). But if I try to test in the Sandbox, I always end up at the "Please login to Developer Central" even if I'm logged in (I click on that link, and I'm already logged in).
I guess this has something to do with using fsockopen() and then outputting the HTML response from teh browser.
Has anyone else tried this? Is there some sort of session code that has to happen? I'm new to HTTP but an old hat to PHP and what not.
Here's a snippet of code that opens the connection and outputs the HTML response:
//open socket to http://www.sandbox.paypal.com/cgi-bin/webscr
$socket = fsockopen($host,80,$errno,$errstr,30);
//just some error code
if (!$socket)
{
$result["errno"] = $errno; $result["errstr"] = $errstr;
return $result;
}
//$reqheader is the string of "hidden" vars I'm posting to the Paypal checkout page (amount, mc_gross, cmd, etc)
fputs($socket, $reqheader);
//get server result into array
while(!feof($socket))
{
$result[] = fgets($socket, 4096);
}
//close connection
fclose($socket);
//iterate through array, find element where html output starts by examining content type of header
for($i=0;$i< count($result); $i++)
{
if(strstr($result[$i], "Content-Type: text/html;")!= FALSE)
{
$counter = $i + 1;
break;
}
} //end foreach()
//start at counter where html output starts and echo output to page
while($counter < count($result))
{
echo $result[$counter];$counter++;
}
This code I believe is very valuable to users like me who have a 3rd party shopping cart where the users can potentially "hang out" during the checkout process where product availability can be compromised if you don't check one last time before leaving Paypal (i.e. I do a product inventory check and insert my temporary order right before calling the fsockopen and redirecting the user to Paypal checkout -> results in cleaner inventory and less temporary orders).
Like I said, this code works perfectly for Production Paypal so what am I missing from a Sandbox standpoint for the server to recognize that I AM logged in?
[edited by: lorax at 2:43 pm (utc) on Nov. 15, 2005]
[edit reason] delinked [/edit]
Any links as to some explanation of what is output by the server when a call like this is made, or I assume it may be a case by case basis depending on configuration of the server?
That's exactly why I'm here. I've found that forum to be useless for 'out of the box' solutions. Most people there seem to be using Paypal IPN as it's described. I just find it very scary that no one there has questioned the ramifications of passing payment amounts and item quantities to Paypal without one final check to see if they're still available. Even scarier is that fact that Paypal doesn't have a true 'max checkout time' on the checkout screen to kill people who sit there for hours and hours (they have a session limit which is useless and gets refreshed everytime a user visits another internal Paypal page). I actually posted this suggestion on their wishlist forum (two new POST variables -> max_checkout_time and max_checkout_return_url; returns user to max_return_url when max_checkout_time reached).
But surely this is down to you to check? Once you relinquish control to Paypal's system, you basically have to abandon all notion of stock ckecking.
This is something I've thought about, and you just need to do the check immediately before sending the customer off to Paypal, and put a temporary "lock" on the items and quantities - to be made permanaent if the transaction completes ok.
You are right about their forum though - it does suck. :-(
-- The problem is that Paypal does not have a maximum checkout timeout period. I understand they have control once I pass the user to Paypal, but they exacerbate the situation by not having a method to cancel these checkouts if the user hangs for hours upon hours. You can't put product locks on something for 24+ hours (customer service for users who actually pay within a normal time period) and that's what Paypal is forcing merchants to do because they don't have a global override on insanely long checkout sessions.
'This is something I've thought about, and you just need to do the check immediately before sending the customer off to Paypal, and put a temporary "lock" on the items and quantities - to be made permanaent if the transaction completes ok.'
-- That's why I'm using the code above. Otherwise, if you follow their normal ways of checking out, you go directly to their site (form action url is paypal's site) without stopping to make any checks. But this check is still not enough.
I digress, but back to the original point of the post, no one has tried to simulate the intial POST to Paypal to give their inventory one more shot of being accurate?
Thanks, I'll take a look at that. I'm going to post my POST (no pun intended) question in the PHP forum and see if I have some luck with the HTTP question as it's still good knowledge to have. I'll post any updates if I get them from somewhere else.
