支付MCP服务器对比（2026）

在我们核查的16家主要支付公司中，有13家在自有域名或GitHub组织上发布了可以直接打开、阅读的官方MCP服务器或AI智能体（AI agent）SDK；另外两家（Visa、Mastercard）发布的是文档型MCP服务器，外加各自独立的智能体商务（agent-commerce）项目（Trusted Agent Protocol、Agent Pay），这些项目本身并不是能动用资金的MCP服务器。这13家的主流模式是：大多数默认就上线了可动用资金的工具（退款、打款、订单、支付链接），控制权继承自普通的API密钥或OAuth作用域，而不是专门针对单个智能体设计的消费上限。在MCP服务器这一层，这批公司里只有Stripe和Airwallex两家在文档中写明了针对智能体的专属管控措施（分别是人工确认关卡和默认拒绝资金流出的设计）。按单个智能体设置预算的做法确实存在于别处，主要出现在原生加密货币的智能体钱包中（Circle、Coinbase、Skyfire），但这些都在MCP服务器之外。

对比表

公司 官方MCP？ 托管/本地 认证方式 默认能否动用资金 内置消费管控 状态 来源
Stripe 是 两者皆可（托管 + 本地配置） OAuth 或 Agent API 密钥 是，通过 stripe_api_write 敏感写操作设有人工确认关卡；自2026年10月31日起要求使用带Agent标记的密钥 正式版（部分子工具为预览版） docs.stripe.com/mcp
PayPal 是 两者皆可 访问令牌（沙盒/生产环境） 是（create_order、create_refund 已上线） 在查阅的官方文档中未发现相关管控 未标注 PayPal GitBook
Adyen 是 仅本地 API 密钥 是（示例提示词：执行退款） 未发现相关管控 Alpha（内测版） docs.adyen.com
Square (Block) 是 两者皆可 OAuth（远程）／访问令牌（本地） 在查阅的页面中未被明确列为默认工具 客户端白名单（限制哪些应用可以连接，并非消费管控） Beta（测试版） developer.squareup.com/docs/mcp
Coinbase (CDP) 没有文档记录的托管MCP；提供CLI/SDK（Agentic Wallet、AgentKit、x402） CLI/SDK CDP API 密钥 是（USDC 钱包） 按会话/按笔交易设上限；OFAC 制裁名单筛查 未标注 docs.cdp.coinbase.com
Circle MCP仅用于文档/代码生成；资金管控功能在独立的Agent Wallets中 MCP：远程；Agent Wallets：CLI/SDK 未完全说明 Agent Wallets：是，在策略范围内 限时USDC消费上限（按笔/按日/按周/按月），修改需一次性密码（OTP）验证；针对钱包和合约地址设有白名单与黑名单，在钱包层执行 未标注 circle.com/blog, github.com/circlefin/skills
Skyfire 位于卖方自有MCP/API前端的令牌协议，而非单一托管MCP 协议 签名JWT（kya/pay/kya-pay） 是，通过 pay/kya-pay 令牌 由用户注资的钱包；未发现明确的按笔上限说明 未标注 docs.skyfire.xyz
Payman 部分支持——官方GitHub组织提供的是范围更窄的Genie MCP桥接工具；主文档站点无法访问 Genie：远程服务器 + 本地stdio桥接 OAuth 2.0 + PKCE 未经核实（README 描述的是 ask_genie 及账户管理工具，而非逐项列出的支付工具） 官方 genie-mcp-stdio 的README中未发现相关管控 未标注 github.com/PaymanAI/genie-mcp-stdio
Crossmint 是 远程 API 密钥 是，一旦设置 ENV=prod 即为真实购买 README/文档中未发现相关管控 未标注 docs.crossmint.com/agents/overview
Airwallex 是 远程（+ CLI） OAuth 否，默认不可 明确默认拒绝资金流出、写操作工具需二次确认、OAuth作用域限制 未标注 airwallex.com/docs .../agentos
Visa 仅为文档型MCP服务器（VIC/VDP集成指南+工具定义，github.com/visa/mcp）；Trusted Agent Protocol是另一个面向商户的签名/信任独立标准 远程（文档型MCP） JWE令牌（文档型MCP） 该MCP未经确认；TAP本身不涉及资金转移 不适用（涉及身份/信任，而非消费上限） TAP于2025年10月14日发布 github.com/visa/mcp, Visa newsroom
Mastercard 公开MCP是文档检索助手；Agent Pay（真正动用资金的项目）是独立项目，本身并非MCP服务器 不适用 对该MCP不适用 Agent Pay需要消费者明确授权；默认不会自动划转资金 智能体注册/验证、代币化、消费者购买管控、争议处理；未公布具体数字上限 2025年4月29日发布 Mastercard Newsroom
Checkout.com 是 远程/托管 控制台账户凭证 支付相关操作（作废、支付链接）可以 权限与控制台用户已有角色绑定 "Production-ready"（生产就绪） checkout.com/docs
Mollie 是 远程（公开API的代理） 通过浏览器重定向的OAuth 2.0 很可能可以，从Payments/Settlements/Mandates工具覆盖范围推断；但没有工具被明确标注为默认开启 官方文档页未发现相关管控 未标注 docs.mollie.com
Razorpay 是 两者皆可（推荐使用托管版；也可通过Docker自托管） API 密钥（也提到OAuth） 默认即可 READ_ONLY 标志（默认值：false）；截至2026-09-29，GitHub README的工具表中标注远程服务器不支持4个写操作工具（create_refund、close_qr_code、create_instant_settlement、create_registration_link） 未标注 razorpay.com/docs, github.com/razorpay/razorpay-mcp-server
Plaid 是，但并非支付执行工具 两者皆可（控制台MCP为远程；编码工具包MCP为本地） OAuth 2.0，client_credentials 授权模式 否——Plaid不涉及资金转移 不适用（仅用于诊断/开发工具） 积极开发中，支持有限 plaid.com/docs/resources/mcp

