Stripe Connect封了我的賬戶

Stripe Connect賬戶被封時，我正盯著剛寫好的Supabase RLS策略。平臺已經能跑通，創作者可以標記付費內容塊，用戶購買后自動解鎖——然后那封郵件來了："Your account has been closed."

從凍結到解封，實際耗時不到24小時。但這個過程暴露了一個被大多數教程忽略的事實：Stripe Connect的審核邏輯和Standard賬戶完全不同，而官方文檔幾乎沒提邊界情況。

為什么你的SaaS教程幫不上忙

市面上90%的Stripe教程都在講訂閱收款。你自己收錢，用戶按月付費，風控模型簡單直接。

但當你要讓平臺上的創作者直接收款——比如我建的Lovai，用戶可以把帖子拆成付費塊賣——整個資金流轉就變了。你不是商戶，是資金聚合方（aggregation）。這個詞在Stripe內部觸發一套完全不同的審查流程。

Connect有三種賬戶類型。Standard讓商戶自己管Stripe后臺，Custom要你自建KYC流程，Express是Stripe托管 onboarding。我選Express的唯一原因：身份驗證和銀行綁定全外包， solo開發者能省幾周工作量。

代碼層面很簡單。創建賬戶時指定國家、能力（收卡+轉賬）、主體類型，拿到account_id后丟給前端跳轉Stripe的托管頁面。用戶填完資料，webhook通知你狀態變更，完事。

但代碼跑通只是第一步。審核團隊看的是另一套東西。

被封的真正原因：一個未完成的申請

收到關閉郵件后，我第一反應是檢查業務模型描述。Lovai的模式是"創作者市場"，用戶賣自己的內容碎片——這算平臺還是聚合？Stripe的政策對聚合（aggregation）有額外限制，需要更多合規文件。

我發了封長郵件解釋：資金直接打到創作者賬戶，平臺只抽成，不觸碰資金池。附上了產品截圖、用戶流程圖、甚至畫了張資金流轉示意圖。

回復來得很快，但內容出乎意料。問題根本不在業務模型，而是"Connect application had not been fully submitted at the time of review"。審核觸發時，我的申請 technically 還沒填完。

這個細節官方文檔不會寫。Express onboarding是托管的，但后臺還有個獨立的"Connect application"需要提交——包括業務描述、預計交易量、退款政策鏈接。我以為用戶填完KYC就完事了，結果平臺端的申請還懸在半空。

補完表格，重新提交，第二天賬戶恢復。整個來回不到24小時，但如果沒有那封解釋郵件，我可能會在錯誤方向上繞很久。

三個被審核團隊卡住的細節

解封后我復盤了所有溝通記錄，發現Stripe審查員在三個地方用放大鏡看：

披露頁面的標題格式必須法定。我的頁面叫"Payment Terms"，被要求改成特定表述。不是內容問題，是字面匹配。

賣家名稱和責任人必須與Stripe注冊完全一致。我注冊時用了英文名，披露頁寫了日文漢字名——被 flagged。審核員的原話是"small details, but they'll hold up your review"。

資金流轉的透明性。雖然這次不是主因，但我附上的流程圖確實加速了溝通。創作者收款、平臺抽成、Stripe手續費的拆分路徑，一目了然比文字描述有效得多。

這些不是技術問題，是合規操作的顆粒度。大多數開發者卡在代碼能跑就上線，但Connect的審核發生在代碼之后。

我的支付流怎么設計的

技術實現上，Lovai用的是destination charges模式。用戶付款時，資金直接路由到創作者的Connect賬戶，平臺手續費在路由前扣除。

具體流程：前端創建PaymentIntent，指定on_behalf_of為創作者賬戶，transfer_data.destination指向同一賬戶，application_fee_amount填平臺抽成。用戶綁卡支付后，webhook監聽checkout.session.completed，觸發Supabase的RLS策略更新，解鎖對應內容塊。

這個模式的好處是創作者看到干凈的流水，平臺收入單獨入賬。缺點是每筆交易產生兩次Stripe手續費——但Express賬戶的定價已經考慮了這層。

Supabase RLS在這里做權限守門。付費內容塊存儲時帶access_tier字段，行級策略檢查當前用戶是否在purchases表有對應記錄。沒有就返回空，有就返回解密后的內容。整套邏輯在數據庫層完成，應用代碼不碰權限判斷。

Webhook處理有個坑：Stripe的測試環境和生產環境事件結構有細微差別。我在staging調試時一切正常，上線后才發現livemode的account對象嵌套層級不同。建議直接用Stripe CLI的listen轉發本地，別依賴dashboard的測試事件。

現在賬戶正常運行，創作者可以 onboard、綁卡、收款。但那次24小時的凍結讓我改了一個習慣：任何支付相關的功能，先完整走一遍審核團隊的 checklist，再寫代碼。