Spreedly

服务商概述

Spreedly 是一家支付编排（payment orchestration）服务商，运营主体为 Spreedly, Inc.，总部设在美国。官网当前的定位语是 "Payment Orchestration for the Agentic Era"，也就是把编排层往 AI 代理下单这个方向延伸。

它不直接收单：既不是收单机构（acquirer），也不是支付服务商（PSP）。交易的清算仍然由商户自己签约的网关、处理商或收单行完成，Spreedly 站在中间做三件事——把凭据存好、把请求路由对、把风控与 3DS 串起来。

理解它要先看四大支柱。Vault 负责把卡号等支付凭据存进商户自己的保险库；Connect 让一次集成触达任意网关、服务商与处理商；Protect 把商户自选的风控、身份核验与 3DS 服务商串到同一条链路上；Optimize 用实时的成本与授权数据决定每一笔交易该走哪条通道。

它围绕 agentic commerce 的说法值得单独看一眼。官网称一个集成足以覆盖 OpenAI、Google、Visa、Mastercard 在这个方向提出的标准，交易可以在 ChatGPT 或 Gemini 内发起，而商户仍然是 merchant of record——货款、退款与法律责任都留在商户这一侧，AI 平台只是入口，不是收款方。

需要提前说清一件事：Spreedly 的价值不在路由算法有多聪明，而在那个保险库归谁。这一条决定了后面所有的成本结构，也决定了几年后你还能不能换掉处理商。不少团队把它当"多通道容灾"来买，买完才发现真正受益的是"凭据我自己握着"这件事。

核心优势

• 凭据主权是真正的差异化：卡数据存在商户自己的保险库，换处理商时把整库带走即可，老客户不需要重新输卡。没有这一条，换 PSP 的实际代价是全部存量客户重绑卡，转化损耗足以让项目搁浅——很多"多通道战略"纸上成立、落地失败，卡的就是这一环。
• 一次集成，后续换处理商的边际成本接近 0：Connect 把不同网关的差异吸收在同一层接口后面。新增一个通道、切换一个通道、按国家拆一个通道，改动都落在 Spreedly 侧的配置里，而不是重写收银台。
• Composer 把规则变更从研发期里拿出来：支付团队自己拖出风控、路由与结算规则并当天发布。风控策略与路由策略本质上是运营决策，不该每次都排两个迭代。
• 路由依据是实时的成本与授权率：Optimize 用真实成交数据决定每一笔走哪条路，而不是按静态优先级轮询。官网给出的口径是授权率提升 30% 以上、已挽回 10 亿美元以上收入。
• 风控、身份与 3DS 服务商可选可换：Protect 不绑定某一家风控厂商，商户保留选择权。对高风险品类来说，风控供应商的可替换性往往比风控算法本身更值钱。
• 公开客户横跨高风险与高客单两端：SeatGeek、Priceline、Hopper 属于高客单、强时效的票务旅行；Lemonade 属于强监管的保险；HBO Max、Bandcamp、Chargebee 属于订阅与数字内容。这几类对授权率与容灾的要求都不低，也说明产品在真实压力下跑过。

产品生态

Vault（凭据保险库）

Vault 是整套产品的基石。卡号、令牌与支付凭据托管在商户自己的保险库中，与具体处理商解耦。这意味着凭据的生命周期不再被某一家网关绑架：换网关、加网关、按地区用不同网关，都不影响已有客户。

Connect（连接层）

Connect 提供统一的集成面，让商户用一套接口触达任意网关、服务商与处理商。集成一次，之后新增通道属于配置动作。对需要按国家、按币种、按卡组织拆流的跨境业务，这一层把"每家网关各写一遍"的重复工作消掉了。

Protect（风控与 3DS 编排）

Protect 把风控、身份核验与 3DS 服务商串到交易链路上，而这些服务商由商户自己挑选。这一点与"直接用编排商自带的风控"是两种完全不同的采购逻辑：前者保留议价权与替换权，后者把风控也一并锁在编排商身上。

Optimize（智能路由）

Optimize 按实时的成本与授权数据逐笔决定路由。它与"按固定优先级轮询"的区别在于，它把每条通道当下的表现当成输入，而不是把历史假设当成规则。对多通道业务，这个差别直接体现为几个百分点的授权率。

Composer（可视化编排画布）

Composer 是面向支付运营的可视化画布。风控规则、路由条件、结算逻辑可以在画布上搭建并发布，不必等研发改代码。这一层把"支付策略迭代速度"从工程节奏里释放出来，也让运营团队第一次能自己调策略。