我们的发现

  1. 默认允许资金流出是常态，而非例外。 Adyen、PayPal、Razorpay和Crossmint都提供退款/订单/支付链接类写操作工具，一旦配置好API密钥或访问令牌即可立即执行，我们查阅的页面中都没有记载专门设计的消费上限、白名单或审批环节。Stripe和Airwallex是两个例外，二者用的都是基于确认的机制，而不是数字化的上限。

  2. "Allowlist"（白名单）一词，在不同厂商那里含义并不相同。 Square的白名单管的是哪些MCP客户端应用可以连接到它的远程服务器——并不限制已连接的智能体能花多少钱。Coinbase的白名单/黑名单管的则是智能体可以付款的钱包或合约地址。我们没有发现哪家厂商在同一产品中把客户端白名单和消费对象白名单结合在一起。

  3. 按单个智能体设置预算的做法集中在加密原生和"面向智能体的银行服务（banking for agents）"这一细分市场，而非出现在传统卡组织/支付处理商中。Circle（限时USDC消费上限，外加钱包和合约地址的白名单/黑名单）、Coinbase（按会话/按笔交易设上限）、Skyfire（按智能体注资的钱包）都描述了针对智能体的专属预算机制。在我们核实过的传统支付处理商（Adyen、PayPal、Square、Checkout.com、Razorpay、Mollie）中，没有一家描述过按单个智能体设置的消费上限；其管控能力继承自商户原有的API密钥或控制台角色权限体系，而这套体系是为人类开发者设计的，而非为约束自主运行的AI智能体而设计。

  4. Airwallex是这批厂商中唯一一家在MCP层默认禁用资金流出的公司，并且书面明确警告了把具备写权限的智能体加入共享/多用户频道所带来的操作风险。这种"默认拒绝+书面警告"的组合，在我们核查的其他厂商中都没有被同样明确地写明。

  5. 这个领域里有好几个所谓的"MCP服务器"根本不是支付执行工具。 Mastercard的公开MCP以及Circle一半的MCP产品都是文档/代码生成类助手；Plaid的两个MCP都是诊断和开发者工具；Visa的公开MCP是面向其Intelligent Commerce和Developer Platform API的文档服务器，而它的Trusted Agent Protocol是面向商户的信任/签名标准，既不是MCP，也不会转移资金。任何统计"支付类MCP服务器"数量的人都应该把这些过滤掉，否则真正能动用资金的服务器数量会被高估。

  6. 这批服务器中使用最广泛的一款，即将迎来一项有明确日期的合规变更。 Stripe自己的文档写明："Beginning October 31, 2026, Stripe MCP no longer accepts full-access secret keys or restricted API keys without the Agent tag"（自2026年10月31日起，Stripe MCP将不再接受完全权限密钥，或未带Agent标记的受限API密钥）（docs.stripe.com/mcp，查阅于2026-09-28）。任何仍在使用普通受限密钥的集成，都需要在该日期前换成带Agent标记的密钥。

  7. 我们无法在Payman的第一方文档页面上核实其消费管控功能。 它的文档站点docs.paymanai.com在两次调研过程中的每次访问都返回了HTTP 526错误，因此该行标注为"未经核实（not verified）"而非"不存在（absent）"。其官方GitHub组织（github.com/PaymanAI）确实托管了一个范围更窄的产品——一个"Genie" MCP桥接工具——其README描述的是单一的自然语言工具（ask_genie）加上账户管理工具，没有出现消费上限相关的说明。关于按笔上限和收款方白名单的描述出现在第三方MCP目录中；一旦Payman的文档可以访问，或Payman方面发来更正，我们会更新这一行。

