PCI Standards Background and Rationale

Between 2005 and the end of 2024, over 3,158 distinct data breaches in the United States have exposed more than 1.35 billion consumer records, underscoring the growing threat to personal information. In response, the major card brands established the Payment Card Industry Security Standards Council (PCI SSC) in 2006 to develop unified data security requirements known as the PCI DSS.

The PCI DSS is the globally recognized baseline for any organization that stores, processes, or transmits payment-card data. It establishes:
1. Secure Data Collection: All card-entry points must ensure sensitive details never travel through insecure channels.
2. Robust Storage Controls: Encryption, continuous monitoring, and regular security testing across the 12 PCI domains.
3. Annual Validation: Organizations must demonstrate, through self-assessments, external scans, and qualified audits, that controls remain effective.

Any business that accepts credit card payments is required to comply with PCI DSS, as non-compliance carries steep fines and possible reputational damage. At the same time, compliance builds customer confidence and reduces fraud losses.

How KUBRA Reduces Your PCI Burden

Achieving full PCI DSS compliance can mean addressing over 300 individual security controls across more than 1,800 pages of guidance. KUBRA minimizes this scope by:

- Tokenization-First Integrations: Card data is processed through KUBRA’s variety of tokenized and PCI-validated integration models, including KUBRA EZ-PAY+™, KUBRA HQ™, KUBRA iDoxs®, KUBRA SHIELD-PAY™, and mobile SDKs, helping you avoid the need to handle sensitive credit card data.

- Guidance: KUBRA analyzes your integration and recommends the correct Self-Assessment Questionnaire (SAQ).

- QSA Connections: If you need to work with a PCI Qualified Security Assessor (QSA), you can consult one of the 400+ certified PCI Qualified Security Assessors worldwide.

A Guide to Meeting PCI-DSS Requirements

1. Understand your PCI level

The initial step toward PCI compliance is to determine which specific standards your organization must meet. PCI outlines four distinct compliance tiers/levels, which are assigned based on the total number of credit card transactions your business processes over a 12-month span.

When working toward PCI DSS compliance, it is important to determine whether your organization is classified as a merchant, a service provider, or, in some cases, both. These classifications determine your compliance responsibilities and the scope of your PCI DSS validation. A merchant is any entity that accepts payment cards (credit, debit, or prepaid) bearing the logos of the card brands (e.g., Visa, Mastercard, American Express, Discover) as payment for goods or services. Examples include a retail store with a POS terminal, an e-commerce site selling products/services, or a subscription service billing cards directly. A service provider is any entity that stores, processes, or transmits cardholder data on behalf of another organization or that manages components of a cardholder data environment (CDE). This also includes companies that provide security services, managed hosting, or payment gateways. Examples include a payment gateway or a managed hosting provider that supports card payment systems. As an organization, consider identifying all your payment channels to determine whether you are a merchant, a service provider, or both.

Your obligations are dependent on your compliance tier/level, including regular vulnerability scans from an Approved Scanning Vendor (ASV). There are also additional requirements for service providers, which are organizations directly involved in the processing, storage, or transmission of cardholder data (CHD) and/or sensitive authentication data (SAD) on behalf of another organization (e.g., payment gateways, payment service providers, and independent sales organizations).

Compliance Level for Merchants

Compliance level

Applies to

Requirements

Level 1

- Organizations that annually process more than 6 million Visa or Mastercard transactions, or more than 2.5 million American Express transactions: or

- Have experienced a data breach;or

- Are deemed “Level 1” by any card association (Visa, Mastercard, etc.)

 

- Attestation of Compliance (AOC) and annual Report on Compliance (ROC) produced by a Qualified Security Assessor (QSA)-led Level 1 Audit.

- Quarterly network scan by an Approved Scanning Vendor (ASV)

Level 2

- Organizations that process between 1–6 million transactions annually

- Self-Assessment Questionnaire (SAQ), or Attestation of Compliance (AOC), or Report on Compliance (ROC)

- SAQ A, SAQ A-EP, and SAQ D documentation must be signed by a PCI Qualified Security Assessor (QSA) or a PCI-Certified Internal Security Assessor (ISA).1

- Quarterly network scan by an Approved Scanning Vendor (ASV)

 

Level 3

- Organizations that process between 20,000–1 million online transactions annually

- Organizations that process fewer than 1 million total transactions annually

- May include completing one or more self-attested PCI DSS Self-Assessment Questionnaires (SAQs).

- Level 3 users must also complete quarterly network scans by an Approved Scanning Vendor (ASV).

 

Level 4

- Organizations that process fewer than 20,000 online transactions annually: or

