简介：这是一套于飞收卡网礼品卡与二手礼品卡回收 PHP 网站源码，定位为在线卡券回收交易平台，面向需要搭建收卡业务的站长、开发者与运营者；系统支持用户提交卡号卡密直接完成回收，对接企业闲置、员工福利、亲友相赠等场景下的礼品卡快速变现，解决大量闲置卡券浪费问题，同时提供线上回收、线下交易 API 接口，支持自定义多样化交易模式。压缩包共 2000 个文件，以 PHP 脚本、PNG 图片、HTML 页面、JS 与 CSS 样式为主，含 TXT 说明文档、SQL 数据库及配置文件，整体约 47.05MB；源码目录结构清晰，便于理解前后端页面、交易逻辑、卡密处理与接口对接模块，适合二次开发或学习 PHP 电商交易系统的实现。目前已有 978 人学习/下载，通过该源码可获得一套可直接部署的收卡网前后端代码，掌握常见电商卡种回收流程、API 集成思路及自定义交易方式，对快速启动在线回收业务或研究虚拟卡交易实现细节有较高参考价值。
1. 收卡网到底是个什么生意：这套 PHP 源码替你解决了哪一环
标题里这套「收卡网」方向的礼品卡回收 PHP 网站源码，解决的不是「做个漂亮网站」，而是把二手礼品卡回收这门生意从「微信聊天、手工记账、人工核销」变成「线上自动接单」。用户手里有闲置的京东卡、沃尔玛卡或者其他购物卡，嫌挂二手平台出手要等买家、要担保交易，就把卡号卡密填到你的回收站，系统按面值打个折扣报一个回收价；你收下卡，再通过自己的渠道去核销变现。底下的 PHP 源码，就是把「提交卡密→实时报价→审核→打款→对接转卖渠道」这条订单链全部接起来的东西。它适合谁？适合手里已经有一点回收渠道、想低成本起盘的个人或小团队。不需要上 Java 那一套重型架构，一台普通服务器配好 PHP 环境就能跑，后面每一处报价规则、打款方式、卡种分类，都是改代码就能动的东西。
2. 收卡网的业务链路与技术底子：这套 PHP 源码到底在替你管哪几步
2.1 前台那条「提交卡密→实时报价」的订单流
收卡站的前台通常比你想的还简单：首页就是一个卡密提交表单，卡种下拉、面值、卡号、卡密、收款方式，没了。这类业态的重心从来不是图文展示，表单越短，转化率越高。常见做法是连注册登录都省掉，用户直接填完提交，因为回收卡的人要的是快手速，登录流程每多一步就多流失一批单子。但省掉登录也带来了一个直接后果：你没法在用户维度做风控，只能靠 IP、卡密哈希和订单频率来兜底。
提交之后，系统要做两件事。第一件是查重，同一张卡密不能出现在两笔未完成订单里，否则你可能会被同一张卡骗两次打款。第二件是报价，用户看到的「实际到账」通常是这么算的：卡面值 × 当前折扣 - 手续费。折扣不是写死的，它存在后台一张卡种价格表里，热门卡种的折扣可能一个小时调一次。这个表单提交必须是 POST，绝不能走 GET，否则卡号和卡密会完整出现在浏览器历史、Nginx access.log 和各种中间层日志里，后面我会专门说这条坑。
2.2 后台那部「审核→核销→打款→对接渠道」的风控机器
后台是整个收卡网真正值钱的部分。常见的操作流程分成两种模式：手动审核和自动接渠道。手动审核适合单量还不大的起步阶段，用户提交卡密后，管理员在后台看到订单，把卡密复制给下游渠道去核销，渠道确认核销成功，管理员再手动点击打款。自动模式则是把卡回收渠道的接口接进来，用户提交卡密后系统直接调用渠道的核销 API，全程无人工，缺点是渠道接口的稳定性直接决定了你的订单成功率，而且一旦渠道接口超时，很容易出现「卡已经被核销、订单还停在待审核」的尴尬局面。
这里必须点破一个很多新手算不清的账：收卡网赚的从来不是什么固定的几何差价，而是「报价低一点、渠道出价高一点」之间的风险差价。用户拿 100 元京东卡换你 96 元现金，你把这张卡 98 元出给渠道，单笔毛利就 2 元。但一旦卡被渠道先行核销、被黑客窃取、或被用户一卡多投，你赔的是一整张卡的面值，做十单的利润都补不回来。所以后台真正在管的不是订单，是风险：一卡一密不能重复提交、IP 异常要自动冻结、渠道核销要留痕。
2.3 为什么 PHP + MySQL 在这个场景里反而比 Java 舒服
说句实话，这类回收系统的并发量通常不大，日订单几百单就算运营得不错了，真正的瓶颈永远是审核的人手和渠道的稳定性，而不是服务器性能。这种场景下，PHP + MySQL 反而是很舒服的组合。部署快，一套 LNMP 环境从零到跑起来用不了一小时；改起来也快，报价规则、卡种列表、打款状态都是改 PHP 数组、改两个 SQL 就能动的东西。另一个现实因素是，这类源码大多是原生 PHP 或者轻量框架写的，文件结构一眼能看穿，出问题剥开来看两小时能定位；你换一套 Java 微服务来接这业务，光环境依赖和编译打包就够折腾的。
不过选 PHP 不代表可以随便乱上版本。拿到源码第一件事是看它语法用了什么特性，如果代码里还是 mysql_connect 这类老函数，那 PHP 7 以上的环境就得开兼容层，否则后台直接白屏。我的习惯是先本地搭个环境把源码跑通，再上服务器，别一上来就改配置。
3. 把收卡源码部署到一台服务器：最小可用的 LNMP 环境与第一笔订单
3.1 准备一台服务器和最小依赖清单
不需要一上来就搞负载均衡、多机部署、读写分离，那是日单量几千以后才考虑的事。这类站点的起步配置，一台 2 核 4G 的云服务器加一块数据盘就完全够用，带宽也不需要买太大，因为页面极轻，真正的流量消耗是后台操作而不是用户提交。系统选主流 Linux 发行版即可，下面按我常用的命令环境写。
需要装的东西就六样：Linux 系统、Nginx、PHP、MySQL（或 MariaDB）、一个可选的 Redis、FTP 或 SSH 工具。Redis 在起步阶段可以不加，后面做接口限流和核销队列时再补。
| 组件 | 版本建议 | 角色 |
|---|---|---|
| Linux | 主流发行版即可 | 运行环境 |
| Nginx | 稳定版即可 | 承载 PHP 请求与伪静态 |
| PHP | 7.x（视源码语法定，老源码慎上 8.x） | 业务逻辑 |
| MySQL / MariaDB | 5.7 或 8.x | 订单与卡密存储 |
| Redis | 可选 | 限流、队列 |
3.2 从上传源码到后台可登录：十分钟部署操作
部署本身不复杂，但每一步都有坑，我习惯一条条来。先装基础服务和扩展，再配置站点，再导入数据库，最后才动伪静态和后台密码。
# 以常见发行版为例，安装 Nginx、MariaDB、PHP 及常用扩展 yum install -y nginx mariadb-server php-fpm php-mysqlnd php-mbstring php-gd systemctl start nginx mariadb php-fpm # 创建数据库并导入源码自带的 SQL 文件 mysql -uroot -p -e "CREATE DATABASE IF NOT EXISTS card_shop DEFAULT CHARSET utf8mb4;" mysql -uroot -p card_shop < /var/www/card/install.sql # 修改源码里的数据库配置，通常位于 config.php 或 .env 文件 sed -i "s/'db_name' => '.*'/'db_name' => 'card_shop'/" /var/www/card/config.php这几条命令看着简单，但有两个点要特别说明。第一，install.sql 是源码包里最常见的数据库初始化文件，但不同版本文件名可能不同，有的叫 card.sql，有的要在安装向导里填数据库信息自动建表，拿到源码先看清楚再执行，别上来就导入。第二，数据库字符集我统一建议 utf8mb4，因为用户填的卡种名称、支付备注里可能带表情符号，utf8 存不了会直接报错。PHP 扩展里 mysqlnd 必须装，老代码的数据库连接全依赖它。
接下来配 Nginx 站点。这一步最容易翻车的是伪静态，很多回收源码的路由没有伪静态也能跑，但首页能开、内页全是 404，非常迷惑人。
server { listen 80; server_name your-domain.com; root /var/www/card; index index.php; location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s=$1 last; } } location ~ \.php$ { fastcgi_pass unix:/run/php-fpm/www.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }这段配置里最关键的是 rewrite 规则，它的作用是把所有不存在的文件路径统一转给 index.php 入口文件去路由处理。不同框架的路由参数可能不一样，有的用 ?s=，有的用 index.php?route=，改伪静态前先找源码入口文件里路由参数叫什么。很多翻车案例都是套用了通用的 ThinkPHP 伪静态规则，结果路由参数对不上，后台能进首页进不去。改完配置后记着 nginx -s reload，然后先用首页测试，首页通了再试内页和后台。
3.3 模拟第一笔回收订单：提交、审核、打款的完整闭环
站点能开了，别急着上真卡，先模拟一笔订单走通全流程。我的习惯是先改管理员密码，再拿假卡密调接口。
-- 先查用户表里密码字段的格式，再决定怎么改 SELECT username, password FROM user WHERE username = 'admin'; -- 如果 password 是 32 位 MD5，直接覆盖 UPDATE user SET password = MD5('你的新密码') WHERE username = 'admin';改密码这一步必须强调：先查后改，不要盲改。很多老源码的密码不是裸 MD5，而是 MD5 加盐或者用了 password_hash，你直接 SET 一个裸 MD5 上去，会发现怎么都登不进后台，还以为自己密码打错了。先看一眼 password 字段长度和格式，要是带盐就去源码里找密码校验函数，按它的加密方式生成新值再写进去。
后台能登录后，去前台提交一笔测试订单。最常见的提交接口路径是 POST 到 /index/api/order/submit 这一类地址，提交参数无非卡种、卡号、卡密、面值、收款账号。
curl -X POST http://your-domain.com/index/api/order/submit \ -d "card_type=jde" \ -d "card_no=123456789012" \ -d "card_pwd=TEST_PWD_ONLY" \ -d "face_value=100" \ -d "pay_type=alipay" \ -d "pay_account=test@example.com"提交完去后台订单列表看状态，正常情况下会出现一条「待风控」或「待审核」的订单。然后管理员审核、调用渠道核销、打款，订单状态依次流转。这一步全流程走完至少验证了五件事：前台表单通不通、报价接口动不动、订单写入数据库没有、后台列表显示是否正常、状态流转是否符合预期。这里有一条必须守住的底线：测试期一律用假卡密，千万别拿真卡去试。真卡密一旦提交，如果代码里已经接了自动核销接口，那就是不可逆的操作，卡被渠道核销了，你只能按面值赔给用户。
提示：模拟订单通过后，把测试订单一律标记为「已撤销」或「冻结」，不要和真实订单混在一起，否则月底对账时你会对到怀疑人生。
4. 订单与卡密的数据结构：把一张二手卡存成一条不会出错的记录
4.1 订单表、卡密表、报价表：三个核心表的关系
回收站的数据库表看起来不少，但真正核心的就三张：订单表、卡密存储逻辑、报价表。很多小团队一开始图省事，卡密不单独建表，直接存订单表里，结果一张卡被多次提交时根本没法查重。下面是一张我实际搭建同类系统时会用的订单表结构，省掉不重要的字段，只留最关键的部分。
CREATE TABLE `order` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `order_sn` VARCHAR(32) NOT NULL COMMENT '商户订单号，唯一', `user_ip` VARCHAR(46) DEFAULT NULL COMMENT '提交者IP', `card_type` VARCHAR(20) NOT NULL COMMENT '卡种编码，如 jde_100', `card_no_hash` CHAR(64) NOT NULL COMMENT '卡号SHA256，用于查重', `card_no_enc` TEXT NOT NULL COMMENT 'AES加密后的卡号', `card_pwd_enc` TEXT NOT NULL COMMENT 'AES加密后的卡密', `face_value` DECIMAL(10,2) NOT NULL COMMENT '卡面值', `discount` DECIMAL(5,2) NOT NULL COMMENT '给用户的折扣，0.95 表示 95 折', `pay_price` DECIMAL(10,2) NOT NULL COMMENT '实际打款给用户的金额', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '1待风控 2待审核 3核销中 4已打款 5已撤销 6冻结', `pay_type` VARCHAR(10) DEFAULT NULL COMMENT 'alipay / wechat / bank', `pay_account` VARCHAR(64) DEFAULT NULL COMMENT '用户收款账号', `channel_code` VARCHAR(32) DEFAULT NULL COMMENT '核销渠道标识', `channel_price` DECIMAL(10,2) DEFAULT NULL COMMENT '渠道结算价', `created_at` DATETIME NOT NULL COMMENT '提交时间', `updated_at` DATETIME NOT NULL COMMENT '状态变更时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_order_sn` (`order_sn`), UNIQUE KEY `uk_card_no_hash` (`card_no_hash`), KEY `idx_status_created` (`status`, `created_at`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;几个字段值得单独解释。card_no_hash 一定要建唯一索引，这是同一张卡被重复提交时的第一道防线，数据库层面直接挡住，比在代码里先 SELECT 再 INSERT 可靠得多。card_no_enc 和 card_pwd_enc 用 TEXT 而不用 VARCHAR，是因为加密串长度远大于明文卡号，VARCHAR 设短了存不进去，设长了又浪费空间。discount 和 channel_price 是两个容易混淆的字段：discount 决定用户拿到多少钱，channel_price 决定你从渠道拿到多少钱，中间差值就是毛利。很多对不上账的情况，追根溯源都是后台只记了 discount 没记 channel_price，月底根本没法算总账。
4.2 订单状态机：从待风控到已打款的流转顺序
订单状态看着简单，但状态机设计得好不好，直接决定上线后会不会出现「钱付了卡没了」「卡核销了钱没付」这种事故。常见的做法是六态流转，不允许乱跳。
状态 1 是待风控，用户刚提交，系统做基础校验；状态 2 是待审核，风控通过，管理员确认卡种、面值、折扣；状态 3 是核销中，代码已经把卡密提交给渠道，等待渠道返回结果，这是最容易出问题的状态；状态 4 是已打款，渠道核销成功且钱已经付给用户；状态 5 和 6 是异常兜底，已撤销是用户自己放弃或重复提交被拦截，冻结是疑似风险单，等待人工复核。
这里有一条必须守住的规则：只有 2 和 3 两个状态允许回退。也就是说待审核的订单管理员可以打回重新风控，核销中的订单如果渠道超时也可以回到待审核重新尝试。一旦进入已打款状态，绝不能自动回退，只能人工介入改冻结并登记操作记录。我见过一个站点为了赶功能把状态流转写得特别「自由」，管理员一个误操作把已打款的订单改回待审核，结果同一张卡被核销了两次，又给用户打了一次款，最后赔了两份钱。
4.3 对账怎么做：每日结算时最容易对上不齐的三个差异点
对账是很多新建站完全没有考虑的事，等月底发现钱少了才开始查，那感觉基本等于大海捞针。我习惯从第一天起就留一条每日汇总的 SQL，每天早上花两分钟看一眼。
SELECT DATE(created_at) AS d, status, COUNT(*) AS cnt, SUM(pay_price) AS total_pay FROM `order` WHERE created_at >= DATE_SUB(NOW(), INTERVAL 7 DAY) GROUP BY d, status ORDER BY d DESC;这条 SQL 把最近每天的订单量和打款金额按状态聚合，一眼就能看出有没有异常。如果某天已打款金额突然多了几千，而订单数没涨，基本就是有一张大额卡被重复打款了。
实际对账时，对不上账的原因通常就三类。第一类是渠道扣点：渠道结算时实际打给你的钱少于 channel_price，因为渠道收取了手续费，这类差异靠账目核销时记实际到账金额解决。第二类是改价：运营在后台手动修改了订单的折扣或打款金额，但没有在 channel_price 里同步记录，这需要后台在改价时强制写入一条操作日志。第三类是退款：用户卡密无效、被渠道拒收后走了人工退款，退款单没有单独标记。我的建议是，对账不要只对总金额，要按天、按卡种分开对，否则只能发现钱少了，根本定位不到是哪个环节少的。
5. 收卡网站上线后的避坑清单：五类翻车现场与解法
5.1 卡号卡密进了 Nginx 日志，等于把卡密送给爬虫
现象：某开发者 A 同学部署完站点，上线第一周就发现好几张热门卡种的卡被渠道提前核销，用户还没收到钱，卡已经废了。查了半天才发现，Nginx 的 access.log 里完整记录了卡号和卡密——因为提交接口用了 GET，或者代码里在日志函数中打印了$_REQUEST。
原因：这类老源码为了调试方便，经常会在控制器里打日志，把整个请求参数数组都写进去。Nginx 默认的 access_log 会记录完整请求行，卡密作为 URL 参数直接裸奔。机房扫描器、搜索引擎爬虫甚至撞库脚本一旦扫到日志文件路径，整张卡密就直接暴露了。
解决：第一，提交接口强制改为 POST，并且代码里不要用$_REQUEST，改用$_POST。第二，Nginx 里对这个接口单独关闭访问日志，其他路径正常记录。第三，日志保留周期压缩到 7 天以内，避免日志文件过大被拖走。凡是涉及卡密的请求，原则只有一条：不落地明文。
5.2 核销超时导致「卡被核销、订单还是待审核」
现象：用户提交卡密后页面一直转圈，最后提示「系统繁忙」。用户以为没提交成功，又试了一次。后台一看，出现了两笔相同卡号的订单，而渠道那边显示这张卡已经被核销掉了。也就是说，卡没到手里，钱已经付出去了或者用户会来投诉。
原因：核销接口调用是同步的，代码把卡密 POST 给渠道后，渠道响应超时，本地代码直接抛异常，订单状态停在待审核，但渠道已经完成了核销。用户重试时系统又发起了一次核销，而这张卡已经被核销过了。
解决：核销绝对不能做成同步调用，要加中间态。提交给渠道前先把订单改成「核销中」，然后发起请求，不管成功还是超时都记录下来。超时后不立即重试，而是等 30 秒到几分钟，用定时任务主动查询渠道的订单状态来确认结果。代码里还要做一个兜底：同一卡号的未完成订单只能有一笔，新提交直接提示「该卡正在处理中」。
5.3 报价和渠道结算价对不上账
现象：月底算账，按前台订单统计的毛利是两千，实际银行卡里只多了一千五，差了五百。翻订单记录发现，很多订单的前台折扣是 95 折，但渠道实际结算只按 92 折，中间还有支付手续费，全部没有算进成本。
原因：后台只记了一张价格表，前台报价和渠道结算共用同一个折扣，渠道价变动后没人同步改，或者改了前台价格忘了改渠道价格。
解决：把价格体系拆成两张表——前台折扣表负责给用户报价，渠道价格表负责记录你实际能拿到的钱。订单创建时把两个值都快照到订单表里，之后渠道价怎么变也不影响历史订单的毛利计算。后台每次改价自动生成一条改价记录，方便追溯。
5.4 同一张卡被反复提交，赔了一整张卡的钱
现象：两个账号几乎同时提交了同一种卡、同一个卡号卡密，后台出现两条待审核订单。审核员没细看，以为是大额单分两笔打款，直接都通过了。
原因：代码里只做了「订单表里是否已有同卡号订单」的查询校验，但查询和插入之间有间隙，两个请求同时进来，都查到「不存在」，然后都创建了订单。数据库层面没有唯一索引兜底。
解决：这是必须上数据库级别约束的典型场景。card_no_hash 字段建唯一索引，第二个请求插入时直接抛异常，代码捕获异常后提示「该卡已在处理中，请勿重复提交」。做这个改造时还要注意，已经存在的脏数据要先清理再建索引，否则建索引会直接失败。
5.5 后台登录不了或首页 500：先看日志再动手
现象：站点部署完，首页能开，后台一登录就 500，或者直接白屏。新手最容易犯的错误是随手改一堆配置，越改越乱，最后连首页都打不开了。
原因：老 PHP 源码在 PHP 8 环境下的兼容性问题占了大多数；其次是伪静态规则和源码路由不匹配；还有一种是后台密码改坏，误以为自己改错了密码，反复重装。
解决：我的处理顺序永远是固定的——第一步看 PHP 错误日志，日志默认在 php-fpm 的日志目录里，里面会明确告诉你哪一行哪个函数报错；第二步看 Nginx error.log，排除伪静态问题；第三步才动源码，而且动之前先备份，用cp复制整个站点目录和数据库。改代码时每次只改一处，改完刷新一次页面验证，别一口气改十处然后从头排查。你节省的那点时间，最后都会变成加倍的排查时间。
注意：排查类问题最忌讳「猜」。每改一个配置前，先问自己一句：这个改动是在解决日志里看到的那个报错吗？如果不是，就先别动。
6. 让这套收卡源码更好用的四个小改造
6.1 把热门卡种的报价改成后台可调的动态折扣
很多源码的报价规则写死在代码里，每次调折扣都要改文件。改造方向是建一张卡种报价表，每行一个卡种编码、面值区间、默认折扣、最低折扣、更新时间。前端报价时实时查表，后台加一个简单的价格管理页，运营自己就能改。注意要加一个「报价有效期」，超过有效期自动恢复默认折扣，防止调了价忘了改回来。
6.2 卡密加密存储，别让数据库裸奔
如果源码里卡号和卡密还是明文存储，这个改造优先级最高。用 PHP 的 openssl_encrypt 做 AES-256 加密，密钥放在站点目录之外的配置文件中，不要写进数据库。老数据可以写一个迁移脚本，一行行读取、加密、写回，跑完后再把备份文件和原数据库清掉。这改动不复杂，但能避免「数据库被拖库后卡密全网传播」这种最坏情况。
6.3 核销请求进队列，接口超时不再卡页面
同步调核销接口的体验很差，用户看着页面转圈，一超时就想重试。常见的做法是不引入消息队列组件，直接用 Redis 的 List 结构做简单队列：提交卡密后把订单号 push 进队列，一个常驻脚本每几秒 pop 一个订单去调渠道接口，结果写回订单表。改造量不大，但对用户体验和订单成功率都有明显提升。
6.4 加一个回收记录查询页，少接一半客服电话
用户最大的焦虑是「我卡提交了，钱怎么还没到」。源码里如果只有订单列表没有查询入口，用户只能加客服微信问。改造方法是加一个公开查询页，输入订单号和提交时的手机号或支付宝账号，展示订单状态和预计到账时间。这个页面没有后台权限，只是只读查一张订单表，技术上几乎没有风险，却能省掉大量重复咨询。
我每次搭完这类系统，第一个习惯就是把日志保留周期从默认的 7 天改到 30 天，第二个习惯是坚持用假卡密完整走一遍全流程再开放提交，第三个习惯是任何涉及真卡密的测试环境单独隔离开，绝不和生产环境共用数据库。这套源码跑起来不难，难的是把每一张卡都当成可能会出事的资产去设计逻辑。希望帮到你。
本文还有配套的精品资源，点击获取
