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:352667 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
