Minimizing PCI compliance when my checkout flow has a confirmation page

Question

I have a shopping cart flow like this:

• Page 1. Choose Products
• Page 2. Enter address, shipping, credit card details on a single page checkout.
• Page 3. User confirms the order - but we want a final opportunity to upsell, so we must be able to change the amount charged. If the user abandons this page they should not be charged OR authorized anything, but we must be able to call them and convince them to order without having to ask for their number again.

• Page 4. Receipt page

• Repeat billing is a requirement for later, with variable amounts and schedules. (The user must be able to come back and change their schedule without entering CC number again).

Here's what I dont want to do :

• Send the user to a third party page (because I want a single page checkout and retain branding)
• Minimize PCI compliance requirements
• Authorize payments and cancel them if the user doesn't confirm. This is asking for trouble on many levels!

Since I need a confirmation page I think I will need to use some kind of tokenization system such as offered by braintreepayments. You basically store the credit card number on their service and they give you back a token that represents that number. You can then make a charge against that card at any time for any amount. This certainly seems the most flexible solution.

I'm kind of going round in circles trying to figure out if this is the best solution or not :

• I don't know if BrainTree is the only company that offers such a service, but I'm also not convinced its really necessary.
• If I temporarily store the CC in session until the user confirms it I can still use pretty much any payment gateway. Therefore the question becomes 'does it matter if I store the CC in memory temporarily' and to what degree.

The 'purest' safest approach seems to be to redirect to braintree (or someone else that offers a similar gateway).

Edit (after assigning bounty):

I've concluded that I absolutely have to have a system where we only need to meet level A for PCI. Been studying PCI in more detail and these questionnaires are the relevant ones for card-not-present merchants (i.e. e-commerce).

SAQ A : (when CC numbers don't even touch our server). You still have to fill out this questionnaire if you're selling online, but it is pretty easy.

SAQ D : (where CC numbers touch our server EVEN IF WE DONT STORE THEM)

Take a look at these questionnaires reveals a huge delta between requirements. The PCI requirments are often misrepresented as being a simple list such as 'maintain a firewall', 'security policy', 'limit physical access' - but if you actually read questionnaire D you'll see it has order of magnitute more questions and requirments. For instance you have to answer whether or not your server is protected by a video camera, and what kind of data encryption you have on your server.

I'd really appreciate knowing what actual products or providers out there that will facilitate me doing what I want to do. If there really is only 1 or 2 companies out there that let me do this then I need to know.

I've got no relationship to Braintree except I've managed to get on their email marketing list. They're just the only company I've managed to find that does this. If you are running another company doing the same then by all means blow your own trumpet. PCI requirements are only going to become more stringent over time and anyone who has got this far reading my question probably already realizes that.

Answer 1

Yes, it matters if you store the CC number in memory. The moment the card number touches your network, you're in scope for PCI.

I don't work for Braintree but do work for a company that does what you need. You need a combination of tokenization and having the data hit an external site. We have a solution that works around the need to redirect to an external site. (I'm pretty proud of making that up, and people are going crazy for it.) It was made specifically to address everything you've mentioned. (Yes, you are not alone.)

I won't bias your search with self promotion as I'm sure there are lots of people out there doing it. (Plus I'm not here in an official marketing capacity and don't want to cause any problems for myself.)

Good luck.

Update: You can be a small company and still reach tier 1. It is all about volume, and if you do it right the first time there is nothing to change should you reach a higher tier. If you're not storing CC numbers (either by way of tokenization or other options), then that limits the applications and servers from what you need to do for PCI should you get to the point where a third party auditor needs to be involved. That is only one issue.

If the card number reaches your server at all, everything up to the point of that server is in scope for PCI. It is extremely silly that the auditors won't accept the fact that storing the CC number temporarily in memory should limit the scope of the server. But you're right; transparent redirect, second site redirect, or even a simple postback have no way of guaranteeing that data won't be stolen. PCI is about putting obstacles in place to make a data breach difficult, and then to be able to say that you've done all you could to prevent the data from being stolen. (My analogy is that PCI aligns the blame fingers to all point in the direction of the user rather than the people conducting business all the way up to the processor.)

The real big problem about PCI is that you can't anticipate how strict the rules will be enforced should you get to the point where an auditor needs to get involved. Every auditor interprets the PCI DSS requirements slightly differently, and even the people reviewing the ROC reports can suddenly decide they don't like what you're doing. It doesn't really matter what you're concerned about; what matters is if the PCI people are going to accept your ROC or if they are going to enforce some new interpretation of the rules.

I've worked with many auditors and many large companies going through PCI. The interpretation right now is that limiting scope means the card numbers can't touch your network. How that affects you is entirely dependent on your current or future volume.

Answer 2

Eh, ok....www.paymetric.com

No redirect to third party "payment entry" page with Data Intercept using XiSecure tokenization. You can store the token and use it for subsequent authorizations all you want.

It was made in response to several other very large companies that want to do the same thing you're trying to do. It is in use by at least a few of these companies at the moment.

I don't know what it costs. I just designed the systems that do it. (Well, I coded quite a bit on them too.) It is evolving and has more features that probably were added when I was off working on another project, so grill them on it meeting your requirements. It is 100% hosted and should keep you at needing SAQ A.

This should sum it up: http://www.paymetric.com/?page%5Fid=1609

Are there other people doing this same thing? I don't know, but I'm fairly certain everyone else requires a redirect. I think a lot of these companies haven't been paying attention to the evolution of web technology. That's all I'm going to say about that. ;)

I hope it helps.

Answer 3

Here's the general rule of thumb: If you don't read, store, or process the PAN (CC#) and/or exp date, then you don't need PCI Compliance. If you even remotely touch that card number, then you need to undergo PCI Compliance.

Why not just make it easy and do PayPal ?

Answer 4

You will have to fill out form D if you do not redirect the user to another site. It applies to all systems that have PANs, even if they aren't written to disk. If you're just getting started, I'd suggest going the redirect route so you can avoid that. PayPal's credit card offering is actually a reasonable choice for this. If nothing else, they're big and solid and unlikely to go anywhere.

Full PCI compliance is time consuming and expensive. I think it's generally best to defer that until a business has some revenue.