一个朋友上周问我：“网站收钱到底怎么弄的网站？我填个银行卡号，钱就没了？支付”他做电商三年，一直用第三方平台，何实从没想过底层逻辑。网站其实支付功能拆开看，支付就是何实三件事：谁发起、谁确认、网站谁记账。支付

最直白的何实实现方式是接入支付网关。你见过收银台页面吧？网站用户点“支付”，浏览器跳转到银行或第三方支付公司的支付页面，输入密码，何实然后跳回你的网站网站。这中间有个关键动作——回调通知。支付银行扣完钱，何实得告诉你“这单成了”，不然你这边还显示未付款，用户得骂娘。回调就是支付公司往你服务器上发一条HTTP请求，带订单号、金额、签名，你收到后得验签，确认是银行发的，不是黑客伪造的，然后更新数据库订单状态。

有人觉得回调麻烦，想自己写个支付系统。我劝你死心——银行接口文档能看哭你，而且安全要求极高。你存用户卡号？PCI-DSS合规认证先过一遍，那玩意儿能把你公司财务拖垮。现实中90%的网站都走第三方：支付宝、微信支付、PayPal，或者聚合支付平台。它们的SDK封装好了，你调几个接口就行。

举个具体例子。用微信支付Native支付，流程是这样的：你后端生成订单，调微信接口拿到一个二维码链接，前端把二维码显示给用户。用户扫码后，微信后台扣款，然后异步通知你的服务器。你得在回调接口里做三件事：验证签名，检查订单状态是否已支付（防止重复通知），改数据库。最后返回“SUCCESS”给微信，不然它会隔几分钟再通知一次，直到你确认。

这里有个坑——订单状态要设计成“待支付、已支付、已退款、关闭”。别用布尔值，一个字段搞定所有状态，不然退款的时候你就抓瞎了。我见过一个团队，订单表只有paid和unpaid，退款功能上线时直接改表结构，数据迁移跑了一夜。

安全方面，除了验签，还得防“金额篡改”。用户提交订单时，前端传个价格给你，后端必须重新算一遍价格，不能信前端传的。有人会改请求参数，把100元改成1分钱。你后端得用服务端价格，比如从商品表里重新查单价乘以数量。还有个细节，回调通知的金额也要和订单金额比对，不一致直接报警。

支付成功后，别忘了用户可能关掉页面。所以前端要用轮询或者WebSocket，等回调触发后推送“支付成功”页面。不然用户付完钱，跳回你网站还是“待支付”，他截图发客服，你后台一查其实到账了，两边都尴尬。

最后说句实在话，别自己造轮子。支付不是炫技的地方，出错就是钱的事。用成熟方案，把精力放在你的业务逻辑上——比如怎么让用户愿意掏钱，那才是你网站真正的核心竞争力。

(责任编辑：焦点)