PCI Data Security Standards
Highnote subscribers who access sensitive payment data from their own servers, must be fully PCI compliant. Consider using the Highnote SDKs to reduce your PCI compliance requirements.
Payment Card Industry Data Security Standards, or PCI DSS, are designed to protect payment data throughout the payment lifecycle. How you process and access PCI data will determine your compliance requirements.
There are different levels of compliance (usually 4 for merchants and 2 for service providers). The PCI Security Standards Council (PCI SSC) develops and maintains standards for each level; and each card network defines their own specific requirements based on those standards.
All levels of PCI compliance require an Attestation of Compliance (AOC). Full PCI DSS compliance requires a Report on Compliance (ROC) and an AOC signed by a Qualified Security Assessor (QSA). Lower levels of compliance require a Self-Assessment Questionnaire (SAQ) and a self-signed AOC.
-
SAQ-A: Typically used for merchants who fully outsource all cardholder data functions to PCI DSS validated third-party service providers, and have no electronic storage, processing, or transmission of any cardholder data on their systems or premises.
-
SAQ-D: Typically used for merchants who don't qualify for any other SAQ and handle cardholder data themselves; or for service providers who handle their own cardholder data and may store it electronically.
Typical Merchant Compliance Levels
| Levels | Transactions Per Year | Requirements |
|---|---|---|
| Level 1 | 6 million | Annual ROC + AOC signed by QSA, Quarterly scans by ASV |
| Level 2 | 1-6 million | Annual SAQ + self-signed AOC, Quarterly scans by ASV |
| Level 3 | 20,000-1 million e-commerce | Annual SAQ + self-signed AOC, Quarterly scans by ASV |
| Level 4 | Up to 20k e-commerce, or 1 mil regular | Annual SAQ + self-signed AOC, Quarterly scans by ASV |
Typical Service Provider Compliance Levels
| Levels | Transactions Per Year | Requirements |
|---|---|---|
| Level 1 | 300,000 | Annual ROC + AOC signed by QSA, Quarterly scans by ASV |
| Level 2 | Up to 300,000 | Annual SAQ-D + self-signed AOC, Quarterly scans by ASV |
Highnote SDKs can significantly reduce your PCI compliance requirements.
Highnote SDKs enable you to handle payment data without having PCI-scoped data flowing through your systems.
Subscribers who are SAQ-A compliant, and want to maintain that compliance, should tokenize payment data with the Highnote Checkout SDK, or more customizable Secure Inputs SDK. Subscribers who are SAQ-D compliant, and already store PCI data securely, can bypass tokenization.
Issuing
- Card Viewer SDK - Embed sensitive card data into your UI using iframes.
- Secure Inputs (PIN) SDK - Securely set and update PIN data from your UI using iframes.
Acquiring
- Checkout SDK - Simple embedded checkout UI to accept payment card information.
- Secure Inputs (Tokenization) SDK - Customized checkout UI to tokenize payment method details.
When analyzing your compliance needs, start by asking the following:
Question 1: Will you handle sensitive cardholder payment data (possibly with the Highnote PaymentCardRestrictedDetails object) on your own servers?
- If YES: Establish SAQ-D compliance at a minimum, or full Level 1 if you have high transaction processing volumes.
- If NO: Use the Highnote SDKs to maintain your SAQ-A compliance (and continue to question 2).
Question 2: Will you customize your payment and card experience for customers?
- If NO: Use the Highnote Checkout SDK (acquirers) or Card Viewer SDK (issuers) to maintain your SAQ-A compliance.
- If YES: Use the Highnote Secure Inputs tokenization or PIN SDKs to maintain your SAQ-A compliance.
For Issuers
| Solution | Purpose | Compliance Requirements | Best For |
|---|---|---|---|
| Card Viewer SDK | Embed viewer solution to display sensitive card data in your UI through iframes | PCI data never crosses your server. Maintains PCI SAQ-A compliance. | Issuers wanting to display card details without handling PCI data |
| Secure Inputs SDK (PIN) | Customize your UI so customers can securely input sensitive data | PCI data never crosses your server. Maintains PCI SAQ-A compliance. | Issuers requiring customized PIN management solution while maintaining SAQ-A compliance |
For Acquirers
| Solution | Purpose | Compliance Requirements | Best For |
|---|---|---|---|
| Checkout SDK (with tokenization) | Embed checkout solution to securely accept payment card details | PCI data never crosses your server. Maintains PCI SAQ-A compliance. | Merchants wanting simple, compliant checkout with minimal integration effort |
| Secure Inputs SDK (Tokenization) | Customize your UI to securely accept payment card details | PCI data never crosses your server. Maintains PCI SAQ-A compliance. | Merchants requiring customized checkout while maintaining SAQ-A compliance |
| Direct API Integration (no tokenization) | Server-to-server processing of card data | Requires SAQ-D compliance at minimum. May require full Level 1 PCI compliance with QSA assessment for high volumes. Your servers must securely store and handle PCI data. | Merchants already PCI SAQ-D compliant who want to bypass tokenization |