Alchemy Wallet APIs：Account Kit 之后，交易层该怎么接

一个应用已经有用户登录和钱包余额，现在准备加入购物助手：用户批准购买后，助手完成付款，不再要求用户先去买 Gas 代币。接入时真正需要理清的是三件事：谁识别用户，哪把密钥有权花钱，交易重试的费用又由谁承担。

资料边界： 本文于 2026 年 11 月 1 日核对官方文档，讨论架构与迁移方案；没有执行钱包迁移，也没有进行真实资金支付测试。

先确认产品现状，再看旧教程

Alchemy 的 Account Kit 弃用说明覆盖内嵌钱包、签名器、密钥管理及相关登录和 UI 组件。官方建议新项目使用 Wallet APIs，并另外选择签名器。如果团队原本期待用一个 SDK 包办登录到支付，这一变化需要重新评估。

Wallet APIs 概览把交易分成准备、签名、提交和跟踪。登录与密钥属于签名服务这一侧，Alchemy 提供交易基础设施。架构图上应明确这条分界：无法登录、签名被拒绝、链上执行失败，是责任方不同的三类问题。

一笔已批准的购买如何走完流程

接入流程概念示意，非交易实测。支付回执与商家的交付记录仍需由应用关联。

在这个设计中，应用先检查订单，再准备调用；签名器或已经获得授权的会话提供执行权限。代付策略决定服务是否承担执行费用，并不判断商品是否值得买。交易提交后，应用跟踪链上结果，再单独更新订单状态。

这种划分也直接影响客服和重试逻辑。“还没完成签名”与“已经提交，尚未确认”不能给出同一条处理建议。如果上一笔购买正在结算，再弹出一个新签名请求，可能既多余又危险。

地址能否沿用，需要单独验收

Alchemy 提供 EIP-7702 与非 7702 两种模式。前者可以在签名器原地址上增加智能账户能力，后者使用另外的智能钱包地址。因此，签名器选择会影响地址模型，不只是开发体验。

迁移前先列出应用里所有依赖地址的地方：充值入口、代币余额、授权记录、订单历史以及客服查询。再逐项确认，所选网络和账户模式下哪些可以保留。更换 SDK 不等于所有地址关系都能自动继承；能够登录，也不代表应用读到的仍是正确账户的余额。

新项目应先确定账户模式，再向用户展示长期使用的充值地址。已有项目则应把地址映射作为迁移数据，设计回退和客服处理流程。这是我们的实施建议，不是说 Alchemy 会替应用自动迁移这些业务记录。

购买预算和 Gas 预算要分开

Gas 代付文档说明了策略管理和代付费用的美元计费方式，也区分不同接入路径的开放条件。核对时，主网链上 Paymaster 代付和 ERC-20 支付 Gas 通常面向 Enterprise 团队，存在例外。测试网示例能跑通，不足以证明生产账户拥有相同功能。

用户的购物额度与应用的 Gas 额度是两本账。一笔金额很小的转账，也可能因重复请求消耗基础设施资源；反过来，代付预算耗尽，会让一笔业务上允许的购买无法执行。产品要明确每种情况的处理方式，不能悄悄切换费用承担者。

接入决策	上线前应记录什么
谁负责签名	服务商、账户模式、恢复责任方和支持网络
Agent 可以花多少	代币、累计额度、允许操作及有效期
谁承担执行费用	代付策略、账单责任方、限额及拒绝后的处理
订单何时算已支付	要求的交易状态与商家对账规则

看清会话权限的实际粒度

Alchemy 的会话密钥文档区分代币额度、合约访问和具体函数权限。ERC-20 额度涵盖转账与授权的累计用量；允许访问整个合约，比只允许一个函数更宽。root 权限则意味着全面访问。

对于这里的购物助手，用户界面不应只显示“已开启 Agent”。需要检查实际授予了什么。如果现有权限无法表达必须遵守的商家或操作限制，就增加真正执行限制的控制，或者不开放这类任务。一次拒绝不能成为默认扩大授权的理由。

重试交易，不要重建一笔购买

交易重试文档说明了如何替换待处理调用，也提醒原交易可能在替换过程中先被打包。因此，重试接口的返回值本身不能作为最终付款凭证。

我们的建议是：不同提交尝试沿用同一业务订单号，保留调用 ID 与交易哈希的关联，并在创建替代购买前核对链上结果。Wallet APIs 可以减少交易层的接线工作，但“同一件商品只买一次”仍然是应用的责任。相关设计可继续阅读支付幂等性与 Alchemy 资料页。