百度支付接入完整指南

一、概述

在百度 App 内完成交易，应使用平台认可的百度收银台（度小满支付）能力，这既是体验要求也是合规要求。整体流程与通用第三方支付一致：服务端创建订单、客户端调起收银台、接收异步通知、更新订单状态、支持退款。这里要明确一点：不要把微信支付当作百度智能小程序的主支付方式。宿主环境不同，平台也不允许这样绕行，方案阶段就按百度侧的收银台能力设计订单与对账模型，后期返工成本很高。

百度端支付还有一个和其他平台不同的背景：很大一部分用户是从搜索结果直接进入小程序的，他们对品牌没有预先认知、耐心也更短。这意味着支付环节的容错空间比私域场景更小——一次加载缓慢或一次报错，用户很可能直接退回搜索结果页点开竞品。因此支付链路的性能与稳定性在百度端的权重要更高。

二、进件与绑定

企业需准备营业执照、法人身份信息、对公结算账户，在百度的商户平台完成支付进件，再把支付能力绑定到智能小程序的 AppID 上。进件时申报的经营类目必须与小程序的类目一致，不一致会被退回。审核通过后才能进行生产环境联调，开发期间可先用测试环境把业务逻辑跑通。建议在项目第一周就启动进件，它的审核时长不由开发团队控制，放到后期会直接卡住联调。

三、技术要点

• 服务端创建预付单，向前端返回调起支付所需参数
• 小程序端使用 swan.requestPolymerPayment 或当前官方支付 API 调起收银台
• 异步通知必须验签，并对同一订单号做幂等更新
• 记录完整支付日志，便于日终对账与客诉追溯
• 处理弱网重试与用户主动取消，避免重复下单

四、合规要求

虚拟商品、预付费、医疗健康等类目各有专门规则，进件前应确认准入。页面上需明确展示价格、服务内容与退款路径，其中退款规则要写清生效条件与到账时效，不能只留一句「详询客服」。还有一项百度端特有的要求：小程序内的服务声明应与站点关联的备案网站上的政策保持一致，两边说法不同会在审核时被质疑内容非同源。涉及医疗、教育、金融周边等强监管类目，建议在提审前请法务过一遍支付与退款相关文案。

五、与搜索落地页的性能配合

从搜索直达进入的用户，支付页的加载速度会直接决定转化率。三项见效最快的优化：把支付相关的脚本单独分包、按需加载；把首屏关键样式内联，避免样式文件阻塞渲染；在用户进入下单页时就预热收银台接口，而不是等点击支付才发起首次请求。性能优化的目标不是跑分，而是让用户从搜索结果点进来到看见「立即支付」按钮的时间足够短。

六、退款、分账与对账

需实现退款接口并与客服系统打通，让客服能在自己的工作台发起退款而不必找技术。部分平台型业务需要把款项分账给服务商或门店，这类能力要在进件时一并开通，事后补开通往往需要重新进件。对账方面，每日拉取平台对账文件与内部订单表逐笔核对，差异按四类归因：未收到回调（订单实际已付但系统未更新）、重复回调（幂等未生效导致多记）、金额精度差异（分账或优惠计算的舍入）、部分退款（内部一笔、平台两笔）。把差异先分类再排查，比逐笔翻日志快得多。

七、安全清单

• 密钥仅存服务端，按环境分离管理，不提交到代码仓库
• 回调接口配置来源 IP 白名单（若平台提供该能力）
• 订单金额在后端计算，前端只负责展示，不参与定价
• 敏感字段（手机号、身份证号、卡号）在日志中脱敏
• 退款接口设置操作权限与审计日志，禁止无记录退款

安全上还有一条容易被忽略的原则：支付状态只能以服务端收到并验签通过的异步通知为准，不能依赖客户端回调结果发货。客户端返回的成功状态可以被伪造，也可能因为网络原因与真实结果不一致。这条原则听起来是常识，但在赶进度的项目里常被简化掉，直到出现刷单或漏单才发现问题。

八、测试用例建议

用例应覆盖八类场景：正常支付、用户主动取消、账户余额不足、重复点击支付按钮、网络中断后重新进入订单页、部分退款、全额退款、超时自动关单。每种场景在测试环境与生产环境各验证一次，生产环境用小金额真机完成。

百度端还要额外加一项联测内容：搜索来源订单打标。建议在验收清单里明确这一项，确保上线后运营能够区分自然搜索、信息流投放与其他来源带来的订单，进而判断不同渠道的订单质量差异。这个标记一旦上线时没做，后续补做需要回溯历史数据，基本等于放弃前几个月的归因分析。

九、与客户管理系统、订单中台的同步

