Salesforce 与 PCI 合规之旅：我们的代币化实践

二月 06, 2026

我记得第一次深入接触到 PCI DSS 合规性要求的时候，团队里的讨论氛围是既谨慎又有点茫然的。

我们当时正在规划一个需要在 Salesforce 内部处理支付流程的项目。最初的想法很简单：用户输入信用卡信息，我们通过 Apex 调用支付网关 API，然后把成功或失败的结果以及一些支付标识保存起来。然而，这个“简单”的想法在 PCI DSS 的大棒面前瞬间变得复杂起来。

核心原则：触碰即风险，存储即地狱

我们很快意识到，PCI 合规的核心原则其实非常直接：如果你不接触敏感的信用卡数据（Cardholder Data），你就不会承担处理它的全部合规责任。如果你非要接触，那就务必不能存储它。

这个原则立刻把我们之前“在 Salesforce 里接收信用卡号然后转发”的方案打了个大叉。即便我们只在内存中短暂持有信用卡号几秒钟，然后立即转发给支付网关，这仍然意味着我们的 Salesforce 环境短暂地成为了“卡持有人数据环境（Cardholder Data Environment, CDE）”的一部分。这意味着我们可能需要对整个 Salesforce 实例进行 PCI 审计，这显然是不现实的，而且成本高昂，超出我们控制范围。

Salesforce 自身虽然是 PCI DSS Level 1 认证的，但这只说明了 Salesforce 平台本身的基础设施符合要求。这不代表你构建在其上的应用自动就合规。就好比住在五星级酒店不代表你房间里的保险箱是防弹的，更不代表你把钱随手放在桌子上就安全了。

我们的抉择：转向“代币化（Tokenization）”

理解了这个核心原则后，我们的思路立即转向了“代币化”。这意味着用户输入的信用卡信息不能经过我们的 Salesforce 服务器，而是直接从用户的浏览器发送到支付网关。支付网关收到敏感数据后，会返回一个不含任何敏感信息、但可以代表这张卡片进行后续交易的“代币（Token）”。我们只需要在 Salesforce 中存储这个“代币”即可。

为什么选择自行实现而非现成的 AppExchange 方案？

市场上其实有不少成熟的 Salesforce 支付 AppExchange 方案，比如 Chargent、Blackthorn Payments 等。它们通常已经帮你处理好了 PCI 合规的大部分细节。我们当时也评估过这些方案，但最终决定自行实现，主要基于以下几点考量：

高度定制化需求： 我们的支付流程与业务逻辑结合得非常紧密，需要高度定制化的用户体验和数据流。现成方案往往在配置和扩展性上存在一定的限制。
成本控制： AppExchange 方案通常有订阅费用，对于我们当时的预算和预期交易量，自行实现从长期来看可能更经济。
技术掌控： 团队希望对整个支付链路有更深入的理解和掌控，积累这方面的经验。

当然，这个选择意味着我们需要投入更多的开发和安全审核资源，但我们认为这是值得的，因为它让我们对风险有了更清晰的认知和更直接的控制。

我们的解决方案架构概览

我们采用了“直接提交（Direct Post）”结合“代币化（Tokenization）”的方案，大致流程如下：

前端捕获： 在 Salesforce 的 LWC 或 Visualforce 页面中，创建一个表单用于收集信用卡信息（卡号、有效期、CVV）。
JS SDK 代币化： 用户提交表单时，我们不直接将数据发送到 Salesforce 后端，而是在前端 JavaScript 中引入支付网关提供的 SDK（例如 Stripe.js、Braintree.js）。这个 SDK 会将信用卡信息直接发送到支付网关的服务器。
支付网关返回代币： 支付网关收到信息后，会进行处理，并返回一个唯一的代币给前端 JS。
Salesforce 接收代币： 前端 JS 接收到代币后，再将这个代币（以及其他非敏感信息，如金额、订单号）提交给 Salesforce 后端（Apex Controller）。
后端处理： Apex Controller 收到代币后，调用支付网关的 API，使用这个代币进行实际的扣款操作。
结果存储： Salesforce 后端只存储支付结果、代币以及支付网关返回的其他非敏感交易详情。

这种模式确保了敏感的信用卡数据从未触及我们的 Salesforce 服务器，从而极大地缩小了 PCI DSS 的合规范围。

一个简化的前端 LWC 代码片段（概念性）：


// myPaymentForm.js (LWC client-side JavaScript)
import { LightningElement, api } from 'lwc';
import { loadScript } from 'lightning/platformResourceLoader';
import stripeJs from '@salesforce/resourceUrl/StripeJS'; // Assuming Stripe.js is uploaded as a static resource
import processPayment from '@salesforce/apex/PaymentController.processPayment';

export default class MyPaymentForm extends LightningElement {
    cardElement;
    stripe;
    paymentIntentClientSecret;

    connectedCallback() {
        // Load Stripe.js library
        Promise.all([
            loadScript(this, stripeJs)
        ]).then(() => {
            this.stripe = Stripe('pk_test_YOUR_STRIPE_PUBLISHABLE_KEY');
            const elements = this.stripe.elements();
            this.cardElement = elements.create('card');
            this.cardElement.mount(this.template.querySelector('.card-element'));
        }).catch(error => {
            console.error('Error loading Stripe.js', error);
        });
    }

    async handlePayment() {
        this.isLoading = true;
        try {
            const { token, error } = await this.stripe.createToken(this.cardElement);
            if (error) {
                console.error('Error creating token:', error);
                // Handle error on UI
            } else {
                console.log('Stripe Token:', token.id);
                // Now send the token to Apex to process the charge
                const result = await processPayment({
                    tokenId: token.id,
                    amount: 1000, // Example amount in cents
                    orderId: 'ORD123'
                });
                console.log('Payment processed result:', result);
                // Handle success/failure
            }
        } catch (error) {
            console.error('Payment error:', error);
        } finally {
            this.isLoading = false;
        }
    }
}

