[thelist] Proceed to Checkout - Authorize.net Question

[Maximillian Schwanekamp]

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.