Stripe 24小時解封記：1個細節讓審核從"聚合風險"秒過

Stripe Connect 賬戶被封，24小時內解封。這不是什么"內部渠道"的功勞，而是一個被大多數開發者忽略的申請時序問題。

我在做 Lovai，一個讓創作者按塊賣內容的平臺。用戶能把帖子拆成付費片段，買家解鎖單塊內容，創作者直接收錢。這種模式下，錢不經過平臺口袋，直接進創作者賬戶——聽起來簡單，但支付架構完全是另一回事。

標準 Stripe 賬戶是給自己收錢的。一旦要把錢路由給第三方，你就進了 Connect 的地界，合規審查、法律文件、資金流設計全得重新考慮。

Express 的陷阱：省事不等于省步驟

我選了 Express 賬戶類型。原因很簡單：Stripe 包辦身份驗證和入駐流程，不用自己造 KYC 頁面， solo 開發者的福音。

代碼層面很干凈。創建賬戶、申請能力、指定國家，幾行搞定。但代碼跑通只是開始。

Stripe 現在把 Standard / Express / Custom 標記為"新集成已棄用"，現有集成繼續運行，新搭建的建議看 controller 屬性或遷移路徑。我這是存量項目，Express 還能用，但文檔里的微妙措辭值得留意。

被封前的"完成度"幻覺

賬戶被封那天，我剛配完 Supabase 的 RLS 策略（行級安全），平臺功能全就緒。郵件標題是"Your account has been closed"，正文提到"potential aggregation"——聚合風險。

這個詞在支付行業有特定含義：如果你讓用戶通過你的平臺收錢，但實質上你在做資金歸集再分發，就可能被認定為無證經營支付業務。Stripe 對此極其敏感。

我第一時間排查業務邏輯。Lovai 的錢是直連創作者，平臺只抽成，理論上不構成聚合。那問題出在哪？

關鍵細節在后續溝通中浮現：審核時，我的 Connect 申請其實沒有完全提交。Stripe 的原話是"the Connect application had not been fully submitted at the time of review"。

換句話說，審核團隊看到一個半成品狀態的賬戶，結合平臺業務模式，誤判為高風險。這不是業務邏輯問題，是申請流程的時序問題。

解封的24小時：補材料不如補狀態

我的修復動作分兩步：第一，完整闡述業務模式，明確平臺角色和資金流；第二，把申請流程走完，確保狀態為"已提交"而非"進行中"。

次日重新審核，通過。

整個過程中，Stripe 審核團隊對法律頁面的要求也值得一提。服務條款、隱私政策、賣家披露聲明必須在網站上線，且措辭要符合法定格式。我的披露頁面標題就被挑過，必須和法規要求的表述一字不差。賣家名稱、責任人信息也要和 Stripe 賬戶注冊信息完全匹配。

這些細節不涉技術，但能直接卡死審核。

支付流的完整拼圖

解封后，整個購買鏈路才算真正跑通。流程是這樣的：創作者標記付費塊 → 買家點擊購買 → Stripe 托管收銀臺 → webhook 通知平臺 → Supabase RLS 更新權限 → 買家即時解鎖內容。

Destination charges（目的地扣款）讓資金直接進創作者賬戶，平臺抽成在交易層面自動拆分。Webhook 負責狀態同步，RLS 負責訪問控制，各管一攤。

這個架構的隱性成本在于：每個創作者都是一個獨立的 Stripe 賬戶，KYC burden 由 Stripe 承擔，但平臺要管理賬戶生命周期、處理入駐失敗、應對不同國家的合規差異。Express 省了前端開發，沒省運營復雜度。

很多教程講怎么給 SaaS 加訂閱支付。但讓用戶賣自己的內容并收款，是性質不同的問題——你不再是商戶，是商戶的商戶。

這次被封又解封的經歷，核心教訓不是"怎么和 Stripe 溝通"，而是申請狀態的完整性比業務描述更重要。審核團隊看不到你后臺的宏偉藍圖，只能看到表單里的字段是否填滿。

你的 Connect 賬戶，現在真的是"已提交"狀態嗎？