Wait, you're doing this in CF?

Just use the cfpayment library: http://cfpayment.riaforge.org/ or the 
the good parts of the authorizenet.cfc by itself.

On 9/22/12 7:23 PM, Rick Faircloth wrote:
> After running a regular form post (no AJAX, no CFHTTP),
> I get back all my form values in a pipe-delimited string,
> along with Authorize.net's approval code and other transaction
> info they return. The submission is a success. I get the
> successful email notification, etc.
>
> However, I'm still not sure how to access the pieces of that
> string. What kind of variable is it, if any? Do I need to assign
> the string to a variable, then parse it?
>
> In the typical AJAX I run, I'm sending data to a component method,
> and I create a Struct and store variables I'm returning to the
> success callback in there, but access them in the AJAX code via
> response.WHATEVER. I've tried "response", "fileContent", etc.,
> trying to figure out how to reference the string that Authorize.net
> returns.
>
> Any more clues anyone?
>
> Thanks!
>
> Rick
>
>
> -----Original Message-----
> From: Rick Faircloth [mailto:r...@whitestonemedia.com]
> Sent: Saturday, September 22, 2012 6:05 PM
> To: cf-talk
> Subject: RE: Question about using AJAX with Authorize.net
>
>
> Looking at the sample CF code, which posts via CFHTTP,
> this is how the post response gets handled:
>
> ---------------------------------------------------------
>
>       <!--- Because coldfusion's ListToArray object ignores empty fields,
> we must
>       put a space in all empty fields to make sure that they are not
> skipped --->
>
>       <cfset post_response=Replace(cfhttp.filecontent,"||","| |", "all")>
>
>       <!--- the same command is run twice, because the first time it only
> adjusts
>       every other empty field --->
>
>       <cfset post_response=Replace(post_response,"||","| |", "all")>
>
>       <!--- now the ListToArray method can be used without skipping fields
> --->
>       <cfset response_array=ListToArray(post_response, "|")>
>
>       <!--- the results are output to the screen in the form of an html
> numbered list. --->
>
>       <cfoutput>
>
> ----------------------------------------------------------------------------
> ----------
>
>  From that code, I get a list of all the data coming back, but I couldn't use
> the structure,
> "filecontent" to access any field of data.  Maybe I should try
> "filecontent[1]" or something.
>
> I made the following changes, just to see if I could access the field data
> in the response:
>
>       <!--- [ ricks changes ] --->
>
>       <p>Thank you for your donation to USO Tampa Bay.</p>
>
>       <cfparam name="response_array[69]" default=""/>
>
>       <cfif len(trim(#response_array[69]#)) gt 0 >
>               <p>This donation has been made in memory of
> #response_array[69]#.</p>
>       </cfif>
>
> And that works.  response_array[69] is the first name of the person the
> donation is sent
> in honor of.
>
> I tried using "filecontent" as the structure containing all the responses,
> which is the
> first thing I see in the CF code above, "cfhttp.filecontent". But that
> didn't work... is the
> "filecontent" part of that specific to a cfhttp post?
>
> I thought I'd mention this code before writing up a regular post to
> Authorize.net.
>
> Does this help figure out the structure the code is being returned in?
>
> Rick
>
>
>
>
> -----Original Message-----
> From: Russ Michaels [mailto:r...@michaels.me.uk]
> Sent: Saturday, September 22, 2012 5:40 PM
> To: cf-talk
> Subject: Re: Question about using AJAX with Authorize.net
>
>
> 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:352726
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm

Reply via email to