简介在电商后端开发中支付系统是连接用户、订单与资金的桥梁也是考验开发者对业务流程和数据一致性理解深度的典型场景。本文基于Django框架从订单状态机的数据建模出发详解支付宝与微信支付两大主流渠道的接入流程重点剖析异步回调验签、幂等控制、超时关单等生产级难题。通过沙箱环境调试、回调联调和内网穿透部署完整演示从下单到支付成功的全链路实现。文章还梳理了答辩高频问题与常见踩坑记录帮助开发者理解支付系统中“私钥签名公钥验签”的安全机制以及如何保证订单状态在并发场景下不出现混乱。无论你是准备毕业设计还是构建电商项目都能从中获得一套可落地的支付系统集成方案。1. 为什么毕设选支付系统一次把Django核心能力打满每年毕业季都能看到大量基于Django的XXX系统这类题目但订单支付系统始终是其中比较特殊的一个。原因很简单其他管理系统做完通常只有一个后台和几张CRUD页面而支付系统天然包含订单状态机、第三方接口对接、异步回调、签名验证、并发控制这些真刀真枪的生产级问题。换句话说做完这个项目你几乎把Django后端开发里最值钱的那部分技能都练了一遍。这个项目的标准组合是Django 支付宝 微信支付核心业务就一句用户在商城下单跳转到支付宝或微信完成付款支付成功后系统自动把订单状态改成已支付。听起来简单真正动手之后才会发现验收一个支付系统老师不会只问页面长什么样而是会追问异步通知怎么保证不重复处理回调频率高怎么办订单状态什么时候改退款怎么处理。这篇博文就把我从选题到答辩的全过程拆开讲包括数据库设计、两家支付渠道的接入步骤、回调处理的完整思路以及那些不写到文档里的坑。无论你是正在做这个毕设还是打算用Django做电商类项目这篇都能当一份实操参考来用。先给一个总览整个项目大概分四块Django商城基础商品、购物车、订单、支付宝网页支付、微信Native扫码支付、支付回调与订单状态流转。难度排序大概是回调处理 微信支付接入 支付宝接入 基础商城。后面我按这个顺序展开。2. 订单与支付数据模型状态机比CRUD重要得多支付系统跟普通管理系统的本质区别在于订单不是一个静态的表而是一个会随着外部事件不断流转的状态机。这个设计一旦想明白后面写代码就顺了。2.1 订单表和支付记录表的关系先说订单表。核心字段除了用户、商品、金额这些基本信息务必单独存一个status字段取值范围建议直接定义成枚举常量不要散落在代码里# orders/models.py from django.db import models from django.conf import settings class Order(models.Model): class Status(models.TextChoices): PENDING pending, 待支付 PAID paid, 已支付 CLOSED closed, 已关闭 REFUNDING refunding, 退款中 REFUNDED refunded, 已退款 order_no models.CharField(max_length64, uniqueTrue, verbose_name订单号) user models.ForeignKey(settings.AUTH_USER_MODEL, on_deletemodels.PROTECT) total_amount models.DecimalField(max_digits10, decimal_places2, verbose_name订单金额) status models.CharField(max_length16, choicesStatus.choices, defaultStatus.PENDING) created_at models.DateTimeField(auto_now_addTrue) paid_at models.DateTimeField(nullTrue, blankTrue)再单独建一张支付记录表class Payment(models.Model): class Channel(models.TextChoices): ALIPAY alipay, 支付宝 WECHAT wechat, 微信支付 order models.ForeignKey(Order, on_deletemodels.PROTECT, related_namepayments) channel models.CharField(max_length16, choicesChannel.choices) transaction_id models.CharField(max_length64, db_indexTrue, verbose_name渠道交易号) raw_notify models.JSONField(verbose_name回调原始报文) status models.CharField(max_length16, defaultnotified) created_at models.DateTimeField(auto_now_addTrue)为什么订单和支付要分两张表因为一个订单可能多次发起支付比如用户扫码后一直没付重试了几次如果只在订单表里记一个支付单号数据就乱了。支付记录表每发起一次支付就插入一条回调来了按transaction_id去匹配记录既方便对账也方便排查用户到底付到哪个单子上了这种问题。2.2 订单号生成规则别用自增ID订单号这里有个初学者很容易忽略的坑绝对不能直接用数据库自增主键当订单号发给支付平台。原因是支付平台的流水号规则要求你这边尽量做到全局唯一、可追溯而且订单号会出现在支付回调、对账单、用户退款申请里纯自增ID既不安全也容易被枚举。我用的方案是时间戳加随机数的组合import time import random def generate_order_no(): ts time.strftime(%Y%m%d%H%M%S) rand f{random.randint(1000, 9999)} return f{ts}{rand}字段定义里给order_no加了uniqueTrue生成后入库前再捕获一次IntegrityError做重试双保险。实际项目中这个方案完全够用不需要引入雪花算法之类的重型方案。2.3 状态流转只有三种合法路径订单状态不能想改就改必须限制合法流转路径。我画了一张流转图自己写代码时反复对照待支付 - 已支付正常支付成功待支付 - 已关闭超时未支付或用户主动取消已支付 - 退款中 - 已退款售后处理任何其他跳转比如已支付再改回待支付已关闭又改成已支付都应该在业务层直接拒绝。实现方式不复杂写一个change_status方法里面判断当前状态和目标状态是否在允许的映射里不在就抛异常。这个方法在支付回调和后台操作里统一调用避免业务散落在各个视图函数里造成状态失控。3. 支付宝接入沙箱环境是调试神器先跑通再谈证书支付宝的接入难度在两家里算低的文档清晰、SDK完善而且有沙箱环境可以反复测试。我的建议是毕设阶段全部用沙箱完成把支付链路跑通后再决定要不要上真实商户号。3.1 开放平台配置和密钥准备去支付宝开放平台创建应用开通电脑网站支付产品能力。毕设阶段用沙箱环境就够了沙箱的配置入口在开放平台的开发服务-沙箱页面系统会给你一套专用的APPID、支付宝网关地址和两个测试账号。重点说密钥。支付宝的签名方式有 RSA2SHA256withRSA推荐直接用它。需要生成一对应用私钥和公钥然后把应用公钥上传到支付宝平台换回一个支付宝公钥。这里要特别注意验签用的是支付宝公钥签名用的是应用私钥两者不能搞混。我第一次联调时签名一直报错查了半天发现是把支付宝公钥填到了应用私钥的位置上。平时常说的私钥签名、公钥验签在支付宝这个场景就是你拿应用私钥对请求参数签名支付宝拿你的应用公钥验签支付宝返回的通知它用支付宝私钥签名你拿支付宝公钥验签。3.2 用SDK构造支付请求支付宝官方提供了python-alipay-sdk这个第三方SDK虽然不是支付宝官方发布的但社区使用非常广泛毕设项目直接用它就够了。安装后按官方示例初始化客户端from alipay import AliPay, IS_ALIPAY alipay AliPay( appid你的沙箱APPID, app_notify_urlhttps://你的域名/api/payments/alipay/notify/, app_private_key_stringopen(keys/app_private_key.pem).read(), alipay_public_key_stringopen(keys/alipay_public_key.pem).read(), sign_typeRSA2, is_alipayIS_ALIPAY, # 沙箱环境传这个 )构造下单页面时直接调用SDK的api_alipay_trade_page_pay方法生成一个跳转URL然后让用户浏览器重定向过去def create_alipay_order(request, order_id): order get_object_or_404(Order, idorder_id, userrequest.user) order.order_no generate_order_no() order.save() pay_url alipay.api_alipay_trade_page_pay( out_trade_noorder.order_no, total_amountstr(order.total_amount), subject商城订单-{}.format(order.order_no), return_urlhttps://你的域名/orders/return/, ) return redirect(pay_url)SDK会帮你把参数排序、拼接、签名这些脏活全部做完返回的pay_url就是支付宝收银台的完整地址。注意total_amount必须传字符串不要传浮点数否则金额精度会出问题。我在测试时不小心传过Decimal对象直接报参数格式错误。3.3 同步跳转和异步通知return是展示notify才是真相支付宝有两条结果返回通道用户在收银台付完钱浏览器会跳回return_url这个叫同步通知同时支付宝服务器会向app_notify_url发一个POST请求这个叫异步通知。毕设阶段最容易被问到的点就在这里同步跳转不能作为支付成功的依据真正的入账依据必须是异步通知。原因是用户完全可能在跳转前关掉浏览器或者网络抖动导致同步跳转失败但钱已经付了。只有异步通知是支付宝服务器主动发到你的服务器上的可靠性完全不一样。同步跳转的视图里只做一件事展示支付中请稍候的页面然后让前端轮询订单状态接口看看订单有没有变成已支付。异步通知的视图才是真正干活的import json from django.views.decorators.csrf import csrf_exempt from django.http import JsonResponse csrf_exempt def alipay_notify(request): data request.POST.dict() success alipay.verify(data, data.get(sign)) if not success: return JsonResponse({code: fail}) out_trade_no data.get(out_trade_no) trade_status data.get(trade_status) if trade_status TRADE_SUCCESS: order Order.objects.select_for_update().get(order_noout_trade_no) if order.status Order.Status.PENDING: order.status Order.Status.PAID order.paid_at timezone.now() order.save() Payment.objects.create(...) return JsonResponse({code: success})这里有两个细节必须交代清楚。第一个是csrf_exempt因为支付宝服务器发来的POST没有Django的CSRF Token必须免除否则回调直接被403挡掉。第二个是返回内容支付宝要求你返回success这个纯文本才认为你处理成功了如果你返回其他内容支付宝会按失败处理并在几小时内持续重发通知。返回JsonResponse虽然你自己看着方便但支付宝就会一直重试导致订单被重复处理。所以一定要return HttpResponse(success)。4. 微信支付接入Native扫码模式的完整链路微信支付的接入难度比支付宝高一个档次主要是因为它没有沙箱环境必须用真实的商户号调试而且APIv3的证书体系、平台证书更新、回调解密这几件事都容易踩坑。毕设评审时老师通常对微信支付这部分兴趣最大因为做出来的人比例不高。4.1 商户号与APIv3配置微信支付需要先有一个已认证的小程序或公众号然后去微信商户平台申请商户号。整个申请流程在真实项目中可能要几天但学生毕设也可以直接使用测试商户号微信提供了小微商户测试入口具体入口在微信商户平台的开发者文档里有指引。APIv3的核心认证方式是商户API私钥 微信支付平台证书 APIv3密钥三件套。商户API私钥是你在商户平台自己生成的平台证书可以在商户平台下载APIv3密钥是一个32字节的字符串在商户平台设置。这三样东西分别承担签名请求、验证微信返回、解密回调内容。4.2 SDK选型和统一下单微信官方的Python SDK更新比较慢社区里用得多的是wechatpayv3这个包。它支持使用商户私钥自动签名请求也封装了回调验签和解密。安装后配置客户端from wechatpayv3 import WeChatPay wxpay WeChatPay( mchid你的商户号, private_keyopen(keys/merchant_private_key.pem).read(), cert_serial_no商户API证书序列号, apiv3_keyAPIv3密钥 )创建Native订单的接口调用如下def create_wechat_order(request, order_id): order get_object_or_404(Order, idorder_id, userrequest.user) order_no generate_order_no() order.save() result wxpay.pay( description商城订单-{}.format(order_no), out_trade_noorder_no, amount{total: int(order.total_amount * 100)}, notify_urlhttps://你的域名/api/payments/wechat/notify/, ) code_url result.get(code_url)这里有一个毕设新手必踩的坑微信支付的金额单位是分必须传整数支付宝传的是元字符串。也就是说订单金额是129.99元微信要传12999支付宝要传129.99。我见过不止一个同学因为忘了乘100结果测试时支付金额变成1.29元。在真实企业项目里这个问题会导致资金损失在毕设里至少会被当场问住。code_url是一个weixin://wxpay/bizpayurl?prxxx的链接把它生成二维码展示给用户用户用微信扫一扫就能弹出支付页面。生成二维码用Python的qrcode库输出成base64编码给前端import qrcode import qrcode.image.base from io import BytesIO import base64 img qrcode.make(code_url) buf BytesIO() img.save(buf, formatPNG) qr_base64 base64.b64encode(buf.getvalue()).decode()4.3 微信回调的验签与解密微信的异步通知比支付宝复杂很多。支付宝的通知是普通表单参数直接POST过来微信的通知是一个加密的JSON结构里面resource字段的密文需要用APIv3密钥解密后才能拿到真正的交易数据。wechatpayv3这个包封装了decrypt_callback方法可以自动完成验签解密。使用时要先调用callback解析请求头里的微信签名信息然后传入请求体import json from django.views.decorators.csrf import csrf_exempt from django.http import JsonResponse, HttpResponse csrf_exempt def wechat_notify(request): body json.loads(request.body) try: result wxpay.callback(headersrequest.headers, bodybody) except Exception: return JsonResponse({code: FAIL}, status500) if result[trade_state] SUCCESS: out_trade_no result[out_trade_no] transaction_id result[transaction_id] # 更新订单状态处理逻辑与支付宝一致 ... return JsonResponse({code: SUCCESS})微信平台的Wechatpay-Signature请求头使用的是平台证书做验签wechatpayv3会自动从微信服务器下载最新平台证书。如果报证书过期或找不到证书多半是平台证书自动更新逻辑没配好可以检查一下定时刷新证书的任务是否在执行。另外微信同样要求收到通知后返回{code: SUCCESS}如果返回其他内容微信也会按失败重试。和支付宝不同的是我们需要返回SUCCESS而不是success。5. 回调处理整个支付系统最容易翻车的环节如果说两家支付平台的接口接入是照文档就能做那回调处理就是真正考验设计水平的地方。这一章所有内容基本是我在项目里实际踩过坑之后总结出来的建议提前消化不要等联调的时候再受苦。5.1 幂等性同一个通知绝不能把订单改两次支付宝和微信的重试机制决定了回调可能到达多次。支付宝对未正确响应的通知会在24小时内重发8次微信的规则也类似。即便你的业务逻辑看起来没问题也应该假设同一个成功通知至少会被处理两次。我把订单状态更新放在了select_for_update()的事务里并在更新前判断order.status是不是pending。也就是说只有待支付订单可以被置为已支付其他状态直接跳过。这样即使两条回调几乎同时到达事务锁会保证后到的进程看到的状态已经是paid从而放弃重复更新。from django.db import transaction with transaction.atomic(): order Order.objects.select_for_update().get(order_noout_trade_no) if order.status Order.Status.PENDING: order.status Order.Status.PAID order.paid_at timezone.now() order.save(update_fields[status, paid_at])5.2 回调验签失败的第一排查点公钥和私钥混用回调验签失败是高频问题我排查过的案例里九成都是密钥配置错误。最常见的三种情况支付宝签名时用了应用私钥验签时却传了同一个私钥应该换成支付宝公钥。微信平台证书类型搞错应该用wechatpay_platform_cert.pem而不是商户证书。回调数据在传输中被存储或打印时编码变了导致验签用的原始报文和收到的报文不一致。调试技巧支付宝SDK的verify方法只返回布尔值失败时不告诉你为什么。我的做法是把回调参数按字典打印出来比对文档重点看sign字段是否存在、charset是否utf-8、sign_type是否RSA2。微信那边wechatpayv3的异常信息会稍微详细一些优先看WechatPayException里的err_code。5.3 支付成功后的业务联动不只是改个状态支付完成后通常要做三件事改订单状态、扣减库存、给用户发通知。毕设一般不需要太复杂但扣减库存是一个容易忽略的点。正确顺序应该是先扣库存再改订单状态放在同一个事务里。否则用户支付成功却发现商品库存不足就会出现订单已支付但无法发货的数据不一致。这里我用的是乐观锁方案更新库存时带上stock 0的过滤条件updated Product.objects.filter(idproduct_id, stock__gtenum).update(stockF(stock) - num) if not updated: raise ValidationError(库存不足)5.4 超时关单待支付订单不能一直挂着支付宝的未支付订单默认在一定时间后自动失效但你的本地订单状态也需要同步处理。我的做法是Django后台写了一个自定义命令close_expired_orders每分钟跑一次把创建时间超过30分钟且仍为pending的订单置为closed。同时调用支付宝的alipay.trade.close接口在渠道侧主动关单避免用户扫码时发现订单已经过期。# orders/management/commands/close_expired_orders.py from django.core.management.base import BaseCommand from django.utils import timezone from datetime import timedelta from orders.models import Order class Command(BaseCommand): def handle(self, *args, **options): deadline timezone.now() - timedelta(minutes30) expired Order.objects.filter(statusOrder.Status.PENDING, created_at__ltdeadline) count expired.update(statusOrder.Status.CLOSED) print(f已关闭 {count} 个超时订单)定时任务在Windows开发机上用python manage.py close_expired_orders手动执行在Linux服务器上配crontab即可。6. 联调测试、演示准备和答辩高频问题写完代码只是完成了大概一半工作量接下来是漫长的联调和测试阶段。这部分做好答辩基本就稳了。6.1 完整的测试路线图我在项目里整理了一套可复现的测试清单每改一次代码就按这个过一遍场景操作预期结果支付宝支付成功沙箱收银台登录买家账号支付订单变已支付页面跳转成功提示支付宝支付取消在沙箱收银台直接关闭页面订单保持待支付可重新发起微信扫码支付成功真机微信扫Native二维码并付款订单变已支付二维码页面刷新状态回调重复通知用Postman手动重发支付宝通知报文订单状态保持已支付不产生重复操作超时未支付修改数据库订单创建时间为1小时前运行关单命令订单变已关闭发起支付被拒绝金额校验构造一个金额和订单不一致的回调验签失败或业务校验拦截注意支付宝沙箱有自带的模拟器工具可以模拟退款、账单下载这些能力对毕设演示很有用。沙箱买家和卖家账号在开放平台沙箱页面直接查看登录密码也可以通过短信重置。6.2 演示环境准备不要现场翻车答辩演示最容易翻车的三个地方我都遇到过第一支付宝沙箱和微信扫码在同一个演示环境里没法同时完美展示因为微信Native扫码需要真机如果教室网络不稳二维码页面半天刷不出来。我的做法是准备两条录制好的演示视频作为后备同时在演示时先用支付宝沙箱走一遍全流程再用微信扫码展示一次。第二回调地址必须是外网能访问的地址。毕设期间我用的是内网穿透工具把本地的Django服务映射到公网这样支付宝和微信的回调才能打到本地。这里强调一句不要在宿舍局域网里直接配回调地址回调根本进不来。如果不想用内网穿透就租一台最低配的云服务器部署测试。第三数据库里准备好测试数据不要现场注册账号、现场下单。把商品、库存、用户全部提前造好演示时只走支付链路省去无关等待。6.3 答辩时老师爱问的问题清单根据我自己的答辩经历和帮同学模拟答辩的经验以下问题出现频率极高提前准备为什么订单号和支付记录要分两张表答订单可能多次发起支付支付记录是流水订单是当前状态。同步通知和异步通知的区别答同步通知是浏览器跳转可能丢失异步通知是服务器对服务器必须作为入账依据。回调重复通知怎么处理答事务锁加状态判断保证幂等。微信和支付宝的金额单位有什么不同答支付宝元字符串微信分整数。验签的原理是什么答私钥签名公钥验签双向验证身份和数据完整性。如何保证订单在支付成功后库存扣减不超卖答乐观锁或事务加锁。这些问题基本都是围绕支付安全、数据一致性、幂等性展开的。只要项目是自己写的把回调处理逻辑讲清楚老师基本不会为难。7. 个人体会做完这个项目我踩过最深的几个坑分享几个印象深刻的教训希望能帮你少走弯路。第一个是关于调试日志的。支付回调这种外部系统触发的请求出了问题最痛苦的就是不知道它到底有没有来过。我前期在本地调试时每次回调都心里没底后来在回调视图里加了一段中间件日志把请求头、请求体、验签结果全部记录到日志文件。不需要什么高级日志系统logging模块就够。这一招帮我解决了至少三次疑难问题强烈建议你从一开始就加上。第二个是关于虚拟环境。Django项目最怕环境不一致本地跑得好好的云服务器上一跑报错。我在requirements.txt里固化了所有依赖版本并且把支付宝、微信支付两个SDK的版本也锁死。尤其wechatpayv3这个包升级比较频繁接口签名方式会有变化锁版本能避免很多诡异问题。第三个是关于数据安全。毕设项目虽然是学习用途但密钥文件绝对不要提交到Git仓库。我在.gitignore里把keys/目录和.env文件全部忽略掉密钥通过环境变量加载。答辩演示时也注意不要把APIv3密钥明文贴到PPT里有同学被老师现场指出这个隐患场面比较尴尬。第四个是关于金额计算的精度。整个项目里所有金额字段都用DecimalField绝不用FloatField。Python的浮点数在涉及分和元的转换时会出现类似0.1 0.2 0.30000000000000004的问题一旦金额算错支付对不上账排查起来极其痛苦。最后一个建议哪怕不打算走开发方向也值得把支付回调这两套逻辑吃透。它是后端开发里外部接口对接这个能力的最典型代表其他凡是涉及第三方开放平台短信、对象存储、开放登录的项目核心思路都是同一套构造请求、签名、发起调用、处理异步回调、验签、保证幂等。做完这个毕设你等于用最少的代码量把这条链路完整走了一遍后面找实习或者工作时遇到类似的对接需求基本都能直接上手。本文还有配套的精品资源点击获取 Django支付系统实战：支付宝微信支付接入与回调处理全解析
简介在电商后端开发中支付系统是连接用户、订单与资金的桥梁也是考验开发者对业务流程和数据一致性理解深度的典型场景。本文基于Django框架从订单状态机的数据建模出发详解支付宝与微信支付两大主流渠道的接入流程重点剖析异步回调验签、幂等控制、超时关单等生产级难题。通过沙箱环境调试、回调联调和内网穿透部署完整演示从下单到支付成功的全链路实现。文章还梳理了答辩高频问题与常见踩坑记录帮助开发者理解支付系统中“私钥签名公钥验签”的安全机制以及如何保证订单状态在并发场景下不出现混乱。无论你是准备毕业设计还是构建电商项目都能从中获得一套可落地的支付系统集成方案。1. 为什么毕设选支付系统一次把Django核心能力打满每年毕业季都能看到大量基于Django的XXX系统这类题目但订单支付系统始终是其中比较特殊的一个。原因很简单其他管理系统做完通常只有一个后台和几张CRUD页面而支付系统天然包含订单状态机、第三方接口对接、异步回调、签名验证、并发控制这些真刀真枪的生产级问题。换句话说做完这个项目你几乎把Django后端开发里最值钱的那部分技能都练了一遍。这个项目的标准组合是Django 支付宝 微信支付核心业务就一句用户在商城下单跳转到支付宝或微信完成付款支付成功后系统自动把订单状态改成已支付。听起来简单真正动手之后才会发现验收一个支付系统老师不会只问页面长什么样而是会追问异步通知怎么保证不重复处理回调频率高怎么办订单状态什么时候改退款怎么处理。这篇博文就把我从选题到答辩的全过程拆开讲包括数据库设计、两家支付渠道的接入步骤、回调处理的完整思路以及那些不写到文档里的坑。无论你是正在做这个毕设还是打算用Django做电商类项目这篇都能当一份实操参考来用。先给一个总览整个项目大概分四块Django商城基础商品、购物车、订单、支付宝网页支付、微信Native扫码支付、支付回调与订单状态流转。难度排序大概是回调处理 微信支付接入 支付宝接入 基础商城。后面我按这个顺序展开。2. 订单与支付数据模型状态机比CRUD重要得多支付系统跟普通管理系统的本质区别在于订单不是一个静态的表而是一个会随着外部事件不断流转的状态机。这个设计一旦想明白后面写代码就顺了。2.1 订单表和支付记录表的关系先说订单表。核心字段除了用户、商品、金额这些基本信息务必单独存一个status字段取值范围建议直接定义成枚举常量不要散落在代码里# orders/models.py from django.db import models from django.conf import settings class Order(models.Model): class Status(models.TextChoices): PENDING pending, 待支付 PAID paid, 已支付 CLOSED closed, 已关闭 REFUNDING refunding, 退款中 REFUNDED refunded, 已退款 order_no models.CharField(max_length64, uniqueTrue, verbose_name订单号) user models.ForeignKey(settings.AUTH_USER_MODEL, on_deletemodels.PROTECT) total_amount models.DecimalField(max_digits10, decimal_places2, verbose_name订单金额) status models.CharField(max_length16, choicesStatus.choices, defaultStatus.PENDING) created_at models.DateTimeField(auto_now_addTrue) paid_at models.DateTimeField(nullTrue, blankTrue)再单独建一张支付记录表class Payment(models.Model): class Channel(models.TextChoices): ALIPAY alipay, 支付宝 WECHAT wechat, 微信支付 order models.ForeignKey(Order, on_deletemodels.PROTECT, related_namepayments) channel models.CharField(max_length16, choicesChannel.choices) transaction_id models.CharField(max_length64, db_indexTrue, verbose_name渠道交易号) raw_notify models.JSONField(verbose_name回调原始报文) status models.CharField(max_length16, defaultnotified) created_at models.DateTimeField(auto_now_addTrue)为什么订单和支付要分两张表因为一个订单可能多次发起支付比如用户扫码后一直没付重试了几次如果只在订单表里记一个支付单号数据就乱了。支付记录表每发起一次支付就插入一条回调来了按transaction_id去匹配记录既方便对账也方便排查用户到底付到哪个单子上了这种问题。2.2 订单号生成规则别用自增ID订单号这里有个初学者很容易忽略的坑绝对不能直接用数据库自增主键当订单号发给支付平台。原因是支付平台的流水号规则要求你这边尽量做到全局唯一、可追溯而且订单号会出现在支付回调、对账单、用户退款申请里纯自增ID既不安全也容易被枚举。我用的方案是时间戳加随机数的组合import time import random def generate_order_no(): ts time.strftime(%Y%m%d%H%M%S) rand f{random.randint(1000, 9999)} return f{ts}{rand}字段定义里给order_no加了uniqueTrue生成后入库前再捕获一次IntegrityError做重试双保险。实际项目中这个方案完全够用不需要引入雪花算法之类的重型方案。2.3 状态流转只有三种合法路径订单状态不能想改就改必须限制合法流转路径。我画了一张流转图自己写代码时反复对照待支付 - 已支付正常支付成功待支付 - 已关闭超时未支付或用户主动取消已支付 - 退款中 - 已退款售后处理任何其他跳转比如已支付再改回待支付已关闭又改成已支付都应该在业务层直接拒绝。实现方式不复杂写一个change_status方法里面判断当前状态和目标状态是否在允许的映射里不在就抛异常。这个方法在支付回调和后台操作里统一调用避免业务散落在各个视图函数里造成状态失控。3. 支付宝接入沙箱环境是调试神器先跑通再谈证书支付宝的接入难度在两家里算低的文档清晰、SDK完善而且有沙箱环境可以反复测试。我的建议是毕设阶段全部用沙箱完成把支付链路跑通后再决定要不要上真实商户号。3.1 开放平台配置和密钥准备去支付宝开放平台创建应用开通电脑网站支付产品能力。毕设阶段用沙箱环境就够了沙箱的配置入口在开放平台的开发服务-沙箱页面系统会给你一套专用的APPID、支付宝网关地址和两个测试账号。重点说密钥。支付宝的签名方式有 RSA2SHA256withRSA推荐直接用它。需要生成一对应用私钥和公钥然后把应用公钥上传到支付宝平台换回一个支付宝公钥。这里要特别注意验签用的是支付宝公钥签名用的是应用私钥两者不能搞混。我第一次联调时签名一直报错查了半天发现是把支付宝公钥填到了应用私钥的位置上。平时常说的私钥签名、公钥验签在支付宝这个场景就是你拿应用私钥对请求参数签名支付宝拿你的应用公钥验签支付宝返回的通知它用支付宝私钥签名你拿支付宝公钥验签。3.2 用SDK构造支付请求支付宝官方提供了python-alipay-sdk这个第三方SDK虽然不是支付宝官方发布的但社区使用非常广泛毕设项目直接用它就够了。安装后按官方示例初始化客户端from alipay import AliPay, IS_ALIPAY alipay AliPay( appid你的沙箱APPID, app_notify_urlhttps://你的域名/api/payments/alipay/notify/, app_private_key_stringopen(keys/app_private_key.pem).read(), alipay_public_key_stringopen(keys/alipay_public_key.pem).read(), sign_typeRSA2, is_alipayIS_ALIPAY, # 沙箱环境传这个 )构造下单页面时直接调用SDK的api_alipay_trade_page_pay方法生成一个跳转URL然后让用户浏览器重定向过去def create_alipay_order(request, order_id): order get_object_or_404(Order, idorder_id, userrequest.user) order.order_no generate_order_no() order.save() pay_url alipay.api_alipay_trade_page_pay( out_trade_noorder.order_no, total_amountstr(order.total_amount), subject商城订单-{}.format(order.order_no), return_urlhttps://你的域名/orders/return/, ) return redirect(pay_url)SDK会帮你把参数排序、拼接、签名这些脏活全部做完返回的pay_url就是支付宝收银台的完整地址。注意total_amount必须传字符串不要传浮点数否则金额精度会出问题。我在测试时不小心传过Decimal对象直接报参数格式错误。3.3 同步跳转和异步通知return是展示notify才是真相支付宝有两条结果返回通道用户在收银台付完钱浏览器会跳回return_url这个叫同步通知同时支付宝服务器会向app_notify_url发一个POST请求这个叫异步通知。毕设阶段最容易被问到的点就在这里同步跳转不能作为支付成功的依据真正的入账依据必须是异步通知。原因是用户完全可能在跳转前关掉浏览器或者网络抖动导致同步跳转失败但钱已经付了。只有异步通知是支付宝服务器主动发到你的服务器上的可靠性完全不一样。同步跳转的视图里只做一件事展示支付中请稍候的页面然后让前端轮询订单状态接口看看订单有没有变成已支付。异步通知的视图才是真正干活的import json from django.views.decorators.csrf import csrf_exempt from django.http import JsonResponse csrf_exempt def alipay_notify(request): data request.POST.dict() success alipay.verify(data, data.get(sign)) if not success: return JsonResponse({code: fail}) out_trade_no data.get(out_trade_no) trade_status data.get(trade_status) if trade_status TRADE_SUCCESS: order Order.objects.select_for_update().get(order_noout_trade_no) if order.status Order.Status.PENDING: order.status Order.Status.PAID order.paid_at timezone.now() order.save() Payment.objects.create(...) return JsonResponse({code: success})这里有两个细节必须交代清楚。第一个是csrf_exempt因为支付宝服务器发来的POST没有Django的CSRF Token必须免除否则回调直接被403挡掉。第二个是返回内容支付宝要求你返回success这个纯文本才认为你处理成功了如果你返回其他内容支付宝会按失败处理并在几小时内持续重发通知。返回JsonResponse虽然你自己看着方便但支付宝就会一直重试导致订单被重复处理。所以一定要return HttpResponse(success)。4. 微信支付接入Native扫码模式的完整链路微信支付的接入难度比支付宝高一个档次主要是因为它没有沙箱环境必须用真实的商户号调试而且APIv3的证书体系、平台证书更新、回调解密这几件事都容易踩坑。毕设评审时老师通常对微信支付这部分兴趣最大因为做出来的人比例不高。4.1 商户号与APIv3配置微信支付需要先有一个已认证的小程序或公众号然后去微信商户平台申请商户号。整个申请流程在真实项目中可能要几天但学生毕设也可以直接使用测试商户号微信提供了小微商户测试入口具体入口在微信商户平台的开发者文档里有指引。APIv3的核心认证方式是商户API私钥 微信支付平台证书 APIv3密钥三件套。商户API私钥是你在商户平台自己生成的平台证书可以在商户平台下载APIv3密钥是一个32字节的字符串在商户平台设置。这三样东西分别承担签名请求、验证微信返回、解密回调内容。4.2 SDK选型和统一下单微信官方的Python SDK更新比较慢社区里用得多的是wechatpayv3这个包。它支持使用商户私钥自动签名请求也封装了回调验签和解密。安装后配置客户端from wechatpayv3 import WeChatPay wxpay WeChatPay( mchid你的商户号, private_keyopen(keys/merchant_private_key.pem).read(), cert_serial_no商户API证书序列号, apiv3_keyAPIv3密钥 )创建Native订单的接口调用如下def create_wechat_order(request, order_id): order get_object_or_404(Order, idorder_id, userrequest.user) order_no generate_order_no() order.save() result wxpay.pay( description商城订单-{}.format(order_no), out_trade_noorder_no, amount{total: int(order.total_amount * 100)}, notify_urlhttps://你的域名/api/payments/wechat/notify/, ) code_url result.get(code_url)这里有一个毕设新手必踩的坑微信支付的金额单位是分必须传整数支付宝传的是元字符串。也就是说订单金额是129.99元微信要传12999支付宝要传129.99。我见过不止一个同学因为忘了乘100结果测试时支付金额变成1.29元。在真实企业项目里这个问题会导致资金损失在毕设里至少会被当场问住。code_url是一个weixin://wxpay/bizpayurl?prxxx的链接把它生成二维码展示给用户用户用微信扫一扫就能弹出支付页面。生成二维码用Python的qrcode库输出成base64编码给前端import qrcode import qrcode.image.base from io import BytesIO import base64 img qrcode.make(code_url) buf BytesIO() img.save(buf, formatPNG) qr_base64 base64.b64encode(buf.getvalue()).decode()4.3 微信回调的验签与解密微信的异步通知比支付宝复杂很多。支付宝的通知是普通表单参数直接POST过来微信的通知是一个加密的JSON结构里面resource字段的密文需要用APIv3密钥解密后才能拿到真正的交易数据。wechatpayv3这个包封装了decrypt_callback方法可以自动完成验签解密。使用时要先调用callback解析请求头里的微信签名信息然后传入请求体import json from django.views.decorators.csrf import csrf_exempt from django.http import JsonResponse, HttpResponse csrf_exempt def wechat_notify(request): body json.loads(request.body) try: result wxpay.callback(headersrequest.headers, bodybody) except Exception: return JsonResponse({code: FAIL}, status500) if result[trade_state] SUCCESS: out_trade_no result[out_trade_no] transaction_id result[transaction_id] # 更新订单状态处理逻辑与支付宝一致 ... return JsonResponse({code: SUCCESS})微信平台的Wechatpay-Signature请求头使用的是平台证书做验签wechatpayv3会自动从微信服务器下载最新平台证书。如果报证书过期或找不到证书多半是平台证书自动更新逻辑没配好可以检查一下定时刷新证书的任务是否在执行。另外微信同样要求收到通知后返回{code: SUCCESS}如果返回其他内容微信也会按失败重试。和支付宝不同的是我们需要返回SUCCESS而不是success。5. 回调处理整个支付系统最容易翻车的环节如果说两家支付平台的接口接入是照文档就能做那回调处理就是真正考验设计水平的地方。这一章所有内容基本是我在项目里实际踩过坑之后总结出来的建议提前消化不要等联调的时候再受苦。5.1 幂等性同一个通知绝不能把订单改两次支付宝和微信的重试机制决定了回调可能到达多次。支付宝对未正确响应的通知会在24小时内重发8次微信的规则也类似。即便你的业务逻辑看起来没问题也应该假设同一个成功通知至少会被处理两次。我把订单状态更新放在了select_for_update()的事务里并在更新前判断order.status是不是pending。也就是说只有待支付订单可以被置为已支付其他状态直接跳过。这样即使两条回调几乎同时到达事务锁会保证后到的进程看到的状态已经是paid从而放弃重复更新。from django.db import transaction with transaction.atomic(): order Order.objects.select_for_update().get(order_noout_trade_no) if order.status Order.Status.PENDING: order.status Order.Status.PAID order.paid_at timezone.now() order.save(update_fields[status, paid_at])5.2 回调验签失败的第一排查点公钥和私钥混用回调验签失败是高频问题我排查过的案例里九成都是密钥配置错误。最常见的三种情况支付宝签名时用了应用私钥验签时却传了同一个私钥应该换成支付宝公钥。微信平台证书类型搞错应该用wechatpay_platform_cert.pem而不是商户证书。回调数据在传输中被存储或打印时编码变了导致验签用的原始报文和收到的报文不一致。调试技巧支付宝SDK的verify方法只返回布尔值失败时不告诉你为什么。我的做法是把回调参数按字典打印出来比对文档重点看sign字段是否存在、charset是否utf-8、sign_type是否RSA2。微信那边wechatpayv3的异常信息会稍微详细一些优先看WechatPayException里的err_code。5.3 支付成功后的业务联动不只是改个状态支付完成后通常要做三件事改订单状态、扣减库存、给用户发通知。毕设一般不需要太复杂但扣减库存是一个容易忽略的点。正确顺序应该是先扣库存再改订单状态放在同一个事务里。否则用户支付成功却发现商品库存不足就会出现订单已支付但无法发货的数据不一致。这里我用的是乐观锁方案更新库存时带上stock 0的过滤条件updated Product.objects.filter(idproduct_id, stock__gtenum).update(stockF(stock) - num) if not updated: raise ValidationError(库存不足)5.4 超时关单待支付订单不能一直挂着支付宝的未支付订单默认在一定时间后自动失效但你的本地订单状态也需要同步处理。我的做法是Django后台写了一个自定义命令close_expired_orders每分钟跑一次把创建时间超过30分钟且仍为pending的订单置为closed。同时调用支付宝的alipay.trade.close接口在渠道侧主动关单避免用户扫码时发现订单已经过期。# orders/management/commands/close_expired_orders.py from django.core.management.base import BaseCommand from django.utils import timezone from datetime import timedelta from orders.models import Order class Command(BaseCommand): def handle(self, *args, **options): deadline timezone.now() - timedelta(minutes30) expired Order.objects.filter(statusOrder.Status.PENDING, created_at__ltdeadline) count expired.update(statusOrder.Status.CLOSED) print(f已关闭 {count} 个超时订单)定时任务在Windows开发机上用python manage.py close_expired_orders手动执行在Linux服务器上配crontab即可。6. 联调测试、演示准备和答辩高频问题写完代码只是完成了大概一半工作量接下来是漫长的联调和测试阶段。这部分做好答辩基本就稳了。6.1 完整的测试路线图我在项目里整理了一套可复现的测试清单每改一次代码就按这个过一遍场景操作预期结果支付宝支付成功沙箱收银台登录买家账号支付订单变已支付页面跳转成功提示支付宝支付取消在沙箱收银台直接关闭页面订单保持待支付可重新发起微信扫码支付成功真机微信扫Native二维码并付款订单变已支付二维码页面刷新状态回调重复通知用Postman手动重发支付宝通知报文订单状态保持已支付不产生重复操作超时未支付修改数据库订单创建时间为1小时前运行关单命令订单变已关闭发起支付被拒绝金额校验构造一个金额和订单不一致的回调验签失败或业务校验拦截注意支付宝沙箱有自带的模拟器工具可以模拟退款、账单下载这些能力对毕设演示很有用。沙箱买家和卖家账号在开放平台沙箱页面直接查看登录密码也可以通过短信重置。6.2 演示环境准备不要现场翻车答辩演示最容易翻车的三个地方我都遇到过第一支付宝沙箱和微信扫码在同一个演示环境里没法同时完美展示因为微信Native扫码需要真机如果教室网络不稳二维码页面半天刷不出来。我的做法是准备两条录制好的演示视频作为后备同时在演示时先用支付宝沙箱走一遍全流程再用微信扫码展示一次。第二回调地址必须是外网能访问的地址。毕设期间我用的是内网穿透工具把本地的Django服务映射到公网这样支付宝和微信的回调才能打到本地。这里强调一句不要在宿舍局域网里直接配回调地址回调根本进不来。如果不想用内网穿透就租一台最低配的云服务器部署测试。第三数据库里准备好测试数据不要现场注册账号、现场下单。把商品、库存、用户全部提前造好演示时只走支付链路省去无关等待。6.3 答辩时老师爱问的问题清单根据我自己的答辩经历和帮同学模拟答辩的经验以下问题出现频率极高提前准备为什么订单号和支付记录要分两张表答订单可能多次发起支付支付记录是流水订单是当前状态。同步通知和异步通知的区别答同步通知是浏览器跳转可能丢失异步通知是服务器对服务器必须作为入账依据。回调重复通知怎么处理答事务锁加状态判断保证幂等。微信和支付宝的金额单位有什么不同答支付宝元字符串微信分整数。验签的原理是什么答私钥签名公钥验签双向验证身份和数据完整性。如何保证订单在支付成功后库存扣减不超卖答乐观锁或事务加锁。这些问题基本都是围绕支付安全、数据一致性、幂等性展开的。只要项目是自己写的把回调处理逻辑讲清楚老师基本不会为难。7. 个人体会做完这个项目我踩过最深的几个坑分享几个印象深刻的教训希望能帮你少走弯路。第一个是关于调试日志的。支付回调这种外部系统触发的请求出了问题最痛苦的就是不知道它到底有没有来过。我前期在本地调试时每次回调都心里没底后来在回调视图里加了一段中间件日志把请求头、请求体、验签结果全部记录到日志文件。不需要什么高级日志系统logging模块就够。这一招帮我解决了至少三次疑难问题强烈建议你从一开始就加上。第二个是关于虚拟环境。Django项目最怕环境不一致本地跑得好好的云服务器上一跑报错。我在requirements.txt里固化了所有依赖版本并且把支付宝、微信支付两个SDK的版本也锁死。尤其wechatpayv3这个包升级比较频繁接口签名方式会有变化锁版本能避免很多诡异问题。第三个是关于数据安全。毕设项目虽然是学习用途但密钥文件绝对不要提交到Git仓库。我在.gitignore里把keys/目录和.env文件全部忽略掉密钥通过环境变量加载。答辩演示时也注意不要把APIv3密钥明文贴到PPT里有同学被老师现场指出这个隐患场面比较尴尬。第四个是关于金额计算的精度。整个项目里所有金额字段都用DecimalField绝不用FloatField。Python的浮点数在涉及分和元的转换时会出现类似0.1 0.2 0.30000000000000004的问题一旦金额算错支付对不上账排查起来极其痛苦。最后一个建议哪怕不打算走开发方向也值得把支付回调这两套逻辑吃透。它是后端开发里外部接口对接这个能力的最典型代表其他凡是涉及第三方开放平台短信、对象存储、开放登录的项目核心思路都是同一套构造请求、签名、发起调用、处理异步回调、验签、保证幂等。做完这个毕设你等于用最少的代码量把这条链路完整走了一遍后面找实习或者工作时遇到类似的对接需求基本都能直接上手。本文还有配套的精品资源点击获取