内容摘要：支付宝当面付最直接的理解就是：让网站生成一个二维码，用户用支付宝扫一下就能完成付款。不需要跳转到支付宝的收银台页面，整个支付过程在扫码那一瞬间就搞定了。我第一次接触这个接口的时候，觉得它比电脑网站支付

支付宝当面付最直接的支付理解就是：让网站生成一个二维码，用户用支付宝扫一下就能完成付款。宝当不需要跳转到支付宝的面付收银台页面，整个支付过程在扫码那一瞬间就搞定了。接入我第一次接触这个接口的网站时候，觉得它比电脑网站支付清爽太多——没有中间跳转，支付没有等待页面，宝当用户扫完就走。面付

但真要把它接进自己的接入网站，有几个坎得提前知道。网站

先搞清楚你要的支付是哪种“当面付”

支付宝开放平台里的“当面付”其实包含两个场景：条码支付和扫码支付。条码支付是宝当你用扫码枪扫用户手机上的付款码，适合线下收银台那种场景。面付扫码支付才是接入我们做网站真正要用的——后台调接口生成一个二维码图片或链接，用户拿支付宝扫。网站

很多教程把这两个混在一起讲，看得人一头雾水。你如果是给网站接入，盯准 alipay.trade.precreate 这个接口就行。

接入流程没想象中复杂，但细节容易翻车

整体路径是这样的：在支付宝开放平台创建应用 → 签约“当面付”产品 → 配置密钥 → 调接口生成二维码 → 处理异步回调。

签约这一步卡住过不少人。当面付需要企业资质，个人开发者暂时签不了。如果你是个体工商户，拿营业执照去申请一般没问题。签约通过后，在应用管理里把“当面付”加进去，然后生成 RSA2 密钥对。公钥上传到支付宝后台，私钥留在自己服务器上。

这里有个我踩过的坑：支付宝密钥工具生成的密钥格式跟某些语言 SDK 要求的格式不完全一样。比如 PHP 的 SDK 需要 PKCS1 格式的私钥，而工具默认导出的是 PKCS8。你得用 openssl 转一下：

openssl rsa -in pkcs8_key.pem -out pkcs1_key.pem

不转的话，调接口会直接报“私钥格式错误”，而且错误提示很含糊，查半天查不出原因。

生成二维码只是开始，回调才是重头戏

调 alipay.trade.precreate 接口，传入 out_trade_no（你自己的订单号）、total_amount、subject 这几个必填参数，支付宝会返回一个 qr_code 字段。这个字段的值是一个 URL，你可以把它转成二维码图片展示给用户。

用户扫码后，支付宝会异步通知你的 notify_url。这个回调处理逻辑必须写对，否则会出现“用户付了钱但网站显示未支付”的尴尬情况。

回调里要做几件事：验证签名、检查 trade_status 是否为 TRADE_SUCCESS、核对订单金额、更新自己数据库的订单状态。验证签名这一步别偷懒，不验签的话别人伪造一个 POST 请求就能把你的订单标记为已支付。

还有个细节：支付宝的回调可能会重复发送。你的回调处理逻辑得做成幂等的——同一个订单号已经处理过了，直接返回 success 就行，别重复发货。

几个实际使用中的观察

当面付的费率是 0.6%，比电脑网站支付的 0.6% 一样，但体验好很多。用户不用离开你的网站就能付款，转化率明显高一些。

二维码的有效期默认是 2 小时。超过时间没支付，这个码就失效了。你可以在调接口时用 timeout_express 参数自己设，最短 1 分钟，最长 2 小时。我一般设 15 分钟，够用户操作了，也不至于让一堆无效订单堆在支付宝那边。

另外，当面付不支持信用卡。花呗倒是可以，但需要单独签约。如果你的用户群体信用卡使用率高，这个得提前考虑清楚。

轮询查单这个方案我不太推荐。有些开发者懒得写回调，前端每隔几秒调一次自己的查单接口。用户量小的时候没问题，量一上来，支付宝的查单接口有频率限制，很容易被限流。老老实实写回调，省心得多。

最后说一句，支付宝的沙箱环境跟生产环境还是有差异的。沙箱里测试通过不代表上线就没问题，尤其是回调地址的配置。上线前拿一分钱真实付一笔，比什么都靠谱。