An all too common misconception these days is that if you are processing online payments with a secure payment gateway you are automatically PCI-DSS compliant. This is not necessarily the case, especially if you are solely using the payment gateway’s API (Application Programming Interface).
PCI-DSS applies to all organisations which store, process, or transmit cardholder information and an API is a connection between where the credit card information is captured and where it ends up for processing.
So, if you are using an API from a PCI-DSS compliant payment gateway, then you can assume that:
- the API connection is secure
- the engine processing the card information is PCI-DSS compliant
as both reside in the payment gateway’s secure environment. That means the “transmit” and “process” to the payment gateway are covered from PCI-DSS perspective.
However the capture point is another story.
Building a web page to cater for online payment or e-commerce is very straightforward these days. Building it so it is PCI-DSS compliant is very different. A credit card number can be intercepted before entering the API if the initial capture point is not PCI-DSS compliant. This makes your website, development process and internal systems (including data and log files) very much in scope for PCI-DSS.
An API is effectively the span of the bridge to compliance. A bridge links two destinations. If one side is not as solid (“secure”), then the entire structure of the bridge (“your system”) is potentially at risk.
There are many options to address this, from using tokenisation, to embedded iframes in a web page, or payment pages depending on you requirements and environment. Check with your payment gateway what they can provide and if this is the best mechanism for you to capture the credit card at the point of entry. And from a PCI-DSS perspective, there are some simple steps that you can take to protect your organisation and your customers.