想让用户在自己的页面完成付款

API支付接口对接，简单说，就是让商家的系统按照支付服务方提供的规则发起收款，并接收交易结果。用户在小程序里点“支付”，看到付款页面，只是其中一段。商家的订单系统还要知道这笔钱对应哪张订单、交易有没有成功，才能继续发货或开通服务。

因此，沟通“能不能接支付接口”时，先说清收款场景：用户在哪里下单，由谁收款，付款后系统要执行什么动作。已有成熟收银台的商家，可能只需接入支付服务方提供的页面；如果订单、会员权益都在自有系统里，开发人员还要把支付结果接回业务系统。两种需求都会被称作“对接”，工作范围却不同。

支付服务方一般会提供接口文档和测试环境。开发人员按文档提交订单信息，服务方返回用于调起付款的内容；用户完成操作后，系统再获取交易结果。接口能发起支付，不代表收款流程已经跑通，后续的订单更新同样要测试。

付款完成，订单却还显示“待支付”

假设一家提供线上课程的平台接入支付后，测试人员完成付款，页面返回课程列表，订单却仍是“待支付”。此时不宜仅凭页面跳转就手动开通课程：用户关闭页面、网络中断，或者返回页面加载失败，都可能改变页面表现，但未必改变支付结果。

开发人员可以围绕这一笔测试订单查记录：支付请求是否生成了对应的交易信息，支付服务方返回了什么状态，通知商家系统交易结果的“支付回调”有没有到达。回调是服务方主动发送的一条消息，商家系统收到后还要核对订单金额、交易标识，并验证消息确实来自约定的服务方，才更新订单。

如果服务方记录显示已支付，而商家系统没有收到回调，处理方向是检查回调地址和接收日志，再通过服务方提供的查询方式核实交易。回调可能重复发送，同一笔订单的更新还要避免重复开通课程。测试团队暂时保留这笔订单的交易记录，等回调问题定位后再复测；期间不能把“页面跳回来了”当作付款成功的依据。

退款也属于同一套交易链路，但不一定包含在最初的收款对接范围内。产品准备上线前，商家和开发人员仍要确认退款由后台人工操作，还是由自有系统发起，否则售后出现时才会发现缺少处理入口。

询价或安排开发前，确认对接范围

商家询问开发时间和费用时，直接说“接一个支付接口”容易得到差异很大的报价。把现有系统、付款入口和付款后的业务动作写清楚，开发人员才能判断要改动哪些页面与订单逻辑。接口文档、测试账号等资料由支付服务方按其要求提供；正式环境的密钥不能直接放进公开页面或客户端代码。

上线前，测试不应停在“付款按钮能打开”。至少用测试订单核对一次支付结果与商家订单状态，并确认重复通知不会造成重复发货或重复开通。正式交易开始后，若用户反馈“已付款但订单未更新”，保留订单号和支付交易记录，按记录核对服务方状态，再处理订单，避免让用户重复付款。