you need to take ajax out of the loop and do a regular http post, and then look at the response that comes back, then you will see what variables they are sending you and you can then adjust your ajax code accordinly
On Sat, Sep 22, 2012 at 10:22 PM, Rick Faircloth <r...@whitestonemedia.com>wrote: > > Judah... (or anyone else...) > > I'm running successful transactions to Authorize.net from > my form using AJAX to post that data to Authorize.net. > > I know the transactions are successful, because I'm getting > Customer Receipts (to myself) and Merchant Receipts (again > to myself). However, in the "success" part of my AJAX code, > I don't know how to access the data/response that Authorize.net > is sending back. My AJAX routine processes and submits the > transaction info, then displays the "Processing..." message > and the page sits there, because I don't know how to check > for the "This transaction has been approved." code. I'm not > sure what variable/array to check. > > What variable should I test to make sure the transaction was > successful in the AJAX callback? The only ColdFusion documentation > I could find doesn't involve AJAX and just uses CFHTTP, which > I want to avoid to simply PCI compliance. (However, I will be > running server-side validation of the data, including credit > card numbers, to make sure one's been entered and is in the > correct format... does that mean I've now passed the data to my > server and causes me to have to be as stringent about PCI > compliance as if I were using CFHTTP to post to Authorize.net > in the first place, instead of AJAX? > > Thanks for any feedback! > > Rick > > > > -----Original Message----- > From: Rick Faircloth [mailto:r...@whitestonemedia.com] > Sent: Tuesday, September 18, 2012 6:37 PM > To: cf-talk > Subject: RE: Question about using AJAX with Authorize.net > > > Thanks for the perspective, Juday... > > My plan is to run client-side validation via Javascript when info is > being entered into the form, then validate with CF in a cfc method > once the form passes Javascript validation and return any errors > that CF picks up. Usually, there aren't any CF errors if JS didn't > find any in the form data, since I program CF to validate the same > way the JS does. > > You mentioned the transaction key and password. I'll provide that data > in the JS processing and assign the values there before submitting > the data via AJAX. Would that be secure? > > Rick > > > -----Original Message----- > From: Judah McAuley [mailto:ju...@wiredotter.com] > Sent: Tuesday, September 18, 2012 5:54 PM > To: cf-talk > Subject: Re: Question about using AJAX with Authorize.net > > > Ah, gotcha. The key there is definitely the "merchant defined" fields. > They do not want you to send them personally defined information that > they then post back to you (the x_ fields that you mentioned). > > I think you are on target with your ajax option. The other option is > to post back to your server, capture the response in memory (just the > Form collection), do a cfhttp post to Auth.net to do the transaction > with the subset of information they need and then redirect to the > receipt page (if successful) or back to the submission page if the > transaction errors. This is what I've done in the past and it allows > you to do the server side validation and any custom processing. > > The downside to this method is that it carries a higher PCI compliance > because the CC details are transmitted to your server even if they are > never stored anywhere other than memory. If you use Ajax calls > directly from the client-side form, you can avoid some of the PCI > compliance stuff because the information never hits your server. > However, you would have to include the transaction key and password in > your client-side form at that point which makes that information > publicly available. Off the top of my head, the only thing I can think > of that that would do is make it so that other people could charge > credit cards and give you money from them but there may be other > attack vectors that aren't obvious to me right away. If you bypassed > client-side validation, maybe you could charge a negative number and > refund money to the card? Probably not, but it would warrant > investigation at the very least. I would also think that the fact that > the client side would be doing the HTTP call would mean that you could > set up a Hosts file entry for the Auth.net gateway and provide a reply > on the client side that said it was successful and then your page > would submit back to you assuming that the call was successful and > therefore allow them to fake a transaction. I don't know if that is > important in your situation or not, but fundamentally, I do no trust > validation that is only performed on a machine I do not control. > > Cheers, > Judah > > On Tue, Sep 18, 2012 at 2:25 PM, Rick Faircloth > <r...@whitestonemedia.com> wrote: > > > > Thanks, everyone, for the comments... > > > > Judah, I'm using the Advanced Integration Method (AIM), > > since I'm hosting my own form. > > > > Here's what I'm referring to in the Authorize.net info > > about personally identifying information: > > > > From the Advanced Integration Method docs: > > > > ---------------------------------------------------------------------- > > > > Merchant-defined data fields are not intended to and must not be used > > to capture personally identifying information. Accordingly, the merchant > > is prohibited from capturing, obtaining, and/or transmitting any > > personally identifying information in or by means of the merchant-defined > > data fields. Personally identifying information includes, but is not > limited > > to, > > name, address, credit card number, social security number, driver's > license > > number, > > state-issued identification number, passport number, and card > verification > > numbers > > (CVV, CVC2, CVV2, CID, CVN). If Authorize.Net discovers that the merchant > is > > capturing and/or transmitting personally identifying information by means > of > > the merchant-defined data fields, whether or not intentionally, > CyberSource > > will immediately suspend the merchant's account, which will result in a > > rejection > > of any and all transaction requests submitted by the merchant after the > > point of suspension. > > > > ---------------------------------------------------------------------- > > > > That seems clear to me, that in the AIM method, I can't use the > > "merchant-defined" > > x_ fields to capture any of the info mentioned above. > > > > My plan was just to send to them what they require for the processing and > > use > > the other fields from the form for the in-house emailing, thank-you's, > "in > > honor of", > > "in memory of", etc., data. I don't think that kind of data can go > through > > Authorize.net's server and back to me. > > > > Rick > > > > > > > > -----Original Message----- > > From: Judah McAuley [mailto:ju...@wiredotter.com] > > Sent: Tuesday, September 18, 2012 3:31 PM > > To: cf-talk > > Subject: Re: Question about using AJAX with Authorize.net > > > > > > You have to send Auth.net personally identifying information in order > > to use AVS (the address verification service), so I know they don't > > forbid that. Maybe it depends on the integration method you are using. > > Are you doing the simple integration method where you send the user to > > auth.net and then they come back or are you using a behind the scenes > > post to their api to do the auth? > > > > Judah > > > > On Tue, Sep 18, 2012 at 10:40 AM, Rick Faircloth > > <r...@whitestonemedia.com> wrote: > >> > >> I'm implementing my first donation form using Authorize.net. > >> > >> I've found in their fine-print that I cannot submit any personally > >> identifiable information to their servers. > >> > >> We have a form which includes personally identifiable information > >> for emailing thank-you's, etc. > >> > >> Therefore, I'm planning to implement an AJAX solution to > >> intercept the formfield data that is applicable to the transaction > >> and is required by Authorize.net and submit that via AJAX to a method > >> in a cfc, which will send the pertinent data to Authorize.net. > >> > >> In the success section of the AJAX solution to Authorize.net, I'll > >> implement a further submission of the rest of the form data (the > >> personally identifiable information) to another method in a cfc, > >> which will process that data for in-house (non-Authorize.net) use. > >> (Or something similar to this process...) > >> > >> Any warnings, cautions, or gotcha's in this approach? > >> > >> Thanks for any feedback! > >> > >> Rick > >> > >> > >> > >> > > > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:352723 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
