配置页面要求填写异步通知地址

易支付异步通知地址，填写的是你的网站用来接收支付结果的服务端接口 URL。例如网站域名是 www.example.com，开发者已部署支付通知接口，那么地址可能写成 https://www.example.com/api/pay/notify。这只是格式示意，实际路径以自己部署的接口为准，不能直接照抄。

这个地址也常在接入文档或代码中写作 notify_url。用户付款后，支付平台向该地址发送通知；网站收到并核对通知，才会把对应订单改为已支付。因此，填一个能打开的网页还不够：该路径背后要有处理通知的程序。

支付成功后用户浏览器跳转到的页面，通常对应同步返回地址或 return_url。用户关闭页面、网络中断，都可能影响浏览器跳转，却不应决定订单能否入账。配置时不要把商品页、会员中心或“支付成功”展示页直接填进异步通知地址，也不要填写 localhost、局域网 IP，或只有本机能访问的开发环境地址。

钱付了，网站订单仍显示待支付

假设一个网站接入易支付后，测试付款已完成，但后台订单一直停在“待支付”。站长起初盯着支付成功页检查，发现页面确实正常跳转。开发者随后查看通知接口的访问记录，发现没有对应请求，再核对提交订单时传给支付平台的 notify_url，才发现其中仍是开发电脑上的本地地址。

处理这类情况时，先确认当前订单实际提交了哪个地址。有的程序在后台配置通知地址，有的在发起支付的代码中生成；只改后台显示的字段，未必会改变已提交订单的参数。地址改为可从公网访问的接口后，再用新订单测试，观察支付平台的通知记录和网站接口日志。此前那笔订单仍需核对平台交易记录，不能因为页面显示待支付就让用户重复付款。

如果平台记录显示通知已发出，而网站日志里出现拒绝访问、跳转登录页或服务器报错，问题就转到接口接收环节。网站设置的登录验证、访问限制，或服务器配置，都可能拦住通知请求。检查时保留请求到达时间和响应状态，避免只凭前台订单页面猜测原因。

通知到了，订单却没有更新

收到请求不代表可以直接改订单。接口要按所接易支付服务的文档核验签名，并核对本地订单号、支付状态和金额，再写入订单。不同服务商的参数、请求方式和“接收成功”响应文本可能不同，照搬另一套易支付代码，容易出现通知反复发送、订单始终不更新的情况。

同一笔支付也可能收到重复通知。订单处理程序应让已完成的订单保持原状态，避免重复发货或重复开通服务；返回给平台的确认内容，则按当前接入文档填写。不要把商户密钥放进通知 URL，也不要依靠访问通知地址时显示一句“success”来判断接入完成。

准备填写地址时，先向网站开发者确认支付通知接口的实际路径，再核对发起支付时传出的 notify_url。上线前用一笔测试订单走完付款、通知接收和订单更新，并保留平台通知记录与网站日志；若订单没有变化，就从这两处记录继续定位。