微信支付開發避坑指南

公众号-JavaEdge發表於2024-09-09

1 微信支付的坑

1.1 不能用前端傳遞過來的金額

訂單的商品金額要從資料庫獲取，前端只傳商品 id。

1.2 交易型別trade type欄位不要傳錯

v2版API，不同交易型別，要呼叫的支付方式也不同。

1.3 二次簽名

下單時，在拿到預支付交易會話標識時，要進行二次簽名操作。二次簽名後的值，才能返回給前端使用。

1.4 小程式可繫結到其它公司的商戶下

可同時關聯到多個商戶號：

1.5 微信支付的單位是分，最小金額是0.01元

支付寶是元。

1.6 做避免重複消費的處理

處理成功之後不要再進行二次處理了，那首先是有事務操作。

第一次處理成功後，需要更新對應訂單的狀態。更新完成後，下次再處理時，直接返回成功，不再進行實際業務處理。

也可以拿這個訂單號加分散式鎖，保證對同一個使用者，同時只能處理一個訂單。

1.7 支付結果驗籤

對支付結果通知，一定要拿配置的私鑰進行驗籤處理。

// 處理內部業務邏輯
try {
    // 支付結果驗籤
    boolean valid = WXPayUtil.isSignatureValid(map1, weixinpaypartner);
    if (valid == false) {
        log.info("簽名不一致" + outTradeNo);
        return "ERROR";
    } else {
        //1、更新訂單狀態
        dealAfterSuccess(basOrder, time_end, transaction_id, result_code);
        log.info("驗籤成功" + outTradeNo);
        result = CommUtils.setXml("SUCCESS", "OK");
        log.info("收到非同步通知返回微信的內容--" + result);
        return result;
    }
} catch (Exception e) {
    e.printStackTrace();
    return "ERROR";
}

不驗籤也可以繼續執行，但支付結果頁容易被偽造哦！

1.8 對支付結果通知處理邏輯中的非事務性操作做操作記錄

可能在支付通知後，透過小程式給使用者傳送模板訊息通知或公眾號訊息通知觸達。若這時事務處理失敗，但結果傳送成功了，會造成啥結果？那你下次是否要重新處理這個訂單流程，在重新處理訂單時難道再發一次推送嗎？肯定不可以。

所以最好拿訂單號作為標識，判斷記錄這個訂單是否已經有過啥事務性、非事務性操作，下次或者是訂單補償時，就只處理事務性操作，不再處理非事務性操作。

1.9 v2的統一下單的介面

服務號、H5下單和小程式下單都可呼叫，甚至app下單都可以呼叫。

關注我，緊跟本系列專欄文章，咱們下篇再續！

作者簡介：魔都架構師，多家大廠後端一線研發經驗，在分散式系統設計、資料平臺架構和AI應用開發等領域都有豐富實踐經驗。

各大技術社群頭部專家博主。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。

負責：

  • 中央/分銷預訂系統效能最佳化
  • 活動&券等營銷中臺建設
  • 交易平臺及資料中臺等架構和開發設計
  • 車聯網核心平臺-物聯網連線平臺、大資料平臺架構設計及最佳化
  • LLM Agent應用開發
  • 區塊鏈應用開發
  • 大資料開發挖掘經驗
  • 推薦系統專案

目前主攻市級軟體專案設計、構建服務全社會的應用系統。

參考：

  • 程式設計嚴選網

本文由部落格一文多發平臺 OpenWrite 釋出！

相關文章