I have been looking at an online payment gateway, authorize.net, and specifically their Direct Post Method. This method would allow me to create a form on my server, then submit the post parameters directly to their server for processing. So you never actually leave my site as a customer, but my server can only see the response, not the initial payment information.

A question I have thought about is PCI compliance. I have been reading in the comments of this authorize.net blog. There is an argument over whether or not the server that has the form needs to be PCI compliant. Some say yes, because the form is on your site that has your URL and there is credit card information. Others say no because the form is submitted directly to authorize.net and the credit card information never even hits the merchant's server.

I have read in a few places on their site that Direct Post Method will "simplify merchant PCI compliance" or it will "relieve some of the worries about security". How exactly is PCI compliance simplified? So my question is, does my site need to be PCI compliant and if so how can this simplify it?

A related question is the transaction key. Authorize.net says to securely store the key. How are keys securely stored on a server? (without an HSM) Is this key considered part of PCI?

3 Answers 3


If you're servers do not store, process or transmit cardholder data in any capacity at any time, your systems are not in scope for PCI compliance and you've effectively outsourced the handling of such data to authorize.net - this means PCI is simplified as you've a reduced scope and would complete a less onerous Self Assessment Questionnaire (SAQ). As a merchant you need to be compliant rather than your site needing to be compliant. How you handle cardholder data dictates which SAQ you complete - if you've outsourced the cardholder data handling, you'd complete SAQ A which is pretty simple!

Visa and MasterCard have guidelines on how web applications should be secured when the transaction handling has been outsourced such as using hosted payment pages. The worry is that the application could be manipulated and cardholder data transmission redirected (or copied) to a third party.

Requirements include secure development lifecycle, vulnerability scanning, logging and file integrity monitoring.

You should consider storing the transaction key separate to the application itself such as encrypted within the database or in a separate file store with strong access controls.


First, I am not a lawyer, you should talk to a a lawyer or a PCI specialist rather than some random person on the Internet. That said, my understanding of Direct Post is that the client sends the PCI to Authorize.Net's server. It is never touched by your server, so it should not require PCI compliance. PCI-DSS only requires that systems touching PCI be compliant though and strictly speaking, the only exchange of PCI is between the client's browser and Authorize.Net's server.

That said, it would still be wise to try to follow many of the guidelines as a compromise of your server could easily compromise where the PCI is sent (such as malicious JavaScript altering the form's POST address). The argument's on Authorize.Net's site are probably about the fact that a compromise of your server can still compromise the integrity of the transaction, but PCI-DSS hasn't caught up with this risk yet and is still technically something that a smart consumer could detect and prevent since their system is the one being tricked in to doing the bad thing.


Your 'solution' there has one big problem: you have to put your Authorise.net ID and API key into the form so A.net can process the transaction and send the money to the right place.

All a hacker would have to do to get the API key and A.net ID is right click and select 'View Source' to get the merchant's API key and A.net ID. If you try to block that with some lame javascript, the hacker will simply save the page to his hard drive and then look at it and get the ID/API key. But the 'for hire' hacker teams have bots to do this automatically.

In my book, this doesn't even rise to a 'hack' - it's just too easy and obvious.

So if you do this, you'll soon be explaining to your client why 1 or 2 clerks are busy all day doing nothing but taking authorize holds off of non-customer credit cards, and rendering credits back to non-customers, and answering angry call from non-customer cardholders (all for absolutely no sales at all) as the bad guys will be gleefully bumping card transactions against your client's A.net account to see if the stolen credit cards they possess are still good. So this would be a great move for you.

So your choices are 2: use Stripe (and pay thru the nose) or program a real solution that's secure and submit the form to your own server, add the API key and shoot the package out the back door of your server to A.net, then parse the direct answer. Yes, this measure does mean you will be under full PCI compliance.

Trust me, there are plenty of hacker teams out there who have bots spidering the web looking for the revealing string'x_tran_key' (the form element name for submitting A.net's transaction key in a form to A.net) which is a dead giveaway for an open A.net transaction key.

You are going to just give those guys a nice payday?

  • There is an API ID, but no transaction key in the form. I did find x_fp_hash, though. This is so authorize.net can verify the message was sent from my server. So it doesn't look like the ID is passed. Update: Looking into their source code, this is the fingerprint hash and is made from hashing the api id, timestamp, amount, and transaction key.
    – Ryan
    May 2, 2013 at 13:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .