PCI DSS for Payment Aggregators, Gateways and Processors

Payment aggregators and gateways sit in the card flow, which makes them service providers under PCI DSS rather than merchants — a different validation path, different levels and, in India, a simultaneous RBI PA-PG authorisation obligation that shares much of the same evidence.

What PCI DSS requires of payment companies

Service-provider level determination based on transaction volume, which decides whether a ROC is required.
A cardholder data environment defined by actual data flow, not by network diagram — aggregators routinely discover card data in logs and support tooling.
Quarterly ASV scanning and annual penetration testing, including segmentation testing where segmentation is claimed for scope reduction.
Requirement 12 governance obligations that are heavier for service providers than merchants, including a documented PCI DSS compliance programme.
Alignment with RBI PA-PG authorisation conditions, which overlap PCI DSS substantially but are audited separately.

Evidence assessors actually ask for

Documentation is rarely the blocker — evidence that controls genuinely operate is. These are the artefacts requested first in this sector.

Attestation of Compliance and the Report on Compliance signed by a QSA
Segmentation test results proving the CDE boundary holds
ASV scan history showing four consecutive passing quarters
Data-flow diagrams reconciled against actual traffic, not against design intent
Evidence of the service-provider governance requirements operating quarterly

Where payment companies usually come unstuck

Assuming merchant SAQ eligibility when acting as a service provider.
Claiming segmentation for scope reduction without segmentation testing to prove it.
Card data in application logs, support tickets and analytics — the most common late discovery.