iFrame or Tokenization for Credit card transactions [closed]

Question

My company is currently processing less than 4000 Credit Card transactions a year and we are a level 4 organization. I see that we are storing the credit card data in one of our databases but the PAN number is encrypted. After proposing either Tokenization or iFrame model to be implemented to reduce our PCI compliance to the management, the company heads wants to go for the iFrame model so we need not worry about PCI compliance at all.

Since we planned to implement iFrame for all credit Card Transactions, I would like to know how to implement iFrame as an automated processes without human intervention especially for recurring payments. I could not find any information for recurring payments using iFrame.

Also I would like to know if iFrame implementation is expensive than tokenization or vice versa. Any suggestions will be greatly appreciated.

Answer 1

In the credit card processing context, iframe solutions refer to a setup where your web site uses an iframe to cause customers to interact with your processor's site when entering their credit card details. So it's not so much a solution you'd implement yourself, as a way that you'd open a window from your site to your processor's implementation for accepting credit card data.

That means that the credit card details go to your processor, not to you. As such, you generally also need some form of tokenization, otherwise the processor is just making that card data accessible back to you for the purposes of repeated payments, recurring payments, chargebacks, &c. &c. (and if they share that back to you, your PCI scope is un-reduced). Tokenization is their way of allowing you to leverage the card data they gather without putting your systems into scope.

So, iframes and tokenization go hand in hand. You can have one without the other, but if you do, you don't get the level of scope reduction you wanted in the first place.

Now, these questions that you're asking, they can only really be answered by your processor. Your processor should be able to tell you how to integrate with their iframe (or equivalent*) solution, and what the costs are for that and the costs for tokenization. It may just be me, but the tone of your question suggests you're wondering how to implement this yourself, when you can't - the whole purpose of these solutions is to shift your PCI scope off to your processor. QED, you need to work with your processor to find out what they offer and how to implement it.

* There are non-iframe equivalents for shifting scope to the processor - my company implements a nifty javascript tech called PayPage to do the same thing. Not trying to flog them, just being pedantic :)

P.S. You'll still need to complete the SAQ A, even with one of these solutions - you'll never "need not worry about PCI compliance at all", you always have to worry about PCI compliance if you accept credit card payments. You'll just have a 15-ish question questionnaire to fill out instead of a 300-ish.