接入易错点

 不得由外部 App 或网页跳转小程序收银台完成交易

 说明：小程序支付仅支持在微信内的小程序场景发起并调起；由商户自有 App 或外部 H5 网页跳转到微信小程序后再调起支付，不在小程序支付支持的场景范围内。外部 APP 或 H5 场景不跳转小程序收银台，须按对应支付产品单独设计支付链路；逾期未整改会被关闭「外部跳转小程序支付」权限。
正确应该怎么做：① 经营场景为小程序且在微信内打开的，在小程序内调用 JSAPI/小程序下单接口获取 prepay_id，再用 wx.requestPayment 调起支付；② 经营场景为外部 App 的，按 APP 场景申请开通 APP 支付权限并接入 APP 下单接口；③ 经营场景为外部浏览器网页的，使用 H5 支付；不以跳转小程序的方式绕行。
典型反例：在商户自有 App 内通过开放平台「App 拉起小程序」能力跳转至微信小程序，再在小程序内调起微信支付。见 4012791910-小程序支付常见问题、4013352071-小程序支付常见问题（服务商）、4013080231-APP下单、小程序交易异常自查与申诉指引-腾讯客服 

 下单接口可正常返回 prepay_id，但在调起支付阶段报错，提示「当前商户该支付方式存在异常，暂时无法支付」，用户无法完成付款，商户小程序还可能被按交易异常处置。 

 openid 须由本次下单及调起支付所用的 appid 获取

 说明：openid 是用户在某个 appid 下的唯一标识，获取 openid 的 appid 必须与下单、调起支付时使用的 appid 保持一致；在哪个小程序内发起交易，就用该小程序的 appid 获取 openid 并下单。
正确应该怎么做：① 小程序场景通过 wx.login 获取 code，服务端用本次下单的 appid 调用 auth.code2Session 换取当次登录用户的 openid；② 调用 JSAPI/小程序下单接口时，appid 传入该小程序 appid，payer.openid 传入基于同一 appid 获取的 openid；③ 调起支付签名中的 appId 同样使用该小程序 appid；④ 发起下单前校验 openid 非空且确属该 appid。
典型反例：多个小程序与公众号共用一套下单服务，统一用某一个公众号 appid 获取 openid 并下单，再在另一个小程序中用返回参数拉起支付。见 4012791897-JSAPI/小程序下单、4012791910-小程序支付常见问题、4012068676-参数说明、wx.login 

 下单接口返回「appid和openid不匹配」，或下单成功但在小程序内拉起支付时报「appid与openid不匹配」，用户无法完成付款。

 下单传入的 openid 须与实际付款用户为同一人

 说明：下单接口传入的 openid 所属用户必须与实际拉起收银台完成付款的用户为同一人；这与「openid 须由本次下单的 appid 换取」是两条不同的约束，需分别校验。
正确应该怎么做：① 在小程序内通过 wx.login 获取 code，服务端用本次下单的 appid 调用 auth.code2Session 换取当次登录用户的 openid；② 服务端校验该 openid 与下单 appid 一致，并将其与当前业务订单的用户身份绑定后再调用下单接口；③ 不在服务端缓存、复用跨用户或跨 appid 获取的 openid。见 4012791910-小程序支付常见问题、4013352071-小程序支付常见问题（服务商）、4020770421-小程序支付错误码 

 调起支付时前端提示「下单账号与支付账号不一致，请核实后再支付」，用户无法完成付款。

 前端下单/支付按钮须做防抖，服务端须对同一业务单据做幂等控制

 说明：用户连点、弱网重连或接口延时都会在极短时间内触发多次下单，生成多笔不同 out_trade_no 的订单并各自完成扣款；微信侧对重复下单的拦截为逐步增强的机制，商户须自行实现防重，不能只依赖微信侧拦截。
