Stripe把API藏了8年，AI代理发现后集体真敢用

AI代理半夜3点扣款，网络闪断了一下——这笔账是扣了一次，还是两次？

这个问题人类用户永远不会遇到。你点"立即支付"时，屏幕要么显示成功，要么显示失败，脑子不会冒烟。但AI代理没有眼睛，没有手指，也没有"等等我看看"的缓冲机制。它必须在0.3秒内判断：刚才那笔请求是网络超时，还是银行真的拒付了？要不要重试？重试会不会变成重复扣款？

支付API选错，你的代理会变成一台自动制造客诉的机器。

支付基础设施评估机构Rhumb最近测了20个维度，给三大主流API打了分。分数差异背后，是三种完全不同的产品基因。

Stripe：9.0分，为机器而生的设计

Stripe的支付自主性拿了满分10分。这不是偶然，是从第一天就写进DNA的架构决策。

幂等键（idempotency key）是一等公民。什么意思？你可以带着同一个钥匙重复敲门，门只会开一次。代理在3am遇到网络抖动，拿着同一个key再发一次请求，Stripe保证不会重复扣款。错误响应是结构化的、可解析的，不是"出错了"这种废话，而是"卡片过期，错误码card_expired"。Webhook带版本号，你的代理不会因为API升级突然看不懂通知。

Rhumb的执行可靠性评分里，Stripe拿到9.0。这个数字的含金量在于：代理可以写出正确的重试逻辑，而不需要人类兜底。

但Stripe也有摩擦点。它的数据模型是为纯线上交易优化的。如果你的代理要同时管库存、门店、线下收银台，Stripe会告诉你：这事不归我管。

Square：7.3分，物理世界的妥协

Square的分数更低，但这不是产品失败，是结构性的取舍。它诞生在咖啡店老板需要同时管实体店和网店的年代，数据模型天然带着"位置""库存目录""多渠道履约"这些维度。

一个代理要管理5个城市的10家门店，同步线上线下库存，处理门店自提和快递发货——Square的API能正确表达这些状态，Stripe不能。

代价是支付自主性只有6.0分。Square的错误响应不够精细，幂等机制不如Stripe健壮。你的代理在3am遇到异常时，需要更多代码来兜底。

Rhumb的结论是：选Square，当且仅当位置、目录或多渠道运营是代理的核心任务。

PayPal：4.9分，人类时代的遗产

PayPal的分数最难看，但原因很具体。它的支付状态机比Stripe多出一堆过渡状态，是从"人类登录网页点击确认"的时代继承下来的。企业账户验证必须有人类介入，仪表盘的操作逻辑没法直接翻译成API调用。

这不代表PayPal不能跑代理。只是你要额外吸收一层复杂度，把人类流程包装成机器流程。

唯一值得选PayPal的场景：你的分销策略依赖PayPal在特定市场的买家信任度。比如某些欧洲用户只愿意用PayPal付款，这时候分数高低不重要，渠道存在性才重要。

一个常见错误：按单笔费率选API。

Rhumb的数据里，代理场景的隐性成本不在费率表上。Stripe的2.9%+0.30和PayPal的3.49%+0.49差距很小，但代理写错重试逻辑导致的重复扣款、退款、客诉处理，成本是费率的几百倍。

更隐蔽的是"3am测试"的通过率。代理在凌晨批量处理任务时，网络抖动、银行系统维护、API限流都会触发异常。API设计决定了这些异常是自动恢复，还是变成早晨的工单队列。

Stripe的idempotency设计让代理可以无脑重试，Square需要额外状态检查，PayPal可能需要人类介入确认最终状态。这三种模式在白天看起来差不多，在3am是完全不同的世界。

Rhumb的评分体系里，"访问就绪度"这个维度很有意思。Stripe 6.6分，Square 5.2分，PayPal 3.7分。它衡量的是从注册到第一笔成功交易的路径长度。PayPal的低分主要来自企业账户的验证流程——代理不能替人类上传营业执照照片。

这个分数在快速原型阶段会被低估。开发者想"先跑起来再说"，选了注册最快的方案。但代理上线后，账户验证的阻塞会变成生产事故。凌晨3点的支付队列因为账户未验证而卡住，没有人类能起床处理。

回到那个核心问题：你的代理在3am扣款，网络闪断，结果是什么？

Stripe用户知道答案：查一下幂等key的状态，要么成功，要么重试。Square用户需要多写几行状态同步代码。PayPal用户可能得等早上9点有人类登录后台确认。

三种答案，三种运维成本。Rhumb的数据把隐性成本显性化了，但选择权还在你手里——你的代理准备独自面对多少个凌晨3点？