訂單號重複致使支付寶支付不了
情景：這個很好理解，比如說你用同乙個支付寶商戶賬號，給不同**（系統）使用的時候，如果各自的**（系統）產生的訂單規則都類似甚至相同，就很有可能發生這種錯誤。
解決方法：一定要讓產生的訂單號在支付寶商戶賬號裡保持唯一。
支付充值後，我的賬號餘額竟然還是原來那麼多！？
「美男子，能不能默默的退出，再登入一下呀？因為，這個那個……」如果我這麼說，你一定會殺了我吧
——滾！
因為支付過後，雖然餘額確實充值到當前使用者的賬戶裡，但是因為沒有更新當前session資訊，而顯示的時候因為用的是當前的session資料，so……
支付總結
不過是支付寶支付還是財富通的支付，其實都差不多。支付成功後，同步返回，而此時非同步的請求也是同時發出。所以在returnurl的頁面和notifyurl的頁面，要對返回來的狀態做相應處理。而尤其要注意的是，比如「擔保交易」，有可能優先在notifyurl頁面裡已經經過了「處理模組」的處理，假如是「賣家確認發貨」，導致在返回到returnurl頁面的時候狀態已經變成了「等待買家確認」，所以要在returnurl頁面的「等待買家確認」狀態下做已經處理過後的處理，比如要返回具體資訊給的結果頁面，比如訂單號，支付了多少錢等資訊。
我一般都會把對訂單號的處理寫在乙個模組方法裡，在新訂單的時候才做處理，這裡的處理一般都有更改訂單狀態，業務複雜的話會關聯其他的表，還得對其他表資料的增刪改等操作。
我遇到的問題：
比如我的處理模組方法叫exceleven，裡面當訂單狀態為「新訂單」的時候發一封email，這時候會偶爾的發聲一次支付發多封的email。
情景：在支付回來的頁面裡的每個狀態方法塊裡，查詢訂單資訊，當訂單狀態為新訂單的時候就會呼叫exceleven方法進行處理， 雖然支付成功後同時請求非同步和同步頁面，但是理論上也不會多發email呀？
原因：因為支付成功後，支付寶會同時請求我們提供的非同步處理頁面（notifyurl）和同步處理頁面（returnurl），而當exceleven方法處理時間過長的時候，有可能在請求兩個處理頁面的時候訂單都為「新訂單」，所以才會多發了email。
解決：在處理訂單的時候，要在where條件後面多加條件，即status=新訂單，否則rollback，有其他表的處理也類似地加上後置條件，而不是相信前面已經在頁面（notifyurl和returnurl）上用if判斷語句斷言了是新訂單。
在支付成功後，如果要對當前使用者更新資訊的時候，比如餘額積分等等，一定要做session的更新哦。
第一次如此工工整整的寫，感覺好麻煩，好好看。
關於做筆記
不管記在 如果不知道回頭看也確實是沒有太大意義。我覺得有一點是電子筆記沒法和紙質筆記相提並論的，那就是紙質的筆記是一種具體的形式，而電子筆記卻只是一種形式上的抽象。如果能堅持把電子筆記列印出來訂成冊子也是個不錯的方法，但如果只是打出來不在那畫圈圈點點的話，意義也不是很大，最省事，最省時，最省腦力的還...
PHP 做支付寶支付介面 總結
以前曾寫過一篇關於 paypal 支付介面的文章 這兩天做了關於支付寶介面的測試，看似不太一樣，但支付介面都是一樣的，其業務邏輯都是 訂單詳情 提交介面 返回資訊 更新本站訂單資訊 的流程 現在寫支付寶介面時也有一些個問題 1.攻擊者是否可以通過偽造乙個資料 post 或 get 上來導致訂單狀態被...
關於支付的幾點注意
無意中看到beecloud創始人講到做支付的經驗，感覺特別貼切，尤其在本人對接過幾家支付或託管業務相關的公司時，感觸更深，好一點的提供完整的 產線環境，對接很順暢，eg 匯付天下，有的雖然無仿產線環境，但是可以臨時搭建環境使用真錢做測試，同時運營支援到位，可以直接對接解決問題，eg 聯動優勢 連連支...