绘制真实的支付边界
从商品页到确认页绘制买家路径。标注卡片输入位置、重定向、iframe、脚本、API、插件、标签管理器、内容分发网络以及能影响该流程的管理员账户。包括相关日志、支持工具和分析记录。这是提交给提供商或评估者的起始记录，而非合规决定本身。
记录每个支付页面元素的域名。PCI SSC 说明，SAQ A 资格要求所有支付页面元素仅来自符合 PCI DSS 的服务提供商，且不得来自商户站点。对于 SAQ A-EP，每个元素可以来源于商户或此类服务提供商，但不得来自其他来源。其它所有资格条件仍然适用。
代码仓库可能遗漏标签管理器注入和平台设置。以正常结账浏览器会话审查脚本、iframe、域名和头部。
审查日志、分析和支持工作流中是否记录了支付字段。切勿在测试工单或共享证据中使用真实卡数据。
用可说明的支付模型减少暴露面
在可行的情况下，采用由符合 PCI DSS 的提供商收集卡数据的集成方式，而不是让你的应用接收或存储卡数据。提供商全托管重定向通常比自定义表单更简单，但嵌入字段和 iframe 仍然可能让你的网站影响支付。记下实际集成方式，而不要仅凭“托管”标签做判断。
避免保留主账号（PAN）、安全码、结账错误截图或复制的支付详情，除非经批准的设计确实需要。加密可以帮助保护数据，但 PCI SSC 警示仅靠加密通常不足以将环境移出范围。与提供商和合格评估者确认令牌、密钥、webhook、退款与责任处理。
将集成指南、责任分配信息、相关合规文档和变更通知流程与架构记录一起保存。
未经命名负责人和访问能力评审，不要添加营销实验、回放工具、聊天小部件或非必要库。
控制脚本、标签和头部
第三方浏览器代码可能引入不受控变更、任意代码执行和向其他方泄露。维护一个结账清单，记录每个脚本的域名、用途、负责人、批准情况和加载位置。包括标签管理器规则和由供应商加载的代码，而不仅限于源码树文件。
PCI SSC 着重于授权脚本、完整性、篡改监测和安全性相关的 HTTP 头。批准一个基线、限制更改、检测差异并调查。Content Security Policy（CSP，内容安全策略）可以限制资源来源。适用时先在 report-only 模式测试再强制执行。CSP 是纵深防御，而非替代安全编码或审查。
Subresource Integrity（子资源完整性）可以拒绝被篡改的外部脚本，但需要兼容的跨域配置，并可能在供应商更新后中断。
限制发布角色，要求强身份验证，审查自定义代码能力，并保留审计轨迹。
限制访问并使结账变更可恢复
将常规内容发布与结账代码、支付提供商管理、托管、DNS 和标签管理分离。使用具名账户、最小权限和支持多因素认证。角色变更后审查访问并移除前员工、供应商和代理的遗留权限。确切的 PCI DSS 适用性取决于环境，但减少共享与常驻权限可降低风险。
对结账实施发布流程：指定负责人、审查、尽可能测试、回滚方法和发布后浏览器检查。测试成功与失败路径、重定向与移动端行为。Status Is UP 支持围绕发布的主动就绪、性能优化和回滚规划；它不决定 PCI DSS 合规性。
将凭证、备份码和回滚说明保存在经批准的访问受控系统中，切勿出现在工单、截图或公共仓库里。
发布后比对浏览器可见的脚本、域名和头部与已批准清单，确保一致或有批准的差异。
更新堆栈并验证结果
维护影响结账的电商平台、插件、主题、服务器组件、库、支付 SDK、标签模板和服务的清单。订阅关键供应商的通告。NIST 将补丁管理定义为识别、优先级排序、获取、安装和验证更新。记录变更、测试支付流程并确认部署内容。
为高风险问题设置紧急处置路径，为例行变更设立维护窗口。优先处理暴露的结账组件，但不要盲目在生产环境打补丁以致破坏支付。使用经测试的回滚方法并遵循提供商发布指南。一个无明确负责人的过时组件是需要解决的风险。
将通告、风险决策、测试结果、部署记录和最终验证保存在一起。
保存证据并寻求合格帮助
将图表、提供商责任信息、SAQ 资格理由、脚本与头部清单、访问审查、批准、测试结果、变更以及供应商联系人保存在受控位置。在架构、所有权、脚本或提供商变更时更新它们。证据应帮助授权评审者而不暴露卡数据、密钥或客户记录。
你的收单行或支付卡组织会设定适用的验证期望。PCI SSC 指定 Qualified Security Assessors（合格安全评估师，QSA）为有资格执行 PCI DSS 评估的独立组织，并将 Approved Scanning Vendors（批准扫描供应商，ASV）定义为在适用要求下的外部扫描供应方。对于自定义结账、范围不清、疑似被入侵或 SAQ 选择问题，寻求合格帮助。
将结账模型、技术负责人、升级联系人、上次审查日期与证据链接集中保存。