从签名到回调，
按这份文档一次接通。

你是一名资深支付接口集成工程师。请在我现有的项目中完成 DuoCai码支付接入，并以 https://pay.1kexiu.xyz/docs/api 为接口规则来源。先只读检查项目已有的订单、支付、回调、数据库和配置实现，优先复用现有结构，禁止重写无关模块、升级框架或修改第三方依赖。

【我的接入目标】
1. 接口域名：https://pay.1kexiu.xyz
2. 商户 PID：从环境变量 DUOCAI_PID 读取。
3. 支付对接密钥：从环境变量 DUOCAI_PAY_KEY 读取。
4. 需要接入的支付分类：alipay、wxpay；如果项目还需要 qqpay，再一并支持。
5. 优先使用服务端 POST /mapi.php 创建订单并获取支付地址；如果现有项目必须让浏览器直接跳转，则使用服务端生成签名后的 POST /submit.php 自动提交表单。
6. 不要要求我把真实 PID 或密钥粘贴到聊天中，不要把密钥写入前端、APP、日志、异常信息或代码仓库。

【必须严格实现的签名规则】
1. 使用 application/x-www-form-urlencoded 解析后的原始字段值。
2. 排除 sign、sign_type、a、c、m、s。
3. 排除值为 null 或空字符串的字段；数字 0 和字符串 0 必须参与签名。
4. 其余实际发送的字段按参数名升序排序。
5. 按 参数名=原始参数值 拼接，字段之间使用 & 连接。
6. 在完整参数串末尾直接追加 DUOCAI_PAY_KEY 的值，不要追加 &key=，然后计算 UTF-8 字节的 32 位小写 MD5。
7. 必须先使用原始值计算签名，再进行表单 URL 编码并发送。
8. 签名前禁止执行 htmlspecialchars、htmlentities、trim、大小写转换、金额格式重写、JSON 转义、URL 重组或二次 urlencode/urldecode。
9. notify_url 和 return_url 可以携带多个查询参数；其中的原始 & 必须参与签名，不能改成 &。
10. 请求中的 money 按实际发送的原始字符串签名；回调中的 money 按平台实际返回值验签，通常为两位小数。

【创建订单】
使用 POST https://pay.1kexiu.xyz/mapi.php，Content-Type 为 application/x-www-form-urlencoded。至少发送：
pid、type、out_trade_no、notify_url、return_url、name、money、sign、sign_type=MD5。
param、clientip、device 等可选字段只要非空并实际发送，就必须参与签名。
return_url 在当前系统中为必填字段。
out_trade_no 必须唯一，只允许字母、数字和 . _ - |。
不要把 SERVER_GENERATED_SIGN 当作真实签名，它只是文档占位符。

接口业务失败可能仍返回 HTTP 200，所以必须解析 JSON 并判断 code。code=1 才表示下单成功。成功响应可能返回 payurl，也可能返回 qrcode；代码要兼容两者，优先使用实际非空字段，并保存平台 trade_no。不要只根据 HTTP 状态码判断成功。

如果使用 /submit.php，它返回 HTML 收银台页面，不是 JSON。签名必须仍在服务端生成，浏览器只能接收已经签好的自动提交表单，不能接触支付密钥。

【异步回调】
1. notify_url 接收端同时兼容 URL 查询参数和 POST 表单；PHP 可用 array_replace($_GET, $_POST)，同名字段以 POST 为准，其他语言实现同等逻辑。
2. 使用收到的原始字段重新计算签名，并用安全比较函数核对 sign。
3. 验证 trade_status 必须等于 TRADE_SUCCESS。
4. 按 out_trade_no 查询本地订单，核对 pid、money、订单状态和平台 trade_no。
5. 使用数据库事务、行锁或唯一约束实现幂等：同一订单重复通知不能重复加款、发货或执行权益。
6. 业务处理成功后只返回纯文本 success；失败返回 fail 或非 2xx，不能误返回 success。
7. return_url 只用于浏览器展示，禁止仅凭同步跳转更新付款状态或发货。

【主动查单】
使用服务端 POST https://pay.1kexiu.xyz/api.php，表单参数使用 pid 和 key 鉴权，key 的值来自 DUOCAI_PAY_KEY，不使用下单 sign 代替 key。
单笔查单：act=order，加 out_trade_no 或 trade_no。
订单列表：act=orders，加 page 和 limit，limit 范围 1 至 50。
商户状态：act=query。
解析 JSON 并判断 code；单笔订单的 status=1 才表示支付成功。GET 查询仅为兼容旧客户端，不要在新代码中把密钥放进 URL。

【固定签名测试向量】
先为签名函数编写自动化测试，下面参数必须得到指定 MD5：
pay_key = test_pay_key_20260813
pid = M1234567890
type = alipay
out_trade_no = ORDER202608130001
notify_url = https://shop.example.com/pay/notify?channel=alipay&version=2
return_url = https://shop.example.com/pay/return?order=ORDER202608130001&source=pay
name = 测试订单
money = 1.00
expected_sign = beddd35092c3afea54c5218de0872502

测试还必须覆盖：空字符串、null、数字 0、money 分别为 1/1.0/1.00、中文商品名、空格、+、%、引号，以及 notify_url/return_url 含多个 &。同时验证签名后再做表单编码，确保实际发送字段与参与签名字段完全一致。

【实现与安全要求】
1. 先找到项目已有的订单模型、支付服务、回调路由和配置方式，做最小修改并保持现有代码风格。
2. PID 和密钥只从服务端环境变量或安全配置读取；日志不得记录密钥、完整签名原文或完整回调 Token。
3. 不关闭 TLS 证书验证，不使用浮点数直接比较金额；金额使用 decimal 或整数分，并按业务规则精确比较。
4. 请求超时或响应不确定时保留原 out_trade_no，先查单再决定是否重试，禁止生成新订单号后盲目重复下单。
5. 未经我明确确认，不进行真实付款、退款、发货或生产数据写入测试。可以先做固定向量、Mock 测试和无资金验证。
6. 如果现有项目规则与接口要求冲突，先指出具体文件和冲突原因，再给出保持兼容的最小修复，不要自行猜测。

【完成后请交付】
1. 说明修改了哪些文件、每个文件做了什么。
2. 给出需要配置的环境变量和部署步骤。
3. 给出签名、下单响应、回调幂等和主动查单的自动化测试结果。
4. 明确哪些内容已经实际验证、哪些因为没有真实付款而尚未验证。
5. 提供一个安全的联调检查清单；如果失败，输出脱敏后的参数名称、排序结果和请求编号，但绝不输出真实密钥。

现在请先检查我的项目结构和现有支付实现，然后直接完成最小范围接入。如果你不能直接读取或修改项目，就按我的技术栈输出可复制的完整文件，并明确每个文件的放置路径。