支付模組是各個公司中公司和使用者之間的交易橋樑，構建一套易用，安全，便捷的支付環境是每個公司的首要任務。在上一家公司我負責搭建該功能模組，在此對在做支付模組需要準備的資料、遇到的問題和以後規劃的設想在這裡做一個簡單的記錄。希望可以幫助到那些對支付模組剛剛接觸的新人。
本文主要是兩種支付方式：支付寶、微信支付，更多支付方式請自行解決，大致的流程應該都是可以通用的

資料準備

需要特殊說明的是:

1. 微信在微信APP內部和微信外部(瀏覽器端H5呼叫支付)呼叫的支付方式是不一樣的，需要自己仔細閱讀文件，並且微信的技術客服支援不是很好，有可能都聯絡不到技術客服。
2. 支付寶相對於微信就簡單許多了，在支付寶APP內部和外部呼叫的方式是一樣的，如果需要技術客服的支付，點選支付寶商戶平臺頁面右邊的機器人之後恢復任意話術7次可喚醒人工支援。

微信

注意事項

微信支付一定要仔細看文件，微信技術客服不好找。
微信公眾號支付，吊起支付的頁面是前端做的

支付準備

• 申請開通微信公眾賬號、開通微信商戶平臺、開通微信開放平臺
• 簡要說明一下這三者的關係:
  • 微信公眾賬號：支付功能需要使用開通服務號並開通微信公眾賬號支付。微信APP內部支付就是走的微信公眾號支付。
  • 微信商戶平臺：這個可以看字面意思就是商戶平臺，你的交易記錄都可以查詢到，並且要實現微信公眾賬號支付的話，微信公眾賬號需要和該平臺做關聯。
  • 微信開放平臺：這個和支付沒什麼關係，拿到這裡來說是因為他是關於微信的，他的主要功能：如果一個公司有多個微信公眾賬號運營的話，並且每個微信公眾號都可以拉取使用者資訊的話，將該使用者記錄到我們的使用者庫裡面，就需要將公司所有的微信公眾賬號和此平臺繫結。繫結後用戶無論訪問哪一個微信公眾賬號，再呼叫微信介面獲取使用者資訊的時候，都能獲取到使用者相對於我們的平臺產生的唯一的unionid。該unionid的說明詳細參照微信公眾號開發文件。

支付功能

支付寶

支付準備

• 申請開通螞蟻金服開放平臺

支付功能

• 手機網站支付（wap支付）
  • 使用場景：PC掃碼支付、H5端支付
  • 支付流程：
    • 吊起支付
• 支付寶APP支付

目前的架構

• 採用傳統的架構模式，採用模組的方式開發,一個模組處理了支付相關的所有東西。
  • 優點：
    • 前期開發週期快
    • 需要開發人員少
    • 除錯方便
  • 缺點：
    • 專案到後期需要加個性化的東西，牽一髮動全身
    • 維護麻煩
    • 公司來新人接入週期長

預想的架構（未實現）

• 支付寶和微信支付都有非同步回撥通知，我的想法是將支付模組拆分成多個模組，大概的拆分邏輯：
  • 支付模組
    • 微信支付模組
    • 支付寶支付模組
  • 非同步通知賬單處理模組
• 基本的實現步驟：
  • 支付模組生成支付訂單，將訂單存入到redis中，生成唯一Key,作為公司層面的訂單號。在生成統一下單時候將該訂單號傳入進去。非同步通知時候提交到我們的服務端。
  • 服務端接收到非同步通知中的訂單號，對接受的引數做合法驗證之後，可以直接告訴前段，該使用者已經支付完成。訂單的寫入使用非同步處理。
• 優點：
  • 模組清晰，容易上手
  • 維護簡單，比如調整了微信支付，指驗證微信支付即可。
  • 新手接入速度快。
• 缺點：
  • 維護成本較高（時間成本和人力成本）
  • 資料同步邏輯複雜。
  • 模組較多，運維成本較高

具體程式碼實現

• PC 一個二維碼支援多平臺掃碼支付

  • 該方式的實現邏輯主要如下：
    • ajax請求服務端介面，服務端將生成唯一訂單號和掃碼跳轉連結繫結到二維碼上，返回給前端一個二維碼連結；
    • 使用者使用手段APP掃描二維碼，請求到繫結的二維碼跳轉連結上，該方法中對請求端的useragent做判斷，看看是什麼APP做的支付請求:

  function IsUa(){
      $userAgent = $_SERVER['HTTP_USER_AGENT'];
      // $str  名稱和相應的支付控制器要對應
      switch ($userAgent) {
          case ( strpos( $userAgent, 'MicroMessenger' ) !== false ):
              $str = 'wxpay'; //微信支付
              break;
          case ( strpos( $userAgent, 'AlipayClient' ) !== false ):
              $str = 'alipay'; //支付寶支付
              break;
          default:
              $str = 'other';
      }
  
      return $str;
  }
  

  • 根據不同的useragent做不同的支付處理建立。
  • 使用者支付完成，第三方支付呼叫我們在第一步呼叫 統一下單介面中的【notify_url】往我們的服務端推送支付訊息。
  • 對推送過來的訊息做校驗，校驗完成寫入資料庫並通知前段提示支付成功。

• 其他段的支付都大同小異，呼叫統一下單，使用者支付完成，非同步訂單處理。