Why PCI compliant APIs are not always enough

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.