homepage Welcome to WebmasterWorld Guest from
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
Forum Library, Charter, Moderators: coopster & jatar k

PHP Server Side Scripting Forum

Processing form data after submit
process and reforward form data

 7:40 pm on Feb 9, 2009 (gmt 0)


I am trying to prepare a form that collects data from the customer before passing the form to a payment gateway. The PHP script provided by the payment gateway requires an MD5 hash key based on a couple of different fields, including the total amount to be charged.

My problem is that we don't know the value of the goods/services until the customer submits the form - so how can I use the PHP script to calculate the MD5 hash and add it to a hidden field in the form. It seems ridiculous to have the form go to our server for processing, then to present the customer with a second form and ask them to press Submit so it can submit the final informtion to the payment gateway site.

Am I missing an obvious solution. I suppose I could use JavaScript to calculate the MD5 hash when the customer has completed the form, but this doesn't seem very secure and I can't find a JavaScript routine that seems to do the job.

Any suggestions or solutions will be most appreciated. I do recall seeing deatails somewhere of a technique to submit one form to another which will automatically submit. Can't remember where though. Has anyone any tips on this please?



 6:56 am on Feb 10, 2009 (gmt 0)

one solution is to submit your data to a hidden page, do you calculations there, create a new form with all fileds ytoiu need and auto-submit it to the payment script


 4:39 pm on Feb 10, 2009 (gmt 0)

I'm guessing you have a "one-page" checkout.

- Submit data to your script
- Calculate order
- compile md5 hash, prepare all other gateway data
- Use cURL to post the data to the gateway and retrieve response
- Based on the gateway response, process the order (update database, send emails, etc., or return to form with values pre-populated and errors displayed)
- return response to browser


 7:48 pm on Feb 10, 2009 (gmt 0)

Thanks Guys

I'm not quite sure what you mean, Rocknbil. I've never used cURL and only basic-level with PHP. It is just frustrating that the payment gateway require a md5 hash fingerprint based on several fields - one of which (the total order charge) is only determined on submission of the customer's form. Clearly the form goes straight to the payment gateway, not pack to our webserver and/or the PHP script which could compile the hash.

It is just so frustrating and inefficient to collect the data from the customer, then present them with a page/form that basically serves no useful purpose but to get the customer to click the button to submit the final calculated hidden fields to the payment gateway. I just hate this sort of inefficiency from the customer's point of view.

I've been out on site all day, so haven't had a chance to play with the hidden auto-submit page idea. Seems like it might be the most approriate way round the problem, but still frustratingly inefficient. Thanks anyway.


 7:51 pm on Feb 10, 2009 (gmt 0)

Hi Rocknbil

Sorry, I realise what you mean now. Yes, the customer only needs to complete a single page (as if they were making a donation payment, where they would enter almost nothing except an amount before completing the gateway-provided credit card payment page). Maybe I need to look into cURL. To be honest, it's not a language I have any knowledge of. Any suggestions of a good place to start? Thanks.


 11:16 pm on Feb 10, 2009 (gmt 0)

Probably the PHP cURL Manual Page [us.php.net]. :-)

Most likely you can skip all the parts of install, go right to the functions and examples, give it a go. It's highly unlikely you'll find a 'nix server without it installed.

Basically, what curl does is make a request or post via command line allowing you to do exactly what you're describing, all in the same process/step of your programming.


 9:02 am on Feb 11, 2009 (gmt 0)

Thanks rocknbil - I'll certainly look into that as it seems to offer the neatest solution


 2:39 pm on Feb 11, 2009 (gmt 0)

PHP cURL seems to offer some exciting possibilities and I've successfully got it to communicate with my payment gateway (Authorize.net).

However, I'm trying to use cURL to call the Authorize.net payment page. If my form script initiates it using cURL, the browser url remains showing the original form URL - not the Authorize.net URl - and, more importantly, not in secure SSL mode. I also find that although the content of the Authorize.net payment page is complete, it is not formatted, as if it is not downloading the CSS file. I assume these problems are connected.

Any thoughts please?


 4:38 pm on Feb 11, 2009 (gmt 0)

Well, a couple things:

I also find that although the content of the Authorize.net payment page is complete, it is not formatted, as if it is not downloading the CSS file.

If I'm reading this correctly, you are using cURL to get the payment page, not post the submitted data to the gateway for a transaction response. If this is the case, you're mixing the two A.N. methods.

Are you using SIM or AIM? I suspected A.N. when you said it required an md5 hash, and also suspect SIM for that reason. SIM is generally used for "web page integration" where you have the customer enter non-sensitive info at your site then redirect to the A.N. secure form for credit card info in "payPal-like" fashion. In this scenario,

- your site submits basic non-sensitive info to your script
- your script makes a database entry, marking the order as "sent to A.N." but not complete
- your script then redirects to the secure payment form at A.N.
- On successful payment, the return link value directs back to your site with a "payment complete" token to update the order as complete.

