简介面向需要实现支付宝页面跳转的安卓开发、自动化测试与逆向分析人员这份scheme大全直接从支付宝APK中提取将已开放跳转接口按功能整理成表。scheme以key-value形式配对key中的数字即对应saId替换数值即可跳转到指定页面内容覆盖扫一扫alipayqr://platformapi/startapp?saId10000007等通用入口、蚂蚁森林等业务模块并保留部分历史活动页面跳转时可能提示服务已暂停。压缩包采用zip格式体积仅62KB共2个文件JSON文件存放scheme列表与活动页信息适合程序化解析XML文件提供页面配置说明便于人工查阅二者互为补充可快速检索目标scheme并核对参数。目前已有5732人学习下载整体结构精简、即取即用无需完整反编译即可获取核心跳转参数适合需要快速定位支付宝scheme、减少抓包或逆向成本的开发者也可作为日常开发、App间跳转联调与功能测试的速查手册。1. 支付宝已开放 scheme 大全不是 alipay:// 那么简单搜“支付宝已开放scheme大全”的人多半是遇到了同一个问题自己的 App 或 H5 里想放一个按钮点一下直接唤起支付宝的扫码、转账或收付款页面但又不想为这一个入口去接整套支付 SDK。A同学接手一个下单页需求时就是这么干的结果从网上翻出来的帖子一半过时、一半参数抄错同一个页面在不同文章里 saId 对不上整整折腾了两天才跑通一个扫码页。这篇文章把支付宝当前可用的 scheme 机制、分类清单、接入步骤和常见坑一次讲透。目标是让新手照着能唤起页面让熟手能避开白名单、编码、来路校验这类隐蔽问题。适合客户端开发、前端开发以及做增长落地页、需要判断“这个跳转到底值不值得做”的读者。2. 打开 scheme 之前的底层认知协议头、页面路由与参数模型2.1 为什么是 alipays 而不是 alipay两个协议头的历史包袱支付宝最早的唤起协议是 alipay://很多老文章里写的都是它。那时候客户端只要把这个协议丢给系统就能拉起支付宝 App功能也简单。后来业务页面越开越多alipay:// 这个入口承载不了复杂的路由需求官方把统一入口收敛到了 alipays:// 上。两个协议现在同时存在但实际地位完全不同。我一般会在接入时直接给出两个判断凡是新接的页面一律用 alipays://alipay:// 只在极少数老设备、老版本支付宝上作为兜底保留不要拿它当主入口。原因很实际——alipays 才是当前支付宝 App 真正在监听、真正在解析的协议alipay 很多时候打开的是同一个 App 的默认首页根本到不了你要去的业务页。另外有个常见误解看到 alipays 多了一个 s以为是“加密版”或“HTTPS 版”。其实这个 s 没有任何安全含义它就是协议名的一部分。排查问题时如果把 alipay 和 alipays 混着用会出现“在 Safari 里能打开、在 App 里打不开”的诡异现象后面避坑章节会专门说这个。2.2 一次唤起请求在系统与支付宝之间怎么流转搞清楚流转让排查问题事半功倍。外部 App 或 H5 发起唤起时实际发生的是这样一段链路系统拿到 alipays:// 开头的 URL根据协议名找到已注册该协议的应用也就是支付宝 App然后把完整 URL 交给支付宝进程支付宝的 URL 处理模块解析 host、path 和 query再把参数映射到内部页面路由。关键在于“路由解析”这一步。支付宝收到的不是一个简单的“打开扫一扫”指令而是一个带 host 和 query 的请求。host 决定走哪一套路由最常见的是 platformapi后面跟着 /startapp 表示“启动一个端内页面”。saId 和 appId 决定具体启动哪个页面url 参数再决定这个页面要带上什么业务数据。这段链路对排错的意义是如果唤起后支付宝打开了但页面不对问题基本在参数映射层不是协议层如果支付宝压根没起来问题在协议分发层比如白名单没配、包名没配对。把“有没有起来”和“起来后去哪”分成两个问题看排查效率会高很多。2.3 统一入口 platformapi/startapp 与 saId、appId 的参数关系现在几乎所有的开放页面都走同一个入口alipays://platformapi/startapp。区别只在于后面挂的是 saId 还是 appId。saId 对应支付宝端的某个业务页面它更像“页面编号”appId 对应某个三方应用或合作页面更像“应用编号”。两类参数不能随意互替写错了支付宝会打开一个空白页或者直接提示页面不存在。带业务参数时统一的拼法是在 query 里再放一个 url 参数这个 url 的值本身又是一段带参数的链接所以必须先做 URL 编码再拼进去。比如转账场景saId 决定去转账页url 里再告诉支付宝“转给谁、多少钱、备注什么”。整套结构可以理解为alipays://platformapi/startapp?saId页面服务IDurl编码后的业务参数参数能否省略、能否由客户端自己拼取决于页面类型。基础入口类页面比如扫一扫不需要 url资金操作类页面比如转账和付款业务参数通常要求由服务端生成并带上签名客户端拼出来的请求很容易被支付宝的来路校验拦掉。这一点后面接入章节会展开。2.4 用 scheme 而不是支付宝 SDK先看清这三点区别很多团队纠结一个问题既然有官方 SDK为什么还要用 scheme这里要给出一线判断标准。SDK 的核心能力是“支付交易”和“结果回执”它能告诉你用户付没付、付了多少、支付结果是什么scheme 的核心能力是“把人带到支付宝的某个页面”至于用户在支付宝里做了什么原 App 基本感知不到。所以选型要看业务诉求。如果目标是让用户去支付宝里完成扫一扫、看账单、扫码领券这类场景没有交易结果需要回收用 scheme 是更轻的选择不引入 SDK 体积也没有复杂的商户参数配置。如果目标是标准支付收单页面付完钱后要回到自己的业务系统更新订单状态那就老老实实接 SDK不要指望一个 scheme 回来。还有一个现实约束部分页面虽然理论上可以通过 scheme 打开但接口权限是分批开放的。基础页面谁都能调资金相关页面可能要签约、要配白名单。判断“能不能用”不能只看文档里有没有这个 saId还要看自己的账号有没有对应权限这个在第 3 章的清单里会说清楚。3. 按业务场景分类的 scheme 开放清单支付、资产、生活服务与营销页3.1 支付入口类扫一扫、转账、收付款与对应参数支付入口类页面是接入频率最高的也是几乎所有开发者最想拿到的一批入口。这类页面本身不直接产生资金变动只是把用户引导到对应的功能页所以开放度相对高。先给三个在公开资料里反复出现、且我实际验证过还能用的常见写法页面常见 saId打开效果主要参数开放说明扫一扫10000007直接进扫码页无基础开放个人开发者也能唤起转账10000003进转账页url 业务参数需签约来路校验严格收付款10000009收钱/付款码页无或少量基础开放版本差异需验证扫一扫这个入口接入价值很高很多做门店扫码、物料跳转的场景都用它收口。它不需要任何业务参数拿协议头直接拼即可。转账页的坑最多不建议在客户端自己拼目标账号和金额因为这类请求容易被判定为“外部篡改参数”常见做法是让服务端生成带签名的完整跳转链接客户端只负责把这个链接交给系统。收付款页在不同支付宝版本里的行为有差异有的版本打开直接是收款码有的版本打开是收付款聚合页。如果业务对“必须展示付款码”有强要求不能只依赖 saId还得配合页面内的用户操作路径来做验证。3.2 资产与服务类账单、余额、充值、城市服务资产和服务类页面能唤起但开放程度明显比支付入口类低一截。账单页、余额页这类涉及资金信息展示的页面通常要求应用完成实名认证、签约并且可能有每日唤起次数的限制。公开资料里很少有人能整理出一份完整且长期有效的清单原因是这类 saId 会随支付宝 App 版本迭代而调整不同账号权限下看到的可用列表也可能不同。我在这类页面上给团队的建议是先确认业务上是不是真的需要跳资产页。很多场景其实用“手机充值、话费充值”这类生活服务页也能达到目的不一定非要进余额页。在官方开放平台的后台里登录后检索“scheme 唤起”或“H5 跳转支付宝”相关能力系统会列出当前账号可用的页面列表和对应标识这是最权威的依据比任何人整理的“大全”都靠谱。以公开资料和实际联调经验来看下面这些页面属于“存在但未必对你开放”的典型代表页面典型场景开放前提账单查消费记录需签约常用于生活号或商户应用余额查账户余额需签约个人开发者基本拿不到手机充值充话费/流量需签约部分渠道有结算分润要求城市服务查社保、公积金等已逐步收敛需单独申请3.3 营销与会员类卡包、商家码、生活号营销类页面的特征是入口很容易找但真正要跑通业务闭环往往还需要配合支付宝的卡券或会员体系。卡包页面可以唤起用于展示用户领取的卡券、会员卡适合做“领券后去卡包查看”的引导商家码页面则适合做商户端工具用户点开后能看到自己的收款码但这个能力通常要求当前账号具备商户资质。生活号是另一个需要提的入口。前几年很多团队通过生活号承载 H5 营销页拉起生活号页面就能看到历史消息和关注关系。现在这个入口在收敛部分页面已经并入支付宝 App 的消息中心建议新项目不要再把核心链路压在生活号唤起上。营销页面的 saId 变动频率最高我一般把它放进可配置项里和业务版本一起灰度发布避免一次性写死。3.4 不在开放范围内的页面别在清单里乱找有些页面无论怎么传参都打不开因为它们压根不在对外开放的边界内。支付宝首页、消息、朋友、我的这种原生 Tab 页是支付宝自身产品结构的核心没有任何文档会把它列为开放能力涉及修改支付密码、解绑银行卡、转出资金等敏感操作也不可能通过一个 scheme 从外部唤起。判断一个页面是否开放的简单标准是看它在支付宝 App 里的层级。如果这个页面在支付宝内是“必须经过登录态和风控才能到达”的那它大概率不会开放如果它本身就是一个“单向动作页”比如扫码、付款码、转账输入页才可能被开放给外部调用。遇到文档里模棱两可的页面先按“不开放”处理再拿真实账号做验证。4. 把 scheme 接入 App 和 H5iOS 白名单、Android 可见性与 URL 组装4.1 iOS 接入LSApplicationQueriesSchemes 与 openURL 唤起iOS 接入的第一步不是写代码而是配 Info.plist。iOS 9 之后系统收紧了 App 查询协议的能力如果没有在 LSApplicationQueriesSchemes 里声明 alipays调用 canOpenURL 时永远返回 falseopenURL 也会静默失败。这个配置写错一个问题很大不回传任何错误信息。配置如下keyLSApplicationQueriesSchemes/key array stringalipays/string stringalipay/string /array两个协议都声明一个是主用一个留给老版本兜底。Swift 侧唤起代码可以这样写// 唤起支付宝扫一扫 let saId 10000007 let scheme alipays://platformapi/startapp?saId\(saId) guard let url URL(string: scheme) else { return } if UIApplication.shared.canOpenURL(url) { UIApplication.shared.open(url, options: [:]) { finished in // finished 只表示系统成功接收了请求不代表支付宝页面打开成功 track(alipay_scheme_launch, params: [saId: saId]) } } else { // 常见原因未安装支付宝或 Info.plist 缺失白名单 openAppStoreFallback() }注意 canOpenURL 的语义它判断的是“当前 App 是否允许查询这个协议”而不是“支付宝是否真的已安装”。白名单没配时即使装了支付宝也会返回 false。所以排查 iOS 唤起失败时先看配置再看设备是否安装客户端顺序不要反。4.2 Android 接入Intent 跳转与 API 30 的包可见性限制Android 侧的核心是 Intent 加包名限定。直接用 ACTION_VIEW 打开一个 alipays 的 Uri 会让系统弹出“选择打开方式”的列表用户一旦选错体验就崩了所以必须 setPackage 限定到支付宝。Android 11API 30之后另一个约束浮出水面包可见性受限resolveActivity 在没声明 queries 时会返回 null。Manifest 里需要加这样一段queries package android:namecom.eg.android.AlipayGphone / /queries对应的 Kotlin 唤起代码val target alipays://platformapi/startapp?saId10000007 val intent Intent(Intent.ACTION_VIEW, Uri.parse(target)).apply { // 限定支付宝包名避免弹出选择器 setPackage(com.eg.android.AlipayGphone) } if (intent.resolveActivity(packageManager) ! null) { startActivity(intent) } else { // 未安装或 Android 11 缺少 queries 声明 goDownloadPage() }这里有一个容易翻车的细节manifest 里的 queries 和代码里的 setPackage 必须指向同一个包名写错任何一个都会让 resolveActivity 返回 null。另外在 Android 上的 URL 参数组装要额外小心Uri.parse 会直接把整个字符串交给系统如果 url 参数里还有未编码的中文、空格或特殊符号支付宝解析时会截断参数。4.3 H5 接入location.href 唤起与超时兜底H5 页面没有客户端那么多系统限制但面临一个更实际的问题如何判断唤起是否成功失败后怎么办。最稳妥的做法不是直接 location.href而是动态创建 a 标签触发点击再配一个超时兜底逻辑时间到了发现页面还没切走就认为唤起失败并跳到下载页或引导页。下面是一个最小可用的 H5 唤起实现function launchAlipay(saId, fallbackUrl) { // 组装 schemesaId 原样拼接业务参数再做一次编码 const scheme alipays://platformapi/startapp?saId encodeURIComponent(saId); // 用 a 标签的 click 触发兼容部分 WebView 对 location.href 的拦截 const link document.createElement(a); link.href scheme; link.style.display none; document.body.appendChild(link); link.click(); // 兜底1.5 秒后页面如果没有被切走多半是唤起失败 setTimeout(() { if (!document.hidden) { location.replace(fallbackUrl || https://www.alipay.com/); } }, 1500); }这个实现里最关键的是“document.hidden”判断。App 被切到后台时浏览器页面会进入隐藏状态如果 1.5 秒后页面仍是可见的说明支付宝没有成功唤起。但 document.hidden 不是所有浏览器都及时准确所以在高并发场景下也可以改成本地时间戳对比在页面切后台的监听里记录时间回到前台再计算唤起耗时。4.4 回调缺失问题能唤起不等于能拿到结果很多团队接入完发现一个大坑按钮点了、支付宝打开了、用户操作完了但自己的 App 收不到任何结果。这不是代码 bug而是 scheme 机制的天然边界。一次唤起本质上是“把控制权交给支付宝”支付宝不会主动通知原 App“用户扫完了”或“转账成功了”。如果想做结果闭环有两条路。第一条是回到前台时感知在 iOS 的 applicationDidBecomeActive 或 Android 的 onResume 里记录时间戳如果 App 被切走超过一定秒数后回到前台可以触发一次业务状态刷新。第二条是走支付宝开放平台的支付结果通知那是 SDK 和 API 的能力边界。确认业务需要结果回收后及时评估是否要从“纯 scheme 方案”升级为“SDK 支付方案”避免上线后才发现拿不到订单状态。5. 接入与复现时的常见问题避坑白名单、编码、来路校验与版本差异5.1 iOS 真机 canOpenURL 永远返回 false现象代码逻辑完全照着文档写但真机上 canOpenURL 永远返回 falseSafari 里直接输 scheme 却能唤起支付宝。原因最常见的是 Info.plist 里的 LSApplicationQueriesSchemes 漏配或者配了 alipay 但漏了 alipays。另一个隐蔽场景是团队用脚本自动化生成 Info.plist脚本里白名单数组没更新打出来的包自然不带。解决先确认 Info.plist 里同时有 alipays 和 alipay 两项改完配置后杀掉 App 重新启动不要用热重载直接测试最后在线上埋点记录 canOpenURL 的结果用数据确认配置已经生效。这个坑最折腾的地方是它不报错唯一的排查手段就是逐项核对配置。5.2 Android API 30 以上 startActivity 静默失败现象低版本设备上跳转正常升级到 Android 11 以上的测试机后调用 startActivity 直接抛 ActivityNotFoundException 或直接静默失败没有任何提示。原因Android 11 收紧了包可见性。没有在 manifest 里声明 queries 时resolveActivity 对未声明的包返回 null代码走了 else 分支看起来就是“没反应”。targetSdk 越高越明显因为高版本系统默认按最严格策略执行。解决在 application 节点下加 queries 声明包名固定写 com.eg.android.AlipayGphone。同时把 resolveActivity 为 null 的场景也纳入埋点区分“未安装支付宝”和“包可见性未配置”两种情况否则线上排查时只能靠猜。5.3 转账类 scheme 提示“来路校验失败”现象按照网上教程拼好了转账参数的 scheme点击后支付宝打开但页面提示“来路校验失败”或“请求无效”有时候直接白屏。原因资金操作类页面会校验请求来源。非签约应用、未做签名的请求、参数被篡改的请求都会被支付宝的安全策略拦下。另一个常见叠加原因是 url 参数没有做 URL 编码导致支付宝解析时把业务参数里的 当成 query 分隔符参数错位。解决转账这类页面不要在客户端拼参数。让服务端生成完整的跳转 URL包含目标账号、金额、备注、时间戳和签名客户端只是把这个 URL 完整地丢给系统。同时约定一句硬规则客户端一律不拼资金参数凡是需要用户填金额的场景先进支付宝页面由用户自己输入。5.4 H5 唤起后返回白屏、URL 被截断现象H5 页面点按钮成功唤起支付宝但从支付宝返回浏览器时原来的页面变成白屏地址栏留下一串百分号编码的乱码。原因最常见的元凶是 URL 没有被正确编码。a 标签的 href 里直接拼了带中文或带 的未编码参数浏览器把它们当成自己的 query 解析返回时又把损坏的 URL 重新加载了一遍。另一类情况是页面在微信等 WebView 里scheme 被拦截后没有正确走 fallback。解决组装 scheme 时只对参数值做 encodeURIComponentkey 不要编码用代码动态设置 href不要用静态模板字符串微信环境优先用微信开放标签或 Universal Link 方案而不是裸 scheme。这个坑强验一次就够后面所有新页面接入都按同一套编码规范走。5.5 版本升级后唤起成功率突然下跌现象代码一两个月没动线上唤起成功率从 90% 掉到 70%甚至更低。客户端版本没发支付宝侧的更新也没法回滚。原因支付宝 App 版本升级后某些业务页面的 saId 会被调整、下线或合并。扫一扫、收付款这类基础页相对稳定但营销类和资产类页面变动最频繁。另一个原因是新版本支付宝风控策略收紧部分低活跃账号的唤起行为会被限制。解决把 scheme 清单做成远端配置由服务端下发客户端不写死。线上配置支持灰度发现某个 saId 成功率下降时可以单独替换或降级到 fallback 页面。定期用真实账号和真实版本跑一遍唤起巡检把成功率数据沉淀下来作为支付宝版本发版后的常规监控项。6. 验证 scheme 可用的三个实用技巧浏览器直联、埋点与抓包6.1 本地静态页直连验证替代真机反复装包拿到一份 saId 清单最快速的验证方式是做一个本地静态页面把候选的 scheme 全部放进去用手机浏览器打开后逐个点击。这样不用每次改代码、打包、装到真机十分钟能过完一批页面。html body a hrefalipays://platformapi/startapp?saId10000007打开扫一扫/a a hrefalipays://platformapi/startapp?saId10000003打开转账/a a hrefalipays://platformapi/startapp?saId10000009打开收付款/a /body /html点开后观察两个信息支付宝是否被唤起以及唤起后落在哪个页面。注意扫一扫这类页面会直接打开相机验证时选一个光线正常的环境一次弄完。这个方法还能顺带核对不同支付宝版本下的页面差异比任何第三方整理的“大全”都实时。6.2 唤起埋点把成功率做成可量化指标方案上线后不能靠“我试了能打开”来判断质量要让数据说话。在唤起前记录目标 saId 和当前时间在 App 回到前台时再记录一次间隔间隔在一个合理区间内视为唤起成功。iOS 可以放在 applicationDidBecomeActiveAndroid 放在 onResume。func applicationDidBecomeActive(_ application: UIApplication) { if let lastScheme lastScheme, let launchTime lastSchemeLaunchTime { let interval Date().timeIntervalSince(launchTime) track(alipay_scheme_return, params: [ saId: lastScheme, interval: String(interval) ]) lastScheme nil lastSchemeLaunchTime nil } }有了这个埋点就能看到每个 saId 的真实唤起率和返回耗时灰度期间可以对比新旧配置的差异。成功率数据比任何“文档里写着可用”都可靠我见过不止一次线上配置的 saId 在文档里是好的、数据里却一塌糊涂。6.3 抓包确认失败原因区分来路校验与参数错误当支付宝被唤起但页面提示异常时抓包是最快的定位手段。在代理工具里观察支付宝加载页面时的请求重点看两类信息一类是返回的错误标识和错误说明能区分是来路校验失败还是参数格式错误另一类是请求里的 referer 参数能看出支付宝收到的唤起来源是不是符合预期。来路校验失败时支付宝返回的请求会带明显的“非法来源”或“签名校验不通过”类提示参数错误则通常表现为“页面不存在”或“页面加载失败”。前者要去查签约、签名和服务端生成逻辑后者要回头查 saId 和 url 编码是否正确。这两个方向完全相反用抓包一次就能分清不用逐条试错。我自己最早接入时就在 alipay 和 alipays 上栽过跟头又漏配了 Android 的 queries整个下午都在怀疑代码最后才发现是配置问题。后来养成一个习惯任何一份 scheme 清单到手先本地静态页验证再进代码每次支付宝版本升级跑一次巡检看一眼成功率曲线。希望帮到你。本文还有配套的精品资源点击获取