Stripe：一個協調層，而非平台

在 localhost，Rami Banna，Stripe 負責 Ecosystems、Apps 和 Stripe Projects 的產品負責人，介紹了 Stripe Projects，這是一款針對建置初期階段的工具：在產品還沒有使用者、還沒向任何人收費、開發者仍在為新技術堆疊連接帳號與服務的時候。

它背後的痛點與撰寫程式碼無關。設定一個新專案通常意味著在各個儀表板之間跳來跳去：建立帳號、架設服務、複製環境變數、輸入付款資訊、將所有內容貼到本機檔案中，並為堆疊所需的每個供應商重複這個過程。Stripe 將這個痛點追溯到付款：人們在第一天使用的多數 SaaS 和開發者工具，已經透過 Stripe 進行計費。這個重疊正是 Stripe Projects 所建立的基礎，讓開發者能從單一 CLI 建立帳號、佈建服務、管理環境變數，並支付升級費用。

其背後的網路目前約有 50 個供應商並持續增加，旨在作為一個開放生態系，任何人都能加入。

Stripe Projects 背後的協定運行在三個物件上：一個帳號（開發者在特定供應商的租戶、組織或團隊）、一個服務（該供應商提供的項目，其方案與價格目錄），以及一個資源（被建立並回傳憑證的具體實例）。

這三個物件支援完整的生命週期：建立或連接供應商帳號，即使原本不存在，也能使用 Stripe 自己的驗證機制來建立新帳號；拉取即時的服務目錄；佈建資源；回傳其憑證；之後輪替這些憑證；並在不再需要時移除資源。

每個供應商透過圍繞相同三個物件建置一小組端點來實作此協定：一個用於初始帳號請求，無需任何瀏覽器互動即可處理；一個用於服務請求，每十分鐘輪詢一次以保持價格與方案最新；以及一個用於資源本身，涵蓋其餘的生命週期。底層的服務 schema 足夠彈性，能夠建模用量計費、固定方案、混合計費或預付額度，因為供應商的收費方式差異很大。

在演講當時，該協定本身尚未公開。計畫是在今年夏天稍晚開放，並期望它能成為共享的標準。

佈建資源後仍會留下誰來支付的問題，而答案是一個共享的付款 token。開發者透過 Stripe Checkout 一次性輸入付款方式，Stripe 會為每個供應商分別將該憑證 token 化。每個供應商以其正常方式對自己的 token 進行計費，而開發者可以針對該共享方式為每個供應商個別設定消費上限。

其結果是在所有已連接的供應商之間，只需在單一地方輸入和檢視付款資訊，而非每個供應商各有一個，另外還有一個自然的控制點，可以限制代理程式正在消費的任何地方的支出。該層位於底層付款方式之上；目前支援銀行轉帳和先買後付。另一個推送 API 讓供應商能直接向 Stripe 回報變更，因此在供應商自家儀表板上所做的更新，仍會出現在 Stripe 這一側。

透過 Stripe Projects 建立的帳號屬於開發者，而非 Stripe。當透過 Stripe 使用 Render 基礎設施時，Render 仍是實際的服務供應商和計費關係；憑證與環境變數會留在開發者自己的專案內。Stripe Projects 只負責協調佈建本身，之後不會介入開發者與供應商之間。

從命令列佈建

從 CLI 拉出 Stripe Projects 目錄，會顯示 Render 在網路中提供的項目：Postgres、Web 服務或靜態網站。輸入 stripe projects add render 會直接顯示該目錄，接著相同的指令可以交給像 Claude 這樣的程式碼代理，它會連接公開的 GitHub 儲存庫，並直接從命令列透過 Render 進行部署。同樣的模式也能擴展到加入其他供應商，包括 OpenRouter、Exa、Clerk 和 PostHog 等，只要用自然語言詢問代理它需要什麼；它會使用相同的底層指令，將所有東西整合到一個專案中，並共用一組環境變數。

https://render.com/blog/stripe-an-orchestration-layer-not-a-platform

https://www.worldprogramming.org/posts/stripe-an-orchestration-layer-not-a-platform-av4nrm