CodeIgniter支付接口接入教程

本文深入讲解了在CodeIgniter框架中安全、稳定对接微信与支付宝等主流支付接口的核心实践，重点剖析了支付请求发起时避免硬编码curl、规范参数组装与签名的正确方式，以及异步回调（notify）中必须严格执行的验签、查单、幂等状态更新三步铁律；同时强调同步回调（return）仅用于前端展示、绝不执行业务变更，并指出调试阶段易被忽视的日志完整性与重发通知实测关键点，为开发者提供了一套可落地、防坑、高健壮性的支付集成方案。

CodeIgniter 框架本身不内置支付 SDK，但通过合理封装 HTTP 请求、签名验签、异步通知校验三块逻辑，就能稳定对接支付宝、微信等主流支付网关。关键不是“能不能”，而是回调地址是否可访问、验签逻辑是否严格、状态更新是否幂等。

支付请求发起：别直接用 curl_exec 硬写

手动拼接参数 + curl 容易漏掉签名字段、时间戳、字符编码（如微信要求 UTF-8）、或忽略 notify_url / return_url 的 URL 编码。推荐做法是：

• 将支付平台文档里的「必填参数」和「签名规则」拆成独立方法，比如 build_alipay_sign_data() 和 sign_with_rsa($data, $private_key)
• 使用 prep_url() 处理网关地址，避免协议缺失导致 302 跳转失败
• POST 请求体必须用 http_build_query($params, '', '&')，不能直接传数组给 CURLOPT_POSTFIELDS，否则微信会返回 INVALID_ARGUMENT
• 超时设为 15 秒以内（支付宝建议 10s），防止用户长时间卡在支付页

异步回调（notify）必须做三件事：验签、查单、更新状态

支付平台的 notify_url 是服务器对服务器调用，没有 Session、无 Referer、可能重发多次。常见错误是直接更新数据库后就 echo 'success'，结果被重放攻击或重复通知搞崩订单状态。

• 第一步：用平台公钥验证 sign 和 sign_type，微信用 openssl_verify()，支付宝用 openssl_verify() 或官方 SDK 的 AlipaySignature::verify()
• 第二步：用回调里的 out_trade_no 查本地订单，确认「未支付」且「存在」，跳过已处理过的通知（加数据库 is_notified 字段或 Redis 锁）
• 第三步：仅当验签通过 + 订单合法 + 支付状态为 TRADE_SUCCESS 时，才执行金额比对、库存扣减、状态更新；完成后必须返回原始字符串 success（微信）或 success（支付宝），不能带空格、换行、HTML

同步回调（return）只做跳转，不做业务变更

return_url 是用户浏览器跳转回来的地址，不可信。它可能被用户手动刷新、F5 重发、甚至伪造参数。这里只能做「展示结果」，不能更新订单状态或发货。

• 不要在 return 方法里调用 $this->order_model->pay_success()
• 应只查一次订单，渲染「支付成功/失败」页面，提示「请以短信或站内信为准」
• 如果需要实时感知结果，前端用 AJAX 轮询 /api/order/status?sn=xxx，后端该接口查数据库最新状态
• 注意：微信 JSAPI 支付的 return_url 必须是备案域名下的路径，否则白屏

调试阶段最容易忽略的两个点

一是日志没打全：只记录「支付成功」，不记录原始回调数据、验签过程、数据库 update 影响行数；二是没模拟重发场景：微信/支付宝控制台都提供「重发通知」按钮，必须实测两次相同通知进来时，第二条是否被静默丢弃。

回调入口函数开头加一行：file_put_contents(FCPATH . 'logs/notify_raw.log', file_get_contents('php://input') . "\n---\n", FILE_APPEND);，比靠 $_POST 更可靠，因为部分平台用 raw body 发送 JSON。

本篇关于《CodeIgniter支付接口接入教程》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！