金流架構
Stripe 提供好幾層整合。層級愈低,畫面愈能客製,你要寫的程式與要自己處理的法規也愈多。先選對層級,再寫 Python。
三種常見做法
| 方式 | 顧客看到什麼 | 你要寫的程式 | 適合 |
|---|---|---|---|
| Payment Link / Pricing Table | Stripe 託管的連結或定價表 | 幾乎沒有 | 先賣起來、沒有工程師 |
| Checkout Session(託管頁或嵌入) | Stripe 結帳頁,可導向或嵌在你的站 | 後端建立 Session + webhook | 大多數網站與課程銷售 |
| Payment Element + PaymentIntent | 你的網站裡的付款表單 | 後端 Intent、前端 Stripe.js、webhook | 要完全自訂版面與多步驟結帳 |
官方目前對多數新專案的建議是:能用 Checkout 就用 Checkout。稅、折扣、多幣別、自動付款方式,Checkout 都幫你接好。PaymentIntent 適合「金額與流程必須自己掌控」的情況。本站現有的 server.py 就是 Payment Element 範例。
sequenceDiagram
participant 顧客
participant 你的網站
participant Stripe
顧客->>你的網站: 按下購買
你的網站->>Stripe: 用 Secret key 建立 Session 或 PaymentIntent
Stripe-->>你的網站: 回傳 url 或 client_secret
你的網站->>顧客: 導向 Checkout 或顯示表單
顧客->>Stripe: 輸入卡號並付款
Stripe->>你的網站: webhook(付款成功)
你的網站->>你的網站: 驗證簽章後出貨
Stripe->>顧客: 導回成功頁
為什麼一定要有後端
卡號不能經過你的伺服器(PCI)。金額也不能只信前端 POST 過來的數字,否則有人把 amount 改成 1 就能買走商品。
正確分工:
- 瀏覽器:顯示商品、載入 Stripe.js、收集付款方式
- 你的 Python 伺服器:查庫存與售價、建立 Session / Intent、處理 webhook、寫入訂單狀態
- Stripe:保管卡號、向銀行請款、處理 3D Secure
選法口訣
- 只要一個連結給人付款 → Payment Link
- 有購物車、要導向專業結帳頁 → Checkout Session,
mode="payment" - 月費會員 → Checkout Session,
mode="subscription" - 結帳必須留在自己的網址列、版面完全自訂 → Payment Element
下一頁看這些選擇對應到哪些 API 物件。