本文實例講述了ThinkPHP框架下微信支付功能總結。分享給大家供大家參考，具體如下：

摘要

• 此文主要為個人解決 ThinkPHP3.2.3 下微信支付所遇到的一些坑的解決方案，僅供參考
• 詳情請參考 原文 : 微信公眾平臺開發(fā)教程之ThinkPHP框架下微信支付功能

踩坑記錄

為便于參考，此處附錄部分 weixinpay.class代碼截圖

①. 驗證不嚴謹，損失教訓

• 補充時間：【2017-01-02】
• 情況描述

【我尊重你，但不認同你】
　　恰逢元旦期間，遭到微信支付被大牛攻破的情況，損失近 80k，好在公司并沒有追究，畢竟一直在趕時間，測試不全面（壓根沒測試人員）,慶幸的的對方 24小時未收款，基本全部退還
　　問題集中在驗證不足的紅包發(fā)放上，不屬于我的編碼范圍，分析后，明白一點，盡全力不要使用前端的數(shù)據(jù)提交，需要進行后端的數(shù)據(jù)判斷，考慮盡量多的情況。

②. “total_fee” 參數(shù)報錯

• 補充時間：【2017-02-05】
• 情況描述

　今天發(fā)現(xiàn)一種情況，如果打開微信支付密碼的界面后，未支付而從待付款進行再支付，會有時候報錯一個“total_fee” 參數(shù)報錯，找到一種解決方法，即將 “out_trade_no” 以時間戳來重新配置，個人猜測或許是因為一次支付未完成后因為某種原因限制再付款　…

代碼參考如下：

$total_fee = floatval($order_amount)*100;
$order=array(
  'body'=>'testMsg',// 商品描述（需要根據(jù)自己的業(yè)務修改）
  'total_fee'=>$total_fee,// 訂單金額 以(分)為單位（需要根據(jù)自己的業(yè)務修改）
  'out_trade_no'=>$out_trade_no.'M'.time(),// 訂單號（需要根據(jù)自己的業(yè)務修改）
  'product_id'=>'1',// 商品id（需要根據(jù)自己的業(yè)務修改）
  'trade_type'=>'JSAPI',// JSAPI公眾號支付
  'openid'=>$openid// 獲取到的openid
);

③. 批量支付問題

• 補充時間：【2017-02-08】
• 情況描述

　　今天在做批量支付時發(fā)現(xiàn)，會有 total_fee 報錯
　　個人最初簡單的想法是將所有待支付的批量訂單拼接為 state 參數(shù)傳入微信，然后再進入 notify() 方法中進行分離整理，此時發(fā)現(xiàn)微信有參數(shù)長度的限制，大概最多 50 個字符 ，不可以無限制的拼接
　　后來的解決方案是進行新訂單的創(chuàng)建，由此新訂單號去查詢關聯(lián)的其他批量訂單信息，并且已完成需求

④. 回調函數(shù)的注意

• 情況描述

　　注意該路徑必須要與配置文件中的回調路徑一致，此回調函數(shù)，是根據(jù)微信是否真正完成支付后的數(shù)據(jù)更新鏈接，一般在此處進行訂單狀態(tài)的修改
　　先前發(fā)現(xiàn)，因為微信服務的設計，會多次回調 notify() 以判斷是否真正的支付成功，而簡單的 update 操作是無法檢測的，為了同自己的平臺相關聯(lián)，同理需要進行狀態(tài)的判斷，否則不可避免的會多次執(zhí)行 notify() 中的邏輯處理

注意：

1. 比如，我在此處異步執(zhí)行的是將訂單號的支付狀態(tài)參數(shù)由 0 置為 1，判斷如果是已支付訂單，則不再執(zhí)行后續(xù)更新邏輯.
2. 個人測試發(fā)現(xiàn)，此處 session 和 cookie 的設置都失效，僅做參考

⑤. D() 方法失效問題

• 補充時間：【2017-02-09】
• 情況描述

