接支付：微信 / 支付宝 / Stripe 的最小可用接法
- 看懂一笔支付从前端发起到订单状态更新要走的完整环节，不再被术语吓住
- 理解回调验签、金额校验、幂等为什么是安全底线，不信前端传来的金额
- 分清个人和企业资质各自能接哪种支付，没有商户号时该怎么办
- 用一张支付安全 checklist 和方案对照表，避开「钱收了订单没改」「被刷重复下单」两类事故
你的产品总算有人愿意付钱了。你兴冲冲去查「怎么接支付」，结果迎面砸来一堆词：商户号、APIv3 密钥、回调通知、签名验签、异步通知、幂等……每一个都不认识，越查越懵，甚至开始怀疑是不是该先放弃收钱。别慌。支付接入的术语吓人，但底层逻辑就一条主线：让用户付的钱，准确地、不重不漏地，变成你系统里一条「已付款」的记录。 这一节就带你把这条主线看清楚，知道每一环在干什么、哪一环偷懒会出事。
这篇适合谁：你已经能用 AI 做出一个能跑、能部署上线的产品（前面部署上线、数据库与后端讲过了），现在想加「收钱」这一步，但从没接过任何支付，一看官方文档就头大。读完你不一定能马上写完代码，但你会彻底搞懂支付该怎么接、哪些坑绝对不能踩，再去看官方文档就有了地图。
提醒：支付涉及商户资质、费率、结算规则，各平台的接口字段和控制台路径也会调整，本文只讲不变的机制和安全底线，具体开通流程、字段名、费率一律以官方文档与平台客服为准、规则会变。
先看清：一笔支付到底走了哪几环
不管接微信、支付宝还是 Stripe，一笔正常支付的骨架是一样的。把它记牢，你看任何一家的文档都能对号入座。
- 前端发起：用户在你的页面点「立即支付」。
- 后端创建订单：你的后端生成一条订单记录（订单号、金额、商品、状态＝待支付），并调用支付平台的接口，换回一个「预支付凭证」（微信叫 prepay_id、支付宝叫支付链接/表单、Stripe 叫 PaymentIntent / Checkout Session）。
- 平台收银台收钱：把凭证交给前端，唤起微信/支付宝收银台，或跳转到 Stripe 的支付页。用户的钱实际是付给支付平台的，不是直接打到你账上。
- 平台异步回调通知你：用户付完后，支付平台会主动向你后端预留的一个「回调地址」发一条通知，告诉你「这笔订单付成功了」。
- 后端验签 + 改订单状态：你的后端收到通知，先验签确认这条通知真是平台发的、再核对金额，确认无误后才把订单状态从「待支付」改成「已付款」，然后发货/开通会员。
这里有个新手最容易搞错的地方：判断「用户到底付没付成功」，不能只看前端。 用户付完钱页面跳回来，只是「看起来成功了」——真正可信的成功信号，是第 4 步平台发给你后端的那条异步通知。前端那条路随时可能因为网络断了、用户手滑关了页面而丢失，只有后端收到并验过签的通知才作数。
原理：为什么验签、金额校验、幂等一步都不能省
支付这块的代码，AI 能帮你写个七七八八，但有三道安全底线，你必须自己看懂、亲自盯住。省掉任何一条，轻则丢单，重则被人薅到破产。
验签：确认通知真是平台发的
你的回调地址是公开在公网上的——任何人都能往它发请求。如果你不验签，坏人完全可以自己伪造一条「订单 XXX 已付款」的假通知打给你，你就白白发了货。
验签的原理：支付平台用只有你和它知道的密钥，给通知内容算了一个「签名」一起发来。你的后端用同一套规则、同一个密钥，对收到的内容重新算一遍签名，两个签名一致，才证明这条通知确实来自平台、且中途没被篡改。签名对不上的通知，一律当假的丢弃。
一句话：回调验签不是「可选的安全加固」，是「不验就等于把发货按钮交给全世界」。
金额校验：永远不信前端传来的金额
第二条铁律：订单金额，永远以你后端数据库里那条订单记录为准，绝不采信前端传过来的金额。
为什么？因为前端的任何数据都能被用户改。如果你下单时是从前端拿「这单 99 元」，懂行的人把请求里的 99 改成 0.01 再发给你后端，你照单创建了一笔 0.01 元的订单——他花一分钱买走了你 99 元的东西。正确做法是：前端只传「买哪个商品」，金额由后端根据商品 ID 自己查表算出来。 回调通知回来时，再核对一遍「通知里的实付金额，和我订单记录里应付金额一致吗」，不一致就报警别发货。
幂等：同一条通知来两次，只能生效一次
支付平台为了确保你一定收到通知，通常会重复发同一条通知（怕第一条丢了）。如果你的代码每收到一次就「给用户加一个月会员」，那同一笔订单通知来三次，用户就白嫖了三个月。
「幂等」就是指：同一个操作执行一次和执行多次，结果一样。 实现思路很朴素——处理通知前先查订单状态，如果这单已经是「已付款」了，说明处理过了，直接返回成功、什么都别做；只有状态还是「待支付」时才真正执行发货逻辑。一句话：拿订单号当钥匙，已经处理过的就跳过。
国内 vs 海外：最小接入思路分别长什么样
国内：微信支付 / 支付宝（需要商户资质）
国内的微信支付和支付宝，核心门槛是「商户资质」——你得先有一个经过认证的商户号，平台才给你开支付能力。这通常需要：
- 企业 / 个体工商户营业执照（个人身份能否开通、能开哪种产品，各平台政策不同且会变，以官方为准）；
- 完成商户入驻、签约对应的支付产品（如网站支付、App 支付、小程序支付）；
- 拿到商户号、API 密钥/证书，这些是后续调接口和验签的凭据。
接入的最小路径（机制不变，字段名以官方为准）：后端用商户号和密钥调「下单接口」拿预支付凭证 → 前端唤起收银台 → 后端配好接收异步通知的回调地址 → 收到通知后验签、校金额、改状态。微信和支付宝各有自己的签名算法和字段，但都逃不出前面那五环。
海外：Stripe（个人开发者门槛相对友好）
Stripe 是海外最主流的开发者支付方案，对个人开发者比国内友好得多——很多国家/地区个人就能注册收款。但它要求你有合规的收款主体和银行账户，面向中国大陆开发者的可用性、需要的公司主体、结算路径，涉及出海合规，规则常变，以官方与专业人士为准（出海收款的完整选择，本站出海方向的「出海收款」专篇讲得更细）。
Stripe 的最小接入比国内还简洁些：后端创建一个 PaymentIntent 或 Checkout Session（金额由后端定）→ 前端用 Stripe 的组件或跳转到它托管的支付页 → 配一个 Webhook 接收支付结果 → 验 Webhook 签名、改订单状态。同样是那五环，验签、金额校验、幂等一个都不能少。
个人没有商户资质，现实选择是什么
如果你既不想注册公司、又想尽快收钱，有两条现实路子（各自的资质要求、费率、合规边界以官方为准、规则会变）：
- 聚合支付 / 第三方收款工具：一些服务商提供「我替你收，扣点手续费再结给你」的能力，能降低你自己申请商户号的门槛。选之前务必确认它的资质和资金安全。
- MoR（Merchant of Record，记录商户）模式：像 Paddle、Lemon Squeezy 这类，它们作为「名义上的卖家」替你收钱、还替你处理税务合规，你只管发货。对没有公司主体、又要卖给海外用户的个人开发者很省心，代价是费率更高。出海这条线，本站出海方向的「出海税务合规」专篇有展开。
增量一：支付最小流程图 + 关键安全点 checklist
把整条链路和安全点画在一起，贴在你显示器边上：
用户点付款
│
▼
[前端] 只传「买哪个商品」，不传金额 ──┐
│ │ 安全点①：不信前端金额
▼ │
[后端] 按商品ID查表算出金额，创建订单（状态=待支付）
│ 生成预支付凭证
▼
[支付平台] 唤起收银台 / 跳转支付页，用户付钱
│
▼
[支付平台] 异步回调 → 打到你后端的回调地址
│
▼
[后端] ① 验签：用密钥重算签名，对不上就丢弃 ◄── 安全点②：验签
② 校金额：通知里实付额 == 订单应付额？ ◄── 安全点③：金额校验
③ 幂等：这单已是「已付款」？是→直接返回 ◄── 安全点④：幂等
④ 都通过 → 改状态为「已付款」→ 发货
│
▼
返回平台要求的成功响应（没正确返回，平台会重发通知）
关键安全点 checklist（接支付前逐条确认你做到了）：
- 不信前端金额：金额一律后端按商品 ID 查表计算，前端只传商品标识
- 回调一定验签：用平台密钥重算签名核对，签名不符的通知直接丢弃
- 回调一定核金额：通知里的实付金额，和订单记录里的应付金额必须一致
- 处理保证幂等：拿订单号判重，已处理过的通知直接返回成功、不重复发货
- 密钥不进代码仓库：商户密钥/证书放服务器环境变量，绝不硬编码、绝不提交到 git
- 回调地址用 HTTPS：明文 HTTP 容易被中间人篡改
- 按平台要求返回响应：没正确应答，平台会判定你没收到而反复重发
增量二：支付方案对照（按你的资质选）
| 你的情况 | 现实可选方案 | 关键门槛 | 说明 |
|---|---|---|---|
| 有公司/个体执照，做国内生意 | 微信支付 + 支付宝官方接入 | 商户资质、入驻签约 | 费率低、最正规，开通流程稍重 |
| 有合规收款主体，做海外生意 | Stripe 直连 | 合规主体 + 银行账户 | 开发者体验最好，对大陆主体的可用性以官方为准 |
| 个人、想尽快收国内的钱 | 聚合支付/第三方收款工具 | 看服务商要求 | 降低自申商户号门槛，务必查资金安全与资质 |
| 个人、卖给海外用户、怕税务 | MoR（Paddle/Lemon Squeezy 等） | 注册即可，无需自有公司 | 平台代收代税最省心，费率最高 |
各方案的资质要求、费率、可用地区经常变动，以官方文档与平台客服为准、规则会变，别拿本文当承诺。
故障排查：支付接不通时照这张表查
| 现象 | 最可能的原因 | 怎么办 |
|---|---|---|
| 用户付了钱，订单一直是「待支付」 | 回调地址不通：地址填错、HTTPS 证书有问题、被防火墙挡了 | 确认回调地址在公网可访问、是 HTTPS；查平台后台的「通知重发/通知日志」看它有没有发、报什么错 |
| 收到回调但验签总失败 | 用错了密钥、签名算法或参数拼接顺序不对、用了测试密钥配生产 | 严格按官方签名规则重写；确认环境（测试/生产）和密钥一一对应；把原始报文打日志逐字段比对 |
| 同一笔订单用户被开通了好几次 | 没做幂等，平台重发通知被你重复处理 | 处理前先查订单状态，已「已付款」就直接返回成功，不再执行发货 |
| 有人用极低金额买走了高价商品 | 信了前端传的金额 | 改成后端按商品 ID 查表算金额；回调时再核对一次实付额 |
| 平台一直反复给你发同一条通知 | 你没按它要求返回正确的成功响应 | 处理成功后，严格按官方要求返回指定的成功内容（如特定 JSON / 文本），平台收到才会停 |
| 测试环境好好的，上线就收不到回调 | 生产回调地址没配、或配的还是测试地址/内网地址 | 确认生产环境回调地址是公网 HTTPS 地址，并在平台生产环境后台登记 |
这张表里最该刻进脑子的两条：「订单一直待支付」八成是回调没通，先去平台后台看通知日志；「被人用一分钱买走东西」一定是信了前端金额。
变体：先不接真支付，怎么验证有人愿意买
如果你还在验证「这东西到底有没有人买」，接全套支付太早了。两个轻量替代：
- 手动收款：早期就放一个二维码 / 一个联系方式，用户想买就直接转账给你，你手动开通。丑是丑，但能用最低成本验证「真有人掏钱」——验证成功了再补正规支付不迟。
- 收款链接 / 托管收银台：很多平台（含 Stripe、部分国内服务商）提供「生成一个收款链接，用户点开就能付」的能力，你连页面都不用写，把链接贴出去就能收钱。适合卖单一商品、做付费咨询、收预订金。
核心判断：「能不能收到钱」和「支付体验丝不丝滑」是两件事。早期先用最糙的方式证明有人买，别在没人买的时候就把精力全砸进验签和幂等里。
动手挑战
挑一个做了才算数：
- 拿你自己的产品，把「一笔支付的五环」逐环写出来：在你这具体是哪个页面发起、后端哪个接口建订单、金额从哪来、回调地址打算配在哪。先把流程图画对，再写代码。
- 找一份你打算接的平台（微信/支付宝/Stripe 任选）的官方接入文档，只读「异步通知 / Webhook」和「签名验证」两节，对照本文那五环，确认你能指出文档里哪段对应验签、哪段对应幂等。
- 进阶：用 MoR 平台（如 Lemon Squeezy）给一个虚拟商品配一个收款链接，全程不写支付代码，体会「个人零资质也能收海外的钱」是什么感觉。
小结 · 你现在掌握了什么
- 你看清了一笔支付的五环：前端发起 → 后端建单 → 平台收钱 → 异步回调 → 验签改状态，知道「付没付成功」要以后端收到的回调为准，不看前端。
- 你理解了三道安全底线：回调必验签（防伪造通知）、金额必由后端定（不信前端）、处理必幂等（防重复发货），少一条都可能出事故。
- 你分清了国内（需商户资质）和海外（Stripe）的最小路径，也知道个人零资质时还有聚合支付和 MoR 这两条现实路子。
支付是产品「从有人用」到「有人付」的关键一跃。代码可以交给 AI 写，但验签、金额校验、幂等这三道闸，你必须自己看懂、亲自守住——这是别人薅不走你钱的最后一道墙。
下一步：能收钱之前，多数产品得先有「用户」——谁付的钱、给谁开通，都要认人。去看本级「用户系统：登录注册 / 鉴权 / 权限的省力做法」那一节，把认人这件事用最省力的方式搭起来；想看自己在整条路上的位置，对照三支柱路线图。
👉 看看我们的 AI 编程实战体系课，或逛 AI 编程教程大全 把基本功打扎实。