搜索来源的订单建议打上来源参数或关键词标签，这样才能分析出哪些词带来的用户真正付费，进而把预算集中到高转化词上。支付回调成功后同步客户管理系统的会员与积分数据，同步失败要进入重试队列而不是静默丢弃。如果企业同时运营多端小程序，百度渠道的订单必须与微信、支付宝渠道的订单共用同一把库存锁，否则大促时极易出现超卖。

十、上线前支付检查表

• 商户进件主体与小程序一致
• 沙箱与生产密钥分离
• 回调 URL 公网可达且验签通过
• 搜索活动价与收银台实付价一致
• 退款权限已配置、客服流程已培训
• 搜索来源打标已联测通过

十一、跨境与虚拟商品提示

虚拟商品、跨境交易、医疗健康等类目对支付与退款都有特殊规则，必须在进件前确认准入结论，不要等开发完成再去申请。这类类目一旦出现违规，可能导致支付能力被下架，届时整个交易链路直接停摆，损失远大于前期合规评估的成本，因此建议与法务共同评估一次再启动。虚拟商品还要额外注意到账时效与使用条件的说明，这是客诉的高发点。

十二、客服与售后支付场景

客服代客退款、手动补单这类操作必须配置独立权限并留审计日志，谁在什么时间为哪笔订单做了什么操作要可追溯。部分行业要求原路退回，具体时效应写入用户协议而不是口头承诺。由于搜索来的用户普遍缺乏品牌信任、耐心也短，建议把退款进度做成小程序内可自助查询，能明显减少电话进线量。客服培训时要特别区分两类话术：「支付失败」（订单已创建、钱没扣成功）与「订单未创建」（下单环节就失败了），两者的排查路径与安抚方式完全不同，混在一起回答会让用户更焦虑。

十三、全链路压测建议

大促或信息流放量之前，要对创建订单、支付回调、库存扣减这三个环节做压测。百度端有一个特殊之处：搜索流量的峰值往往不可预测，可能因为某个热点事件带动某个关键词的搜索量突增，不像私域活动那样有明确的开始时间。因此接口层面必须配置限流与排队策略，回调处理建议走异步队列，避免阻塞主服务进程。看店通的大促保障套餐包含一次压测报告与参数调优建议。

日常运维中还应持续监控「搜索来源的支付转化率」这一单独指标。当它低于整体均值时，优先排查落地页加载速度与价格一致性，而不是急着加功能——搜索用户的流失绝大多数发生在「页面太慢」和「价格和我搜到的不一样」这两件事上。

十四、多端支付策略

若企业同时运营微信、支付宝小程序，各端的支付渠道不同，但订单中台应当统一。有一个统计纪律要守住：百度端的支付失败率应单独监控，不要与微信端混算。两端的用户来源与网络环境差异很大，混算会掩盖百度端的真实问题。退款与对账按渠道分开记账，财务科目才清晰。看店通的中台方案支持多渠道订单聚合报表，减少财务用表格手工对账的工作量。

十五、合规文案

支付页必须展示商户全称、客服联系方式与退款规则三项基础信息。虚拟商品还需额外说明到账时间与使用条件。医疗、教育等类目以平台最新审核指引为准，文案变更后需重新提审，不能直接改线上内容。若业务包含订阅或自动续费（且类目允许），必须在用户支付前显著提示扣费周期、扣费金额与取消路径，并在维护阶段定期核对扣费成功率与相关投诉率——这既是平台审核的要求，也直接决定用户对品牌的信任。另外建议在小程序内增加一个「订单与支付帮助」入口，用问答形式说明常见失败原因（余额不足、网络中断、重复支付），这个小改动通常能明显降低搜索渠道用户的客服压力与跳出率。

十六、价格一致性：百度端最容易翻车的一点

这是百度智能小程序区别于纯私域小程序的关键运维纪律。因为页面会被搜索收录，价格信息会同时存在于四个地方：搜索摘要、信息流素材、小程序商品详情页、收银台实付金额。四处只要有一处不同步，用户就会觉得被欺骗，轻则投诉退款，重则被平台认定为虚假宣传。

具体做法有三条。第一，同一商品在不同长尾落地页上的价格必须一致，不能为了某个关键词单独挂低价引流。第二，改价要走后台审批并设定生效时间，避免大促零点前后出现新旧价格并存。第三，把「搜索规则复核」明确写入改价的标准操作流程——每次改价后必须有人检查对应的搜索摘要与信息流素材是否已同步更新。这一步在其他平台不存在，也正因如此最容易被漏掉。

最后一项常规工作：生产环境的密钥建议每年至少轮换一次，轮换窗口选在业务低峰期，并提前通知财务对账人员，避免出现「旧密钥已失效、新密钥未生效」的空窗导致当日订单全部支付失败。