How does a PayFac prove PCI compliance for its merchants?

Short answer

The PayFac validates itself as a service provider, with an annual ROC and AOC by a QSA above 300,000 Visa transactions a year, and collects each sub-merchant’s SAQ and AOC at onboarding. Using hosted pages and a tokenized vault keeps merchants in SAQ A; hosted checkout pages are the usual tool.

In detail

The PayFac validates itself as a service provider, with an annual ROC and AOC by a QSA above 300,000 Visa transactions a year, and collects each sub-merchant’s SAQ and AOC at onboarding. Using hosted pages and a tokenized vault keeps merchants in SAQ A; hosted checkout pages are the usual tool.

Validation as a service provider

A PSP, PayFac or white-label platform that handles card data for merchants is a service provider, with its own validation. Visa sets Level 1 at more than 300,000 Visa transactions a year, with an annual on-site assessment by a QSA, an AOC signed by both, and quarterly ASV scans; Level 2 providers submit an annual SAQ D for service providers. Visa lists validated providers on its Global Registry of Service Providers, and that AOC is the document a merchant needs to confirm its provider is PCI DSS compliant.

Keeping sub-merchants in SAQ A

Acquirers hold PayFacs and PSPs responsible for the compliance of their sub-merchants. A platform that serves hosted payment pages and hosted fields from its own PCI DSS validated infrastructure keeps card data out of the merchant’s systems, so the merchant qualifies for SAQ A. The onboarding file should record which integration each merchant uses, derive the SAQ type from it, and collect the signed AOC with its expiry date.

More detail in our #PayDecoding episode on PCI DSS SAQ.

Still have a question?

Our team walks you through the platform with your use case on the table.

Book a demo