digital goods api 已被 w3c 暂停标准化且被 chrome 117 彻底移除，当前无任何浏览器原生支持 web 端应用内购买；替代方案包括跳转原生 app 结算、使用 stripe 等自有支付网关，或通过 twa/wkwebview 封装 pwa 并集成官方 sdk。
目前浏览器中无法直接使用 digital goods api 处理内购，因为该 api 尚未被任何主流浏览器正式支持，且已被 w3c 暂停标准化进程。它曾是 chrome 实验性功能（仅限 android webview），但自 2023 年起已移除，不再可用。
为什么 Digital Goods API 不能用了
Google 原计划用它替代旧的 Play Billing Library Web 接口，用于在 Android WebView 中安全调用 Google Play 结算系统。但实际落地时发现：WebView 场景受限、跨平台兼容性差、与 PWA 和桌面浏览器完全脱节。W3C 在评估后决定暂停推进，Chrome 也已在 117 版本中彻底下线该 API。
现在没有浏览器原生支持基于 Web 的应用内购买（IAP）结算 —— 这不是实现问题，而是平台能力缺失。
当前可行的替代方案
若你开发的是 PWA 或网页应用，想接入应用商店内购，只能通过“间接方式”实现：
- 移动端：跳转到原生环境 —— 在 Android/iOS 上，通过 deep link 或 intent 触发原生 App（如已安装），由 App 调用 Google Play 或 App Store SDK 完成购买；网页本身不参与结算流程，只负责展示商品和跳转。
- Web 端：走自有支付系统 —— 对于纯浏览器场景（如桌面或 Safari），必须使用 Stripe、PayPal、支付宝等合规支付网关，自行管理订阅/许可证验证，不经过应用商店，也不受其分成约束（但需自行承担风控与合规责任）。
- PWA + 商店上架组合 —— 将 PWA 打包为 Android App（通过 Trusted Web Activity）或 iOS App（通过 WKWebView 封装），再在原生层集成 Play Billing 或 StoreKit，网页通过 postMessage 与原生层通信，传递购买结果。
别踩的坑
很多开发者误以为“只要写 JS 调用 digitalGoods.xxx 就能唤起支付”，实际上：
- Chrome DevTools 控制台里执行
navigator.digitalGoods会返回undefined（除非你用的是早已废弃的旧版 WebView 测试环境）； - MDN 和 Can I Use 都已将该 API 标记为 Deprecated 或 No support；
- 试图在 Safari、Firefox 或新版 Chrome 中启用该 API 的实验性 flag 已无效。
下一步建议
聚焦真实可交付路径：
- 确认你的分发渠道（App Store？Play Store？纯网页？）；
- 如果是商店上架应用，用官方 SDK（StoreKit / Play Billing）做结算，网页作为 UI 层；
- 如果是独立网站，用 PCI 合规的支付服务商，配合 JWT 许可证校验或服务器端订阅状态同步；
- 关注 WICG/digital-goods 仓库 动态 —— 目前无重启迹象，短期勿依赖。
不复杂但容易忽略：浏览器内购不是技术没写好，而是根本没这个接口。把精力放在清晰的架构分层上，比找一个不存在的 API 更有效。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