如何选择支付类MCP服务器：一份防护清单

以上内容并非对某家厂商的背书——这只是一份清单，供你在把智能体接入支付MCP服务器之前，先去阅读该厂商自己的文档时参考。

  • 使用限定作用域的密钥，而非完全权限密钥。 多家厂商（Stripe、Coinbase、Circle）都明确支持与完全权限账户密钥不同的受限或带Agent标记的凭证。请选用工具实际需要的最小作用域。
  • 如果厂商提供，就为写操作开启人工确认。 Stripe的确认链接关卡和Airwallex的"require manual approval for tool calls"（要求对工具调用进行人工审批）都是厂商原生、有文档记载的做法，可以在资金转移前增加一道检查点。
  • 确认资金流出功能默认是开启还是关闭。 Airwallex是这批厂商中唯一一家默认禁用资金流出、需要显式开启的公司；我们核实过的其他所有厂商，只要配置好凭证，写操作工具就会立即生效。
  • 不要把"client allowlist"（客户端白名单）当作消费管控手段。 正如前文所述，客户端白名单（Square）限制的是哪些应用可以连接——对已连接的智能体能花多少钱只字未提。如果你需要的是消费管控，请专门去找按笔上限、限时额度，或钱包/合约白名单（Coinbase）这类功能。
  • 避免把具备写权限的支付智能体加入共享或多用户频道。 Airwallex自己的文档警告称："anyone who can prompt the agent may perform Airwallex actions with your privileges"（任何能够向该智能体下达指令的人，都可以用你的权限执行Airwallex操作）——这一风险适用于任何带有已生效写操作工具的MCP服务器，而不仅仅是Airwallex。
  • 不要把不受信任的MCP服务器和支付MCP服务器放进同一个会话。 来自无关工具输出（网页、文档、另一个MCP服务器的响应）的提示词注入，可能会试图触发支付工具调用；把支付工具隔离在单一、受信任的MCP会话中，可以缩小这一攻击面。
  • 如果厂商没有在MCP层内提供预算限制，就在MCP层之外自行设置。 这里列出的大多数厂商，其MCP工具本身并没有专门针对单个智能体设计的预算功能——请把底层账户自身的消费限额、提醒或审批流程，当作真正的最后一道防线。

消费管控层：架在支付MCP服务器前面的工具

