AI SaaS 為什麼現在要買 ReBate Pay
你賣的是推理、生成與 Agent 工作流。客戶要的是穩定月費，加上可對帳的 Credits 與權益控制。ReBate Pay 把 Subscription、Checkout、API / Webhook 先接上，Credits、Entitlement 與 MCP 依真實可用性標示，不把開發中的能力寫成已上線。
因為你不該同時自建訂閱狀態機、Token 對帳與金流進件。
必須講清楚的差異化
- Subscription 訂閱
- Credits / 用量
- Entitlement 權益
- API / Webhook
- 多 Provider 方向
- AI / MCP
這個客群在痛什麼
- 1
Token 成本波動，帳單對不上用量
模型單價與呼叫量每天都在變，自己拼用量報表很容易和收款紀錄脫節。
- 2
月費與 Credits 兩套帳
方案費、點數包、超額加購分開處理，客戶看不懂自己到底買了什麼。
- 3
點數用完仍繼續提供服務
沒有 Entitlement 聯動時，未付款用量會直接吃掉毛利。
AI SaaS：方案、Credits 與 API 事件
專業方案
NT$990 / 月
GPT-4 等級 · API 上限 10k/月
現在自己處理的成本與風險
工程月數被 Billing 吃掉
訂閱生命週期、失敗重試、Portal 取消 — 每多一個 edge case 就多一季維護。
用量超賣與客訴
對帳錯誤會變成退款、爭議與信任損失，不是單純的技術債。
金流開通與 Provider 綁死
自己接單一金流，之後換通道或做多 Provider 方向會重寫核心。
ReBate Pay 怎麼解
Subscription 先穩定收月費
Product / Price、Checkout、續約與取消走同一套狀態，Dashboard 與 Webhook 同步。
Credits / Usage 與 Entitlement 預留同一帳本
用量與權益仍在開發中，可先用 API 回報用量。
API、Webhook、MCP 給產品與 Agent
後端用 API / Webhook 同步訂閱；MCP Billing Tools 開發中，供 Agent 查詢與建立 Checkout。
一次進件，ReBate Pay 統一收款
商家進件與金流開通都在 ReBate Pay 完成，不必另外找其他服務。
典型 Billing 流程
從進件到撥款 — 依實際可用性標示。
商家進件 / 金流開通
建立工作區並完成金流開通。
Product / Price：方案 + Credits 包
月費方案與點數包共用目錄，Checkout 一次賣清楚。
Checkout → Subscription / Usage
客戶完成付款後建立訂閱；用量由 API 回報，Credits 扣減開發中。
Webhook / MCP 同步產品權益
subscription.created、invoice.paid 推到後端；MCP 可查詢訂閱（開發中）。
Refund / 對帳
退款與對帳都在後台追蹤。
Payout / API
撥款與多 Provider 路由是產品方向，尚未開放，不宣稱已上線。
價值鏈對位
- 1開發中
商家進件 / 金流開通
完成金流開通與 ReBate Pay 審核即可收款。
- 2
Product / Price
方案、價格與計費週期在同一目錄。
- 3
Checkout
託管結帳頁完成付款。
- 4
Subscription / Payment
訂閱與付款紀錄寫入 Dashboard。
- 5開發中
Refund / 對帳
退款可追蹤；正式 Provider 對帳依 API 進度。
- 6開發中
Payout / API
撥款與路由開發中，不宣稱已上線。
可用／開發中邊界
還在開發中的能力，不會寫成正式上線。
可用：Subscription、Checkout、Portal、API / Webhook
可走完整商家流程：開通、結帳、訂閱與 Webhook。
開發中：Credits、Entitlement、MCP、金流開通
這些能力仍在開發中。
開發中：多通道路由與自動撥款
多通道路由與自動撥款仍在開發中。