I found myself writing this rather lengthy answer to a question posed by a potential client and thought I should share it.
Because this was originally written as an email, please accept it as more of a discussion, and less of a formal piece of writing. Nevertheless, I hope you find it informative.
Fully integrated - In this scenario the entire payment system is within the merchants owned and maintained infrastructure. The POS machines, the terminals, the servers, the firewalls, everything. In this scenario the entire system is also within PCI scope. Any change in a part of the system affects the other parts. They are all connected and communicating with each other as a whole point of sale and payment processing environment. Encrypted card holder data and transactional data is being stored on the system, and being sent for processing through their internet connection. Historically to build a fully integrated EMV payment system from scratch you are looking at 12 to 18 months of a qualified person’s time, and likely a few hundred thousand dollars in software development and hardware. If you are a tier one retailer, and you are processing millions of transactions a minute, escaping middleware/gateway fees which are usually assessed on a cents per transaction basis one can see the benefit of building and maintaining a fully integrated system in the long run. So once you have invested all this time and money in building this system, you need to get it certified with a processor. Which will also cost well into the tens of thousands when its all said and done. Furthermore, you are now married to the system you have built, and any changes, even down to the manufacturer and model of the terminal will cause a ripple effect, and the system will have to be re-evaluated and re-certified. Independent of changes to the initial architecture you built the system on, it is a full time job to maintain the system and keep it up to date with never ending PCI mandates. An example of that would be the POODLE vulnerability that was recently discovered with SSL connections. Consequently SSL connections were replaced with TLS connections to eliminate that vulnerability. You can see how maintaining a fully integrated system would be a full time job.
Semi-integrated - In this scenario you have partitioned the POS or kiosk application in a way. By using a gateway/middleware allowing the terminal to talk directly to the gateway switch through either an isolated software agent on the host PC, or through a dedicated secure connection, the only real surface area that is in PCI scope is the SDK you have integrated with your application. We are talking about something like .001% PCI security exposure, compared to 100% of a fully integrated solution being in PCI scope. Furthermore, the SDK and its associated gateway switch comply with PCI-DSS standards. So in a semi-integrated scenario you can do a self assessment questionnaire for your attestation of PCI compliance and be done with it in most cases. No encrypted card holder data ever passes through the POS application or is stored anywhere on the system locally. Your application never “sees” any card holder data. Most gateway software also supports tokenization. Tokenization has many uses, but the simplest to understand is recurring billing. The terminal can send the encrypted card data to the gateway which then generates and returns a unique token to the POS/kiosk application. That token can then be used again and again to bill that card. The beauty of tokenization is that a token is worthless to anyone except the gateway that generated it. So even if someone was able to hack into the POS/kiosk application and steal the token, you couldn’t turn it into a fake credit card. It is a totally useless string of numbers that can only be matched up to the card data associated with it at the payment gateway data centers. Data centers which are the gateway partner's responsibility to protect from hackers or physical security threats. Also maintaining and updating the system is their responsibility, so for example when the POODLE vulnerability was identified, Creditcall discontinued support for SSL connections and went to what is now the industry standard (TLS) in a matter of a week or so to let current customers also update to the new more secure connection type on their side. It is their job to maintain and re-certify the system, and run security checks regularly to ensure their customers that card data is protected. A partner like Creditcall also puts a disaster recovery system in place. They have four data centers (two in the US, and two in Europe) that are all set up for system redundancy, ensuring that if a fire breaks out at one data center the other three are there to pick up the slack. This allows them to ensure their customers 99.996% system uptime, and that they can continue processing thousands of transactions a second all around the world.
Unattended Card Payments Inc.
Las Vegas, NV