Tag Archives: PCI DSS

FormSite, Authorize.net, & PCI DSS Compliance

For the past couple weeks I have been working with a client on a web application project which requires online payment.  The organization has chosen to work with FormSite, a company that allows you to easily generate and edit HTML Forms and Surveys.  FormSite also has integration with PayPal,  Google Checkout, and Authorize.net.  FormSite boasts quite a few notable clients: Dell, Fed Ex, Oracle, and Pepsi, to name just a few.

With all this in mind, as I have been working with my client to send the user to the payment integration forms, I have stumbled across a couple interesting issues with FormSite’s Authorize.net integration, which I have brought to FormSite’s attention.

FormSite is using the Simple Checkout integration method with Authorize.net.  The standard setup for this method (as described in the Simple Checkout link), is that customers click the (already generated) Simple Checkout button, and are taken to Authorize.net’s hosted payment form to enter their payment information, along with any other required information.  In other words, the merchant’s server has nothing to do with generating or displaying the payment form–The customer is taken directly to the authorize.net server.  You can see an example of this from the screenshot below.  (Notice that the URL is Authorize.net)

What this does is take the merchant’s server out of the PCI compliance scope, since the merchant does not have anything to do with the checkout process–They don’t generate or display the payment form, neither do they capture or transmit the credit card information–This all falls to Authorize.net.

So with that in mind, let’s look at what FormSite does:

When the customer clicks on the (already generated) Simple Checkout button, instead of being redirected to Authorize.net’s hosted payment form, the customer stays connected to FormSite’s server, and the Authorize.net’s payment form is pushed to the customer from the FormSite server.  You can see what it looks like from the screenshot below.  (Notice that the URL is FormSite.com)

After the customer inputs his payment details, he clicks the “Submit” button;  At this point, the customer’s machine connects directly to Authorize.net over a secure connection, and submits the payment details.

So what is the issue?

When asked for PCI Compliance details, FormSite responded saying that “The credit card details are submitted to Authorize.net and not FormSite.  If you click submit on the form or look at the form source, you will see the info is being sent straight to Authorize.net and not thru FormSite.”

After getting some more information from FormSite, it was clear that the only PCI compliance issues that they validate for is the SSL Certificate, among a couple other minor things; in their book, since they are not handling credit card details, but submitting them directly to Authorize.net, they feel that they are PCI compliant, since Authorize.net is the organization that captures the credit card information, not them.

Here is the issue I have with how they are currently doing things:

Because they do not forward the customer on to the Authorize.net server for the Authorize.net hosted payment form, but push the form down to the customer from their own servers, they have made themselves part of the checkout process, and, according to section 6.3 of PCI DSS, they need to do a bit of work to make sure that they are PCI compliant; things such as: regular code audits(6.3.7); separation of duties (; change control procedures (6.4);  etc.

Here is a pdf of PCI DSS section 6.3.

I have brought this to Formsite’s attention, and they have responded by saying that the way they currently do Authorize.net payment integration is non-standard, and that they will be changing it in the future– but that at this time, in their understanding, they are fully PCI Compliant as they are.

Because I believe that they are in violation of PCI DSS, from a liability standpoint, there is no way that I can recommend the Authorize.net payment feature of Formsite to any of my clients, until Formsite either changes the way that they do Authorize.net payment processing, or they recognize their need for completely validating their PCI compliance.


Tagged , , ,

SANS Audit 521: Meeting the Minimum: PCI/DSS 1.2: Becoming and Staying Compliant

This week I am starting a new 2 day SANS class.  This class deals with the credit card industry standard PCI DSS.  The organization I work with is working on PCI DSS compliance, and I am heavily involved in it, so we decided that I should go ahead and take the class, to get as educated as I can about the standard.  I will be posting a Lessons Learned and Review of the class after I finish it, sometime in the next few weeks.  I will also be posting what I am currently doing in my new position in Michigan.


Tagged , ,