集成与开发者接口

对外提供 API 与 webhook，覆盖建档、令牌化、交易与回调。对自建系统，接入面主要是凭据的录入与令牌的使用；对已有收银台的业务，可以只替换后端路由层，前端改动很小。

不足之处

• 不承担收单，商户仍是每一家的签约方：商户号、保证金、行业准入审核、结算周期都要与各网关单独谈。编排层不替商户解决"能不能开户"这个前置问题。
• 定价不公开：官网未列出标准费率，需与销售议价。交易体量小的团队既拿不到好价格，也很难在采购前把总成本算清楚。
• 学习成本压在支付工程侧：团队需要理解各网关的差异、令牌化机制、3DS 流程与失败码语义。没有 1 到 2 名懂支付的工程师，这套东西很难独立运维。
• 单通道商户收益有限：如果只有一家处理商、也没有容灾要求，接入与迁移成本大概率大于收益，不如直接用处理商自己的 SDK。
• 中国大陆主体基本无法使用：人民币本地收单、境内清算与备案要求都不在其覆盖范围，境内业务不应把它列入候选。
• 保险库自持会放大合规责任：凭据存在自己手里，PCI DSS 的范围界定、加密与访问审计责任同时回到商户。这块工作量在采购阶段经常被低估。

适用场景

• 多收单商与多通道容灾（★★★★★）：已经在 2 家以上网关签约、需要按地区或按卡组织拆流的业务，这套编排层的收益最直接，凭据库与路由层都正好对上需求。
• 高客单与高风险品类（★★★★☆）：票务、旅行、保险、iGaming 这类对授权率极其敏感的行业，逐笔路由与风控可替换性带来的是实打实的收入差。
• 订阅制与会员业务（★★★★☆）：凭据托管在自有保险库，续费时的通道切换不会触发客户重新绑卡，对降低流失很关键。
• 跨境独立站与出海业务（★★★☆☆）：需要按国家接本地支付方式与本地收单商时有用，但本地收单资质仍要自己拿。
• 中国大陆本地收单（★☆☆☆☆）：境内人民币收单、清算与备案链路不在其能力范围，这一档是明确限制而不是待优化项。
• 单 PSP 的小型商户（☆☆☆☆☆）：最不适合的一档。只有一家处理商、月交易量不大的团队，接入成本与运维负担都远超收益。

价格参考

影响成本的因素主要有 5 类：

• 交易额与交易笔数的规模，规模越大单价越低
• 接入的网关与处理商数量，通道越多配置工作量越大
• 是否需要迁移存量凭据，迁移是典型的一次性重成本
• 启用的模块数量，特别是路由与风控模块的调用量
• 是否涉及多币种、多地区与 3DS 定制流程

上表不含任何费率数字，Spreedly 官网当前未公开标准报价。实际价格以官网当前报价与合同为准，大额与复杂场景建议直接与销售议价。

常见问题

• Spreedly 会替我收单吗？
  不会。它是编排层，不持有收单资质，也不承接资金清算。商户仍需自己与网关、处理商或收单行签约，Spreedly 负责把凭据托管好、把请求路由到正确的通道、把风控与 3DS 串起来。

• 换处理商时老客户需要重新绑卡吗？
  不需要，这正是 Vault 的核心价值。凭据存在商户自己的保险库里，与具体处理商解耦，换通道后直接使用同一批令牌即可。前提是凭据确实托管在 Spreedly 的 Vault 里，而不是仍由原网关持有。

• 只有一家处理商，还有必要上编排层吗？
  通常没有必要。编排层的收益来自"多条通道之间做选择"，单通道场景下接入成本与运维负担明显大于收益，直接用处理商自己的 SDK 更划算。等到准备上第二家处理商、或需要按地区拆流时再评估。

• Composer 能把风控规则交给业务团队维护吗？
  可以，但要有边界。Composer 让支付团队自行搭建并发布规则，省掉了研发期；但风控规则直接关系资金损失，仍然需要明确的审批与回滚流程，不能变成谁都能随手改。

• 中国大陆公司能用吗？
  境内人民币收单与本地清算不在其覆盖范围，大陆主体基本不适用。若主体在境外、面向大陆以外市场收款，可以评估；但"技术能接"与"业务合规"是两件事，需要分别判断。

来源：16IDC 原创，产品能力、支持国家与费率口径以 spreedly.com 官网文档及合同为准。