WooCommerce 支付成功但订单仍「待付款」或不扣库存：先核 webhook 与支付回调，再查库存预留与缓存

支付网关后台已经显示「已扣款 / Paid」，客户也收到了发卡行短信，回到 WordPress 一看：WooCommerce 订单仍卡在「待付款」，库存没减、订单邮件没发、后续履约流程全停------这和今天写过的「登录后跳回登录页（Cookie / CDN）」「Elementor 编辑器空白」「前台 502/503」「白屏 / Fatal」「Shopify 结账按钮灰色」「WP-Cron 定时不准点」「媒体库上传失败」「固定链接改文章名后全站 404」「微信小程序真机预览白屏」不是一类故障。尤其不要和上午的 Shopify「结账按钮灰色」混着改：那个卡在结账页脚本、收款测试模式与主题 App；这里钱已经从网关扣成功了，卡在 WooCommerce 收不到 / 消化不了支付回调------webhook / IPN、回调 URL 与 HTTPS、支付插件、库存预留、对象缓存脏读、HPOS 与 Scheduled Actions 积压。

更稳的顺序是：先分清是 webhook 没到站 / 回调 URL 写错或被 CDN 缓存 / 支付插件配置 / 库存 hold 与预留 / 购物车结账页缓存 / HPOS 与定时动作 backlog → 对照网关投递日志与 Woo 订单状态 → 核 notify / return URL、HTTPS、Basic Auth 拦截 → 看 WooCommerce → 状态 → 日志与 Scheduled Actions → 再查库存预留分钟数与 HPOS → 最后排除 cart / checkout / wc-ajax / webhook 路径的缓存。别一上来就重装支付插件，也别在没看投递日志之前怪「库存系统坏了」。

很多站点在换支付渠道、开 CDN 全站缓存、迁 HTTPS、切 HPOS、或改「保留库存（分钟）」之后才「突然」出现：网关 Paid、站内 Pending。根因通常不在「商品 SKU 写错」，而在 异步回调这条链路------网关以为通知成功、站点却没把订单推到 processing / completed，库存预留也就一直挂着或根本没触发扣减。

先分清：webhook 未达 / URL·HTTPS·CDN / 支付插件 / 库存预留 / 缓存脏读 / HPOS·Actions

「支付成功但订单待付款或不扣库存」常见落在六条线上，别和 Shopify 结账按钮、WP-Cron、媒体上传混着改：

• Webhook / IPN 未到达站点：网关仪表盘里投递失败、超时、4xx/5xx；站点防火墙、WAF、或临时维护页把回调挡掉。
• 回调 URL 错误 / HTTPS / CDN 误缓存 ：notify URL 仍是旧域名、http、带 Basic Auth；CDN / 全站缓存把 wc-api、webhook、支付回调端点当成可缓存页面返回了 200 空壳。
• 支付网关插件配置：测试密钥与正式密钥混用、webhook 签名密钥过期、插件「调试模式」开着导致状态机不推进。
• 库存预留 / Hold stock：订单创建时预留了库存，回调没把状态推过去，预留到期释放或一直占着；「管理库存」与「保留库存（分钟）」设置与预期不符。
• 对象缓存 / 页面缓存脏读：cart、checkout、my-account、会话碎片被缓存，或订单状态读到旧对象缓存。
• HPOS 与 Scheduled Actions 积压 ：高容量订单存储与旧 post meta 不同步；Action Scheduler 队列堵着 woocommerce_run_on_hold_to_processing 一类动作。

另记易混项：仅某一支付方式 Pending、其它方式正常 → 优先查该网关的 webhook 与插件日志；所有方式都 Pending 但网关都 Paid → 几乎肯定是回调 URL / CDN / WAF；订单变 processing 但不扣库存 → 转向库存预留、manage stock、与库存相关插件。

第一步：网关仪表盘对照 Woo 订单 ------ 先看 webhook 投递日志

不要先改库存。打开支付网关后台（Stripe / PayPal / 国内聚合等）与 WooCommerce → 订单：

