孟加拉商户支付订单管理：从创建订单到支付确认与异常处理

在孟加拉商户支付业务中，用户点击付款后，业务订单、支付请求和最终交易结果不一定同步更新。页面显示超时，不代表交易失败；收到两次通知，也不代表发生两笔付款。可靠的支付订单管理，需要把创建、确认、查询和异常处理连成可追踪的流程。

对于涉及 bKash、Nagad 的业务，商户应以自身合法取得的账户、通道权限和实际接口文档为基础设计流程，不能假设不同服务具有相同的状态、回调或查询机制。

一、创建订单：先保证唯一性与可追踪性

建议区分业务订单、支付尝试和通道交易。一笔业务订单可能有多次支付尝试，每次尝试都应独立编号；重新发起支付不能覆盖上一笔记录。

• 业务标识：保存商户编号、商户订单号和内部订单号，并对商户范围内的订单号设置唯一约束。
• 交易信息：记录金额、币种、支付用途、通道配置和有效期。金额采用统一精度规则，避免浮点运算误差。
• 关联信息：保存支付尝试编号、通道请求编号及通道返回的交易标识。
• 审计信息：保留创建时间、状态更新时间、请求摘要和操作来源，敏感字段按需脱敏。

创建接口应支持幂等：同一商户以相同幂等键提交相同请求时，返回已有结果；如果金额等关键参数不同，应拒绝并提示冲突，而不是再建一笔订单。

二、设计订单状态机：把“未知”与“失败”分开

订单状态机的作用，是明确哪些事件可以推动状态变化。下面是内部状态设计示例，实际映射仍需依据客户自有通道的接口语义。

• 待支付：订单已创建，尚未确认付款。
• 处理中：请求已受理，或正在等待最终结果。
• 支付成功：通过可信接口确认成功，且订单、金额、币种等校验一致。
• 支付失败：通道明确返回终态失败，而非网络请求失败。
• 待核查：结果未知、信息冲突或需要人工介入。

建议把业务订单的“已关闭”与支付尝试的交易状态分开管理。收银台过期可以停止继续支付，但不能据此认定通道没有扣款。退款、结算和业务履约也应使用独立状态，不要用一个“成功”字段代表全部完成。

状态更新应附带原状态条件或版本校验，避免查询任务与回调同时写入造成状态倒退。已经确认成功的交易，不应被迟到的处理中通知覆盖；出现相互矛盾的终态时，应记录冲突并核查。

三、支付确认与重复回调处理

先校验真实性，再更新订单

浏览器跳转、用户截图或前端提示不能单独作为支付成功依据。回调应按照对应接口要求验证签名、时间戳或其他认证信息，并核对商户归属、订单关联、金额和币种。校验不通过时，应保留必要日志，不触发发货或余额变更。

通知可以重复，业务动作不能重复

重复回调处理通常需要两层保护：通知接收层防止同一事件被反复处理，业务执行层保证同一支付只触发一次履约或入账。可优先使用通道事件编号；若接口没有事件编号，应按实际语义设计稳定的去重标识，不能仅用订单号屏蔽后续合法状态通知。

将事件记录和状态更新可靠落库后，再按通道协议应答；向业务系统发送消息时，可采用事务消息表与重试机制，下游仍需幂等。有效的重复通知通常应返回协议约定的正常响应，而不是不断报错导致更多重试。

四、支付超时处理：查询优先于盲目重试

支付超时处理首先要区分接口响应超时、用户操作超时和本地订单过期。这些情况都可能出现“请求未收到响应，但通道已经受理”。

1. 将不确定的支付尝试标记为处理中或待核查，避免直接认定失败。
2. 使用原始请求编号或通道支持的其他标识进行支付结果查询。
3. 根据接口限流要求设置查询间隔、退避策略和重试上限。
4. 超过自动处理窗口仍无结论时，转入人工核查或后续对账，不无限轮询。

查询返回“未找到”也不一定立即等于失败，应考虑通道的数据可见延迟和官方定义。结果未明确前，不宜无条件引导用户再次付款。若确需创建新支付尝试，应提示风险，并持续跟踪旧尝试。

订单关闭后收到成功结果，不能直接丢弃。系统应记录真实支付结果，再根据履约情况转入补履约、退款审核或人工处理。退款是否可执行，取决于客户自有通道权限与业务规则，不能仅凭软件状态变更宣称退款完成。

五、订单异常排查：沿同一笔交易查证据

订单异常排查应串联创建请求、通道响应、回调记录、主动查询和业务处理日志，而不是只看后台最终状态。

• 用户称已付款，订单仍待支付：检查订单关联是否正确、回调是否到达、验签是否失败，并执行支付结果查询。
• 支付成功但未发货：检查业务通知、消息重试和履约幂等记录，不要重新创建支付。
• 金额不一致：核对原始请求与交易数据，转入异常队列，不能自动改写订单金额来完成匹配。
• 同一订单对应多笔成功交易：逐笔核实通道交易标识，区分重复通知与真实重复付款。

自动订单匹配应优先采用可靠的唯一标识；仅凭金额和相近时间匹配容易误认。财务对账还应结合客户可取得的通道账单或交易明细，识别漏单、重复交易和跨日差异。支付成功不等于结算到账，二者需要分别核验。

六、BD Payment 的软件服务边界

BD Payment 提供支付系统软件租赁、部署和技术/API 对接，可围绕订单、商户、代收付流程、多通道管理、自动订单匹配、财务对账、风险管理、代理商、报表、权限和交易查询规划系统，并支持评估独立部署或多租户部署及标准、定制 API 对接。

客户使用自己的支付通道。涉及 bKash、Nagad 的对接可行性，需要结合客户权限、接口文档及测试条件评估，不代表已取得相关机构合作、授权或接入资格。BD Payment 不提供银行账户、电子钱包账户、支付通道、牌照或监管授权。账户使用、数据处理等监管要求，应由客户按自身业务模式向孟加拉国当地专业人士核实。

小结

孟加拉商户支付系统的可靠性，来自唯一标识、清晰状态机、可信支付确认和可恢复的异常流程。上线前应重点测试重复创建、重复回调、回调乱序、查询超时及关闭后付款成功等场景，确保每笔交易有证据、可追踪、可核查。

常见问题 FAQ

1. 支付页面显示成功，可以直接发货吗？

不建议。应由服务端通过经过验证的回调或查询确认支付结果，并校验订单、金额和币种后再触发履约。

2. 重复回调是否说明用户重复付款？

不一定。通道可能因响应丢失等原因重复通知。应核对通道交易标识与交易明细，不能按通知次数判断付款次数。

3. 订单超时后多久可以判定失败？

没有适用于所有通道的统一时长。应依据接口定义、查询结果和有效期规则设置处理窗口，无法确认时保持待核查状态。

4. 接入多个通道能否统一订单状态？

可以建立内部统一状态，但应保留各通道原始状态、错误码和响应记录，避免映射时丢失排查所需信息。

5. BD Payment 是否提供 bKash 或 Nagad 账户和通道？

不提供。BD Payment 提供软件租赁、部署和技术/API 对接服务，客户需自行准备账户、支付通道及相应使用权限。