如果您开发了涉及支付的自研工具，合规风险由谁承担？

答案是您自己。不是生成代码的 AI，不是您的托管服务商，也不是您的支付服务商。在您开发的工具涉及支付的那一刻起，合规风险就落在了您的企业身上，无论您接入了多少家合规的供应商，这一事实都不会改变。您能改变的是风险的大小，而一个设计精良的定制工具与一个粗制滥造的工具之间，差距是巨大的。

为什么风险会落在您身上，而不是您的供应商？

银行卡受理基于一系列合同链条。卡组织制定规则，您的收单行（为您结算银行卡销售额的银行）执行规则，而您的商户协议则将这些规则传递给您。这套规则就是 PCI DSS，即银行卡行业的行业数据安全标准，它适用于所有存储、处理或传输持卡人数据（卡号及随附的详细信息）的企业。当前版本为 4.0.1。（版本号和计划详情在发布时是准确的；请将具体细节视为当时的快照。）

您的供应商对其自身系统承担义务，而一家合规的支付服务商可以大幅减少您的工作量。但是，供应商的任何行为都无法转移责任归属。PCI 安全标准委员会明确指出，您是否必须验证合规性是由支付品牌和您的收单行决定的，而他们写在您商户协议中的答案是：是的，必须验证。每年，您企业中的某个人都要签署一份证明，声明您的环境符合该标准。那个签名是您的，而不是您供应商的。

当您自己的代码接触到卡片数据的那一刻，会发生什么变化？

评估范围（Scope）。合规成本是以评估范围来衡量的：每个接触持卡人数据的系统，以及与之相连的所有设备，都属于该标准的管辖范围。

如果商户的支付完全由合规的服务商及其认证设备处理，则只需通过一份简短的自我评估问卷（年度清单）进行验证，其中仅包含几十个问题。而如果商户使用自己的软件处理卡号，则会落入最严格的级别，这几乎等同于完整标准的绝大部分要求：包含两百多项要求，涵盖季度漏洞扫描、渗透测试、访问控制、日志记录和正式的安全策略¹。

AI 花了一个下午帮您写好的结账表单？如果它接收卡号，那么您的 Web 服务器、数据库、管理员笔记本电脑以及店铺的 Wi-Fi 都可能被纳入评估范围。而且，您无论如何也不能悄悄提交那份简短的问卷。选择一个您不符合条件的级别并不能降低您的风险；这意味着您签署的文件是错误的，而这往往会在最糟糕的时刻——即发生数据泄露之后——暴露出来。

搞砸了合规，实际代价是什么？

规则的执行是基于合同的，因此通常会体现在您的账单上。许多支付处理商在您通过验证之前，每月都会收取一笔周期性的不合规费用。一旦发生数据泄露，成本就会堆积如山：您必须自费进行强制性法证调查、承担重新发卡的费用，以及通过收单行转嫁给您的不断升级的罚款（根据 PCI 合规评估机构公布的罚款标准，通常在每月 5,000 至 100,000 美元之间）。在严重的情况下，企业甚至会完全失去受理银行卡的资格。

对于小商户来说，最沉重的代价往往比任何罚款都要隐蔽：运行一个真正的安全项目需要耗费大量时间，而这些时间本应花在经营业务上。

如何在不将卡片数据纳入评估范围的情况下构建定制工具？

让您的代码远离卡片数据的传输路径。您的定制工具应该只负责协调销售：构建购物车、应用折扣、计算订单总额，并发送待扣款金额。而卡片本身应该只与认证终端（经证实可处理卡片的支付硬件）或服务商托管的支付页面接触，这两者都会将数据直接传输给支付处理商（负责资金划转的公司）。您的工具只需接收返回的结果（批准或拒绝）以及一个令牌（Token，一个对窃取者毫无用处的参考号）。

这种分离正是倡导 无头 POS 架构 的核心论据：上层是定制化屏幕，底层是经过认证的支付基础设施。这也是为什么 AI 生成的结账系统 在演示时效果极佳，但在生产环境中却举步维艰的原因；同时也是为什么网页表单不适用于 像 Interac 这样的刷卡借记卡支付 的原因：无论在技术上还是合同上，面对面支付都应该在经过认证的硬件上进行。

Final 正是围绕这一明确界限构建的。您构建的工作流（无论是由您自己提示生成的，还是通过 MCP 连接您自己的 AI）只控制屏幕、购物车和商品目录。卡片数据通过 Final Pay 从认证的终端硬件直接传输到支付处理商，绝不会进入您构建的工作流。在安全的地方进行定制，在承担责任的地方实行标准化。

那么，合规风险到底由谁承担？

答案是您自己，而且永远是您。您真正需要做出的决定是承担多少评估范围，这是一个架构选择，而不是文书选择。在发布涉及支付的工具之前，请问自己一个问题：我的代码是否有可能看到卡号？ 如果答案是肯定的，那么合规计划就需要由您来运行。如果答案是否定的，您就能在保留定制化开发灵活性的同时，只承担极少的一部分负担。如果您目前正在权衡此类开发，不妨先从 您已不再适用现成 POS 的迹象 开始了解。