为何PayPal官方文档未收录更优的纯客户端集成方案？

两种集成方式对比 #

官方推荐的服务端模式 #

官方文档中普遍指引开发者通过服务端（以Node.js为例）处理订单创建，客户端需先调用自有服务端接口，示例代码如下：

async createOrder() {
    const response = await fetch("/api/orders", {
        method: "POST",
        headers: {
            "Content-Type": "application/json",
        },
        body: JSON.stringify({
            cart: [
                {
                    id: "NQ888P",
                    quantity: "3",
                },
            ],
        }),
    });
}

论坛流传的纯客户端方案 #

存在一种无需服务端、完全在客户端运行的集成方式，可直接对接PayPal完成订单创建，性能更优，示例代码如下：

createOrder: function (data, actions) {
    return actions.order.create({
        intent: 'CAPTURE',
        purchase_units: [{
            amount: {
                value: "14.99",
                currency_code: "USD"
            }
        }]
    })
},

官方未收录该方案的核心原因 #

• 安全风险防控：纯客户端方案会将订单金额、商品信息等关键数据暴露在前端，恶意用户可轻易篡改参数，造成支付金额被修改、订单内容被伪造等欺诈风险。服务端集成能在后端校验数据真实性与完整性，从源头规避这类问题，官方优先保障交易安全。
• 业务扩展性适配：服务端模式更适配复杂业务场景，比如订单状态持久化、库存扣减、会员系统联动、后续退款对账等流程。纯客户端方案仅能完成基础支付发起，无法支撑企业级全流程业务需求，官方文档面向全场景开发者，更倾向提供具备扩展性的标准方案。
• 合规与纠纷处理：支付行业对交易数据存储、溯源有合规要求，服务端处理能让商户留存完整交易记录，一旦出现纠纷，举证和责任界定更清晰。纯客户端方案下交易数据仅在前端流转，商户难以留存完整记录，合规性和纠纷处理都会面临障碍。
• 版本稳定性保障：PayPal的API与SDK迭代较快，纯客户端方案依赖前端SDK的特定回调逻辑，这类非标准化实现可能在版本更新时出现兼容性问题。官方文档收录的都是经过充分测试、长期稳定支持的集成方式，能保障开发者的接入体验。

内容的提问来源于stack exchange，提问作者Shawn