AP2 (Agent Payments Protocol) 技术流程详细解析
AP2 并非一个完全独立的、底层的网络传输协议，而是建立在现有的智能体通信协议（如 Agent-to-Agent/A2A 或 Model Context Protocol/MCP）之上的一种开放式支付扩展 。它的核心技术思想是将传统的"指令式（Imperative）"API 调用（比如 create_order），转变为了由多方参与的基于密码学签名的"契约协商式（Declarative, consensus-driven）"模型。
以下从关键技术角色、核心载体，到典型交互流程为您系统地进行讲解。
第一部分：生态中的关键技术角色 (Actors)
在 AP2 的拓扑架构中，一次完整的支付交易并非只是客户端（Client）和服务器（Server）那么简单，而是被解耦成了如下几个专职的参与节点：
- User Agent (UA) / Shopping Agent (SA) - 用户/购物智能体：这是用户直接使用的 AI。它负责理解自然语言需求、搜索商品、代替用户跟商家进行交互以及发起支付授权请求。
- Credentials Provider (CP) - 凭据提供方：类似数字钱包。它安全地管理用户的支付方式序列，为 SA 分配或加密支付 Token，在不泄露用户明文卡号给 SA 的情况下完成支付准备。
- Merchant Agent (MA) / Merchant (M) - 商家端 / 商家智能体：代表商家系统。它维护商品目录、展示库存，与 SA 协商最终的"购物车（Cart）"，并核实用户的真实购买意图。
- Merchant Payment Processor Endpoint (MPP) - 商家收单通道：负责将构造好的带签名的交易信息发给传统的支付卡组织及银行进行实际的扣款动作。
信任与安全隔离： UA/SA 不直接触碰用户的敏感支付数据（PCI data），这些数据仅在 CP, MPP 和发卡行之间流转。
第二部分：典型的技术交互时序图 (Mermaid)
下面是一次完整的"人在场 (Human-Present)"支付场景下，所有 6 个节点交互的标准时序图，展示了从需求沟通到支付完成的数据流向：
Merchant Payment Processor (收单机构) Merchant (商家核心系统) Merchant Agent (商家智能体) Credential Provider (钱包凭证提供方) Shopping Agent (购物智能体) User (用户) Merchant Payment Processor (收单机构) Merchant (商家核心系统) Merchant Agent (商家智能体) Credential Provider (钱包凭证提供方) Shopping Agent (购物智能体) User (用户) 9. 构建购物车授权凭证分片 (Create CartMandate) 19. 创建支付授权凭证 (Create PaymentMandate) 21. 用户硬件设备签发不可抵赖凭证 (Attestation) 若存在网络特殊要求，CP 将向银联/Visa 发送代币化或风险补充信息 28. 传统金融网络最终处理 (Process payment) 1. 自然语言购物指令 (Shopping Prompts) 2. 意图确认 (IntentMandate confirmation) 3. 同意确认 (Confirm) 4. (可选) 选择凭证提供方 5. (可选) 确认收货地址 6. 请求获取支付方式 7. 返回支付方式列表 { payment methods } 8. 传递购物意图 (IntentMandate) 10. 请求商家签名以锁定库存与价格 11. 返回已签名的 CartMandate { signed CartMandate } 12. 将带商家签名的 CartMandate 发给 SA 13. 获取用户最终可用的支付选项 14. { payment options } 15. 在客户端展现 CartMandate 与支付方式选项 16. 用户选定支付方式 17. 申请支付 Token 18. 返回脱敏的支付 { token } 20. 唤起本机安全环境(FaceID/指纹)，进行双重凭证联合签发 22. 获得用户设备签名结果 { attestation } 23. 向凭证方知会签署完成的 PaymentMandate + attestation 24. 提交最终购买请求 { PaymentMandate + attestation } 25. 商家代理向收单通道发起扣款 { PaymentMandate + attestation } 26. 收单通道向凭证方核实验证与扣款 27. { 付款凭证处理 } 29. 返回付款账单收据 30. 返回付款账单收据 31. 将账单收据发给购物智能体 32. 购物完成并展示结果
第三部分：传递的数据结构 (VDCs - 可验证数字凭证)
传递的核心数据就是 VDCs（可验证数字凭证），这是一种不可篡改的 JSON 结构，内含了多方声明以及加密学签名（Signature）。下面是两个核心数据结构示例：
1. CartMandate (购物车授权) 数据结构
此凭证由商家生成并预先签名，用户在客户端校验后追加签名，主要包含商品明细，用以避免"货不对板"的纠纷。
json
{
"contents": {
"id": "cart_shoes_123",
"user_signature_required": false,
"payment_request": {
"method_data": [
{
"supported_methods": "CARD",
"data": {
"payment_processor_url": "http://example.com/pay"
}
}
],
"details": {
"id": "order_shoes_123",
"displayItems": [
{
"label": "Nike Air Max 90",
"amount": { "currency": "USD", "value": 120.0 }
}
],
"shipping_options": null,
"total": {
"label": "Total",
"amount": { "currency": "USD", "value": 120.0 }
}
},
"options": {
"requestShipping": true
}
}
},
"merchant_signature": "sig_merchant_shoes_abc1",
"timestamp": "2025-08-26T19:36:36.377022Z"
}2. PaymentMandate (支付授权) 数据结构
此凭证作为敏感金融数据载体，向金融结算网络证明这是一次"受人委托的 AI 发起的交易"。
json
{
"payment_mandate_contents": {
"payment_mandate_id": "pm_12345",
"payment_details_id": "order_shoes_123",
"payment_details_total": {
"label": "Total",
"amount": { "currency": "USD", "value": 120.0 },
"refund_period": 30
},
"payment_response": {
"request_id": "order_shoes_123",
"method_name": "CARD",
"details": {
"token": "xyz789" // 注意：这里传递的是脱敏的 Token，并非明文卡号
}
},
"merchant_agent": "MerchantAgent",
"timestamp": "2025-08-26T19:36:36.377022Z"
},
"user_authorization": "eyJhbGciOiJFUzI1NksiLCJraWQiOiJkaWQ6ZXhhbXBsZ..." // 用户设备的私钥数字签名
}第四部分：防篡改纠纷解决
上述这些通过参与方传递的数据 JSON 是防篡改的：
- 这些 JSON 结构会被附上密码学签名（例如
user_authorization是用户可信客户端利用内部私钥加密生成的）。 - 任何篡改中间价格的中间人攻击会导致签名破裂。
- 在发送拒付或争议（Disputes & Chargebacks）时，将这个 CartMandate 原封不动交给国际发卡网络，发卡网络就能查明这确实是用户本人的意愿（因为私钥不可伪造），这不仅化解了 AI 开发者的过失担忧，也给予了接入 AI 生态的商家极大的安全感。
QA
1. Intent Mandate (购物意图) 是怎么生成的？谁负责？
生成者 ：由User Agent (购物智能体/SA) 负责生成主体内容，但必须由用户 (User) 亲自签名才生效。
流程：
- 意图转化：当您对助手说："如果苹果发布新款耳机，只要在 1500 块以内就直接帮我下单"，您的购物智能体（SA）会把这段"自然语言"转换成一段极其结构化的 JSON 数据。这段 JSON 里包含了：预算上限、目标商品特征、有效期等。
- 用户授权签名 ：SA 拿着这份 JSON，在您的手机弹出一个提醒："我要在接下来的 30 天内，拿着最多 1500 块钱替您巡逻并购买新耳机，同意吗？" 您通过 FaceID 确认。此时，您手机的安全芯片会用您的私钥对这份 JSON 进行加密签名。
- 生效 ：这份被您签过名的 JSON 才正式成为
Intent Mandate。以后您的 AI 跑去跟各个商家的 AI 谈判时，就会亮出这个带有您电子签名的凭证，告诉商家："看，我主人真的授权我买这个东西了"。
2. Cart Mandate (购物车凭据) 是依据什么生成的？
生成者 ：由Merchant Agent (商家端/MA) 负责生成。
生成依据 ：
取决于智能体之间的"讨价还价"。比如您的 SA 跑到某家鞋店的 MA 那里，根据尺码、配送地址、优惠券，最终算出来一个"死板的"订单明细（包含准确的 SKU 编号、税费、运费加起来总共 125.00 美元）。
约束力 ：MA 把这个明细写成 JSON（即 CartMandate 的前身），然后 MA 会用商家的私钥进行签名 。这个签名的意思是："商家承诺：只要用户在此明细上付 125 美元，我们绝不涨价且保证发货"。 把这个承诺锁死后，再发给用户的手机去确认。
3. Attestation (用户设备签名结果) 的核心作用是什么？
您问到了整个架构最关键的一块盾牌。
在使用 AP2 支付时，点击"确认购买"不仅仅是一个前端按钮点击，它是一个加密学签名(Attestation) 动作。
为了什么签名？为了"防抵赖 (Non-repudiation)"和"防商家篡改"。
- 保护用户 ：用户设备会对
CartMandate进行签名。这就意味着，我只同意花 125 块买这双 42 码的鞋。如果商家偷偷在后台把金额改成 1250 块去扣款，因为 1250 块没有经过用户设备的私钥签名（哈希值对不上），发卡银行会直接拒绝扣款。 - 保护商家 ：传统的信用卡盗刷纠纷（Chargeback）中，用户经常可以找银行撒谎说"我没买过这个，我的卡被盗了或者是我的 AI 发神经乱买的"。但在 AP2 体系下，因为
Attestation包含了用户唤起 Apple Pay 或是指纹解锁时调用底层安全硬件不可导出的私钥得出的签名。发卡行一看这个签名，就能判定"这绝对是你本人授权的"，从而保护商家免受恶意退款的困扰。
4. Payment Mandate与无账号支付：为什么发给商户就能结算？
您察觉到了一个非常反直觉的事情："里面没有账号密码，发给商户怎么扣我的钱？"
其实，这里面涉及到了现代金融体系的 Tokenization（支付凭证代币化） 机制。
- 没有账号也能支付？
不是没有账号，而是您的真实账号（比如 VISA 卡号4111********1111）由 Credential Provider (CP, 即钱包提供方，如 Google Pay) 严格锁了起来。
当您要支付时，CP 并不会把您的真实卡号放进PaymentMandate里。相反，它会向银联或 VISA 网络申请一个**"单次有效、绑定特定商户"的虚拟暗号（Token）**。PaymentMandate里装的就是这个暗号。 - 为什么连同 Token 直接发给商户就能结算？
因为商户并不是用自己去扣款的。现代绝大部分正规电商背后都有一个 Merchant Payment Processor (即收单机构/MPP，如 Stripe, Alipay 等) 。
全流程如下：- 用户的 SA 把包含了 Token 加密信息的
PaymentMandate丢给商户。 - 商户因为没有解密钥匙，看不到您的卡号。但他会把这个打包的内容原封不动通过 API 转发给他们的收单机构（Stripe）。
- Stripe 拿着这段暗号（Token）和您的硬件签名，转身扔给底层的 Visa/Mastercard 网络。
- Visa 内部的黑盒一查："哦，这个暗号 (Token) 对应的是 PPG 先生的那张尾号 1111 的信用卡，而且他还用指纹签了名，扣款合法！"
- 钱就从您的银行卡，经过收单机构，结转到了商家的账户里。
- 用户的 SA 把包含了 Token 加密信息的
总结一句话：
由于 AP2 使用了代币化 (Token) 代替了真实卡号，又使用了设备私钥签名 (Attestation) 代替了传统的输入短信验证码，所以整个支付流程变成了几个 JSON 信封的互相传递和验签------谁也看不到别人的老底，但谁也无法抵赖自己做过的承诺。