This is a round-about CFML question, but not really and apologizing up front if this is in the wrong channel. I have come across code related to Authorize.net, which uses Authorize.net's transact.dll in a CFHTTP call within a CFC. The CFC is called from a post form on a CFM page where the merchant employee enters the sale on the form page. Basically, the data from the credit card and transaction information is passed to this CFC and the CFC grabs the API Login ID and Transaction Key depending on the client logged in and then sends the transaction data with the API Login ID and Transaction Key to Authorize.net. This process keeps the API Login ID and Transaction Key from ever reaching the web page and secured. Due to PCI Compliancy concerns, my client wants to cut out the call to the CFC and post directly to Authorize.net to reduce PCI Compliancy stickiness. The trouble is that in order to have the web form post directly to Authorize.net, then the API Login ID and Transaction Key would essentially have to remain in a hidden input field and would be able to be viewed in the source code of the web page, which is definitely not ideal. Has anyone experienced this sort of conundrum? I know that there is Accept.js, but the client allows for card swipes and the website captures track data which Accept.js is not able to handle track data.

I wrote an entire implementation of Authorize.net's API in CF in 2017-18. You should definitely not be posting any login IDs in a form field; you will flunk PCI compliance. PCI compliance does not care about whether you use CFCs on the back-end; it can't tell (or at least, if it can tell, then something much bigger is wrong)

I would update your code to use the current api (https://developer.authorize.net/api/reference/index.html#gettingstarted-section-section-header)... (I have a set of CFCs for this if you need them let me know). I think that the version that submits to the .dll is a very old version.

yeah, deffo no DLL involved even as of 5 years ago

if you are working with code that old.... you should make sure that you are not storing any CC info in your databases too. I would reccomend tokenizing the data by using customer profiles/payment profiles https://developer.authorize.net/api/reference/index.html#customer-profiles

that's what we used (and it's pretty close to Stripe's model as well) - we created profiles for every customer and had them add cards to their profile, and then we would just be sending the customer ID and the saved card profile ID, which was useless information outside of their Authorize.net account.

I just went through that whole process last year with a client of mine that had a legacy system that was using the old authorize.net API then started having fraud issues.... I had to re-write their whole payment system to get it PCI compliant

Why is your client telling you how to solve it - especially as they are suggesting something that is definitely not PCI compliant?

Thank you all for your feedback! Yeah, I believe it is old as well. Also, it has been 10+ years since I previously worked with Authorize.net which was my own company and I resorted to using their embedded web page many many years ago to keep it simple. I have been looking at the API examples you mentioned and Accept.js and noticed that these examples are grabbing the API Login ID and Transaction Key from a "constants" file. I know this is an example, but looking at the json data that would be passed to authorize.net seems like it would be viewable data in the Network debugger. I get that it is obfuscated by grabbing the key and id from a different file, but it would still be viewable in the debugger, I think. @Scott Bennett Thank you for wanting to share your CFCs. I would love to take a look at how you are handling everything. Thank you 🙂

With Accept.js the only thing it should be sending is the non-secret / public key - same as with most eCommerce providers where you have to have some key available to front-end clients but that key by itself usually isn't sufficient to do much.

@ryan I sent you a DM with my email. Send me a note and I'll reply back with a zip containing the CFCs and some basic instructions on how they are set up

Anything would be helpful to kickstart and compare. I would very much appreciate it.