对应的 Apex Controller (概念性)：


// PaymentController.cls (Apex)
public with sharing class PaymentController {
    @AuraEnabled(cacheable=false)
    public static String processPayment(String tokenId, Integer amount, String orderId) {
        // In a real scenario, you'd make a callout to Stripe's API
        // For demonstration, let's simulate
        System.debug('Received token: ' + tokenId + ' for order: ' + orderId);

        // This is where you'd typically make an HTTP POST request to Stripe's Charge API
        // using the tokenId and other details.
        // Example (pseudo-code):
        // HttpRequest req = new HttpRequest();
        // req.setEndpoint('https://api.stripe.com/v1/charges');
        // req.setMethod('POST');
        // req.setHeader('Authorization', 'Bearer sk_test_YOUR_STRIPE_SECRET_KEY');
        // req.setHeader('Content-Type', 'application/x-www-form-urlencoded');
        // req.setBody('amount=' + amount + '¤cy=usd&source=' + tokenId);
        // Http http = new Http();
        // HttpResponse res = http.send(req);
        // if (res.getStatusCode() == 200) {
        //     // Parse response, save transaction ID, etc.
        //     return 'Payment successful! Transaction ID: ' + someTransactionId;
        // } else {
        //     return 'Payment failed: ' + res.getBody();
        // }

        // For now, just return a success message
        return 'Payment process simulated successfully with token: ' + tokenId;
    }
}

这里需要特别强调的是，Apex 中使用的秘密密钥（sk_test_YOUR_STRIPE_SECRET_KEY）必须安全存储，不能硬编码。通常会使用 Salesforce 的 Named Credentials 或 Custom Metadata Type 来管理。

那些容易被忽视的“陷阱”

即便我们采用了代币化方案，PCI 合规的警报依然不能解除。以下是我们遇到或考虑过的几个常见陷阱：

意外的日志记录

这是最危险也是最容易犯的错误。在开发调试阶段，我们往往会随意使用 System.debug() 或者 addError() 来输出变量内容。如果一不小心，将包含敏感卡信息的请求体、响应体，甚至是前端表单原始数据输出到 debug log、Platform Event payload 或者其他日志系统，那么整个代币化努力就可能前功尽弃。

我们的对策：
- 严格的代码审查，确保所有与支付相关的日志输出都经过审查，只记录非敏感信息。
- 明确规定不允许在任何生产环境的日志中记录原始信用卡数据，甚至是对部分屏蔽（masking）后的卡号也需要谨慎评估。
- 对于任何与支付网关的 API 交互，只记录代币和交易 ID。
用户界面集成与 CSP

为了提供流畅的用户体验，我们希望支付表单能与 Salesforce 的 UI 保持一致。但当使用支付网关的 SDK 或嵌入其提供的 iFrame 时，可能会遇到 Content Security Policy (CSP) 的问题。Salesforce 默认的 CSP 规则可能不允许你的页面加载来自支付网关域的脚本或样式。

我们的对策：
- 在 Salesforce 的“设置 > CSP 可信站点”中，添加支付网关的域名。
- 如果使用 iFrame，确保 iFrame 的源也添加到可信站点。
- 仔细测试不同浏览器和设备上的兼容性，确保支付体验不会因为安全限制而中断。
自定义字段与数据保留

虽然我们存储的是代币，但有时候业务方会提出需要保存信用卡最后四位数字或卡类型等信息用于显示或识别。这些信息本身不构成完整的卡号，但在某些情况下，如果结合其他数据，仍然可能提高风险。

我们的对策：
- 仅存储支付网关明确允许返回并被认为是“非敏感”的数据（例如，卡品牌、卡号后四位、有效期月/年）。
- 对于这些非敏感数据，也要确保它们被正确分类，并在需要时进行加密（虽然对非敏感数据不是强制的，但多一层保护总没错）。
- 审查所有自定义字段，确保没有任何字段被错误地配置为存储了敏感数据。

对 PCI 合规的持续看法

通过这次实践，我对 PCI DSS 合规有了更深刻的理解。它不仅仅是一套技术规范，更是一种持续的安全思维和流程。它强迫我们思考数据流的每一个环节，识别潜在的风险点，并采取最严格的措施去规避。

我们没有试图成为 PCI 专家，而是尽力理解其核心精神：通过最小化敏感数据暴露，来最大化安全性并降低合规成本。 代币化是实现这一目标的强大工具，但在实施过程中，每一个细节都可能影响最终的合规性。这要求团队内部有非常清晰的沟通、严格的开发规范和持续的安全审计。

仍需关注的问题：

数据保留策略：： 代币本身虽然不敏感，但其与客户订单的关联数据仍需遵循数据保留和销毁策略。
Webhook 安全：： 如果支付网关通过 Webhook 回调 Salesforce，如何验证 Webhook 的真实性，并确保其传输安全？
第三方集成风险：： 如果未来引入其他与支付相关的第三方服务，它们如何融入当前的 PCI 合规架构？

总而言之，PCI Compliance 是一场永无止境的旅程。每一次新的功能开发，每一次新的系统集成，都需要我们重新审视其对合规性的影响。

参考资料： (我们主要参考了以下官方文档，但具体链接可能因版本更新而变化)

PCI Security Standards Council Official Site: pcisecuritystandards.org
Stripe Documentation for Salesforce Integration: stripe.com/docs/salesforce (或类似支付网关的官方文档)
Salesforce Developer Documentation on LWC and Security

Salesforce中文网