这是《线上支付 API 接入实战》第02篇。上一篇讲清了一笔订单从下单、支付、通知到退款和对账的完整链路；这一篇解决接入项目的第一个选型问题：用户从不同入口付款，应该选择哪种接入方式？
一家企业准备在自己的业务系统里增加线上支付。
产品经理说：“我们要支持微信和支付宝。”
技术人员继续追问：
- 用户是在微信公众号里付款，还是微信小程序里付款？
- 手机网页是在微信内打开，还是在短信、浏览器或其他App里打开？
- 企业有没有自己的原生App？
- PC网站是跳转收银台，还是让用户用手机扫码？
- 同一个订单会不会从电脑打开，再用手机完成付款？
这些问题如果不先回答，项目很容易出现一种情况：商务上已经确认“支持线上支付”，开发拿到文档后却发现入口、应用、商户权限或调起方式并不匹配。
先说结论
支付接入方式不能只按“想收微信还是支付宝”选择。
真正的选择顺序应该是：
用户从哪里进入 → 在什么环境确认付款 → 使用哪个应用身份 → 由谁签约收款 → 支付完成后回到哪里。
公众号、小程序、外部H5、独立App和PC网站，看起来都是“线上支付”，但它们不是同一个前端环境，也不一定使用同一种调起方式。
企业可以统一内部订单，但不能假设所有入口都能复用同一套前端参数。
一、先纠正一个常见误区：“H5”不是一个万能答案
很多团队把手机上打开的网页都叫“H5”。从页面开发角度看，这种说法容易理解；从支付产品和接入环境看，却可能造成误判。
同一个手机网页，可能出现在：
- 微信内置浏览器；
- 支付宝客户端内；
- 手机系统浏览器；
- 短信、邮件或二维码打开的外部浏览器；
- 企业自己的App内嵌网页；
- 其他App的内置浏览器。
页面看起来一样，支付能力、应用身份、跳转方式和返回路径却可能不同。
例如，微信支付官方文档将微信内置浏览器网页的JSAPI场景、小程序场景、移动端App场景和Native扫码场景分别说明。支付宝开放平台也将小程序、网页和移动App作为不同开发场景提供接入支持。
因此，需求文档里只写“支持H5支付”远远不够，还要写清：这个页面由什么入口打开，打开时处于哪个客户端或浏览器环境。
二、五种常见支付入口，分别适合什么场景？
1. 公众号内网页：用户在微信里打开页面并付款
典型现场
用户关注公众号，从菜单、消息、文章链接或业务通知进入商城、缴费页、预约页，然后在微信内完成支付。
接入判断
这类需求通常不是“公众号本身直接收款”，而是用户在微信内置浏览器打开商户网页，再由网页和商户服务端配合调起相应支付能力。
项目要重点确认：
- 当前页面是否确实在微信内置浏览器中打开；
- 公众号或相关应用身份由谁持有；
- 商户号、应用与支付权限如何关联；
- 页面域名、支付目录、授权或用户标识等配置是否满足实际产品要求；
- 支付完成后返回订单详情还是业务结果页；
- 链接被转发到外部浏览器后，是否仍有可用支付路径。
容易踩的坑
在微信里测试成功，就默认这条链接复制到手机浏览器后也能原样调起。入口环境一旦改变，原有调起方式可能不再适用。
2. 小程序：用户全程停留在小程序里
典型现场
用户在微信小程序或支付宝小程序中浏览商品、预约服务、提交订单并付款。
接入判断
小程序支付通常需要小程序前端、商户服务端、支付服务方和对应应用身份共同配合。服务端先创建支付订单，再把当前场景所需的调起参数交给小程序。
项目要重点确认：
- 小程序由谁注册、认证和运营；
- 小程序应用身份与收款主体是什么关系；
- 是否已经申请并具备相应支付权限；
- 体验版、审核版和正式版使用哪些环境配置；
- 小程序页面路径、服务端域名和回调地址怎样配置；
- 用户支付后停留在哪个页面，订单状态如何刷新。
容易踩的坑
企业已经有公众号，就认为小程序可以直接沿用公众号的全部支付配置。即使属于同一家企业，应用身份、授权关系和场景配置仍需逐项核对。
3. 外部H5：用户在手机浏览器里打开网页
典型现场
用户点击短信、邮件、客服消息或广告链接，在手机系统浏览器中打开付款页；也可能先扫描一个业务二维码，再进入移动网页。
接入判断
外部H5的关键不是“页面能在手机上显示”，而是支付产品是否支持当前移动浏览器环境，以及怎样从网页进入付款工具、再返回商户页面。
项目要重点确认：
- 用户通常从哪个渠道获得链接；
- 页面会在哪些浏览器或其他App内置浏览器中打开；
- 产品是否支持这些真实环境；
- 支付跳转、返回地址和订单查询怎样衔接；
- 用户关闭页面或切换App后，怎样重新找到订单；
- 链接是否需要登录、实名或业务身份校验。
容易踩的坑
把“手机网页”直接等同于某个渠道的“H5支付产品”，没有验证页面实际运行环境。结果可能是外部浏览器能付，转发到微信内打不开；或者页面能打开，却无法按原方案完成支付调起。
4. 独立App：在企业自己的App内调起支付
典型现场
企业拥有自己的iOS或Android App，用户在App内购买商品、充值、订阅服务或支付订单。
接入判断
独立App通常需要商户服务端创建订单，App集成对应SDK或调起能力，再完成客户端跳转与结果展示。
项目要重点确认：
- App的运营主体、应用名称和实际业务；
- iOS、Android或其他系统分别怎样接入；
- 包名、签名、Bundle ID、Universal Link或其他应用配置要求；
- SDK版本、客户端升级和兼容策略；
- 从付款工具返回App失败时，用户如何恢复订单；
- 支付最终状态如何由服务端确认，而不是只依赖客户端回传。
容易踩的坑
只测试“能从App跳出去付款”，没有测试付款后无法返回、用户中途切换网络、App进程被系统回收或旧版本客户端仍在使用等情况。
5. PC网站：用户在电脑上选择支付
典型现场
用户在电脑商城、企业采购平台、SaaS后台或缴费网站提交订单，再通过页面跳转或手机扫码完成付款。
接入判断
PC端常见路径包括电脑网页收银台、展示二维码后由手机扫码，以及其他经产品确认的支付方式。对于扫码流程，订单在电脑创建，付款动作却发生在手机，两端状态必须能够同步。
项目要重点确认：
- 用户是在PC浏览器内完成，还是拿手机扫码完成；
- 二维码由谁生成，有效期怎样管理；
- 二维码失效后是刷新、重新下单还是继续查原订单；
- PC页面怎样查询或接收订单最新状态；
- 用户扫码后更换支付方式，会不会产生多个支付尝试；
- 页面长时间打开、重复扫码或重复刷新怎样处理。
容易踩的坑
把二维码当成一张长期有效的静态图片。支付二维码通常关联具体订单或支付请求，项目必须按实际产品规则管理有效期、刷新和状态确认。
三、五种入口的判断表
| 入口 | 用户主要环境 | 常见确认动作 | 接入时首先核对 | 特别容易混淆 |
|---|---|---|---|---|
| 公众号内网页 | 微信内置浏览器 | 页面内调起付款 | 公众号应用身份、商户关联、目录与授权配置 | 与外部H5混为一谈 |
| 小程序 | 微信或支付宝小程序 | 小程序内调起付款 | 小程序身份、支付权限、服务端与页面配置 | 直接复用公众号配置 |
| 外部H5 | 手机系统浏览器或外部入口 | 网页跳转或调起付款 | 真实浏览器环境、域名、返回路径 | 把所有手机网页都叫同一种H5支付 |
| 独立App | iOS或Android App | SDK或客户端调起 | 应用信息、签名配置、SDK与回跳 | 只相信客户端支付结果 |
| PC网站 | 桌面浏览器 | 网页支付或手机扫码 | 二维码、订单有效期、PC状态刷新 | 把支付二维码当静态收款码 |
这张表用于项目初筛，不代表任一具体支付产品一定支持全部场景。最终仍要以宜收宝实际接入能力、合作机构审核、产品文档和正式协议为准。
四、同一个商城，为什么可能需要不止一种接入方式？
假设企业有一个统一商城：
- 用户从公众号菜单进入；
- 用户把商品链接转发给朋友，对方用手机浏览器打开；
- 企业又把商城嵌入自己的App；
- 销售人员还会把商品二维码发给电脑端客户。
虽然背后是同一套商品和订单系统，但用户进入的环境已经不同。
更合理的设计不是建立五套互不相干的业务订单，而是：
- 统一业务订单层：商品、价格、优惠、库存和履约规则保持一致；
- 独立支付订单层：记录每一次支付尝试及所选入口；
- 建立场景路由层：根据终端环境、支付方式和产品权限选择对应接入路径；
- 统一结果确认层：通知、查单、退款和对账回到同一套内部状态模型；
- 保留入口标识：知道订单从公众号、小程序、H5、App还是PC发起。
这样做的好处是：前端入口可以变化，但订单、退款和财务对账仍有统一主线。
五、产品经理在需求文档里，至少要写清这8个字段
不要只写一句“接入微信支付宝”。建议为每个支付入口建立一行配置，至少包含：
- 业务入口：公众号菜单、小程序页面、短信链接、App页面或PC网站；
- 运行环境：微信内、支付宝内、手机外部浏览器、原生App或桌面浏览器；
- 用户终端：手机、平板、电脑或跨端扫码；
- 应用身份：对应的公众号、小程序、App或网站由谁持有；
- 收款主体：由哪一家企业或商户签约收款；
- 支付方式：希望支持哪些付款工具；
- 结果返回：支付后回到哪个页面，怎样查看最终订单状态；
- 异常替代路径：当前环境不能支付时，是否允许切换入口或付款方式。
技术团队拿到这8个字段后，才能进一步核对接口、权限、SDK、域名、参数和测试环境。
六、选型前最容易忽略的6个问题
1. 页面从哪里打开？
同一个网址，在微信内、手机浏览器和App内嵌页面中的能力可能不同。需求评审必须用真实用户路径描述，而不是只提供页面截图。
2. 付款在哪里确认？
用户是在当前页面内调起、跳到付款工具、打开系统浏览器，还是用另一台设备扫码？这会影响前端流程和状态同步方式。
3. 应用与收款主体是什么关系？
公众号、小程序、App、网站和商户号可能由不同主体持有。能否关联、需要什么授权或证明，必须在开发前核对。
4. 支付后回到哪里？
成功回跳只是用户体验的一部分。还要设计无法回跳、用户关闭页面和订单结果仍在确认中的处理方式。
5. 一个订单能否更换入口？
用户可能先在PC生成二维码，扫码失败后又打开手机链接。系统要明确是否复用业务订单、怎样创建新的支付尝试，以及如何避免重复付款。
6. 当前产品实际支持什么？
行业里常见的支付场景，不等于某一套聚合接口、服务商产品或商户权限已经全部支持。需要产品和合作机构逐项书面确认。
七、不要用“万能收银台”掩盖场景差异
统一收银台可以减少商户前端开发工作，但它不等于所有终端环境都没有差异。
即使使用同一个收银台页面，项目仍要确认：
- 当前浏览器或客户端是否支持；
- 收银台怎样识别终端与路由支付方式；
- 用户退出后怎样回到业务系统；
- 支付结果由谁通知商户服务端；
- 同一业务订单切换支付方式时如何记录；
- 退款、查询和对账是否能统一关联。
产品可以帮企业封装差异，但业务系统仍然要知道订单从哪里来、最终选择了什么支付路径。
八、企业现在可以先完成这份选型清单
准备接入线上支付时，先回答：
-
用户主要从公众号、小程序、外部H5、App还是PC进入？
- 是否存在链接转发、跨浏览器或跨设备扫码？
- 每个公众号、小程序、App和网站分别由谁持有？
- 计划由哪个主体签约收款？
- 当前已经具备哪些支付产品或商户权限？
- 是否需要同时支持微信、支付宝或其他付款方式？
- 支付成功、取消和结果未知时，用户分别看到什么？
- 用户更换入口或支付方式时，订单怎样避免重复？
- 服务端怎样接收通知、主动查单和完成对账？
- 哪些能力已经由宜收宝及合作机构书面确认？
如果前5个问题还没有答案，不建议直接进入接口开发。
写在最后
支付方式选型看似是一个技术问题，实际上先是用户路径和业务主体问题。
不要先问“有没有一个接口全部支持”，而要先确认用户从哪里来、在哪里付、以什么应用身份付、由谁收款、付完回到哪里。
内部订单可以统一，前端接入应按真实环境选择；场景判断越准确，后续开发返工、权限补办和上线异常越少。
我们整理了一份《线上支付场景选型表》，覆盖五类入口、应用主体、收款主体、终端环境、支付方式、返回路径和异常替代方案。
关注“富盛锦科技”，回复“API”，即可领取。
填写业务入口、现有系统、应用归属和计划上线时间后，还可以申请一次接入评估。
下一篇预告：
《支付下单接口怎么设计？订单号、金额和状态是三个关键》
参考依据
- 微信支付商户文档中心：《支付模式》，分别介绍Native、JSAPI和App等支付场景；
- 微信支付商户文档中心：《JSAPI/小程序下单》，说明微信内置浏览器JSAPI场景及小程序支付场景的下单与调起关系；
- 支付宝开放平台：《小程序》，介绍支付宝小程序开发场景；
- 支付宝开放平台：《网页/移动应用》，介绍网页与移动App的应用创建、开发配置和上线流程。
