PCI Requirements for Service Providers: A Practical Guide
PCI requirements for service providers explained: validation levels, PCI scope, card data rules, audit evidence and a payments platform checklist.
“Use a compliant processor and complete your annual questionnaire” is incomplete advice. It skips the hardest part of PCI requirements for service providers: proving which systems affect payment security, who operates their controls, and whether those controls still work after each release.
Your validation level determines how you report compliance. Your architecture determines how much you must prove. For payments, engineering and revenue teams, the useful objective is to keep card data out of unnecessary systems and make evidence part of operating the product, not an assessment-season scramble.
Table of Contents
- Which Validation Level and Reports You Need
- What PCI DSS v4.0.1 Requires From Service Providers Today
- What Puts a System Inside Your PCI Scope
- Who Owns Which PCI Controls
- Card Data Rules for Storage, Vaulting and Retention
- Evidence to Keep Between Assessments
- Incident Response for Payment Platforms
- PCI Readiness Checklist for Payments Platforms
- Confirm Your Card Data Path and Portability This Quarter
Which Validation Level and Reports You Need
Start with transaction volume by payment brand, not the questionnaire someone used last year. The Visa service-provider validation guide sets Level 1 for providers processing or transmitting more than 300,000 Visa transactions annually, with an annual on-site assessment, ROC, AOC and quarterly ASV scans; Mastercard similarly requires an annual QSA-led ROC above 300,000 combined Mastercard and Maestro transactions annually.
Service provider validation levels and required reports
| Level | Who it applies to | Assessment | Evidence produced | Network scans |
|---|---|---|---|---|
| Level 1 (Visa) | More than 300,000 Visa transactions a year | Annual on-site assessment by a QSA | ROC and AOC | Quarterly ASV scans |
| Level 1 (Mastercard) | More than 300,000 combined Mastercard and Maestro transactions a year | Annual QSA-led assessment | ROC | Confirm applicable Mastercard scanning rules for the assessed environment |
| Level 2 (below threshold) | Below the Level 1 threshold for each brand, where self-assessment is permitted | Annual self-assessment | SAQ D for service providers and AOC | Quarterly ASV scans |
These are separate brand tests. Don't combine all card volume into a single total and assume that answers every network's classification question. Equally, don't count Visa transactions and ignore Mastercard and Maestro.
Know what each document proves
A Qualified Security Assessor (QSA) evaluates the environment and its controls. The Report on Compliance (ROC) records the detailed assessment findings, while the Attestation of Compliance (AOC) summarizes the entity's assessed compliance status and scope.
A Self-Assessment Questionnaire (SAQ) is a reporting route, not a lighter security standard. For service providers permitted to self-assess, SAQ D is the usual route. An Approved Scanning Vendor (ASV) performs external vulnerability scans; a scan report doesn't replace the broader assessment.
Before sending a customer an Attestation of Compliance, check the legal entity, assessed services and relevant locations. A document covering the wrong entity or service can stall merchant or acquirer onboarding even when another part of the business has been assessed.
Classify the service you actually operate
Calling yourself a gateway, software vendor or orchestration platform doesn't determine your obligations. A provider may transmit account data or operate security-impacting systems even when its customers outsource processing elsewhere.
Make the classification decision with your assessor and relevant payment-brand or acquiring contacts. Confirm how they count your activity, how they treat the threshold boundary, and whether your particular service requires assessor-led validation.
Practical rule: Pull a complete year of transaction counts by brand, document the counting method, and match your actual service to the reporting path before booking the assessment.
What PCI DSS v4.0.1 Requires From Service Providers Today
31 March 2025 was the deadline for future-dated PCI DSS v4.x requirements to become mandatory, and v4.0.1 didn't reset that timetable, as IBM's PCI compliance overview explains. The revision clarified wording and corrected errors rather than giving organizations a fresh implementation window.
The standard retains 12 high-level requirement areas, according to that overview. They cover the operating environment, including network security, secure configurations, account-data protection, access, logging, vulnerability management and testing.
Prove operation, not policy ownership
Service providers need to address the requirements applicable to their architecture. The SecurityMetrics service-provider FAQ highlights expectations including customer support for external penetration testing in multi-tenant environments, stronger authentication alternatives, documented cryptographic architecture, written responsibility acknowledgments, and scope confirmation at least every six months and after significant changes.
Translate those expectations into operational evidence:
- Authentication: Show how privileged access is approved, authenticated, revoked and recorded.
- Cryptography: Document where encryption happens, where keys live and who can use them.
- Tenant boundaries: Explain how testing can establish that customers remain isolated without exposing other tenants.
- Responsibility: Give customers a written statement of the security duties your service accepts.
A certificate from a previous assessment cycle doesn't prove today's routing service, checkout component or vault integration meets current requirements. Nor does a policy establish that engineers followed it during an urgent release.
Treat ongoing proof as a standing product obligation. Every payment-related change should have an owner, a scope-impact decision and retrievable evidence of the relevant tests. That's how compliance stays connected to what the business runs.
What Puts a System Inside Your PCI Scope
Your cardholder data environment (CDE) includes systems that store, process or transmit card data. Scope also reaches connected systems and systems capable of affecting that environment's security.
The PCI Security Standards Council's connected-service-provider guidance makes the important distinction: a provider can affect payment security without possessing cardholder data. “We only connect to the processor” isn't a scoping conclusion.
Trace the unexpected copies
Scoping is the work teams most often underestimate. The difficult part isn't identifying the vault. It's finding where developers, support staff and automated jobs create additional copies or security dependencies.
- Customer-facing systems: Review checkout pages, their scripts, browser components and payment APIs.
- Storage and observability: Inspect production and staging databases, backups, application logs and monitoring payloads.
- Operational workflows: Check support tools, call recordings, ticket attachments and CSV exports.
- Security-impacting access: Include deployment pipelines, administrative accounts and remote support connections.
Search sample payloads and actual workflows, not just architecture diagrams. A developer may have removed card numbers from the main database while leaving them in an error trace or failed-request queue.
Choose a smaller card-data path
Passing raw card numbers through your own servers creates the broadest direct card-data footprint and substantial assessment work. Your application, infrastructure and supporting access paths all need scrutiny.
Hosted fields can keep card entry inside provider-controlled browser components and keep numbers away from merchant servers. They narrow exposure, but they don't make the surrounding checkout page irrelevant. Review scripts and integration behavior that could affect payment security.
Agent entry into a customer relationship management system creates a different problem. If staff type card numbers into a CRM, the scope review may need to include desktops, clipboard behavior, tickets and call recordings.
A vault-token handoff or Agent Vault flow can keep raw numbers off agent screens. Understanding card tokenization helps teams design that boundary: business applications use a reference to a saved payment method rather than handling the underlying card number.
Shrink scope through architecture first. Don't build a sprawling card-data footprint and expect documentation to make it small.
Reduced exposure still leaves integration, administrative-access and monitoring responsibilities. Name the owner of each boundary and prove that the boundary works.
Who Owns Which PCI Controls
A compliant provider reduces the merchant's implementation burden. It doesn't transfer the merchant's obligations or establish that every integration choice is compliant.
Use a responsibility matrix to make the boundary explicit before anyone approves the integration.
Assign controls at service level
An AOC identifies an assessed boundary, not blanket coverage for everything a supplier sells. The Trend Micro AOC illustrates why assessed services, locations, components, responsibilities and third-party dependencies need explicit documentation.
Responsibility matrix for a payments platform
| Control area | Typical owner | Evidence to request |
|---|---|---|
| Checkout SDK and hosted fields | Shared | Provider's AOC for the SDK and hosted fields; merchant's review of its own page scripts |
| API and payment routing | Provider | AOC covering the exact API and routing services used |
| Vaulting and tokenization | Provider | Token design, key management and storage controls addressed by the assessed scope and supporting documentation |
| Hosted infrastructure | Provider | Network security, secure configuration and penetration test summary |
| Support tooling, exports and logs | Shared | Provider's access controls; merchant's rule against raw card numbers in tickets and exports |
| Agent-access workflows | Shared | Provider's multi-factor authentication and remote-access logs; merchant's agent role restrictions |
These are starting assignments, not permission to stop asking questions. A merchant-operated API proxy, custom support integration or separately managed cloud account can change the ownership split.
Shared must mean named tasks
Say a merchant adds a script that reads card-entry fields on its own checkout page. The merchant can't assume the hosted-fields provider accepts responsibility for that script. The integration needs a fresh scope review and an explicit owner for those page controls.
Record equivalent changes when data enters a hosted page, browser component, API call, call-center workflow or vault. Break “shared” into concrete tasks: who configures access, who reviews logs, who fixes defects and who supplies evidence.
Use the same control-by-control approach when discussing the flow with technical and commercial stakeholders.
Stripe can remain the processor while the platform and merchant document their respective duties. Processor selection doesn't resolve ownership of checkout scripts, support exports or agent permissions.
Draft the matrix before the next assessment. Share it with the provider and get both sides to approve the same boundary, including the escalation route when a control fails.
Card Data Rules for Storage, Vaulting and Retention
A primary account number (PAN) is the full card number. Retaining it requires protection that renders it unreadable, such as strong encryption; using a vault reference instead can keep the underlying number out of business applications.
Other data has a stricter rule. The PCI SSC self-assessment document prohibits retaining sensitive authentication data after authorization, even encrypted, including card validation codes, PIN blocks and full track data.
What you can store after authorization
| Data element | Stored after authorization? | Practical rule |
|---|---|---|
| Full card number (PAN) | Only when rendered unreadable, such as tokenized or encrypted | Keep tokens in your systems and the number in a PCI-compliant vault |
| Card validation code (CVV, CVC, CID) | No, never after authorization | Recurring billing should rely on the token, not a stored code |
| PIN or encrypted PIN block | No | Never store after authorization |
| Full magnetic-stripe or chip track data | No | Never store after authorization |
| Cardholder name and expiry date | Yes, when protected and justified | Keep only the fields the business uses |
| Retention period for any location | Defined per location, deleted when it expires | Verify deletion at least every three months |
Don't turn a retry mechanism into prohibited storage
CVV, CVC and CID are card validation codes. They aren't reusable subscription credentials, and encrypting them doesn't make post-authorization retention acceptable.
Inspect retry queues, request bodies and debugging tools for accidental retention. A recurring payment should use a permitted saved credential or token, not retrieve a validation code from the original checkout.
The limited issuing-services exception isn't a general permission for orchestration platforms or subscription merchants. Don't apply it to ordinary recurring billing.
Give every copy an expiry
The PCI DSS retention guidance in SAQ A calls for documented retention periods and justifications for stored account data, with verification at least once every three months that expired data has been deleted or rendered unrecoverable.
Apply that process to backups, logs, support tools and storage services, not just the payment database. Where a backup can't support selective deletion, document its expiry controls and how restoration avoids reintroducing data that should no longer be retained.
A credit card vault separates reusable payment references from protected card storage. That separation is valuable operationally, but portability is a separate design question.
If every saved credential is usable only inside Stripe, a processor problem can become a recurring-revenue problem. Flo Vault gives merchants a processor-neutral, PCI-compliant card-on-file layer, making saved payment methods portable across supported providers. Confirm provider coverage and migration conditions before relying on fallback.
Evidence to Keep Between Assessments
A static AOC describes an assessed state. It doesn't establish that a subsequent checkout release, routing change or support integration preserved that state.
Keep an evidence register with an owner, storage location and refresh trigger for each artifact. Use the following as an operating schedule, then have your assessor confirm the requirements applicable to your environment.
Evidence to hold between assessments
| Artifact | What it proves | Refresh cadence |
|---|---|---|
| Attestation of Compliance (AOC) | Validation for the exact assessed services | Annually |
| Report on Compliance extract or SAQ | Assessed controls and the boundary they cover | Annually |
| ASV scan reports | External network vulnerabilities were scanned and reviewed | Quarterly |
| Responsibility matrix | Who owns each applicable requirement | At least annually and after significant change |
| Scope confirmation record | CDE boundaries still match reality | Every six months and after significant change |
| Penetration test summary | Testing performed, weaknesses identified and remediation status | Annually and after significant change |
| Access logs and MFA records for remote access | Who reached provider and merchant systems | Continuously captured, reviewed on a defined cycle |
Make evidence obtainable by contract
Reuters Practical Law's PCI DSS guidance describes Requirement 12.8 provider governance, including inventory, pre-engagement due diligence, written responsibility agreements and compliance monitoring at least annually, alongside 12.9.2 support for customers' reporting-information requests.
Don't wait until customer onboarding to discover that a supplier won't provide the necessary documentation. Contracts and operating procedures should address:
- Data responsibilities: Whether the provider stores or transmits account data, and who operates tokenization and key management.
- Incident cooperation: Notification windows, forensic access and evidence-preservation procedures.
- Supplier dependencies: Subcontractor disclosure and controls covering failover processors.
- Lifecycle controls: Retention, deletion and agent-assisted access restrictions.
- Reporting access: AOC or ROC availability and a process for answering customer scope questions.
Reconcile the AOC against the services and configurations purchased. A compliant cloud environment isn't evidence that the provider's payment application, support tooling and routing service were all assessed.
Release gate: Don't close a payment-related change until the team has recorded its scope impact and stored the supporting evidence.
Version data-flow diagrams and responsibility matrices alongside architecture changes. Link the release ticket to relevant tests, approvals and access changes so customer-facing teams can answer questions without assembling a last-minute evidence bundle.
Incident Response for Payment Platforms
A payment-data incident needs an executable plan, not an informal escalation channel. Under Requirement 12.10, the PCI incident-response guidance calls for a plan tested at least once every 12 months, supported by designated responders available 24/7.
Business-hours engineering cover doesn't meet that operational need. Responders need training, security-alert handling procedures and a process for incorporating lessons learned, including specific action when stored card numbers appear somewhere they shouldn't.
Run the first response in a controlled sequence
-
Activate and isolate. Assign an incident lead and restrict affected systems, credentials or export functions. Choose containment that stops further exposure without unnecessarily disrupting unaffected payment paths.
-
Preserve evidence. Secure relevant logs, access records and configuration snapshots before routine processes overwrite them. Don't let an eager cleanup destroy the evidence needed to establish what happened.
-
Establish the exposure. Determine which data elements were present, where they traveled and who could access them. Distinguish unexpected storage from confirmed unauthorized access, while continuing to investigate both.
-
Coordinate notification. Follow contractual escalation windows and the applicable customer, acquirer and payment-brand procedures. Give verified facts, identify uncertainties and keep a record of communications.
-
Restore and verify. Remove the cause, validate the corrected controls and restore payment operations through an approved path. Routing elsewhere is appropriate only when the alternative remains outside the compromised boundary.
Test an ordinary operational failure
Say a support analyst discovers a full card number in a downloadable case export. The team should know who can disable exports, restrict the file, preserve access history and establish whether copies exist elsewhere.
Don't delete the original and close the ticket. Check attachments, downloaded copies, integrations and retention jobs, then coordinate secure removal with evidence-preservation needs.
The exercise should also test commercial decisions. Who tells merchants that a support function is unavailable? Who confirms that checkout can continue safely? Who authorizes recovery?
Finish with named out-of-hours contacts, a recorded test date and the contractual notification window. If the team can't retrieve those quickly, the plan isn't operationally ready.
PCI Readiness Checklist for Payments Platforms
Work through these checks in order. Give each action a named owner and link the result to the evidence register, rather than marking it complete in an isolated spreadsheet.
Establish the boundary
-
Confirm your validation level using a complete annual transaction record by brand.
Common slip: counting only a single network. Use Which Validation Level and Reports You Need to check the reporting path. -
Inventory every card-data flow from checkout through vaulting, support, exports and backups.
Common slip: omitting downloadable exports. Use What Puts a System Inside Your PCI Scope to trace secondary copies. -
Draw the boundary around connected and security-impacting systems.
Common slip: treating connectivity as harmless because no card numbers are stored. Apply the security-impact test in What Puts a System Inside Your PCI Scope. -
Choose the card-data path for each workflow and remove unnecessary raw-number handling.
Common slip: leaving a legacy support path outside the redesign. Compare the entry paths in What Puts a System Inside Your PCI Scope. -
Check that validation codes, PIN data and track data aren't retained after authorization.
Common slip: a code surviving in a retry queue or log. Use Card Data Rules for Storage, Vaulting and Retention.
Make the boundary provable
-
Assign retention periods and schedule recurring deletion verification for every storage location.
Common slip: leaving backups out. Follow the storage-location approach in Card Data Rules for Storage, Vaulting and Retention. -
Approve the responsibility matrix and supporting contract clauses.
Common slip: accepting an AOC for a different service. Use Who Owns Which PCI Controls and Evidence to Keep Between Assessments. -
Collect evidence artifacts and assign their refresh triggers.
Common slip: assuming an AOC proves every later configuration remains covered. Use Evidence to Keep Between Assessments. -
Test the incident plan and verify out-of-hours contacts.
Common slip: naming responders who can't be reached. Record the results using Incident Response for Payment Platforms. -
Review scope when releases touch routing, checkout SDKs, vaulting or agent access.
Common slip: adding a raw-data logging field. Apply the change discipline in What PCI DSS v4.0.1 Requires From Service Providers Today.
Readiness means the boundary, responsibility matrix and evidence match the production service, not merely that every checklist box has a tick.
Confirm Your Card Data Path and Portability This Quarter
Processor continuity depends on how saved payment methods are stored and routed, not just on adding a second gateway. Trace the card-data path before committing to a fallback plan.
Stripe can remain part of your payment setup when it suits your business. Avoid making any single processor the only route for recurring payments.
Ask questions that change the decision
Can saved payment methods be used with another supported processor without asking customers to enter them again? Ask how routing or migration works in your integration. Check token compatibility, contractual permissions and implementation dependencies before treating a fallback as available.
Which systems, tickets and exports handle card data? Build a current flow map with input from support, engineering and payment operations. Include active exports and agent workflows, not just checkout and billing systems.
Does the provider's AOC cover the exact services you use? Match the assessed services and legal entity to your contract and production configuration. Resolve gaps before expanding the integration or promising payment continuity.
Buy resilience with clear boundaries
Processor-agnostic routing and secure payment data vaulting can reduce reliance on one provider, but they do not guarantee authorization or make every saved credential interchangeable. Confirm how each provider handles vaulted payment data and what your integration supports.
FloPay combines checkout, payment routing and secure payment data vaulting through one SDK and API across supported providers. Its Agent Vault also supports secure payment handling in agent-assisted flows. Treat these capabilities as part of your architecture review, not as proof that a particular integration meets PCI requirements.
Bring the payment, engineering and operations owners together. Trace an initial checkout and a subscription rebill, then check each flow against your scope map and evidence register.
Contact FloPay to discuss how saved payment methods are stored and routed in your integration.