支付回調介面 Session 丟失問題根因分析與解決方案

問題現象

開發支付介面（如微信支付、支付寶）時，支付網關異步通知回調 URL，伺服器端無法讀取 Session 資料，導致用戶狀態驗證失敗。

根因分析

1. 跨域請求：支付網關回調屬於第三方域名發起的請求，瀏覽器預設阻擋第三方 Cookie
2. SameSite Cookie 屬性：現代瀏覽器預設 SameSite=Lax，跨站請求不攜帶 Cookie
3. Session ID 傳遞缺失：回調請求未攜帶 Session ID（Cookie 或 URL 參數）
4. 無狀態回調設計：支付回調本質是 Server-to-Server 通訊，不應依賴用戶 Session

解決方案

方案一：回調介面無狀態化（推薦）

支付回調**不依賴 Session**，改用以下機制驗證：

• 支付下單時生成唯一訂單號，關聯業務訂單 ID 存入資料庫
• 回調攜帶訂單號、簽名、支付狀態
• 驗證簽名（使用支付方公鑰/密鑰）
• 根據訂單號查詢本地訂單，更新狀態
• 回應支付方 SUCCESS 確認收到

方案二：允許跨域 Session（不推薦生產環境）

// PHP 設置 Cookie 支援跨域
ini_set('session.cookie_samesite', 'None');
ini_set('session.cookie_secure', '1'); // 必須 HTTPS
session_start();

// 或在 Nginx/Apache 層設置
// Set-Cookie: PHPSESSID=...; SameSite=None; Secure

風險：CSRF 攻擊面擴大，需額外驗證來源 IP、簽名。

方案三：URL 參數傳遞 Session ID

下單時將 Session ID 作為參數附加在回調 URL：

$notifyUrl = "https://example.com/pay/notify?sid=" . session_id();

回調入口：

if (isset($_GET['sid'])) {
    session_id($_GET['sid']);
    session_start();
}

最佳實踐檢查清單

• [ ] 回調介面**不依賴用戶 Session**
• [ ] 簽名驗證**必須**在業務邏輯前執行
• [ ] 訂單狀態機：防止重複處理（冪等性）
• [ ] 回應支付方標準格式（如 SUCCESS、FAIL）
• [ ] 記錄完整回調日誌（請求頭、請求體、處理結果）
• [ ] 異常情況告警（簽名失敗、金額不符、訂單不存在）

參考資源

原文分析：ZCOOL 文章