接入支付

如果你想收錢，對獨立開發者而言的標準路徑是 Stripe（或者 Lemon Squeezy / Paddle，如果你想讓它們替你處理銷售稅——作為登記在冊的銷售方（merchant of record），它們抽成更高，但讓稅務的頭疼消失）。這些機制是重複且文件完善的，這讓它們非常適合外包出去。你需要的幾塊拼圖：

• 一個**結賬（checkout）**流程——Stripe Checkout 是最快的；它直接給你一個託管好的支付頁面，讓你永遠不必碰原始卡資訊。
• 把 webhook 想像成支付公司在一筆交易剛一清算成功的那一刻就打電話通知你的應用，而不是讓你的應用反覆地追問"到底成沒成？"。一個 webhook 正是如此：它是支付服務商會去呼叫的一個端點（endpoint，你伺服器上的一個 URL），讓你的應用知道一筆支付究竟何時真正成功了。這是新手會跳過的部分，然後他們納悶為什麼訂單從來不會被履約。回到你站點的那個重定向可能被關閉、被攔截或被偽造；webhook 才是伺服器對伺服器的事實來源。絕不要只信任那個重定向；要信任 webhook。
• 一種**儲存權益（entitlements）**的方式——在你的資料庫裡把使用者標記為已付費。這樣重新整理一下或換一臺裝置，他們買的東西依然在。

關鍵的洞察在於你信任哪一根箭頭。把使用者帶回你站點的那個重定向可能丟失或被偽造；真正解鎖產品的，是伺服器對伺服器的那條 webhook 線：

 ┌──────┐  1. 點選購買    ┌───────────┐
 │ 使用者 │────────────────▶│  YOUR APP │
 └──────┘                 └─────┬─────┘
    ▲                           │ 2. 建立結賬會話
    │                           ▼
    │                    ┌─────────────┐
    │  3. 在託管頁支付   │   STRIPE    │
    └───────────────────▶│   Checkout  │
       (卡資訊)          └──────┬──────┘
                                │
          ┌─────────────────────┴─────────────────────┐
          │ 4a. 重定向返回          4b. WEBHOOK 呼叫   │
          │     (可能丟失/偽造)       (伺服器→伺服器,  │
          ▼                              簽名·可信)    ▼
   ┌──────────────┐                          ┌────────────────────┐
   │ 感謝頁       │   ✗ 請勿在此解鎖        │ YOUR APP /webhook   │
   │ (僅 UI)      │                         │ 驗證簽名 →          │
   └──────────────┘                          │ 標記使用者為 PAID ✓  │
                                             └────────────────────┘

讓 AI 把這三塊都搭好，並解釋 webhook 的簽名驗證，因為那是其中唯一對安全敏感的一步——沒有它，任何找到你 webhook URL 的人都能偽造一個"支付成功"事件，把你的產品免費解鎖。在切換到正式 key 之前，用 Stripe 的測試模式和它們的測試卡號（4242 4242 4242 4242 是最有名的那個）把一切都測一遍，並用 Stripe CLI 把 webhook 事件轉發到你的本地機器，親眼看著它們觸發。不要跳過測試模式這場帶妝彩排。第一筆流經你應用的真錢，應該是一筆你已經看過它成功運作十幾次的交易。