WooCommerce 支付接口接入
从选网关到「付款成功但订单没变」的排查路径
WooCommerce 本身不带收款能力，所有支付都通过网关插件完成：用户在结账页提交，插件把请求发给支付机构，机构回调通知，WooCommerce 再把订单状态改掉。这条链路上任何一环出问题，表现都是同一句话——钱扣了，订单还是待付款。
四类网关形态
选型先看责任边界
形态决定了 PCI 责任范围、转化率与失败点位置，比费率更值得先想清楚。
跳转托管
用户离开站点到支付机构页面完成付款。接入最简单，卡信息不落在自己服务器，PCI 责任最轻；代价是多一次跳转，移动端掉单率略高。
站内嵌卡
在结账页内嵌支付机构的输入框组件，卡号由对方域名承载。体验接近原生，仍需通过对方的域名校验与 HTTPS 要求，主题改动大时要重测。
直连接口
卡信息经自己服务器转发。转化率通常更高，但站点进入 PCI 合规范围，要满足隔离、日志脱敏、密钥保管等要求，中小站一般不建议自己扛。
线下与本地
银行转账、货到付款、询盘后开票。没有实时回调，靠人工改状态。B2B 站常见，必须把「到账后几天内改状态」写进流程。
选型还要看四件事：目标市场常用的支付方式是否覆盖、结算币种与到账周期、拒付与风控政策、退款是否支持接口操作。费率通常在小额百分比加固定笔费区间内浮动，具体以各家官方报价为准；对客单价高的机械、化工类站点，固定笔费的占比反而比百分比更值得算。
接入四步
回调地址是成败关键
每一步都要在沙箱里验证过再进下一步，跳步是上线后掉单的主要来源。
拿两套密钥
沙箱与生产各一套商户号、密钥、签名盐。分开存放在密码管理器里，绝不混填。测试环境的密钥填到生产站，是「支付成功却验签失败」的头号原因。
填回调与返回地址
回调地址形如 https://站点域名/?wc-api=网关标识，固定链接为美化模式时也接受 /wc-api/网关标识/。返回地址是用户付款后跳回的页面。两者都必须 HTTPS、无 basic 认证、不被 CDN 缓存。
沙箱跑通全流程
用测试卡跑成功、失败、取消、3D 验证四类场景，再测一次部分退款。观察订单状态是否从待付款变为处理中，库存是否扣减，邮件是否只发一封。
上线做小额真单
用真实卡片下最小金额订单，确认到账、回调、发货邮件、退款四条链路。同时打开网关侧的事件日志，留存至少三十天。
四类形态的接入对照
工作量与风险点
| 维度 | 跳转托管 | 站内嵌卡 | 直连接口 | 线下本地 |
|---|---|---|---|---|
| 接入工作量 | 低，装插件填密钥 | 中，要调结账页样式 | 高，需自定义开发 | 低，人工处理 |
| PCI 责任 | 最轻 | 较轻 | 最重 | 无卡数据 |
| 移动端转化 | 受跳转影响 | 较好 | 较高 | 不适用 |
| 典型失败点 | 返回页丢失、回跳 404 | 域名校验、主题覆盖模板 | 签名算法、证书链 | 人工漏改状态 |
| 退款方式 | 网关后台或插件内 | 插件内 | 需自建流程 | 线下退款 |
多网关并存时注意结账页的顺序与默认选中项：把目标市场渗透率高的方式放第一位，能减少一次选择动作。不同网关的订单状态映射也要统一，否则财务报表里会出现同一状态的两种叫法。
支付成功但订单未变更
按这条链路倒着查
现象统一，原因分层。顺序是：网关有没有发出通知 → 服务器有没有收到 → 插件有没有验签通过 → 订单有没有被改。
通知根本没到
- 防火墙或 WAF 拦了外部 POST，回调路径返回 403
- 站点开着维护模式、口令保护或 basic 认证，回调被挡在门外
- CDN 缓存了结账页与回调路径，请求没落到源站
- SSL 中间证书缺失，网关侧握手失败后停止重试
- 回调地址写成了 http，或被 301 到另一个域名，POST 变 GET
到了但没改成
- 密钥环境混用，验签失败后插件直接丢弃通知
- 金额或币种小数位不一致，校验比对不通过
- 网关插件里「订单状态」被设成了待付款，付款后原样不动
- 订单号与网关侧单号对不上，找不到要改的订单
- 启用了高性能订单存储，某个旧插件仍读写旧表，状态写进了另一处
排查动作固定：先在网关后台看该笔交易的事件记录，确认通知发出与返回码；再到服务器访问日志里搜回调路径，看有没有对应时间的请求与状态码；然后翻 WooCommerce 状态页里的网关日志；最后临时停用缓存与安全插件复现一次。用户侧还有一种情况是付款后直接关页面，返回地址没触发，但通知正常到达，订单其实是处理中，属于误会。
环境层面的两个基础项别忽略：站点必须全程 HTTPS，证书链完整，否则部分网关直接拒绝回调；服务器时间要与标准时间同步，签名带时间戳时偏差过大会被判过期。相关配置见SSL 证书与 HTTPS 配置与防火墙与 WAF 配置。
常见问题
五个高频疑问
可以，结账页会并列显示。要注意各网关对货币与国家的限制不同，不支持的组合要隐藏，否则用户选中后提交才报错，体验很差。
必须关。留在测试模式时，真实用户下单不会真正扣款，订单却显示成功，发货后才发现收不到钱。上线检查清单里把这一项单独列出来核对。
虚拟商品或可下载商品付款后直接完成，实物商品默认进入处理中，等发货后人工改为已完成。这是设计如此，不是故障。想改默认状态可在网关设置里调整，但别把实物订单设成自动完成，会丢失发货环节的把控。
先在网关后台确认两笔都成功，再在 WooCommerce 里对多出的订单做全额退款，备注原因。若因回调延迟导致用户以为失败而重付，应在结账页加一句「付款后请勿重复提交，页面跳转可能需要十秒」。
先看结账页是否被主题覆盖了模板，再确认网关插件是否声明兼容当前 WooCommerce 版本与高性能订单存储。升级前在测试站跑一遍下单流程，比事后排查便宜得多。整体搭建顺序见WooCommerce 商城搭建。
支付链路可以先做一次联调体检
信科网络在山东淄博做 WordPress 建站与出海服务 11 年，服务过 3000 多家出口企业。可以帮你核对网关选型、回调地址、证书链与订单状态映射，把掉单原因定位到具体一环。