ASP .NET POSTing.



  • I'm fairly sure this is a beginner's question, so please don't hurt me too bad. ;)



    The people I'm working for have decided to use a third-party to process credit card payments.  To initiate the
    payment process, the user, once they have given us all the info we
    need, must be redirected to this third-party's website with a POST
    containing some information such as our company's ID and the amount to
    be paid.  However, all of our pages are ASP .NET pages, which do
    not allow POSTing to anything other than themselves.



    I've googled about POSTing to other sites from ASP .NET, and I've found
    several workarounds for the probem, but they all seem a little kludgey.



    How would you all tackle a problem like this? 


  • ♿ (Parody)

    The good ole' fashion way. I've done this with PayPal and a few other services ...

    <form action="https://paypal" method="post">
     <input type="hidden" name="..." value="..."/>
     You will be redirected to a third party site to complete payment processing....
    </form>

    Don't be afraid to go in and do HTML.



  • @Alex Papadimoulis said:




    <form action="https://paypal" method="post">
     <input type="hidden" name="..." value="..."/>
     You will be redirected to a third party site to complete payment processing....
    </form>
    <form action="<A href=" https://paypal="">

    Don't be afraid to go in and do HTML.



    Yeah, I found something similar to this when I was searching around about the issue.  Right now I have a class named RemotePost that allows me to add name value pairs to a collection.  When the Post method is called, it assembles a plain ol' HTML page with hidden input types for all the name value pairs that were added and outputs it, using System.Web.HttpContext.Current.Response.  It works just fine, but it just seems a little "iffy" to me.  Is this the type of thing you're talking about, or am I missing something completely simple and obvious?
    </form>


  • @UncleMidriff said:

    However, all of our pages are ASP .NET pages, which do not allow POSTing to anything other than themselves.

    If you're using ASP.NET 2.0, look up "Cross Page Postback". The gist of it is that whatever button you need to do the submitting, you add a "PostBackUrl=" parameter to it.

    IMO, this is kind of a WTF in itself, because what this essentially does is to make the button run a javascript which changes the action of the the form in question to point to your new page, then submits it. But since the normal submit in asp.net uses javascript as well, I guess it's not all that much of a WTF more than normally.

    If you're using ASP.NET 1.1, then you are correct, there's essentially no good way to do what you want to do. In which case building an HTML with an auto-submitting script in it is as good as any other way.

     



  • @Otto said:

    @UncleMidriff said:

    However, all of our
    pages are ASP .NET pages, which do not allow POSTing to anything other
    than themselves.

    If you're using ASP.NET 2.0, look up "Cross Page Postback". The gist of it is that whatever button you need to do the submitting, you add a "PostBackUrl=" parameter to it.

    IMO, this is kind of a WTF in itself, because what this essentially does is to make the button run a javascript which changes the action of the the form in question to point to your new page, then submits it. But since the normal submit in asp.net uses javascript as well, I guess it's not all that much of a WTF more than normally.

    If you're using ASP.NET 1.1, then you are correct, there's essentially no good way to do what you want to do. In which case building an HTML with an auto-submitting script in it is as good as any other way.


    Interesting.  We're still using ASP.NET 1.1 where I'm at, so no dice there I guess.

    It'd be nice if it could be a little more involved than merely changing the action attribute of the form.  Doing things like removing the viewstate would make me happy, because I'm pretty sure whatever third party I might POST to wouldn't much care to have the potentially huge, meaningless viewstate POSTed to it.

    Anyway, thanks for the tip...I'll look into it.



  • You could try turning the viewstate off for the whole page... If you use the VS IDE you should be able to fiend a property for that in the page's property panel.

     

    Drak



  • Our e-payment implementation has to do something very similar; the
    difference is that we have to post XML to an SSL URL instead of
    submitting form posts, but the difference is minor. We use the
    HttpWebRequest class via WebRequest.CreateDefault().



    At first I thought it was a little kludgy, but that's what the class is
    there for. I can confirm that this approach works (and works well) in a
    medium-volume production system.



  • @John Bigboote said:

    Our e-payment implementation has to do something very similar; the
    difference is that we have to post XML to an SSL URL instead of
    submitting form posts, but the difference is minor. We use the
    HttpWebRequest class via WebRequest.CreateDefault().


    At first I thought it was a little kludgy, but that's what the class is
    there for. I can confirm that this approach works (and works well) in a
    medium-volume production system.



    The system we're using works like so:


    The user visits to our page, enrolls in a class, and is then presented with the option of paying for that enrollment.  If they click the Pay Now button, a plain ol' HTML page is generated which tells them that they are about to redirected to the payment processing site.  This page has the few necessary values in hidden inputs which are then POSTed to the SSL URL of the payment processing site when the user clicks the Proceed button.  The payment processing site, behind the scenes, grabs our unique tracking ID from the form POSTed to it and in turn POSTs it back to an SSL URL on our end which checks to make sure that the transaction that the payment processing site is about to process is indeed one that it should be processing.  If it isn't, we respond that it isn't and the transaction process stops right there.  If the transaction is a valid one, we have the opportunity to respond to the POST with any additional information we may have already collected from the user (in XML or name-value pair form), so that they don't have to enter it again on the payment processing site.  The payment processing site then collects the rest of the necessary info from the user, processes it, and then POSTs the results of the transaction to another SSL URL on our end where we record the results to the database.  If the transaction was successful, the user gets redirected to a success URL on our end, otherwise they're redirected to a failure URL.

    While designing all the pages for this and before the payment processing site was ready for us to hit their test servers, I set up a little stand-in page that would communicate to all the other pages mentioned above, so that we could at least test those pages out.  The stand-in page used the HttpWebRequest and HttpWebResponse classes to do all the behind-the-scenes communication with the other pages.  It worked much better that I had antcipated, being as convoluted as it is. :) 

Log in to reply