Home>Article>Backend Development> PHP payment system design and typical cases (recommended)
This article mainly introduces the design and typical cases of PHP payment system in detail. It can be used as a small payment system or as a payment flow system when third-party applications are connected to the open platform. It has certain reference value. Interested friends can refer to
Due to the company's business needs, it took two weeks to implement a small payment system. Although it is small, it has all the necessary modules, such as account locking, transactional Guarantee, running water reconciliation, etc. are fully implemented. There is a lot of experience accumulated in the entire development process. In addition, after searching on the Internet, most of them are research papers and have little practical value, so this This time I specially took it out to share with you.
This system can be used as a small payment system or as a payment flow system when third-party applications are connected to the open platform.
The original demand is more responsible, I will simplify it and say:
For each application, external needs to provideGet balance, pay equipment, rechargeWait for the interface
There is a program in the background, and the liquidation will be carried out on the first of every month
The account can be frozen
It is necessary to record the flow of each operation, and the daily flow must be reconciled with the initiator
In response to the above requirements, we set up the following database:
CREATE TABLE `app_margin`.`tb_status` ( `appid` int(10) UNSIGNED NOT NULL, `freeze` int(10) NOT NULL DEFAULT 0, `create_time` datetime NOT NULL, `change_time` datetime NOT NULL, PRIMARY KEY (`appid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `app_margin`.`tb_account_earn` ( `appid` int(10) UNSIGNED NOT NULL, `create_time` datetime NOT NULL, `balance` bigint(20) NOT NULL, `change_time` datetime NOT NULL, `seqid` int(10) NOT NULL DEFAULT 500000000, PRIMARY KEY (`appid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `app_margin`.`tb_bill` ( `id` int AUTO_INCREMENT NOT NULL, `bill_id` int(10) NOT NULL, `amt` bigint(20) NOT NULL, `bill_info` text, `bill_user` char(128), `bill_time` datetime NOT NULL, `bill_type` int(10) NOT NULL, `bill_channel` int(10) NOT NULL, `bill_ret` int(10) NOT NULL, `appid` int(10) UNSIGNED NOT NULL, `old_balance` bigint(20) NOT NULL, `price_info` text, `src_ip` char(128), PRIMARY KEY (`id`), UNIQUE KEY `unique_bill` (`bill_id`,`bill_channel`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `app_margin`.`tb_assign` ( `id` int AUTO_INCREMENT NOT NULL, `assign_time` datetime NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `app_margin`.`tb_price` ( `name` char(128) NOT NULL, `price` int(10) NOT NULL, `info` text NOT NULL, PRIMARY KEY (`name`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `app_margin`.`tb_applock` ( `appid` int(10) UNSIGNED NOT NULL, `lock_mode` int(10) NOT NULL DEFAULT 0, `change_time` datetime NOT NULL, PRIMARY KEY (`appid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; INSERT `app_margin`.`tb_assign` (`id`,`assign_time`) VALUES (100000000,now());
The detailed explanation is as follows:
tb_status application status table. Responsible for whether the account is frozen and what type of account it is (the real requirement is that the application may have two accounts, so it is not listed here for simplicity)
appid Application id
freeze Whether to freeze
create_time Creation time
change_time Last modification time
tb_account_earn Application account balance table
appid Application id
balance balance (unit is cent, do not use decimal storage, because the decimal itself is not accurate; in addition, PHP must be on a 64-bit machine can support bigint)
create_time creation time
change_time last modification time
seqid operation sequence number (anti-concurrency, every update will be 1)
tb_assign table that allocates serial id, the bill_id of tb_bill must be There is a
id assigned by tb_assign, an auto-increment id
create_time, a creation time
tb_bill flow table. Responsible for recording each operation flow. The bill_id here is not the primary key, because the same bill_id may have two flows, payment and rollback.
id Self-incrementing serial number
bill_id serial number
amt The amount of the operation (this It is necessary to distinguish between positive and negative, mainly to directly calculate the change in amount during a certain period of time when selecting all)
bill_info detailed information of the operation, such as 3 webservers and 2 db
bill_user operating user
bill_time Billing time
bill_type Billing type, distinguishing whether to add money or subtract money
bill_channel Billing source, such as recharge, payment, rollback, settlement or others
bill_ret Billing return code, including unprocessed and successful , failed, the logic here will be explained later
appid application id
old_balance account balance before the operation occurs
price_info records the unit price of the item being paid when the operation occurs
src_ip client ip
tb_price unit price table, records the unit price of the machine
name unique identifier of the machine
price price
info description
tb_applock lock table, this is designed to avoid concurrent write operations to an application, specifically The code will show
appid application id
lock_mode lock status later. If it is 0, it is locked, if it is 1, it is locked.
change_time The last modification time
OK, after the library table is designed, let’s take a look at some of the most typical operations.
1. Payment operation
I only list the way I currently implement it. It may not be the best, but it should be the most economical and meet the needs.
Let’s talk about the caller first. The logic is as follows:
#Then the corresponding internal logic of the payment system is as follows (only payment operations are listed, the rollback logic is similar, and the flow check is To check whether the corresponding payment flow exists):
Commonly used error return codes may be enough as follows:
$g_site_error = array( -1 => '服务器繁忙', -2 => '数据库读取错误', -3 => '数据库写入错误', 0 => '成功', 1 => '没有数据', 2 => '没有权限', 3 => '余额不足', 4 => '账户被冻结', 5 => '账户被锁定', 6 => '参数错误', );
对于大于0的错误都算是逻辑错误，执行支付操作，调用方是不用记录流水的。因为账户并没有发生任何改变。
对于小于0的错误是系统内部错误，因为不知道是否发生了数据更改，所以调用方和支付系统都要记录流水。
对于等于0的返回，代表成功，两边也肯定要记录流水。
而在支付系统内部，之所以采用先写入流水，再进行账户更新的方式也是有原因的，简单来说就是尽量避免丢失流水。
最后总结一下，这种先扣钱，再发货，出问题再回滚的方式是一种模式；还有一种是先预扣，后发货，没有出问题则调用支付确认来扣款，出了问题就调用支付回滚来取消，如果预扣之后很长时间不做任何确认，那么金额会自动回滚。
二. 账户锁定的实现
这里利用了数据库的加锁机制，具体逻辑就不说了，代码如下:
class AppLock { function __construct($appid) { $this->m_appid = $appid; //初始化数据 $this->get(); } function __destruct() { $this->free(); } public function alloc() { if ($this->m_bGot == true) { return true; } $this->repairData(); $appid = $this->m_appid; $ret = $this->update($appid,APPLOCK_MODE_FREE,APPLOCK_MODE_ALLOC); if ($ret === false) { app_error_log("applock alloc fail"); return false; } if ($ret <= 0) { app_error_log("applock alloc fail,affected_rows:$ret"); return false; } $this->m_bGot = true; return true; } public function free() { if ($this->m_bGot != true) { return true; } $appid = $this->m_appid; $ret = $this->update($appid,APPLOCK_MODE_ALLOC,APPLOCK_MODE_FREE); if ($ret === false) { app_error_log("applock free fail"); return false; } if ($ret <= 0) { app_error_log("applock free fail,affected_rows:$ret"); return false; } $this->m_bGot = false; return true; } function repairData() { $db = APP_DB(); $appid = $this->m_appid; $now = time(); $need_time = $now - APPLOCK_REPAIR_SECS; $str_need_time = date("Y-m-d H:i:s", $need_time); $db->where("appid",$appid); $db->where("lock_mode",APPLOCK_MODE_ALLOC); $db->where("change_time <=",$str_need_time); $db->set("lock_mode",APPLOCK_MODE_FREE); $db->set("change_time","NOW()",false); $ret = $db->update(TB_APPLOCK); if ($ret === false) { app_error_log("repair applock error,appid:$appid"); return false; } return true; } private function get() { $db = APP_DB(); $appid = $this->m_appid; $db->where('appid', $appid); $query = $db->get(TB_APPLOCK); if ($query === false) { app_error_log("AppLock get fail.appid:$appid"); return false; } if (count($query->result_array()) <= 0) { $applock_data = array( 'appid'=>$appid, 'lock_mode'=>APPLOCK_MODE_FREE, ); $db->set('change_time','NOW()',false); $ret = $db->insert(TB_APPLOCK, $applock_data); if ($ret === false) { app_error_log("applock insert fail:$appid"); return false; } //重新获取数据 $db->where('appid', $appid); $query = $db->get(TB_APPLOCK); if ($query === false) { app_error_log("AppLock get fail.appid:$appid"); return false; } if (count($query->result_array()) <= 0) { app_error_log("AppLock not data,appid:$appid"); return false; } } $applock_data = $query->row_array(); return $applock_data; } private function update($appid,$old_lock_mode,$new_lock_mode) { $db = APP_DB(); $db->where('appid',$appid); $db->where('lock_mode',$old_lock_mode); $db->set('lock_mode',$new_lock_mode); $db->set('change_time','NOW()',false); $ret = $db->update(TB_APPLOCK); if ($ret === false) { app_error_log("update applock error,appid:$appid,old_lock_mode:$old_lock_mode,new_lock_mode:$new_lock_mode"); return false; } return $db->affected_rows(); } //是否获取到了锁 public $m_bGot = false; public $m_appid; }
为了防止死锁的问题，获取锁的逻辑中加入了超时时间的判断，大家看代码应该就能看懂
三. 对帐逻辑
如果按照上面的系统来设计，那么对帐的时候，只要对一下两边成功（即bill_ret=0）的流水即可，如果完全一致那么账户应该是没有问题的，如果不一致，那就要去查问题了。
关于保证账户正确性这里，也有同事跟我说，之前在公司做的时候，是采取只要有任何写操作之前，都先取一下流水表中所有的流水记录，将amt的值累加起来，看得到的结果是否和余额相同。如果不相同应该就是出问题了。
select sum(amt) from tb_bill where appid=1;
所以这也是为什么我在流水表中，amt字段是要区分正负的原因。
总结：以上就是本篇文的全部内容，希望能对大家的学习有所帮助。
相关推荐：
The above is the detailed content of PHP payment system design and typical cases (recommended). For more information, please follow other related articles on the PHP Chinese website!