1. 记下网关侧的 payment / charge ID、状态（Paid / Succeeded）、金额、时间；与站点订单号、订单备注里的交易号是否同一笔。
2. 打开网关的 Webhook / IPN / 异步通知 投递记录：目标 URL、HTTP 状态码、重试次数、响应体摘要。若全是超时或 403/502，问题在站点可达性，不在库存。
3. 在 Woo 订单详情看状态是否仍为「待付款 / Pending payment」、是否有「支付完成」类备注、客户是否已收到 Woo 订单邮件（邮件没发通常说明状态机没走到 processing）。
4. 若网关支持「重新发送 webhook」，先对单笔失败通知重放一次，再刷新订单------能推进则定界在「偶发投递失败」，而不是业务逻辑写坏。

预期定界：

• 重放 webhook 后订单立刻变 processing 且库存下降 → 定界在投递链路；
• 投递日志显示 200 但订单不动 → 进第二、三步看 URL、签名与插件日志；
• 网关根本没有 webhook 记录 → 插件可能没向网关注册端点，或用的是同步 return URL 而非异步 notify。

第二步：确认 notify / return URL、HTTPS、无 Basic Auth、CDN 不缓存回调

回调端点必须「网关能 POST 进来、站点能验签、中间层不篡改」：

1. 对照支付插件文档里的 notify / webhook URL （常见形态含 ?wc-api=... 或插件自定义 REST 路径）是否与网关后台登记的完全一致；换域名、加 www、改 HTTPS 后最容易漏改。
2. 全程 HTTPS；证书过期、中间证书不全、强制 HTTP→HTTPS 循环时，网关侧常记为 SSL 错误或超时。
3. 站点若开了 Basic Auth / 维护模式 / 防火墙国家限制，异步回调会被 401/403------浏览器你自己能进后台，不代表网关 IP 能进。
4. CDN / 全站缓存规则：cart、checkout、my-account、wc-api、webhook、支付插件回调路径必须 Bypass / 不缓存 ；曾见过 CDN 对回调返回缓存的 200 HTML，网关以为成功、Woo 实际没跑状态机。结账链路里动态请求与缓存排除的分层思路，可对照 结账链路里动态请求与缓存排除的分层思路 先定界是「端点被缓存」还是「端点根本不可达」，再决定改 CDN 规则还是改插件 URL。
5. 用网关提供的「发送测试事件」或服务器侧查 access log：是否出现对应 POST、状态码是否 200、响应是否过短（空壳页）。

预期：URL 与 HTTPS 对齐、去掉 Auth 拦截、CDN 对回调路径 Bypass 后，新支付的 webhook 能稳定 200，且订单状态随之变化。

第三步：WooCommerce 状态日志、Scheduled Actions、支付插件与重发

回调能打到站但仍不改状态时：

1. WooCommerce → 状态 → 日志：打开对应网关的日志源，看验签失败、金额不匹配、订单 ID 找不到、或「already paid」一类记录。
2. WooCommerce → 状态 → Scheduled Actions：筛 pending / failed，看是否有支付完成、库存、邮件相关动作堆积；Action Scheduler 表过大或 cron 触发不稳时，状态更新会晚很久才跑（这和今天 WP-Cron 篇相关，但这里先只处理与该订单绑定的动作）。
3. 支付插件设置：正式 / 测试密钥、webhook signing secret、是否误开「仅记录不改状态」的调试项；换密钥后务必在网关后台同步新 secret。
4. 插件若提供「手动拉取交易 / 重新同步订单」，对单笔 Pending 订单执行一次，确认能否对齐网关状态。
5. 一次只动一层：先日志，再单笔重放，再改密钥------避免同时重装插件与清全站缓存，无法定界。

预期：日志里验签通过且 Scheduled Action 跑完后，订单进入 processing / completed；若日志明确报签名错误，回到网关更新 secret，而不是改库存参数。

第四步：库存 ------ 预留、Hold 分钟数、管理库存、HPOS

订单已能推进但仍「不扣库存」或超卖风险时：