- Organizations that process up to 1 million total transactions annually

- Annual completion of  PCI DSS Self-Assessment Questionnaires (SAQs), depending on how the merchant processes cards.

- Level 4 users must also complete quarterly network scans by an Approved Scanning Vendor (ASV), if applicable.

 

1 Level 2 merchants completing SAQ A, SAQ A-EP, or SAQ D are required to have their compliance validated by a QSA.

Compliance Level for Service Providers

Compliance level

Applies to

Requirements

Level 1

- More than 300,000 card transactions per year.

 

- Annual onsite assessment by a QSA

- Submission of a Report on Compliance (ROC)

- Quarterly ASV network scans

 

Level 2

- 300,000 or fewer card transactions per year

-Completion of a Self-Assessment Questionnaire (SAQ)

- Quarterly ASV network scans

- Some brands may require a QSA-led assessment depending on risk

 

 

2. Know your integration type and documentation requirements

Once you are familiar with your PCI level, the next step is to determine which PCI documents are required to validate your compliance, based on the type of integration you use with KUBRA.

Level 1 Users

Level 1 businesses are NOT eligible to use an SAQ to prove PCI compliance. They will be required to engage a PCI-certified company to conduct a QSA-led PCI-DSS audit to attain a Report on Compliance (ROC) and an Attestation of Compliance (AOC).

Level 2-4 Users

For Level 2-4 users, there are different SAQ types depending on your payment integration method. If you are unsure what SAQ type is right for you, the table below details KUBRA’s product offerings based on their integration types, which will help you determine the type of documentation that is appropriate for your business. If your organization uses other payment channels, these SAQ suggestions may not be applicable, and you may have to consult a QSA company.

 

KUBRA HQ Platform Product Name

Integration

Requirement

Description

EZ-PAY+TM, MyHQ+TM, BizHQ+TM

(BDX, BDE, MyHQ, iDoxs® User Console)

 

URL Redirection

SAQ A

Cardholders are redirected off-site to a KUBRA-hosted checkout page. No card data touches your servers.

KUBRA HQ SDK

(if used with iFrame, JavaScript) (SHIELD-PAY)

Inline Frame (iFrame)/JavaScript Forms

SAQ A/SAQ A-EP

Your site embeds KUBRA’s payment form in an iFrame. All card entry/transmission remains within KUBRA’s iFrame, or you use a web-based JavaScript library to allow customers to save bank and credit accounts with KUBRA, or process one-time payments.

 

Mobile SDK

Mobile SDK

SAQ A

KUBRA’s mobile SDK development and change control complies with PCI DSS (requirements 6.3–6.5) and uses our PCI-validated systems. When you use only UI components from our official SDKs for iOS or Android, card numbers are passed directly from your customers to KUBRA, resulting in the lightest PCI compliance burden.

The KUBRA SDK communicates directly with KUBRA backend services. If your application requires your customers to enter their information on their own devices, then you qualify for SAQ A.

 

IVR+

(Interactive Voice Response)

IVR (Interactive Voice Response)

SAQ A

The caller enters card details via phone keypad on a KUBRA-hosted IVR system. No card data flows through your systems.

Or

A caller chooses to make a bank payment, and you collect the bank details directly from the user before passing those details to KUBRA via WCF/SOAP API/.

 

CSR Assisted Payments

Call Center

SAQ A

Customer Service Representatives (CSRs) guide users to enter card data into a KUBRA-hosted, PCI-validated interface using their phone keypad. No card data hits your systems.

Or

CSRs ask users to speak card details while they key in the details on behalf of the user.

 

KUBRA HQ SDK

(Direct API - Merchant Gateway with third-party APIs)

 

Direct API (Merchant Gateway with third-party APIs)

SAQ D

When your back end collects card data and transmits via KUBRA’s server-to-server API, you’re fully in scope for controls, and you’re required to annually prove your PCI compliance using theSAQ D– the most demanding of the SAQs.

 

 

Completing and Submitting Your Assessment

1. Gather Documentation: Identify the correct SAQ based on level and integration.
2. Engage a QSA if Needed: High-volume or direct-API merchants should work with a PCI QSA.

Ongoing Monitoring and Evolution

PCI compliance is not a one-and-done task. As you expand—adding new payment flows, markets, or customer-service channels—you must:
- Reassess Integration Scope: Any new card-data touchpoint may change your SAQ requirements.
- Maintain Quarterly Scans and Annual Audits: Ensure emergent vulnerabilities are caught early.
- Leverage Tokenization: Whenever possible, shift to methods that never expose raw card data.