SOC 2 Audits for Payments Companies
Merchants, platforms embedding your checkout, acquiring banks, and card networks all run security reviews before they route authorization or settlement through you. Here is how payments companies scope the audit — criteria, the PCI overlap, controls, and cost.
Why payments companies get asked for SOC 2
Payments companies sit between the most demanding reviewers in the ecosystem: acquiring banks and sponsor institutions with regulator-driven vendor programs, card networks with their own compliance regimes, and platform partners (marketplaces, SaaS embedding payments) whose own auditors ask about the vendors that touch their buyers' cards. A gateway, facilitator, or payfac relationship almost always carries a due-diligence questionnaire where a current SOC 2 Type 2 sits next to an Attestation of Compliance, not instead of it.
The data and the stakes are specific: primary account numbers, tokens, settlement and payout instructions, chargeback and dispute records, and 3-D Secure results. Reviewers want evidence that authorization, capture, and settlement are complete and accurate, and that a payout can't be initiated and approved by the same hand — which is why Processing Integrity and tight access control around money movement dominate a payments audit far more than a generic SaaS review.
Trust Services Criteria focus for Payments
Security (the Common Criteria) is mandatory in every SOC 2 report. The other four criteria are elective — you scope them in based on what your customers actually rely on. Here is how payments companies typically scope them, and why:
| Criterion | Typical scope | Why it matters in Payments |
|---|---|---|
| Security | Always in scope | Mandatory in every SOC 2. For payments, expect deep scrutiny on cardholder-data access, tokenization key management, and change control around authorization and settlement services. |
| Availability | Usually in scope | Authorization is latency- and uptime-sensitive; a declined or timed-out transaction is lost revenue for your merchants, so partners expect tested failover, capacity, and incident evidence. |
| Confidentiality | Usually in scope | Tokens, settlement files, and merchant contracts are confidential by agreement. Reviewers look for classification, encryption, and retention controls over cardholder and payout data. |
| Processing Integrity | Common | Central for payments: partners want proof that captures, refunds, and settlement amounts are complete and accurate, with idempotent processing, reconciliation against processor reports, and exception handling. |
| Privacy | Sometimes | Scoped in when you hold consumer PII beyond the card itself — billing profiles, dispute correspondence. Many payments infrastructure firms handle this contractually and leave Privacy out of the report. |
Each elective criterion adds controls and evidence — and cost. Scope what your customers demand in security reviews, not everything at once.
Scoping decisions specific to Payments
These are the Payments-specific calls that shape your system description, control list, and ultimately your audit price. Settle them before you request quotes — firms price scope, not industry labels.
Align the SOC 2 boundary with your PCI cardholder-data environment
Decide whether the audited system spans the full cardholder-data environment or a de-scoped surface behind a tokenizing processor. Where the two boundaries diverge, reviewers notice — draw the SOC 2 system boundary so the money-touching services your partners consume are unambiguously inside it.
Your role (gateway, processor, or facilitator) sets who owns which controls
A gateway passing tokens owns different controls than a payment facilitator underwriting sub-merchants or a processor settling funds. Name your role explicitly in the system description so auditors test the controls you actually operate rather than ones your upstream bank owns.
Settlement, payout timing, and dispute handling as tested processes
If Processing Integrity is in scope, auditors sample settlement runs, payout batches, refund flows, and chargeback adjudication. Automate reconciliation against network and processor reports and keep exception queues — payout timing errors are a recurring audit finding.
Acquiring bank, card networks, and fraud vendors as subservice organizations
Your sponsor/acquiring bank, the card networks, cloud host, and 3-D Secure or fraud-scoring vendors are typically carved out. Map which commitments (settlement finality, uptime, fraud decisioning) depend on them and document the complementary controls you rely on them for.
Encryption and tokenization key management evidence
Auditors expect to see key generation, rotation, and access controls for the keys protecting card data — often HSM- or KMS-backed. Who can access key material, and how dual control is enforced, is sampled directly, so lock this down before the observation window opens.
Segregation of duties around initiating and approving movement of funds
Partners expect that the engineer who can trigger a payout cannot also approve it, and that manual fund movements require a second reviewer. Small teams pass this with enforced maker-checker workflows, approval gates, and immutable logging rather than headcount.
What a SOC 2 audit costs for payments companies
These are first-party published rates from accredited firms on the AuditNex network — actual prices, not survey estimates. Data as of 2026-07-26.
Quote requests priced at network rates: Withheld — 2 samples, below our 5-sample minimum.
Frameworks payments companies pair with SOC 2
SOC 2 is rarely the only requirement in this category. These are the frameworks most often pursued alongside it — and overlapping evidence you can reuse if you plan both from the start:
| Framework | Why it comes up alongside SOC 2 |
|---|---|
| PCI DSS | The baseline for anyone storing, processing, or transmitting card data. Scope your cardholder-data environment tightly and reuse segmentation, encryption, access-control, and logging evidence across both the AoC and the SOC 2. |
| ISO 27001 | Comes up as you sell into European acquirers and platforms that ask for certification. The control overlap with SOC 2 is large; many payments firms run both engagements on one evidence base. |
| Penetration testing | Both PCI DSS and partner questionnaires expect a recent independent test of the payment stack. Scheduling it inside the SOC 2 observation window lets one engagement answer several requests. |
Finding an auditor who knows Payments
Best SOC 2 auditors for fintech › · All auditor profiles › · How we verify auditors ›
SOC 2 for Payments: common questions
Does SOC 2 replace PCI DSS for a payments company?
No — they answer different questions and reviewers ask for both. PCI DSS validates that you protect cardholder data to the networks' specific requirements, while SOC 2 attests to your broader control environment over an observation window. A payments company touching card data typically maintains a current PCI Attestation of Compliance and a SOC 2 Type 2 side by side.
Should a payments platform include Processing Integrity?
If partners rely on you to capture, refund, or settle funds accurately, expect the question in due diligence. Including Processing Integrity adds reconciliation, idempotency, and settlement-accuracy controls to the audit, which costs more but tends to end recurring back-and-forth with acquiring banks. A pure tokenization vault that never moves money may leave it out.
Can we reduce SOC 2 scope by using a tokenizing processor?
Using a processor that tokenizes cards can shrink your cardholder-data environment for PCI, and that de-scoping often simplifies the SOC 2 boundary too. It doesn't remove your own controls from scope — access management, change control, and reconciliation of the token and settlement flows you operate are still tested. Document which services are carved out to the processor as a subservice organization.
Do our merchants and platform partners accept a SOC 2 Type 1?
A Type 1 can unblock a partnership stalled on paperwork, but acquiring banks and larger platforms almost always want Type 2 because it shows the money-movement controls operated over time. A common path is a Type 1 first to establish design, then convert to Type 2 on the same control set for the next cycle.
Get SOC 2 quotes scoped for Payments
Answer five questions once — we’ll show accredited auditors that fit your scope, with transparent pricing and no sales calls. Scope it the way this guide describes: report type, criteria mix, and timeline are what drive your quotes.
Start a quote →