Stripe Connect封了我的賬戶

Stripe Connect賬戶被封時(shí)，我正盯著剛寫好的Supabase RLS策略。平臺(tái)已經(jīng)能跑通，創(chuàng)作者可以標(biāo)記付費(fèi)內(nèi)容塊，用戶購買后自動(dòng)解鎖——然后那封郵件來了："Your account has been closed."

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

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

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

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

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

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

但代碼跑通只是第一步。審核團(tuán)隊(duì)看的是另一套東西。

被封的真正原因：一個(gè)未完成的申請

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

我發(fā)了封長郵件解釋：資金直接打到創(chuàng)作者賬戶，平臺(tái)只抽成，不觸碰資金池。附上了產(chǎn)品截圖、用戶流程圖、甚至畫了張資金流轉(zhuǎn)示意圖。

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

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

補(bǔ)完表格，重新提交，第二天賬戶恢復(fù)。整個(gè)來回不到24小時(shí)，但如果沒有那封解釋郵件，我可能會(huì)在錯(cuò)誤方向上繞很久。

三個(gè)被審核團(tuán)隊(duì)卡住的細(xì)節(jié)

解封后我復(fù)盤了所有溝通記錄，發(fā)現(xiàn)Stripe審查員在三個(gè)地方用放大鏡看：

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

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

資金流轉(zhuǎn)的透明性。雖然這次不是主因，但我附上的流程圖確實(shí)加速了溝通。創(chuàng)作者收款、平臺(tái)抽成、Stripe手續(xù)費(fèi)的拆分路徑，一目了然比文字描述有效得多。

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

我的支付流怎么設(shè)計(jì)的

技術(shù)實(shí)現(xiàn)上，Lovai用的是destination charges模式。用戶付款時(shí)，資金直接路由到創(chuàng)作者的Connect賬戶，平臺(tái)手續(xù)費(fèi)在路由前扣除。

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

這個(gè)模式的好處是創(chuàng)作者看到干凈的流水，平臺(tái)收入單獨(dú)入賬。缺點(diǎn)是每筆交易產(chǎn)生兩次Stripe手續(xù)費(fèi)——但Express賬戶的定價(jià)已經(jīng)考慮了這層。

Supabase RLS在這里做權(quán)限守門。付費(fèi)內(nèi)容塊存儲(chǔ)時(shí)帶access_tier字段，行級(jí)策略檢查當(dāng)前用戶是否在purchases表有對應(yīng)記錄。沒有就返回空，有就返回解密后的內(nèi)容。整套邏輯在數(shù)據(jù)庫層完成，應(yīng)用代碼不碰權(quán)限判斷。

Webhook處理有個(gè)坑：Stripe的測試環(huán)境和生產(chǎn)環(huán)境事件結(jié)構(gòu)有細(xì)微差別。我在staging調(diào)試時(shí)一切正常，上線后才發(fā)現(xiàn)livemode的account對象嵌套層級(jí)不同。建議直接用Stripe CLI的listen轉(zhuǎn)發(fā)本地，別依賴dashboard的測試事件。

現(xiàn)在賬戶正常運(yùn)行，創(chuàng)作者可以 onboard、綁卡、收款。但那次24小時(shí)的凍結(jié)讓我改了一個(gè)習(xí)慣：任何支付相關(guān)的功能，先完整走一遍審核團(tuán)隊(duì)的 checklist，再寫代碼。