Passing Form Data Through A Redirect

[rainborick]

I'm working on a shopping cart system where a customer fills out an order form on a single page and when they click Submit, I need to save the form data before sending it on to PayPal. So I have the form pointing to a PHP script that does the database stuff and ends with:

 header("Location: " . $action, FALSE, 302);

which I hoped would send the $_POST data on through the redirect, but my test script shows $_POST is empty, so I'm doing something wrong. I'd rather avoid an interstitial page that would require another customer click, but I'm open to suggestions and/or corrections. Really open. Bordering on desperate. Thanks!

[g1smd]

POST cannot be redirected for security reasons.

[rainborick]

Oh, Darn. But thanks!

[penders]

So I have the form pointing to a PHP script that does the database stuff...

Can you not recall the information from the database again after the redirect?

[rainborick]

The object was to simplify the process. The client is a non-profit offering members/supporters a limited array of products with specialized ordering limits - all of which made a complete shopping cart environment severe overkill, and why they wanted to dump Zen Cart. But, of course, the back-end does require the functions of a shopping cart admin system, so I created a hybrid of a sort with a system I'd developed previously.

I have a single page with an order form that collects the personal data (name, address, phone, email) with a JavaScript-dependent product selection area. I had hoped to invisibly insert a data capture script between my form and the wondrous environment PayPal offers for direct upload of a shopping cart. PayPal's system does do a callback for payment confirmation, but it only includes the customer details and a summary of the payment information - none of the cart contents data is returned.

Anyhow, after confirming that a simple redirect wouldn't work, I just turned the data capture script into the interstitial page I was trying to avoid. I have a Monday deadline and some further admin processes to integrate, so that's going to have to stand for now. I have some hopes of eventually using AJAX to call the data capture script during onsubmit(), but the other stuff has to come first. And even with the interstitial, it's still much better than a full shopping cart for these folks.

[penders]

Or... dump the $_POST data into the $_SESSION and recall from there?

[rainborick]

I need to record the order data before sending the user off to PayPal because once he's there, his browser may never come back to the website. The callback I mentioned comes from PayPal, not the user.

[rainborick]

Oh, wait. I think I sort of see what you had in mind, but I don't think it would really simplify things. The only way I can see to get the form contents into $_SESSION would be via AJAX calling an external PHP script before he leaves the order form page. If I set the <form> to method="post", which is unavoidable, there's no way to redirect the user on to PayPal with $_POST data intact.

[penders]

...I have the form pointing to a PHP script that does the database stuff and ...

I was kind of envisaging you saving the form data (into the session) at this stage. However, you'd probably have to override the default session handler or at least make it persist when they are sent off to PayPal and resume when/if they return (within a period of minutes). That was my thought anyway.

[rocknbil]

I need to record the order data before sending the user off to PayPal because once he's there, his browser may never come back to the website. The callback I mentioned comes from PayPal, not the user.

This is a classic payPal problem. :-) "What happens if they never click 'return to merchant's site' after payment?"

Store the data in a database, even a plain text one, but add two fields: a "transaction id" field which you'll pass along to P.P., and a "completed" field that is set to 0 or false. Mod your script so it only does this, doesn't display any emails or success responses (unless they actually do return to the site via the 'return to merchant' link).

Set up payPal's IPN for this site. In that setup, you will be asked for a URL to which payPal will post Instant Payment Notifications.

Create a second script as a "pay pal listener script" that "listens" for posts from payPal that send two bits of data: a transaction id and a status. When it comes in, you look up the record, set it's status to 1, send out your emails. No success response is necessary since this is all silently posted.

It's really not that hard to set up and a bazillion "if's/maybe's/headaches" go away.

[rainborick]

Yeah, that's exactly what I did. It's just an unusual situation where I'm not sending the user through a typical Select Items -> Checkout -> Make Payment process. It's a one-page ordering form and I wanted to make it Submit Order -> Make Payment, but I had to settle for Submit Order --> Continue (record order) --> Make Payment. And, miracle of miracles, it's up and running and taking orders just fine.

[rocknbil]

Make Payment, but I had to settle for Submit Order --> Continue (record order) --> Make Payment.

Why can't you do the record in the first submit, then pass the variables on the PP via a query string in header()? Doesn't matter I guess, if it's working it's working, but one less step.

[rainborick]

I ran into a deadline, or I'd probably have opted for using AJAX to call a PHP script to record the order before sending the user to PayPal. The organization has two promotions, the first of which started this past Monday. The second one is in March, when I'll have a chance to take a second swing at it with some experience to guide me. That's fortunate because the traffic and order volume will be much higher and there are a handful of bugs/issues that need fixing.