Post form with "secret" data from the server and open result in user browser

I am building a simple payment process using an external payment gateway.

1. The user chooses a product, clicks Buy,
2. The server makes a POST requests to load the payment page from the 3rd party site.

The payment gateway has no idea what "products" are, and expects a request with an actual price value. This rubs me the wrong way, as it would mean that someone able to view source will see the request fields and values. Some would be tempted to mess up with the values and the ordering system. Not that this is a huge problem, the order confirmation will anyway be authenticated with a token, but it will not stop smart guys to mess up the values and make a payment.

Is there are way to request the gateway page by posting the data from the server and open result in user browser?

If they have to go through the user's browsers, what would be a more obscure way to do it? Playing with HTTP headers in the response? Posting with an AJAX call?

Thanks.

PS: This is not about making an tacit server post (ie with curl), the resulting page must open in the user's browser.

PPS: Well, after playing a bit more with the payment gateway API (Payline.com to be precise) I discovered that they do provide a mechanism for this, wh开发者_JAVA技巧ere the post is made by the server, a token is returned and the user goes to the page with everything filled in. The browser is not sending the data, which is just what I wanted. It's the solution to my problem but not the answer to this question. I won't post this as an answer and I still think it would be nice to have an answer.

This is possible, but it's so highly dependent on the payment gateway vendor's API that it is not possible to give you a tailored answer. That being said, there are a few ways to do it.

HTTP headers are NOT the way to do it. Neither is an AJAX call. Both are eminently easy to tamper with. The best thing to do is simply to verify the order with the amount received, and reverse the charge if they don't match by more than a small (+/-1%) margin for error, to account for rounding and whatnot. If someone messes with the results, their money comes back minus a couple days (as returning money is often slower than charging it.)

The second way to do it would involve using curl to make the (as you say) tacit server post, and then returning the results to the user - in effect acting as a proxy between the payment gateway and your customers. This probably isn't as good a solution as the first one.

Basically, the solution to this is strong bookkeeping. Anything that goes through the user's browser at all is going to get tampered with at one point or another, no matter how much you try to secure your communications. Just be sure your system is smart enough to smell it when funny business goes on.

What you can do is to proxy the POST request through your own server. Show the payment page with price and all fields to the user but instead of Submit action going directly to the payment gateway you can intercept the submit action on your server and then make the request to payment gateway server side after verifying it.