　　今天發(fā)現(xiàn)，當在微信完成支付后進行的回調中，針對于 ThinkPHP 框架里的 D() 方法是無法執(zhí)行的，測試發(fā)現(xiàn)同樣的代碼不是這樣微信回調就可以執(zhí)行，畢竟之前記得是沒有問題的
　　此時考慮的解決方法是使用 model 的實例化 new 方法進行曲線優(yōu)化，發(fā)現(xiàn)可行…

⑤. 鬼知道是什么情況

• 補充時間：【2017-05-02】
• 情況描述

　 　這兩天再次進行代碼的迭代，根據(jù)自己之前的印象繼續(xù)折騰微信支付，發(fā)現(xiàn)這可真真的是個坑，我認為剛開通微信支付的服務號很有可能不滿足某些代碼開發(fā)需求，配置完成的數(shù)據(jù)，半天都不能接收到正確的反饋
　　待到第二天再準備繼續(xù)攻克時發(fā)現(xiàn)，未動的代碼又實現(xiàn)了需求
　　舉個例子:
　　前一天回調的路徑放在 M 模塊下怎么都不執(zhí)行，手賤參考以前的回調路徑放到 Home下就可以了，首先排除低級的個人代碼問題，因為第二天無聊又改回去了 M,竟然又好了…

補充一部分測試的代碼：

/**
 * 微信支付監(jiān)聽接口 判斷是否完成了微信支付操作
 */
public function notify(){
  // ↓↓↓下面的file_put_contents是用來簡單查看異步發(fā)過來的數(shù)據(jù) 測試完可以刪除；↓↓↓
  // 獲取xml
  /*$xml=file_get_contents('php://input', 'r');
  //轉成php數(shù)組 禁止引用外部xml實體
  libxml_disable_entity_loader(true);
  $data= json_encode(simplexml_load_string($xml, 'SimpleXMLElement', LIBXML_NOCDATA));
  file_put_contents('.notify.log', $data);*/
  // ↑↑↑上面的file_put_contents是用來簡單查看異步發(fā)過來的數(shù)據(jù) 測試完可以刪除；↑↑↑
  // 導入微信支付sdk
  Vendor('Weixinpay.Weixinpay');
  $wxpay=new \Weixinpay();
  $result = $wxpay->notify();
  if ($result) {
    $out_trade_no = explode('M',$result['out_trade_no'])[0] ;
    $this->toUpdatePayInfo($out_trade_no);
    //TODO 進行頁面跳轉
  }
}

⑥. ThinkPHP 跨模塊調用方法失效問題

• 補充時間：【2017-05-03】
• 情況描述

　　有種情況的出現(xiàn)是，同樣的代碼在實際支付回調的函數(shù)中不執(zhí)行，然而自己做了個測試路徑傳入固定訂單號發(fā)現(xiàn)執(zhí)行順利，前提是所處環(huán)境完全一致（都在線上進行），就如同上次使用D()方法測試可以執(zhí)行，放在實際的微信回調后就打死也不執(zhí)行
　　而這次吸取了教訓，使用的 new model 實例化方法，因為其中的一個 model 類在初始化時調用了部分數(shù)據(jù)，結果微信支付回調時卡在實例化這行代碼上，雖然測試的代碼是沒問題的，自己也說不清楚，鬼知道到底是怎么回事
　　不過發(fā)現(xiàn) A() 跨模塊方法還是可以用的，至少現(xiàn)在是可行的…
后期發(fā)現(xiàn)如下的類似方法也能執(zhí)行

//TODO 獲取對應訂單的交易價
$cartPayController = new \M\Controller\CartpayController();
$order_amount = $cartPayController->wxPayOrder($out_trade_no,0);

更多關于PHP相關內容感興趣的讀者可查看本站專題：《PHP微信開發(fā)技巧匯總》、《php curl用法總結》、《PHP網(wǎng)絡編程技巧總結》、《php字符串(string)用法總結》、《PHP中json格式數(shù)據(jù)操作技巧匯總》及《PHP針對XML文件操作技巧總結》

希望本文所述對大家PHP程序設計有所幫助。

最新評論