派想网
Pi 官方开发文档把应用支付分成前端发起与后端确认两部分。前端负责加载 Pi SDK、认证用户和启动支付；后端负责验证身份、批准 paymentId、完成链上支付并决定何时交付商品或功能。只在浏览器端显示“支付成功”不能作为最终凭据。
第一步：加载 SDK 并区分测试与生产
应用必须从官方地址加载 https://sdk.minepi.com/pi-sdk.js，随后调用 Pi.init()。官方文档特别说明，Pi Browser 不会自动注入 window.Pi；缺少脚本标签或初始化调用时，后续认证与支付方法会直接失败。
开发阶段使用 Sandbox，生产环境再切换为主网设置。测试时同时记录浏览器版本、网络环境和应用配置，避免把 Sandbox 支付结果误当作主网成交。
第二步：认证结果必须交给后端验证
调用 Pi.authenticate() 时，只申请当前功能真正需要的范围；接受支付时需要 payments。前端拿到的 accessToken 应发送给自己的后端，后端再通过 Pi Platform API 的 /me 验证。用户名或前端返回的 user 对象只能用于显示，不能单独决定账户权限或发货。
第三步：支付要经过 approve 与 complete
- 前端调用
Pi.createPayment()； onReadyForServerApproval返回 paymentId 后，发送给后端；- 后端用保存在服务器环境变量中的 API Key 调用 approve；
- 用户签名并提交交易，前端取得 txid；
- 前端把 paymentId 与 txid 发送给后端，后端调用 complete；
- 只有服务器确认 complete 成功后，才交付付费内容或功能。
Server API Key 不应写入网页、移动端包或公开仓库。客户端能看到的任何“秘密”都应视为已暴露。
为什么必须处理未完成支付？
用户可能在链上提交后关闭页面、断网，或在后端 complete 之前退出。官方要求在认证时提供 onIncompletePaymentFound 回调。应用应把未完成支付交给后端核对，而不是直接重建一笔新订单，否则可能造成重复扣款或重复交付。
上线前的最小测试清单
- SDK 加载失败、Pi Browser 版本过旧和用户取消授权时有明确提示；
- 后端能拒绝无效或过期 accessToken，并以
/me结果为准； - approve 成功但用户未签名、链上已提交但 complete 未完成都能恢复；
- 重复发送同一 paymentId 或 txid 不会重复交付；
- 日志不记录完整 accessToken、API Key 或不必要的用户信息。
关于近期 Developer Portal、BlockExplorer 与 SoloHost 的变化，可参阅Pi 开发者平台更新梳理。如应用还要申请展示或广告变现，也要参考Pi 开发者生态规模与资格边界，平台存在分发能力并不代表应用自动获得流量或广告资格。
本文只解释官方接入流程。接口参数、审核规则和生产环境要求可能更新，上线前应重新核对 Pi 官方开发文档。
