由於自己專案需要，花兩周時間實現了乙個小型的支付系統，麻雀雖小五臟俱全，各種必須的模組如賬戶加鎖，事務性保證，流水對帳等都是有完整實現的，整個開發過程中有很多經驗積累，再加上在網上搜尋了一下，大部分都是些研究性的**，對實際使用價值不大，所以這次特意拿出來和大家分享一下。
這個系統可以用作小型支付系統，也可以用做第三方應用接入開放平台時的支付流水系統。
原來的需求比較負責，我簡化一點說:
對每個應用，對外需要提供 獲取餘額，支付裝置，充值 等介面
後台有程式，每月一號進行清算
賬戶可以被凍結
需要記錄每一次操作的流水，每天的流水都要和發起方進行對賬
針對上面的需求，我們設定如下資料庫:
`freeze` int(10) not null default 0,
`create_time` datetime not null,
`change_time` datetime not null,
) engine=innodb default charset=utf8;
`create_time` datetime not null,
`balance` bigint(20) not null,
`change_time` datetime not null,
`seqid` int(10) not null default 500000000,
) engine=innodb default charset=utf8;
`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,
`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;
`id` int auto_increment not null,
`assign_time` datetime not null,
primary key (`id`)
) engine=innodb default charset=utf8;
`name` char(128) not null,
`price` int(10) not null,
`info` text not null,
primary key (`name`)
) engine=innodb default charset=utf8;
`lock_mode` int(10) not null default 0,
`change_time` datetime not null,
) engine=innodb default charset=utf8;
詳細解釋如下:
tb_account_earn 應用的賬戶餘額表
balance 餘額（單位為分，不要用小數儲存，因為小數本身不精確；另外php要在64位機下才能支援bigint）
create_time 建立時間
change_time 最後一次修改時間
seqid 操作序列號（防併發，每次update都會+1）
tb_assign 分配流水id的表，tb_bill的bill_id必須是有tb_assign分配的
tb_bill 流水表。負責記錄每一條操作流水，這裡的bill_id不是主鍵，因為同乙個bill_id可能會有支付和回滾兩條流水
tb_price 單價表，記錄了機器的單價
lock_mode 鎖定狀態。為0則為鎖定，為1則為鎖定
change_time 最後一次修改時間
ok，庫表設計出來之後，我們就來看一下最典型的幾個操作.
一. 支付操作
我這裡只列出了我目前實現的方式，可能不是最好的，但應該是最經濟又滿足需求的。
先說呼叫方這裡，邏輯如下:
然後對應的支付系統內部邏輯如下（只列出支付操作，回滾邏輯差不多，流水檢查是要檢查對應的支付流水是否存在）:
常用的錯誤返回碼可能如下就足夠了:
$g_site_error = array(對於大於0的錯誤都算是邏輯錯誤，執行支付操作，呼叫方是不用記錄流水的。因為賬戶並沒有發生任何改變。-1 => '伺服器繁忙',
-2 => '資料庫讀取錯誤',
-3 => '資料庫寫入錯誤',
0 => '成功',
1 => '沒有資料',
2 => '沒有許可權',
3 => '餘額不足',
4 => '賬戶被凍結',
5 => '賬戶被鎖定',
6 => '引數錯誤',
);
對於小於0的錯誤是系統內部錯誤，因為不知道是否發生了資料更改，所以呼叫方和支付系統都要記錄流水。
對於等於0的返回，代表成功，兩邊也肯定要記錄流水。
而在支付系統內部，之所以採用先寫入流水，再進行賬戶更新的方式也是有原因的，簡單來說就是盡量避免丟失流水。
最後總結一下，這種先扣錢，再發貨，出問題再回滾的方式是一種模式；還有一種是先預扣，後發貨，沒有出問題則呼叫支付確認來扣款，出了問題就呼叫支付回滾來取消，如果預扣之後很長時間不做任何確認，那麼金額會自動回滾。
二. 賬戶鎖定的實現
這裡利用了資料庫的加鎖機制，具體邏輯就不說了，**如下:
function __destruct()
public function alloc()
$this->repairdata();
if ($ret === false)
if ($ret <= 0)
$this->m_bgot = true;
return true;
}
public function free()
if ($ret === false)
if ($ret <= 0)
$this->m_bgot = false;
return true;
}
function repairdata()
return true;
}
private function get()
if (count($query->result_array()) <= 0)
//重新獲取資料
if ($query === false)
if (count($query->result_array()) <= 0)
}
}
return $db->affected_rows();
}
//是否獲取到了鎖
public $m_bgot = false;
} 為了防止死鎖的問題，獲取鎖的邏輯中加入了超時時間的判斷，大家看**應該就能看懂
三. 對帳邏輯
如果按照上面的系統來設計，那麼對帳的時候，只要對一下兩邊成功（即bill_ret=0）的流水即可，如果完全一致那麼賬戶應該是沒有問題的，如果不一致，那就要去查問題了。
關於保證賬戶正確性這裡，也有同事跟我說，之前在公司做的時候，是採取只要有任何寫操作之前，都先取一下流水表中所有的流水記錄，將amt的值累加起來，看得到的結果是否和餘額相同。如果不相同應該就是出問題了。
所以這也是為什麼我在流水表中，amt欄位是要區分正負的原因。
網上支付系統的結構與典型流程
網上支付系統的結構與典型流程 柯技 網上支付結構 網上支付系統是面向網路金融服務業務的總需求而搭建的，必須滿足以下幾個方面的市場需求 1 對金融資訊綜合服務的需求。2 網路銀行的綜合服務內容。主要內容包括網路營銷 電子商務服務 網上銀行服務等。3 要能夠成功地克服電子商務網上支付過程中的諸多關鍵問題...
支付系統設計 支付系統的賬戶模型（一）
賬戶體系是支付系統的基礎，它的設計直接影響整個系統的特性。這裡 如何針對電子商務系統的支付賬戶體系設計。我們從一些基本概念開始入手，了解怎麼建模。賬戶體系設計首先要區分兩個概念，支付賬戶和登入賬號。這是兩個不同業務領域的概念 支付賬戶指使用者在支付系統中用於交易的資金所有者權益的憑證 登入賬號指使用...
php分享二十六 支付系統設計
參考 blog.sina.com.cn s blog 81f6205801017ec8.html 畫了2周時間寫的，麻雀雖小五臟俱全，各種必須的模組如賬戶加鎖，事務性保證，流水對帳等都是有完整實現的，整個開 發過程中有很多經驗積累，再加上在網上搜尋了一下，大部分都是些研究性的 對實際使用價值不大，所...