还有一类更新出现、彼此独立的工具，它们自己不通过任何轨道转移资金——而是架在钱包、发卡机构或支付MCP服务器前面，加上一层上表大多数厂商都不具备的预算管控。以下每一项都已在其官网或代码仓库上核实，截至2026-09-29；这七项都不构成背书，其中有几个还是较新的产品，在把真实资金交给它们之前，值得先确认其活跃程度。

  • SpendNod 是一个免费、开源、可自托管的“human-in-the-loop authorization gateway for AI agents,”（面向AI 智能体（AI agent）的人工介入式授权网关），通过MCP连接，会根据消费阈值、厂商黑名单、每日上限和类别限制来评估每一笔交易，并返回自动批准、待审核或拒绝三种结果之一。
  • PayAgents 是一个npm SDK/MCP服务器，供AI智能体通过Lightning（L402）和Base USDC（x402）付款，设有硬性的按笔、按日、按30天上限，外加目的地域名白名单/黑名单和人工审批触发机制。
  • PolicyLayer 是一个代理，会拦截发往任意MCP服务器的MCP tools/call 请求，依据一份YAML策略文件逐一评估，并返回允许、拒绝、限速或需要审批。
  • Locus 让智能体通过一个MCP连接，就能访问一整套按次计费的API目录，费用从预付的工作区余额中扣除（以USDC/x402结算），消费上限和审批流程在其控制台中按工作区配置。
  • agent-verifier-mcp 是一个开源MCP服务器，实现了一套预扣/结算式的“Budget Authority Protocol”（预算授权协议，create_budget、check_budget、settle、release、refund），不绑定特定支付轨道，并会跨多个服务追踪消费情况，这样即便智能体调用的每个工具都各自独立通过审批，也不会导致整体超支。
  • Authoryze 会为一笔已批准的购买签发一张限定用途的一次性虚拟卡（Mastercard/Visa），按智能体设置按笔、按日、按周及累计上限，并支持商户白名单；Claude、ChatGPT、Claude Code、Codex和Cursor均可通过OAuth连接。
  • Tempo Wallet CLI 在凭证层面而非MCP服务器层面执行预算：限定作用域的访问密钥支持按单次请求和按密钥设置 --max-spend 上限，并可在资金实际扣除前用 --dry-run 预览。

在这些工具之间做选择时，真正重要的区别在于：凭证层面的上限（比如Tempo的访问密钥，或Stripe带Agent标记密钥的权限设置）是由提供方在凭证被调用时强制执行的，无论调用发生在MCP之内还是之外，都不例外。服务器层面的上限（SpendNod、PolicyLayer、agent-verifier-mcp）只能看到实际经过该服务器的调用——如果智能体还有另一条路径能够触达同一凭证，服务器层面的上限就管不到。只要提供方支持凭证层面的强制执行，就应优先采用；服务器层面的工具应被当作额外的一层防护，而不是替代方案。

方法论

我们用同一个标准核查了16家公司：该公司是否在自有域名或官方GitHub组织上，发布了能够接触支付业务的MCP服务器或AI智能体工具包？对每一家，我们都直接打开该厂商自己的文档、开发者网站或官方GitHub仓库，记录下确切的工具名称、认证方式，以及发现的任何消费管控相关表述——原文引述保留在配套数据集中。上文对比表中出现的任何结论，我们都没有依赖搜索引擎摘要或第三方MCP目录列表；如果某个结论只来自WebSearch摘要或第三方来源，表格中会明确说明这一点（例如Payman的上限/白名单说法、Mastercard公开MCP的独立定性），而不会把它当作已核实的事实呈现。

所有页面均于2026-09-27访问，此前五行未经核实的内容（Payman、Visa、Mastercard、Mollie、Plaid）已于2026-09-28独立重新抓取，并在官方页面上得到确认。完整的原文引述、URL以及逐行备注都在配套数据集（payment-mcp-landscape-v2.csv）中。