1. 商品编辑页确认 管理库存 已开启，库存数量与「允许超卖 / 缺货时隐藏」策略符合预期。
2. WooCommerce → 设置 → 产品 → 库存：看「保留库存（分钟）」------客户下单未付款时会预留；若 webhook 迟迟不到，预留到期释放，表现为「网关已扣款、站内库存却像没动过或已释放给别人」。
3. 查是否有 库存预留 / 仓库 / 多仓库 类插件把「可售库存」与「物理库存」分开；回调成功后是否写回正确仓库。
4. 若启用了 HPOS（高容量订单存储），确认订单在新表与旧 post 之间无同步延迟；个别库存插件仍读 post meta 时会出现「订单 processing、库存数字不变」。
5. 对问题订单：看订单行项目的库存变动记录 / 订单备注；必要时在测试环境用同款商品走一笔沙盒支付，只验证库存扣减路径。

预期：Hold 时间合理、管理库存开启、HPOS 与库存插件读同一数据源后，processing 订单会稳定扣减；预留释放导致的「看似没扣」与「回调没到」要分开处理。

第五步：缓存 ------ 排除 cart / checkout / my-account 与 wc-api / webhook

缓存层最容易把「偶发 Pending」变成「大面积 Pending」：

1. 页面缓存 / CDN：排除 /cart、/checkout、/my-account、含 wc-ajax、wc-api、支付 webhook 的路径；不要对登录会话页做匿名全站缓存。
2. 对象缓存（Redis / Memcached）：支付回调后若订单对象被长期缓存，后台列表可能短时间仍显示旧状态------对单订单或 woocommerce 相关 group 做定向清理，避免「为修一单而 flush 全站」导致其它动态页雪崩。
3. 浏览器与网关 return URL：同步跳转的 thank-you 页若被缓存成未登录版本，客户以为失败，实际要以 webhook 异步结果为准。
4. 改完规则后做一笔小额真实或沙盒支付：网关 Paid → 站内 1～2 分钟内变 processing → 库存 -1 → 邮件发出。
5. 仍异常时回到第一步看该笔的 webhook 投递码，而不是继续加缓存插件。

常见误操作（尽量避开）

• 网关已 Paid 就直接在后台手动改订单为已完成，却从不查 webhook 日志------下一单同样 Pending，问题被掩盖。
• CDN 全站缓存开启后未排除 wc-api / 支付回调，网关侧全是 200，站内状态机从未跑。
• 测试密钥与正式密钥混用，或换 secret 后只改了插件忘了改网关。
• 把「保留库存（分钟）」设得极短，回调稍有延迟就释放预留，再叠加手动改状态，库存对不上。
• 同时重装支付插件、flush 全站 Redis、改 CDN、改 Hold 分钟数四项------维护窗口建议一次只动一层并保留可回滚的插件版本与 CDN 规则快照。
• 和 Shopify「结账按钮灰色」同一套思路去改主题 JS------Woo 这笔钱已经扣成功，问题在回调与库存，不在结账按钮渲染。

验收清单（无软广，只验结果）

同一轮验证建议勾完下面几项再收工：

1. 网关该笔交易 Paid，且 webhook / IPN 投递记录对站点 URL 返回 200；必要时单笔重放成功。
2. notify / return URL 与插件文档一致，HTTPS 有效，无 Basic Auth / 维护页拦截；CDN 对回调与 wc-api 路径 Bypass。
3. WooCommerce 状态日志无验签 / 金额错误；Scheduled Actions 中无长期 pending 的支付完成类动作。
4. 订单进入 processing / completed；管理库存商品数量正确扣减；Hold 分钟数与预留行为符合预期。
5. cart / checkout / my-account 与 webhook 路径未被页面缓存；对象缓存清理后后台状态与客户 thank-you 一致。
6. 变更可回滚：保留上一版支付插件、webhook secret 变更记录、CDN 规则快照，出问题能单条撤回。

把「网关对照与 webhook 日志 → URL / HTTPS / CDN → Woo 日志与 Scheduled Actions → 库存预留与 HPOS → 缓存排除」按顺序走完，大多数「支付成功但订单待付款 / 不扣库存」会落在前三步之内。与今天的 Shopify 结账按钮灰色、WP-Cron、媒体上传、固定链接 404、小程序真机白屏分界清楚，就不必在错误层重装整站或清全部库存。