已有會員系統，尚未部署
保留原本的會員資料與登入，讓 Hunterest 帳號和既有會員做安全綁定。
- 會員
- 沿用既有會員系統
- 部署
- 規劃中：由 Hunterest 建立 staging 與 production
目前可先連接 GitHub 並完成部署健檢；managed production hosting 開放後再加入 OAuth 帳號綁定與 Entitlement guard。
Choose your path
先確認你現在在哪裡
會員系統與主機都不需要為了 Hunterest 重做。選擇最接近的情況，我們只補上缺少的部署或權限層。
已有會員系統，已自行部署
不搬動現有主機，只把 Hunterest 購買狀態接進既有會員權限。
- 會員
- 沿用既有會員系統
- 部署
- 維持自己的伺服器
設定 callback／webhook URL，將 Hunterest user ID 對應到既有會員。
沒有會員系統，已自行部署
直接使用 Hunterest OAuth 作為登入來源，不需要先自建完整會員服務。
- 會員
- 使用 Hunterest OAuth
- 部署
- 維持自己的伺服器
建立最小 server session，所有付費功能在 server 端查 Entitlement API。
沒有會員系統，尚未部署
目標是由 Hunterest 代管部署並建立登入／權限整合；目前 production 代管尚未開放。
- 會員
- 使用 Hunterest OAuth
- 部署
- 規劃中：由 Hunterest 建立 staging 與 production
目前可先連接 GitHub、通過健檢；production gate 完成後才由部署精靈準備正式環境與整合設定。
One stable contract
你串的是 Hunterest，不是金流廠商
即使未來更換付款或電子發票供應商，你的登入與權限合約都不需要跟著改。
正式買家收費開放後，Hunterest 負責
- 官網 checkout、付款最終狀態與對帳
- 電子發票、折讓、退款與爭議
- 版本化方案、履約政策與 seller payable
- 每月撥款清單與公司人工銀行匯款核銷
你的工具負責
- OAuth callback 與自己的安全 session
- 將 Hunterest user ID 對應到本機帳號
- 在 server route 呼叫 Entitlement API
- 驗證簽章 Webhook、去重並重新查詢權限
Test to live
七個步驟完成整合
自助 Test 憑證開放後，先在隔離環境證明所有狀態都正確，再申請獨立的 Live 設定。測試憑證不會被直接帶進正式環境。
01
選擇版本化方案
從 Hunterest 後台目前允許的方案中選擇，再設定售價。保障期、退款規則與撥款時程由平台版本控制，既有購買不會被未來改版回寫。
02
準備 Test 整合資料
Test 憑證的自助建立目前尚未開放。可先準備測試環境的 OAuth callback 與簽章 Webhook URL；開放後，Client Secret／Webhook Secret 只在建立時顯示一次，必須直接存進伺服器的 Secret Manager。
03
接上 Hunterest OAuth
瀏覽器只負責導向登入；你的 server callback 驗證 state、交換授權碼並建立自己的 session。已有會員時做帳號綁定，沒有會員時保存最小 Hunterest user mapping。
04
用 Entitlement API 守住付費功能
每個真正需要付費權限的 server route 都要檢查 Hunterest entitlement。前端隱藏按鈕只能改善體驗，不能取代 server authorization。
05
接收簽章 Webhook
付款、續約、退款、到期或服務暫停會產生權限事件。先用 raw body 驗章，再用 event ID 去重；漏掉事件時仍以 Entitlement API 的 authoritative state 為準。
06
跑完狀態測試矩陣
不要只測付款成功。至少驗證未購買、有效、到期、退款、停權及 Webhook 重送，確認任何 unknown／逾時都 fail closed。
07
通過 Live gate 才換正式憑證
Test 設定不直接變成 production credential。供應商 sandbox、法律與會計簽核、production migration、環境差異與 no-traffic candidate 全部通過後，Hunterest 才核發 Live 設定。
Production hosting、Test self-service 與 Live 目前保持鎖定
目前可先準備 callback、webhook 與 server authorization。Hunterest 還要先完成 Test → Live credential lifecycle、供應商 sandbox、付款／發票／退款真實 E2E、法律與會計簽核、production migration 與 no-traffic candidate，才會開放自助測試與正式買家收費。
Do not test only success
上線前必跑的狀態矩陣
付款成功只是其中一格。每個會改變使用權限的終局都要在 server 端得到可重現結果。
| 狀態 | 預期結果 | 你要留下的證據 |
|---|---|---|
| 尚未購買 | 拒絕付費功能 | Entitlement API 回傳 denied；直接輸入深連結仍不可進入。 |
| 權限有效 | 允許已購功能 | OAuth user mapping、product ID 與有效 entitlement 完全一致。 |
| 方案到期 | 下一次檢查即拒絕 | 到期時間使用 server clock；舊 client cache 不可永久放行。 |
| 退款完成 | 撤銷或調整權限 | 退款終局、電子發票折讓與 entitlement 狀態可對回同一筆 order。 |
| 服務暫停 | 依購買政策暫停並進入處理 | Webhook 後重新查 authoritative state；不得只相信本機事件順序。 |
| Webhook 重送 | 不重複開通或撤權 | 相同 event ID 只處理一次；回應遺失後重送仍得到一致終局。 |
After launch
收費之後仍由同一套狀態管理
先免費部署、日後開始收費時，不需要重做登入或重新部署。新增 offer 並通過 Live gate 後，原本的 Hunterest user mapping 可以繼續使用。
- 正式買家收費開放後，買家會在 Hunterest 官網付款，由 Hunterest 對買家開立電子發票並處理退款與交易支援。
- 正式買家收費開放後，底層金流商只和 Hunterest 溝通；Maker 不取得 provider API key、卡號、付款 token 或 raw webhook。
- 正式買家收費開放後，Hunterest 會依購買當下的方案與費用快照形成 seller payable，不讓後續政策改版回寫歷史訂單。
- 正式買家收費開放後，每月後台會列出可撥、未到期、文件阻擋與爭議阻擋金額；公司完成人工銀行匯款後再核銷。
先把整合端點準備好
Secret 只放在你的伺服器或 Secret Manager；不要貼到教學頁、討論串、GitHub 或瀏覽器程式碼。