This is a less robust method with the user being directed from your site to A.N. and back, all of which can raise abandoned orders and affect customer trust by switching sites. The more robust method is to use AIM with cURL as previously described. This allows customers to enter their order on your site without ever leaving it.

In case I'm not clear, what should be doing with cURL is actually posting the data to the gateway and getting a transaction response, NOT cURLing the payment page (explanation below.)

- Do you have an SSL cert installed on this domain? If you are having someone enter sensitive info, this is vital.

the browser url remains showing the original form URL

This is actually a benefit, not a negative. If you do have an SSL cert installed, you solve this with something like this at the top of your script:

if (! ($_ENV['HTTPS']=='on')) { header("Location:https://www.example.com/same-script.php"); }

I also find that although the content of the Authorize.net payment page is complete, it is not formatted, as if it is not downloading the CSS file.

When you cURL a page, you are taking an external URL and outputting it in your domain environment. So if the A.N. page has


it will not find that file on your site. You can "make" this work by doing a preg_replace on the $response to sub out the full URL's to the A.N. location for these files, but it's the long way around the fence and tells me you're cURLing the payment page, not posting to the processor.

The overall outcome is it's worth the trouble to install an SSL cert on the domain and use AIM methods to connect to the gateway so the customer has the impression the order is processed entirely on your site. If you do not have an SSL cert, you will indeed need to redirect to the payment page, but if the client has invested in Authorize.net, an additional $30/year for an SSL cert is the way to go. You're already halfway there, all you need is the cert.

I don't have an immediate link handy, but dig around the authorize.net site, they have sample code in PHP for both AIM and SIM methods and how to use them.


 5:37 pm on Feb 11, 2009 (gmt 0)

Thanks rocknbil

I am using SIM. I am with you all the way - it all makes sense. The stupid thing is that this requirement is so simple.

The easiest description would be to describe this as a donation page. In theory, the user would simply need a link/button that would take them to the Authorize.net payment page where they could enter their card details and the amount they are donating. However, because the charge amount is part of the required hash fingerprint, I have to provide a form that establishes the amount before calling the Authorize.net payment page. Worse still, I need two forms so that the hash fingerprint can be calculated before the final call to Authorize.net. I am now achieving it via onmoutop's suggestion of a hidden auto-submit page. It works, but I just don't like inefficient methods like this.

Thanks for all your help - really appreciated.


 9:34 pm on Feb 12, 2009 (gmt 0)

Well, last comment (promise. :-) ) You should give AIM a stab, it's not all that difficult. But if you're stuck with SIM, to fill out the auto submit idea,

-Submit form

-compile variables in hidden fields, but at the same time compile a query string:

foreach ($_POST as $key=>$value) {
hiddens .= '<input type="hidden" name="' . $key . '" value="' . $value . '">';
$qstring .= "&amp;key=$value"

Then when you output your form,

<meta http-equiv=REFRESH CONTENT="3; url=http://processing-page?submit=yes$qstring">

This allows Javascript to submit the form first, but if it's disabled, the refresh will send it. It's pretty unlikely both will be disabled.

Of course, in that event, on the page is . . .

<p>Please <input type="submit" value="Press to Continue"> if you are not redirected to our secure payment processor.

About "submit=yes" - pick any one variable and put that at the front of the query string. This is so you don't have to futz around with this possibility: processing-page?&amp;some-key=some=value&amp;....


 1:35 pm on Feb 13, 2009 (gmt 0)

Hi Rocknbil

AIM looks very interesting, but this is a low-budget job and I'm not really keen to 'throw in' use of our secure area. So, from an academic point of view, I'm keen to find a low-cost solution as I envisage a number of client's in this category (forget donations, the site's are for payment of vacation property rentals).

Your solution sounds interesting - but just to make sure I'm understanding you, can I confirm that your suggestion uses a single submission form.

The first submission comes back to my server for processing. I assume, therefore, that the meta refresh would automatically take it to Authorize.net? Sorry, I need to try this and ensure I've got my head around it correctly - but I REALLY appreciate all your input and suggestions.


 4:36 pm on Feb 13, 2009 (gmt 0)

can I confirm that your suggestion uses a single submission form.

Well, not for the overall process, but from the user standpoint on your site, yes, you submit once. It's one way of implementing omoutop's suggestion. You start with the single submission, then after compiling your variables to post to A.N., you output a page to the browser and the meta-refresh/javascript "auto posts" the "second" form to the A.N. secure payment form. So overall there's three forms in the process, but the user only inputs on two - your site, then the secure payment form.


 6:18 pm on Feb 13, 2009 (gmt 0)

Brilliant, rocknbil - I shall give that a try as soon as I can clear the decks. Thanks again.

Global Options:
 top home search open messages active posts  

Home / Forums Index / Code, Content, and Presentation / PHP Server Side Scripting
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved