MagicPay 安全支付工作流

它解决什么问题

填登录、身份、结账、订阅、支付这类敏感表单时，浏览器自动化有两个高频坑：要么把明文密码和卡号塞进模型提示词，要么在用户没有明确点头的情况下点了提交。MagicPay 的思路是把「用户预先批准的数据」和「当前页面要填的字段」解耦：规划阶段只传字段描述和不透明引用，真正写入表单的值在本地物化；所有关键动作都必须有逐字输入的授权。

核心能力与执行顺序

• 会话优先：先跑 magicpay status（或恢复配置），再 magicpay start-session。产品工作流会话是父资源，浏览器只能作为它的子资源被绑定。
• 浏览器归属：在 OpenClaw 中默认用内置浏览器工具完成打开页面、读快照、点击、普通字段填充与续跑；只有 MagicPay 命令确实需要浏览器时，才 magicpay launch 或在用户批准的私有 CDP 上 magicpay attach。
• 先规划后填充：magicpay plan-fill 观察当前页面、取回无值的 Memory 描述符并做语义匹配；magicpay apply-fill 才把已批准的值物化并写入计划字段。计划本身不含原始值。
• 批准界定动作：authorize-payment、sign-message、confirm-action 要求用户逐字输入确认，且只覆盖与被批准事实一致的那一步。授权前需先收集金额、币种、收款方、是否周期扣款等可见信息。
• 仅用于恢复的 CAPTCHA：magicpay solve-captcha 只能在当前浏览器子资源上确认存在真实验证码时调用，不能当作通用等待或挑战探测。

适用边界

• 它不替 runtime 背书：浏览器、OS 或 shell 一旦被攻破，MagicPay 本身不提供保护。
• 用户已经打在聊天里的密钥无法回收，最安全的做法是走 Memory 或请求路径，让原始值绕开提示词。
• MAGICPAY_API_KEY、本地配置文件、CDP endpoint、itemRef 都不应打印、上报或传给外部工具。
• provider-backed 银行卡在 authorize-payment 通过前不会暴露 handles，任何情况下都不应索取或推断 PAN/CVV。
• plan-fill 的 matcher 不可用时会 fail closed，而不是降级猜测。
• 浏览器清理与流程结束是两件事：magicpay close 关掉浏览器子资源，magicpay end-session 只结束工作流。