支付宝网页支付沙箱用于联调支付接口，不发生真实资金结算。接入电脑网站支付时，网页能跳转到收银台，只完成了支付入口这一段；付款结果还要进入服务端，才能更新业务订单。

开发者常遇到的卡点集中在两处：请求还没进入收银台就报错，或者测试付款完成了，自己的订单仍显示“待支付”。两种现象对应不同的处理方向。

收银台打不开时，核对请求用了哪套配置

接入 alipay.trade.page.pay 时，先把沙箱应用信息与沙箱网关放在同一套配置中。正式环境的应用 ID 配上沙箱网关，请求即使成功发出，也可能在应用识别或验签环节被拒绝。具体入口和网关地址以支付宝开放平台当前沙箱页面及文档为准。

公钥模式下，应用私钥由商户服务端保存，用来给请求签名；对应的应用公钥配置到平台。支付宝公钥则用于验证支付宝返回的数据。把应用公钥当成支付宝公钥，可能出现请求能发出、返回结果却验签失败的情况。私钥不要放进前端代码，也不要随完整配置写入日志。

排查时保留接口错误码和请求时间，对照实际加载的配置。代码仓库里改对了，不代表正在运行的进程已经读取新值；部署环境变量或旧配置缓存仍可能让请求使用另一套密钥。

沙箱付款按当前控制台指引使用测试买家账号及相应入口，普通支付宝账号不能直接替代沙箱账号完成这类测试。

付款完成后，订单为什么还在等待

网页回跳地址 return_url 负责把用户带回商户页面。用户关闭窗口、网络中断，都可能让这次跳转没有完成。服务端确认付款，主要依靠异步通知 notify_url，缺失结果时再通过订单查询核实，不能仅凭浏览器显示“支付成功”就发货。

例如，假设一个本地开发的商城已经能打开沙箱收银台，测试买家完成付款后，商城订单仍停在待支付。开发者发现回跳页面能打开，但服务端没有收到异步通知的访问记录；配置里的通知地址指向本机地址，支付宝服务器无法访问它。

这时处理的是通知可达性，不是修改付款按钮。开发者把通知接口部署到外部可访问的测试服务，并确认入口没有被登录验证拦截。使用临时穿透地址联调时，也要限制暴露范围，避免把管理后台一并开放。

收到通知后，服务端用支付宝公钥验签，核对通知属于当前应用，再确认商户订单号与订单金额匹配。只有交易状态符合付款成功条件，才更新业务订单；处理成功后按接口约定返回 success。

同一笔交易可能收到重复通知。订单更新要保留幂等控制，也就是重复请求到达时，不重复发货或发放权益。这个假设场景中，此前仍待支付的订单还要发起查询；新订单收到通知，并不会自动补齐旧订单的状态。

切换正式环境时，保留哪些测试结果

沙箱联调通过，能验证接口调用和订单处理逻辑，但正式收款仍取决于实际应用的产品开通、签约状态及线上配置。沙箱账号和测试交易记录也不能迁移成正式账户余额或真实订单。

切换时单独核对正式应用、网关和密钥配置，别只替换应用 ID。正式回调地址同样要验证外部访问，尤其是上线后增加了网关鉴权或访问限制的情况。

上线前保留一次完整的订单核对记录：支付结果如何进入订单，以及重复通知到达后订单如何处理。对没有收到通知的测试单，补做查询核实；仍返回未支付或状态不明的订单，保留待核实状态，不凭页面截图改成已付款。