Rob Smith wrote: >Collect Information -> Confirm -> Pay -> Receipt Page >At what point in this process do you store the information into your >database? The Authorize.net form (AIM) is a post to their .dll. So >obviously you have to store the information before you pay. But should you >do it before you confirm? :: > > No, not necessarily. You could just put the info into session variable(s) until you get an approval. However, I find that my clients like to have a record of transactions non-approved transactions as well as the approved ones, so I store the info in a table with columns for transaction id (as generated by AuthNet, default empty string) approval status, approval code etc. >Collect Information -> Confirm -> Pay -> Receipt Page > | > L--- here + form validation? > >That way if you hit the back button (browser or <input type="button" >onclick="window.history.go(-1)" value="Back">) you can still edit this >before presenting the user with confirm everything. The Confirm page will >not have any forms but all the hidden fields that the AIM requires. > Are you thinking of SIM rather than AIM? Normally AIM is done server-side: i.e. the customer submits the order to your server, your server sends the post data directly to AuthNet, captures the response data from AuthNet, and gives an appropriate friendly response to the customer. I believe it is SIM where you have the customer's browser make the post to Authorize.Net directly. Continuing with the method just described, I pass an internally-generated unique order ID (e.g. the primary key of my transactions table) to AuthNet, which then passes it back in the response, and the transaction record gets updated with the approval code, etc (verifying the session ID as well as the order ID). Anyway, that's the general flow that I have been using successfully for a few years.