UPI Deeplink支付：扫码与浏览器超链接调用差异问题排查

问题描述 #

我有一个商户静态二维码，提取其中的UPI ID后生成带金额的动态UPI支付链接：

upi://pay?am=100&cu=INR&pa=id@upi&pn=Store%20Name

• 该链接转为二维码扫码时，可正常完成预填100卢比的支付；
• 但将相同链接作为浏览器超链接调用时，UPI应用（Paytm、PhonePe）虽能打开并填充金额，却支付失败，金额被退回：
  • Paytm提示「Payeer_account is not accepting payment」
  • PhonePe提示「receiver's account is inactive」

请问这种同一链接扫码正常、浏览器调用失败的情况，遗漏了什么？

可能的原因及解决方案 #

1. 链接二次编码问题 #

浏览器处理超链接时，可能对部分特殊字符（如%20）进行二次编码，导致UPI应用接收到的参数与扫码时不一致。比如%20被再次编码为%2520，会导致商户名称解析异常，触发支付拦截。

• 排查方式：在浏览器控制台打印实际跳转的链接，对比扫码解码后的原始链接是否完全一致；
• 解决方法：直接使用原始编码的参数拼接链接，避免重复编码，或者使用encodeURIComponent单独处理每个参数后再拼接。

2. UPI应用的来源风控校验 #

多数UPI应用会对支付请求的来源做校验：扫码属于无明确来源的线下场景，而浏览器发起的请求会被标记为Web来源。部分商户的UPI ID可能被设置为仅接受线下扫码支付，拒绝Web端发起的请求。

• 解决方法：联系商户UPI的服务商（如Paytm商家后台、PhonePe商家平台），确认是否开启了Web端支付权限，或是否需要添加额外参数（如tr交易流水号、tn交易备注）来标识合法的Web交易。

3. 缺失原始二维码的关键参数 #

你提取UPI ID时可能遗漏了原始静态二维码中的核心参数（如tr唯一交易ID、mc商户代码、tid终端ID等）。扫码时二维码的完整参数会被正确解析，而浏览器调用的链接因缺少这些参数，被UPI平台的风控系统判定为无效请求。

• 排查方式：使用二维码解码工具重新解析原始商户二维码，对比你生成的动态链接，找出缺失的参数；
• 解决方法：保留原始链接中的必要参数，仅修改am（金额）参数的值，生成完整的动态支付链接。

4. 浏览器自定义协议处理差异 #

部分浏览器对upi://这类自定义协议的处理存在兼容性问题，可能会截断参数、调整参数顺序或丢失部分字段，导致UPI应用接收到的参数不完整。

• 解决方法：尝试使用window.location.href直接触发跳转，而非依赖<a>标签的默认跳转；测试不同浏览器（Chrome、Firefox、Safari）的表现，排查是否为特定浏览器的问题；确保链接无换行、多余空格等格式问题。

内容的提问来源于stack exchange，提问作者Inversa Innovations