Umbraco uCommerce：DIBS 回调后未执行 Checkout pipeline

2026-10-24支付老李

结论

问题不在 Checkout pipeline，而是 DIBS 无法访问自动生成的回调地址：

http://localhost:13267/9/26/PaymentProcessor.axd

acceptUrl 是用户完成支付后，浏览器跳转到的地址，所以浏览器可以访问本机的 localhost。callbackUrl 通常由 DIBS 服务器主动请求，而 DIBS 服务器访问 localhost 时，指向的是 DIBS 服务器自身，并非你的开发机。

由于回调没有到达 uCommerce，支付状态会一直停在 Pending authorization。依赖支付完成事件的 Checkout pipeline 不会运行，basket 也就不会被清空。

为什么返回确认页不代表回调成功

支付过程包含两条彼此独立的请求：

DIBS 将用户浏览器重定向到 acceptUrl。
DIBS 后端请求 callbackUrl，通知 uCommerce 处理支付结果。

目前浏览器能够成功返回：

http://localhost:13267/en-us/paymentconfirmation.aspx

这只能证明第一条链路正常。

支付页面提交的参数中虽然包含：

callbackurl ---> http://localhost:13267/9/26/PaymentProcessor.axd
transact ---> 727162826
statuscode ---> 2

但这些参数只能说明回调地址和交易信息已传给 DIBS，不能证明 DIBS 随后成功请求了该地址。

uCommerce 通常要由 PaymentProcessor.axd 接收回调、匹配订单并更新付款状态。完成这些处理后，系统才会执行为该支付方式选择的 pipeline。

解决步骤

1. 提供公网可访问的回调地址

可以将站点部署到 DIBS 能够访问的测试环境，也可以通过 HTTPS 隧道将本地站点临时暴露到公网。例如：

https://commerce-test.example.com/9/26/PaymentProcessor.axd

这个地址需要满足以下条件：

DIBS 服务器可以直接访问。
不需要 Windows 登录、Basic Authentication 或后台身份验证。
不会被防火墙、IP 白名单或反向代理拦截。
TLS 证书有效。
请求能够转发到正确的 Umbraco/uCommerce 应用。
回调期间不会被强制跳转到登录页或错误的域名。

2. 不要让 `(auto)` 生成 `localhost`

callbackUrl="(auto)" 会根据当前请求和站点环境生成地址。本地访问时生成 localhost:13267 属于预期行为，但这个地址不能用于服务器之间的回调。

如果当前使用的 uCommerce/DIBS provider 版本支持显式配置回调 URL，可以将其改为公网地址：

testMode="True"
debug="False"
login="*********"
password="*****************"
callbackUrl="https://commerce-test.example.com/9/26/PaymentProcessor.axd"
acceptUrl="https://commerce-test.example.com/en-us/paymentconfirmation.aspx"
cancelUrl="https://commerce-test.example.com/en-us/productoverview.aspx"
merchant="90151341"
useMd5="False"
key1="******************************************************"
key2="******************************************************"

其中，/9/26/ 是当前系统生成的处理路径，不能直接复制到其他环境。应先让 uCommerce 在目标环境中生成实际地址，再以生成的地址为准。

如果所用 provider 只支持 (auto)，则要确保调用 Library.CreatePayment(PaymentMethodId) 时使用的是正确的外部主机名，并正确配置反向代理转发的 Host、scheme 等信息。

3. 验证回调是否真正到达应用

重新创建一笔支付，不要复用已经处于异常状态的测试订单。检查以下内容：

Web 服务器访问日志中是否出现对 PaymentProcessor.axd 的请求。
请求是否发生在支付完成后。
HTTP 响应是否为成功状态。
uCommerce 日志中是否有订单匹配、签名校验、金额校验或 pipeline 异常。
DIBS 后台是否记录了 callback 超时、连接失败或非成功响应。

如果访问日志中完全没有回调请求，问题仍然出在网络或 URL 配置上。

如果请求已经到达，但付款状态仍未更新，则继续检查：

merchant 是否与测试账户匹配。
测试模式是否与测试账号配套。
orderGuid、orderid 和付款记录能否正确匹配。
回调金额是否与订单金额及币种一致。
MD5 设置是否与 DIBS 后台一致。
PaymentProcessor.axd 是否返回异常。
该 Payment Method 选择的 pipeline 名称是否确实为 Checkout。
pipeline 内部是否有组件抛出异常。

4. 区分 authorization 和 acquisition

Pending authorization 表示 uCommerce 尚未成功处理支付通知，因此无法更新付款状态。它不等同于 DIBS 页面显示的支付成功。

DIBS 账户还可能采用”先授权、后扣款”的交易模式。即使 callback 恢复正常，最终状态是否会直接变为 Acquired，仍取决于当前 provider、DIBS 账户设置及支付方式的 capture 流程。不能只根据 statuscode="2" 判断 uCommerce 必须立即将状态标记为 Acquired。

无论采用授权模式还是即时扣款模式，当前指向 localhost 的 callback URL 都需要先修正。

注意事项

不要将清空 basket 的逻辑直接放到 confirmation page 中作为替代方案。acceptUrl 属于浏览器可控制的跳转流程，用户可能关闭页面、重复刷新，甚至直接访问该 URL。订单是否完成，应以经过校验的支付回调为准。

测试期间关闭 MD5：

useMd5="False"

这样可能更便于排查问题，但生产环境应根据 DIBS provider 和商户后台的实际要求，启用并正确配置签名校验。签名设置不一致也可能造成回调已经到达，却被支付处理器拒绝。

先将 callback 改为 DIBS 可以访问的公网 URL。确认 PaymentProcessor.axd 收到请求后，再检查账户模式、签名校验和 pipeline 内部异常。