API支付接口，是商户系统与支付服务之间交换订单和支付结果的方式。顾客点击付款后，商户服务端向支付服务发起请求，取得收银台地址或其他付款凭据；顾客完成操作后，支付服务再把结果告知商户。接口接通只是开始，订单状态怎样更新，决定了顾客能否正常取货、开通服务或继续下单。

顾客付款后，订单为什么还显示“待支付”

付款页面提示成功，通常是顾客最先看到的结果。商户系统却不能仅凭顾客浏览器跳回成功页，就把订单改成已支付：页面可能被关闭、网络可能中断，跳转信息也不宜作为唯一凭据。商户服务端收到支付服务发来的通知后，还要核对签名、商户订单号、金额和支付状态，再更新自己的订单记录。

通知也可能延迟或重复到达。接口设计中常提到的“幂等”，落到订单上，就是同一笔成功通知处理多次，仍只产生一次发货或服务开通动作。若通知迟迟未到，商户系统可通过支付服务提供的订单查询接口核实结果，而不是让顾客反复付款。

假设一家提供线上课程的商户接入API支付接口：顾客付款后，支付页面显示成功，返回商户页面时课程仍未开通。客服查到商户订单还停留在待支付，技术人员便核对该订单的服务端通知记录，并向支付服务查询对应交易。查询结果显示支付成功，但通知没有完成处理。

商户先依据可核对的交易结果修正这笔订单，避免顾客重复付款；技术人员继续定位通知失败发生在网络接收还是业务处理环节。若同一通知随后再次送达，订单记录应识别它已处理过，不重复开通课程。故障原因尚未确认前，商户保留通知日志和查询结果，下一笔订单仍按原有校验规则处理，不因这次延迟而直接信任页面跳转。

接入前，先确认系统要接住什么

选择支付服务时，商户往往先问费率和能否收款，开发对接时却还要问清：付款由支付方收银台完成，还是商户页面需要承载更多支付操作？前者通常能减少商户直接接触敏感支付信息的范围；具体接入方式仍以服务方文档和商户业务需求为准。

随后把订单状态说清楚。创建订单时生成的商户订单号，要贯穿发起支付、接收通知和查询交易。支付失败、顾客取消付款、付款处理中，这几种情况不能都写成“未支付”。如果业务要求付款后立即交付数字内容，就要约定通知未到时由谁查询、何时向顾客展示处理中，以及客服依据哪条记录核实。

接口密钥和签名配置也应由服务端管理。测试时别只跑通一笔成功付款，还要检查重复通知、金额不一致和查询结果仍在处理中的情况；这些情况发生时，系统应留下记录，而不是悄悄改动订单。

钱款记录对不上时，查哪一笔

订单显示已支付，与资金最终结算到商户账户，并非同一个时间点。顾客发起退款后，商户订单、支付交易和退款记录还会继续变化。财务核对时，可用商户订单号关联交易记录，再按支付服务提供的账单核对金额与状态。若商户订单已标记成功，支付服务却查不到对应交易，先暂停该订单的自动交付，核对请求和通知记录，避免仅凭页面状态处理。

准备接入API支付接口的商户，可先把现有业务里“付款后立即交付”的动作写清楚，再与开发方确认通知校验和订单查询如何衔接。已有接口却频繁出现漏单时，从一笔异常订单的请求、通知、查询记录查起。