收
聚合收款
按业务需要配置常用付款方式。
统一订单入口
商户使用一致的订单信息发起支付，再按实际方式完成跳转或收银台展示。
移动端适配
付款页面适配手机访问，让主要信息和操作保持清楚可见。
覆盖顾客常用付款方式
- 支付宝
- 微信支付
- QQ钱包
- 银联支付
- H5收银台
支付入口集中，订单处理清楚
不是简单地多放几个付款按钮，而是让顾客选择、订单创建、结果确认与商户业务共享同一套逻辑。
单
订单全程处理
支付前后围绕同一商户订单号。
创建与查询
提交订单号、金额与商品信息，必要时主动查询交易状态。
状态边界
待支付、已支付、已取消和已完成拥有明确的业务处理规则。
信
结果通知
页面返回与异步通知各有职责。
后台确认
顾客是否返回页面，不影响商户系统通过异步通知确认结果。
重复保护
同一通知多次到达时，不重复发货、开通权益或增加余额。
查
商户运营
支付完成后仍然能够查询与核对。
交易核对
根据订单号查找结果，检查商户订单、支付金额和状态是否一致。
异常排查
保留必要时间、订单号与处理结果，为客服和技术定位提供依据。
经营方式不同，结果处理仍然清楚
先确定付款成功后商户需要做什么，再选择支付如何进入业务。页面服务顾客，订单状态服务商户。
确认付款，再安排商品发出
顾客提交商品订单并完成付款，商户核对订单号与金额后更新状态，再进入拣货和发货流程。
关键状态待支付 · 已支付 · 已取消 · 已完成
适合业务独立商城 · 社群零售 · 移动商城
预约、到店与服务围绕同一订单
支付可以发生在预约时、到店前或服务结束后，商户根据实际经营方式决定。
适合业务餐饮 · 美业 · 维修 · 活动
下一步确认预约或开始服务
付款结果只触发一次交付
确认支付成功后开通会员、课程或数字内容；移动场景通过链接与 H5 收银台完成付款。
重复保护权益只发放一次
适合业务课程 · 会员 · 软件 · 现场收款
每一步都知道，要交什么、等什么
先把商户订单规则想清楚，再创建支付、接收通知并完成联调。接入路径明确，后续维护才稳定。
-
1
准备商户资料
确认账号、配置和业务规则。
需要准备商户账号、返回页面、可从公网访问的通知地址，以及测试与正式环境配置。
需要决定订单号如何生成、未支付订单保留多久，以及成功后执行发货还是开通服务。
-
2
创建支付订单
提交清楚且稳定的参数。
可信订单信息金额与商品信息来自服务端，商户订单号在自己的业务系统中保持唯一。
out_trade_nomoneyname两个不同地址返回地址面向顾客，通知地址面向商户系统，两者不应相互替代。
notify_urlreturn_url -
3
接收支付通知
先校验，再更新业务。
校验通知检查签名、订单是否存在、金额是否一致，以及当前状态是否允许更新。
处理结果更新成功后返回约定应答；重复通知不能产生重复履约。
-
4
联调与上线
成功和异常路径都要验证。
联调范围验证支付页面、通知接收、签名校验、金额核对和业务状态更新。
上线检查测试配置与正式配置分离，并保留必要监控、日志与异常订单处理入口。
安全保障
每个结果，都应该经得起核对
支付页面可以简单，但进入商户业务前的检查不能省略。可信来源、真实订单、一致金额与正确状态需要同时成立。
商户侧责任
密钥保存在服务端，金额由可信服务端生成，异常订单停止自动履约并进入人工核对。
- 加密传输
- 使用安全连接传递订单和支付结果，减少内容在传输过程中的暴露。
- 签名校验
- 确认请求和通知来自可信来源，并识别内容是否被修改。
- 金额核对
- 通知金额必须与商户服务端记录的订单金额保持一致。
- 状态控制
- 只有符合业务规则的订单才能进入下一状态，已完成订单不重复履约。
- 幂等处理
- 同一订单多次收到结果时，发货、开通权益或增加余额只执行一次。
- 异常留痕
- 记录必要的订单号、接收时间和处理结果，但不在日志中输出密钥与敏感数据。
- 权限与配置
- 控制谁可以查看配置、处理订单和修改支付设置，测试与正式配置保持分离。
接入前常见问题
先理解结果如何进入订单，再开始注册和联调。
享易付适合哪些类型的商户？
适合线上商城、本地生活、移动收银、数字内容与会员服务等需要订单和付款结果衔接的业务。
页面返回可以直接作为支付成功依据吗？
不建议。页面返回主要服务顾客体验，商户系统应结合异步通知或主动查询确认最终结果。
如何避免同一订单重复发货？
按照商户订单号管理业务状态，并对通知处理做幂等控制。已完成履约的订单不再次执行相同动作。
线下门店也可以使用吗？
可以。门店可以通过业务页面、链接或 H5 收银台引导顾客付款，再根据订单结果继续服务。
接入前可以先体验付款页面吗？
可以，通过在线测试入口了解付款页面与基本流程，再开始商户注册和系统联调。