如果您将所有持卡人数据外包给第三方并且您自己要求合规，则 SAQ A 的适用要求适用于您。虽然 PCI DSS 包含大量要求（即 SAQ D），但如果您不处理持卡人数据，其中绝大多数将不适用于您。根据数量，您可能没有资格完成 SAQ。在这种情况下，您将在 ROC（合规性报告）中有完整的执行摘要，并且只有适用于您的要求才会得到验证。

如果您希望传输、处理或存储持卡人数据，该标准的许多要求将适用于验证，但合规的成本和时间会增加，但最终可能会给您更大的自由度（并使您面临更大的风险）。

如果您的客户处理持卡人数据，他们需要合规。如果他们将此外包给您，您需要向他们证明您是合规的。当然，您可以进一步将其转让给另一个合规的第三方。例如，商户 A 可以使用服务商 B，服务商 B 使用服务商 C 来处理商户 A 的持卡人数据。在这种情况下，商家和两个服务提供商都需要合规，尽管只有一个实体，服务提供商 C，处理持卡人数据。

如果 CC 数据从未接触过您的服务器，那么您就不会是 (PCI) 服务提供商，所以不——相同级别的合规性要求不适用于这两种情况。（也就是说，SAQ D 涵盖了大多数情况，所以是的，它涵盖了广泛的参与）。

是的，您的客户在收集数据时需要具备一定程度的 PCI 合规性。根据定义：

PCI DSS 适用于参与支付卡处理的所有实体，包括商家、处理商、金融机构和服务提供商，以及存储、处理或传输持卡人数据和/或敏感身份验证数据的所有其他实体。

您想考虑与服务提供商合作，以使自己尽可能远离循环。如果您是 SaaS 提供商，请专注于 S 和 S 而不是 CC。

更新下面的评论

我觉得我们这里没有所有信息。

如果您是 SaaS 提供商，则该软件是“集中托管”的，这意味着它在您的服务器上运行。如果该软件随后存储、处理或传输卡数据，那么您就是 PCI 实体，需要弄清楚您在合规世界中的位置。您可能能够从您的收单方或处理方那里获得帮助，以确定您的合规性要求是什么（如果没有收单方或处理方，您将无法对这些卡做任何事情，他们是（例如）收集您的 SAQ 和，希望能帮助您确定哪一个适用）。

如果您只是为其他人提供在他们的系统上运行的软件，并且想要添加与信用卡相关的功能，那么您可能会误入PA-DSS领域——“开发支付应用程序的软件供应商的权威数据标准”。那是更复杂的领域。

如果您正在将其他人的软件（例如处理器的 API）集成到您自己的软件中，那么我根本不知道，但同样，提供 API 的处理器应就使用其软件的人的 PCI 义务提供指导。我在那里没有深度，不能说太多用处。

至于您的评论“很难看到您适合的位置”-系统非常复杂；从 Wikipedia on Processor Vantiv考虑这一点：“支付接受的另一种演变形式是集成软件提供商 (ISP)、支付服务商 (PayFacs) 和增值经销商 (VAR)。” 我相信 PayFacs 至少属于商家而不是服务提供商。我检查了一下，PayFacs 至少属于服务提供商（我在 Vantiv 工作并询问了合规部门的同事）。这又去 - 再次 - 与您的处理器或收购方交谈。它们可能有帮助，也可能没有帮助，但它们是一个开始。

我的想法：这是一个很好的链接，可以解释不同的 SAQ 级别。如果您是服务提供者，您需要填写服务提供者的SAQ D。您的客户在收集 CC 数据时肯定需要获得 PCI 合规性。

另一件可能对您有所帮助的事情是此链接上的 PCI 第三方安全保证信息补充文档。

我同意上述答案，最好询问处理方/收单方。