这是一份快照，而非永久性排名——这个领域的MCP服务器和智能体支付类产品变化很快（Stripe自身已排定于2026年10月31日进行密钥格式变更就是一例）。如果你在这些公司之一任职，发现某一行有误或已过时，或者你知道能解决某个悬而未决问题的第一方页面（比如Payman的主文档站点、Circle的MCP工具级名称），欢迎指正——请引用具体的官方页面，我们会重新核实并更新。

常见问题

有多少家支付公司拥有能够动用资金的官方MCP服务器？ 在我们核查的16家公司中，有12家拥有可核实的第一方MCP服务器或AI智能体SDK，能够动用资金，我们可以直接在厂商自己的域名或GitHub组织上打开、阅读（Stripe、PayPal、Adyen、Square、Coinbase、Circle的Agent Wallets、Skyfire、Crossmint、Airwallex、Checkout.com、Mollie，以及Razorpay）。另外两家（Visa的Trusted Agent Protocol、Mastercard的Agent Pay）是相邻的智能体商务项目，而非MCP服务器本身。Plaid的官方MCP以及Circle用于文档/代码生成的MCP都不涉及资金转移。Payman具体的消费管控说法，在Payman自有页面上仍未得到核实。

哪些支付类MCP服务器内置了专门针对AI智能体的消费管控？ Circle的Agent Wallets（按笔/按日/按周/按月消费上限，修改需OTP验证）和Coinbase的Agentic Wallet（按会话/按笔交易设上限，OFAC筛查）是官方文档中最清晰的、专门针对单个智能体设计的预算功能范例。Stripe（人工确认关卡）和Airwallex（默认禁用资金流出）采用了不同的思路：靠检查点或默认拒绝的设计，而不是数字化的上限。

Stripe的MCP服务器是否允许智能体未经审批就花钱？ 默认情况下，stripe_api_write 涵盖退款和对外付款，但Stripe自己的文档写明，敏感写操作需要通过一个URL进行人工确认，未获批准的操作会在24小时后"expires"（过期）。另外，从2026年10月31日起，Stripe MCP将停止接受完全权限密钥，或未带Agent标记的受限API密钥（docs.stripe.com/mcp，查阅于2026-09-28）。

Visa的Trusted Agent Protocol或Mastercard的Agent Pay是MCP服务器吗？ 不是。Visa的Trusted Agent Protocol（2025年10月14日发布）是一套加密消息签名标准，让商户能在结账时验证AI智能体的身份；它本身并不执行支付（Visa另外在github.com/visa/mcp发布了一个文档型MCP服务器）。Mastercard的Agent Pay（2025年4月29日发布）是一个基于代币化的支付项目，需要消费者明确授权；Mastercard另外发布的公开MCP是一个文档检索助手，并不是真正动用资金的部分。

为什么这篇文章没有核实Payman的消费管控说法？ Payman的主文档站点docs.paymanai.com在两次调研（2026-09-27和2026-09-28）的每次访问中都返回了HTTP 526服务器错误，我们因此无法自行阅读该页面。关于Payman流传的具体说法——"per-transaction/daily caps and recipient whitelist"（按笔/按日上限及收款方白名单）——出现在第三方MCP目录和Payman自己的营销文案中，而不是我们能打开的、Payman自有的文档页面上。Payman的官方GitHub组织确实托管着另一个范围更窄的产品（一个"Genie" MCP桥接工具），其README中没有出现消费管控相关的说明。

更正

  • 2026-09-28： Visa那一行原本写的是"Not an MCP"（不是MCP）。实际上Visa确实发布了一个官方文档型MCP服务器（github.com/visa/mcp："AI tools, examples, and integrations for the Visa Developer Platform"（面向Visa开发者平台的AI工具、示例与集成）），因此该行、摘要和FAQ现已相应更正说明。至于Visa的任何MCP工具是否会动用资金，目前尚未得到确认。

Pink 的位置：Pink Agentic AI Payments（PinkWallet 出品，早期访问）是 AI 智能体与公司资金之间的审批层：由自然语言规则、每个智能体的预算和人工审批来决定每一笔付款，之后才会签发一次性卡或银行转账。加入早期访问名单。