SaaS / API 產品為什麼選 ReBate Pay
你的客戶用 API Key 換配額。他們要的是可預測的訂閱，加上可驗證的用量與權益。ReBate Pay 先把 Subscription、Checkout、REST API 與 Webhook 接好，Credits / Entitlement 與多 Provider 依真實狀態標示。
因為 API 產品的收費失敗，會直接讓 Key 失效或超賣額度。
必須講清楚的差異化
- Subscription 訂閱
- Credits / 用量
- Entitlement 權益
- API / Webhook
- 多 Provider 方向
- AI / MCP
這個客群在痛什麼
- 1
席次、方案與用量混在一起
月費、呼叫次數、超額加購若沒有同一帳本，對帳與客服會同時爆炸。
- 2
付款成功卻沒開通 API 權限
沒有可靠 Webhook 與 Entitlement 查詢，Provisioning 只能人工或輪詢。
- 3
自己接金流後難以換通道
Checkout 與對帳寫死在單一系統，之後換通道就要重做。
SaaS / API：Checkout、Webhook 與 Key 開通
現在自己處理的成本與風險
Billing bug 等於產品事故
扣錯、重複扣或沒開通，開發者客戶會立刻取消並公開客訴。
PCI 與卡號處理成本
自建結帳頁要把合規、3DS 與失敗重試一次扛下。
對帳與退款沒有單一真相
API 日誌、錢包與金流後台三套數字，財務無法月底結帳。
ReBate Pay 怎麼解
Subscription + Hosted Checkout 先收得到錢
方案、價格、結帳與續約同一套，給開發者客戶可分享的 Checkout。
API / Webhook 驅動開通
付款與訂閱事件推到你的後端，再開 API Key 或調額度。
Credits / Entitlement 作為用量方向
呼叫次數與功能權益仍在開發中。
收款統一由 ReBate Pay 處理
進件與金流開通納入價值鏈；尚未開放 的 Partner API 清楚標示。
典型 Billing 流程
從進件到撥款 — 依實際可用性標示。
商家進件 / 金流開通
工作區完成金流開通，取得收款能力。
Product / Price：方案與用量包
定義月費、年費與未來 Credits 包，避免兩套目錄。
Checkout → Subscription
開發者客戶完成付款，建立訂閱與顧客。
Webhook 開通 API 權限
subscription.created / invoice.paid 觸發 Key 發放或額度更新。
Refund / 對帳
退款回寫交易；對帳能力依金流服務進度提供。
Payout / 多 Provider API
撥款與路由是方向。目前以 REST API 與 Webhook 為可用整合面。
價值鏈對位
- 1開發中
商家進件 / 金流開通
完成金流開通與 ReBate Pay 審核即可收款。
- 2
Product / Price
方案、價格與計費週期在同一目錄。
- 3
Checkout
託管結帳頁完成付款。
- 4
Subscription / Payment
訂閱與付款紀錄寫入 Dashboard。
- 5開發中
Refund / 對帳
退款可追蹤；正式 Provider 對帳依 API 進度。
- 6開發中
Payout / API
撥款與路由開發中，不宣稱已上線。
可用／開發中邊界
還在開發中的能力，不會寫成正式上線。
可用：訂閱、Checkout、開發者 API、Webhook 簽章
可走完整收款與事件流程。
開發中：Credits、Entitlement
可規劃產品，不可對外宣稱已正式計量上線。
開發中：自動撥款與多通道路由
撥款自動化與第二金流仍在開發中。
相關整合
來自 Integration config，含金流、Webhook、API 與 MCP。