server side redirection

Yes.

If this is a "POST" form, it is actually worse than you think.  The Redirect and Transfer methods do not persist the form variables.  In fact, there is no easy way to "redirect" to a page to another server using a POST form.

You need to provide the new variable in the page which has the form.

Another option is to create an intermediate page which has a FORM and set the action attribute to the payment gateway.  Add your extra variable to this page, and then use javascript to automatically submit the form on load.

"You need to provide the new variable in the page which has the form."

The page with the form is going to the customer and being posted back to me. The variable I want to add is a MerchantPIN value that tells the payment gateway the transaction is really from me.  This variable can't be in the form the customer sees, or a "View Source" would show it. So are you saying to create the variable in the form but don't give it it's true value until the page is posted back to me?

"Another option is to create an intermediate page which has a FORM and set the action attribute to the payment gateway.  Add your extra variable to this page, and then use javascript to automatically submit the form on load."

So I would transfer into this new, intermediate form all the form values from the form the customer submitted, fill in the MerchantPIN and  then use javascript to submit the form from my server?  But doesn't javascript only execute in the client?

You cannot use the server to slipstream a POST variable.  It has to come from the client.

You can either put it in the main page (which doesn't look like an option), or you can create an intermediate page which uses Javascript (on the client-side) to submit the new form before the user has access to it.

Those are the only options that I can see for what you are trying to do.

There is one more option that is more difficult to implement, and may not work in your case.  You can use the HttpWebRequest/HttpWebResponse classes to send the FORM from the server.  You would create a fake POST request, fill in the customer's data and your PIN number, and then send it to the payment gateway.  Then use the HttpWebResponse to read the response and send it to the client.

You may need to process the response yourself so that you can detect any error conditions.  It isn't easy, but it looks like your only option.

Out of curiousity, why does your PIN need to be kept secret?  If someone else were to use your PIN, it would still be tied to your account.  It doesn't seem like someone could defraud you, you might want to check the documentation and be absolutely sure that the PIN must be kept safe.  Most payment processors give sample code as well to show you how this should work.

Thanks for the info.  I'm still a bit unclear on the "intermediate page" concept, though.  I understand how a client could access a page on my server that has javascript in the page_load that triggers  the submit to my payment gateway.  But this wouldn't be the normal page the client accessed.  Normally they would access the main page with the visible order form and Submit button.  Are you saying to insert the intermediate page into the stream of the main page with something like response.write?  

Regarding the "secret PIN" I agree it seems useless since the transactions are normally deposits to my account, so how could I be cheated?  Perhaps it's to keep someone from reversing a charge?  The payment gateway is MerchantPartners (resold by Pay-Me-Now).  I have found even their Level 3 support to be clueless, and when they get into a question over their head they just stop responding to emails.  It's frustrating.  The manuals have no examples of how to include the MerchantPIN.  Tech Support just says, "You need to have a script on your sever that will receive the form post and then add the merchant pin and send it to us.  It's a backend operation."   Maybe this is easier in something like php.

Thanks.

By the way, perhaps I can give back some information to you.  You said in your first response
"The Redirect and Transfer methods do not persist the form variables."

But here's Programming Microsoft ASP.NET 2.0 Core Reference, by Dino Esposito on page 521:

"The Transfer method has the following overloads:
        public void transfer(string);
       public void Transfer(string, bool);
       public void Transfer (IHttpHandler, bool);

The string parameter indicates the destination URL.  The Boolean parameter indicates what to do with regard to the QueryString and Form collections.  If true, the collections are preserved; otherwise, they are cleared and made unavailable to the destination page. "

I've never done this and I only pass it on to you for whatever it's worth.

Thanks again for your help.

steva

Right, but you were trying to transfer to a different server.  I could be wrong, but I think that if you transfer to a different server the form variables are not preserved.

If I am wrong, then perhaps you could modify the collection.

I was reading over your answer  and one piece is still not clear.  You say...

"Your server creates a new page.  This page has ...  an additional input element called "MerchantPIN"..  In the <body onload> attribute, use onload="document.forms[0].submit();", to automatically submit the page.  This would happen before the user could view the source."

My question is, how does the server get this new page down to the client's browser to be executed?  The client got the original page by requesting it through his browser, but he's not going to request this page.

The main page does not submit to the payment processor, it submits to a page on your server.

This page contains nothing that the user can see, it just generates a form with a bunch of hidden input elements (these elements correspond with all the values that were submitted by the user).  One of those elements will be a new one named "MerchantPIN".  This form's "action" attribute will be the payment processor's URL.

Then, in the body onload event, use Javascript to submit the page on behalf of the user.

So, to answer the question, "how does the server get this new page down to the client's browser?".  The server returns this page when the user submit the "main" page to your server.  He is requesting the intermediate page when he submits it.

Got it!

I was thinking that when you submitted a form,  the form action page just processed the form and went away.  I realize now that the submission actually requests that form action page, and any html (or JavaScript) that you put in the body of the page comes right back into the user's browser and gets rendered. Processing the form is just one thing the form action page does; it also displays anything you put in the body back in in the customer's browser.  Therefore, you can put a new form in the action page body with  just hidden stuff (the original stuff plus MerchantPIN)  and have Javascript resubmit the form in the onload handler before anyone can enter View Source.

(Clearly, I haven't been doing this very long.)

As you point out, though, sending the MerchatPIN to the client this way still exposes it to someone with a  packet analyzer - unless  the server has a digital certificate and has set up an SSL connection with the customer.

Thanks for your patience.

steva

You are correct that it exposes the MerchantPIN through a packet analyser.  However, it should be a given that the entire process would occur on a SSL link.

If the link between the server and client is SSL,  doesn't that solve the exposure problem completely?

Yes