Can a non PCI DSS business pre-populate form fields on a credit card field?

November 15, 2011 3:20 PM

I'm working on a project that takes credit card payments online but wants to avoid the overhead of PCI DSS by not storing people's card details. This is fine, but it seems to be making our checkout process unwieldy.

I'm told that, because we want to stay outside of the PCI DSS system, I'm not allowed to pre-populate someone's address with account details in the "we need your credit card billing address" fields. We're not storing people's addresses with any kind of "this is the credit card billing address" flag, so it would be their home address which they could type over. Additionally, I'm told I can't pre-populate it either from form data carried over in hidden form fields from a previous page in the checkout flow.

Not being able to pre-populate these fields sucks as it means registered customers typing out their address every time, and new customers having to type it out twice (once for their account details and once for the credit card).

Is this information correct? Can anyone point me at the pertinent documentation on this issue?

Thanks.

posted by TheDonF to Computers & Internet (5 answers total)

Right now, all the cool kids are using Stripe. They use a javascript include to turn sensitive data into a token. It's both encrypted and decrypted locally, so it can be used to pull in address data.
posted by michaelh at 3:51 PM on November 15, 2011 [2 favorites]

Response by poster: We're using Authorize.net as a third-party processor, but apparently this has less to do with who's doing the processing and more to do with PCI DSS rules that state something as strict as a home address typed entered on Page A can't be posted to Page B and used to pre-populate the "my credit card billing address" fields on Page B.

We're trying to avoid anything really expensive, both financially and in terms of red tape, at the moment.
posted by TheDonF at 4:17 PM on November 15, 2011

Best answer: a) you should read the PCI documentation yourself, so you know what you're trying to avoid
b) you shouldn't take the advice of some random guy on the net about this stuff

Having said that, Stripe and Braintree won't help you for this bit of the problem, and avoiding PCI like this is always going to leave you with a clunky workflow, I'm afraid.

PCI covers "cardholder data" and "sensitive authentication data". Sensitive auth data is basically the CV2 number, and you don't get to touch that ever. Cardholder data is the PAN, the cardholder name and the expiration date.

The billing address is not cardholder data. If someone is telling you this, ask them to cite the PCI spec, and please post back to the thread because I'd be interested in hearing this.

(BTW, if you can shoehorn it into your workflow you should pre-populate the Shipping Address, not the Billing Address, and give the option to add a billing address if different from the Shipping Address. I know that's hard when working around PCI.)
posted by Leon at 4:44 PM on November 15, 2011 [2 favorites]

Leon is absolutely correct that the billing address is not Account Data and therefore not restricted by PCI DSS. He is also correct that this is business critical compliance for ecommerce and you should not look to the internet for solid advice here, including my advice, and you should do your own due diligence.

I would be wary of additional advice from whoever told you that you can't prepopulate the address.
posted by Kwine at 12:41 AM on November 16, 2011

Response by poster: Thanks for the replies. I read through the documentation and, yes, there was nothing in that that said that a customer's address couldn't be used where I wanted it. I challenged my colleague who said it's a "grey area" and that he had documentation that showed the ambiguity. I asked to see it, it never appeared. And then, two weeks later, they canned me. So now I'm out of work.
posted by TheDonF at 12:17 PM on December 16, 2011