正确应该怎么做：① 前端在用户点击「下单/支付」按钮后立即置灰或禁用，并用节流/防抖逻辑限制短时间内的多次点击；② 支付返回后前端须调用商户查单接口确认订单状态，只有拿到明确的成功或失败终态后才恢复按钮或引导再次支付；③ 对仍未支付的订单再次发起支付时复用原商户订单号与有效期内（如 15 分钟）的支付参数（timeStamp、nonceStr、package、paySign），超过有效期整单取消后再重建；④ 服务端以业务订单为幂等粒度做防重复提交，通过锁或数据库唯一约束校验是否已存在待支付订单或短期内已支付成功的订单，重复请求直接返回原支付参数，不再调用下单接口；⑤ 服务端幂等须覆盖全部下单入口，不能只在部分接口加锁。
典型反例：前端已做按钮防抖，但服务端仅按请求或页面会话去重、未以业务订单为幂等粒度兜底；仅在支付按钮上做 300 毫秒防抖，间隔 300 毫秒以上的连点仍可触发多次下单；前端已防抖但服务端无防重复提交兜底；支付结果尚未确认就重新露出付款入口；旧架构小程序前端未做防重复点击，同一秒生成两笔订单且均支付成功并按两笔发货。见 4012791911-小程序支付开发指引、4012076732-小程序支付开发指引（服务商）、4012791870-JSAPI支付开发指引、4012791897-JSAPI/小程序下单、4012075249-支付回调和查单实现指引、4012791900-商户订单号查询订单、4020770421-错误码 

 同一笔业务生成多笔订单并被分别扣款，用户侧可见多笔支付记录，商家需人工核对并逐笔退款，产生额外的退款与客诉成本；在充电桩、场馆预约、购票、寄存柜等场景下还会造成同一用户重复占用库存或资源、重复开柜。

 服务端须按用户维度做流控并限定同一用户的购买次数

 说明：秒杀、抢票、定时开票等并发场景与「同一业务单据防重复」是两套不同的约束：即便服务端已做单据级幂等，同一用户仍可发起多笔彼此独立的业务订单并全部支付成功，脚本还能绕过页面交互直接批量调用下单。
正确应该怎么做：① 服务端对同一 openid（可叠加设备维度）在设定时间窗口内的下单请求次数做限制，超出阈值的请求直接拒绝并向用户返回明确提示；② 同时设置活动/商品的单用户购买次数上限，限购策略须覆盖全部下单入口与页面，策略调整后在灰度环境验证生效再放开；③ 该频次限制与前端按钮防抖、服务端业务单据幂等并列实施，三者不互相替代。注：可按同一 openid + 同一设备限制 1 秒内只能下单一次，具体阈值以商户自身业务需要设定。见 4012791911-小程序支付开发指引、4012791870-JSAPI支付开发指引 

 抢购、定时开票等高并发时段同一用户在 1 秒内成功下多笔订单并全部扣款；黄牛通过第三方软件/脚本在 1 秒内下数十单批量屯券占库存，造成超卖或库存多占，商户需事后封号、回查限购策略并承担库存与活动损失。

 不可在小程序 web-view（H5 页面）内通过 JSAPI 拉起支付或收款页面

 说明：小程序内的 web-view（H5 页面）不支持通过 JSAPI 拉起支付或收款页面，也不支持在 web-view 内使用 H5 支付（H5 支付只能在微信外的浏览器中使用）。
正确应该怎么做：① 小程序内的支付须在小程序原生页面完成：服务端调用 JSAPI/小程序下单接口获取 prepay_id，前端用 wx.requestPayment 调起收银台；② 若业务为商家转账的用户确认收款授权，须按 JSAPI 调起免确认收款授权文档在小程序内通过 wx.requestMerchantTransfer 拉起，不能沿用 H5 页面里的 JSAPI 调起逻辑。
典型反例：把已有的 H5 收银台页面或 JSAPI 调起逻辑直接放进小程序 web-view 内复用。见 4012791910-小程序支付常见问题、4012791898-小程序调起支付、4015930512-JSAPI调起免确认收款授权 

 在 web-view 内调起时报错，支付或收款页面无法拉起，用户无法完成付款或收款确认。

 调起支付签名须用实际调起支付的 appid 与本次下单返回的 prepay_id 计算

 说明：paySign 由 appId、timeStamp、nonceStr、package 四行参数构造签名串，用商户私钥做 SHA256 with RSA 签名并 Base64 编码得到；其中 appId 须为实际调起支付的小程序 appid 且与下单时传入的 appid 一致，package 为本次小程序下单返回的 prepay_id（格式 prepay_id=）。调起支付签名与下单请求的请求签名不是同一套签名。正确应该怎么做：① 调用 JSAPI/小程序下单接口获取 prepay_id；② 以实际调起支付小程序的 appid、当前 10 位秒级时间戳、随机字符串、**prepay_id= 四行构造签名串；③ 用商户 API 证书私钥签名并 Base64 编码，作为 paySign 连同 timeStamp、nonceStr、package、signType 传给 wx.requestPayment。
典型反例：把下单接口的请求签名串或其他支付产品的签名串直接用作调起支付的 paySign。见 4012791898-小程序调起支付、4012365341-小程序调起支付签名、4012791910-小程序支付常见问题 

 调起支付返回签名错误（sign error），无法拉起收银台，交易无法完成。