讀完這一章，你會知道如何用 Lovable 做出真正可營收的產品整合。你會以 Paddle 作為台灣讀者的金流主線，理解 Merchant of Record、test mode、live mode、go-live checklist、產品與價格同步、訂閱權益、customer portal、退款與取消情境。接著你會把同一套整合思維套到 Resend Email、Lovable AI、Google Maps、Slack、Notion、Airtable 和其他 API。
這章不是 connector 大補帖。真正重要的是一個可重複的模式：
事件發生
-> 後端處理
-> 外部服務呼叫
-> 本地資料更新
-> 使用者權益或通知改變
-> 測試與監控
只要你掌握這個模式，金流、Email、AI、Maps、Slack、Notion、Airtable 都只是不同服務套進同一個架構。
前面幾章已經把 LaunchNote 做成一個有首頁、資料庫、登入、權限和 dashboard（儀表板） 的 SaaS prototype（原型）。可是產品要真的運作，通常還需要第三方整合：
這些整合會把 prototype（原型）推向真實產品，也會把風險推高。
金流會碰到稅務、退款、訂閱狀態、權益解鎖和 customer support。Email 會碰到寄件網域、退信、投遞率和使用者通知。AI 會碰到成本、速率限制、資料外洩和回應品質。外部 API 會碰到 token、scope、rate limit、權限和錯誤重試。
Lovable 可以大幅降低 wiring 的成本，但你仍然要設計產品規則。
Lovable 的 payments 文件提到，內建 payments 可用不同 provider。對本書讀者，我們把主線固定為 Paddle。
原因很務實：台灣開發者做全球 SaaS、數位產品、會員內容、模板、工具型網站時，Paddle 的 Merchant of Record 模式比較適合書中的教學主線。Paddle 作為 Merchant of Record，會處理付款、稅務合規、發票或收據、部分 billing 與 payout 流程。你收到的是扣除費用後的 payout，而不是自己直接成為每筆交易的主要商家。
這不代表你永遠不能使用其他 provider。它只代表本書要給台灣讀者一條最清楚、最少分岔的路。
所以本章規則是：
金流教學主線：Paddle
其他服務商：不作為本書主要實作路線
如果你在 Lovable 介面看到其他選項，請不要在這本書的案例裡混用。Lovable 文件也提醒：一個 project（專案）同一時間只能使用一個 built-in payment provider。切換 provider 會中斷既有 catalog、webhook（事件回呼）、customer ID 和訂閱資料脈絡，不適合當成一般迭代操作。
很多人做 SaaS 金流時，會先想 pricing page 和 checkout（結帳） button。這是錯的起點。
付款真正要解決的是：
誰付了錢
-> 付了哪個方案
-> 現在狀態是有效、試用中、逾期未付、已取消或其他狀態
-> 應該解鎖哪些功能
-> 何時失去權益
-> 使用者如何管理訂閱
所以付款系統不是 checkout（結帳）。付款系統是 entitlement（權益）system。
對 LaunchNote 來說，方案可能是：
免費版：
- 1 個專案
- 10 筆已發布項目
- LaunchNote 品牌標示
Pro 方案：
- 5 個專案
- 不限項目數量
- 自訂網域
- AI 摘要
- 團隊成員
團隊：
- 不限專案數量
- 進階角色
- Slack 通知
- 優先支援
你的 app 要根據 subscription state 判斷權益，而不是只在付款成功當下做一次 unlock。
開始本章前，請先確認：
Lovable payments 文件也提醒：如果 project（專案）使用 external Supabase connection，built-in payments 目前不適用。這代表第 9 章若你使用自己的 Supabase project（專案），第 11 章的 Lovable built-in payments 路線需要改成 Lovable Cloud project（專案），或改用自建金流整合。這是重要架構決策，不要等到最後才發現。
不要先說：
請新增付款功能。
你要先描述商業模型。
請規劃 LaunchNote 的 Paddle 付款模型。
產品：
LaunchNote 是讓小型軟體團隊發布公開更新日誌頁面的 SaaS。
請使用 Paddle 作為金流服務商。
方案：
- 免費版：1 個專案、10 筆已發布項目、LaunchNote 品牌標示。
- Pro：每月 19 美元、5 個專案、不限項目數量、自訂網域、AI 摘要。
- 團隊版：每月 49 美元、不限專案數量、團隊成員、Slack 通知。
規則：
- 購買紀錄必須連結到已驗證的使用者。
- 使用者可以從客戶入口網站管理訂閱。
- 訂閱狀態為 active 或 trialing 時，開放付費功能。
- 訂閱狀態為 past_due 時，顯示帳務警告，但不要立即刪除資料。
- 訂閱狀態為 canceled 時，保留存取權限直到已付費週期結束。
請提出：
- 價格方案頁結構。
- 訂閱和權益狀態所需的資料庫欄位。
- free、active、trialing、past_due 和 canceled 的使用者介面狀態。
- 正式上線前的測試情境。
先不要實作。
這個提示詞的重點是把金流設計成狀態機。
當 pricing 和 entitlement（權益）plan 確認後，再請 Lovable 啟用 payments：
請為 LaunchNote 新增 Paddle 付款功能。
需求：
- 使用 Paddle 作為金流服務商。
- 建立價格方案頁，包含免費版、Pro 和團隊版方案。
- Pro 每月 19 美元。
- 團隊版每月 49 美元。
- 為 Pro 和團隊版新增結帳功能。
- 把購買紀錄連結到已驗證的使用者。
- 在應用程式資料庫儲存訂閱狀態和方案權益。
- 在儀表板新增帳務頁面。
- 新增「管理訂閱」按鈕，點擊後開啟客戶入口網站。
不要建立任何其他金流服務商整合。
請先顯示設定步驟和帳號驗證要求。
Lovable 的 payments setup 會包含：
Paddle setup 表單會需要 email、legal name、project（專案）name / business name、acceptable use policy 同意等資訊。若 email 已註冊 Paddle，Lovable 文件建議可以使用 plus alias，例如 yourname+lovable@gmail.com。
圖 11-1：Preview 頂端明確標示 payments 正在 test mode；定價卡只是入口，仍要驗證 checkout、付款成功、失敗、取消與 entitlement 生命週期。
Lovable payments 的 test mode 會在 preview（預覽） 裡運作。Checkout（結帳） 只接受測試卡，不會真的扣款。Live mode 則是 published app，用真卡收真錢。
測試不能只測「付款成功」。你要測 subscription lifecycle。
最低測試清單：
請測試 LaunchNote 的付款情境。
情境：
- 成功購買 Pro 訂閱。
- 成功購買團隊版訂閱。
- 付款失敗。
- 需要 3D Secure 驗證的付款。
- 如有啟用試用期，測試 trialing 狀態。
- 從 Pro 升級到團隊版。
- 從團隊版降級到 Pro。
- 取消訂閱。
- 續訂款項逾期未付。
- 客戶入口網站在獨立瀏覽器分頁開啟。
請驗證：
- 儲存了正確的方案。
- 解鎖了正確的功能。
- 儀表板顯示正確的帳務狀態。
- 使用者取消訂閱後，在已付費週期結束前仍保有存取權限。
- 付款失敗時顯示清楚的帳務警告。
- 公開更新日誌仍可正常運作。
Lovable 文件提到 customer portal 會開在新 browser tab，不能嵌在 iframe 裡，也不能在 Lovable preview（預覽） panel 裡完整測。測試時要用 standalone browser tab。
付費權益不能只靠前端判斷。你需要在 database 裡保存 subscription 和 plan 狀態，並讓後端或 RLS（Row Level Security，列層級安全） 能用它判斷功能。
常見資料模型：
subscriptions
- id
- user_id
- provider
- provider_customer_id
- provider_subscription_id
- plan_key
- status
- current_period_start
- current_period_end
- cancel_at_period_end
- created_at
- updated_at
entitlements
- id
- user_id
- plan_key
- max_projects
- max_team_members
- allow_custom_domain
- allow_ai_summary
- allow_slack_notifications
- updated_at
不一定每個產品都需要獨立 entitlements table，但你一定要有一個明確的 entitlement（權益）source of truth。
提示詞：
請檢查並實作訂閱權益儲存機制。
需求：
- 儲存每位使用者目前的方案和訂閱狀態。
- 追蹤服務商 Customer ID 和 Subscription ID。
- 追蹤目前帳務週期的結束時間。
- 把 active 和 trialing 視為付費存取權限。
- 把 past_due 視為受限存取，並顯示帳務警告。
- canceled 狀態在 current_period_end 前仍保有存取權限。
- 訂閱變更時不要刪除使用者資料。
請新增共用邏輯，讓功能門檻可以一致檢查權益。
套用前，請先顯示資料庫變更。
不要在每個元件裡散落 if plan === "pro"。請 Lovable 幫你集中 feature gate 邏輯。
Paddle go-live 不是「按 publish 就好」。Lovable 文件提到 Paddle 會有 readiness check、project（專案）setup、verification、domain review 和 approval。
Readiness check 會看：
Seller verification 會收集產品資訊、compliance screening questions、個人或公司資料。審核時間可能一天內，也可能數天，Paddle 可能用 email 或 dashboard（儀表板） 要求補資料。
要使用 Paddle 正式收款，必須先完成 seller verification。以我這次申請的經驗，驗證大致分成兩個階段：
第一階段的身分證件相對直接，真正卡住我的是第二階段的地址驗證。只提供有地址的文件不一定足夠；我最後是使用水電繳費單，而且繳費單上必須同時顯示我的姓名與有效地址。
當時台電繳費單上的姓名不是我的名字，因此文件一直無法通過。我特地到台電更新繳費單上的姓名，取得姓名與申請資料一致的新文件後，才終於完成驗證。
如果你也準備申請 Paddle，建議提前確認：
不要等到產品準備上線才處理這些文件。地址文件需要更名或重新開立時，可能會讓正式收款時程往後延。
上線提示詞：
請準備讓 LaunchNote 的 Paddle 金流正式上線。
檢查清單：
- 新增隱私權政策頁面。
- 新增服務條款頁面。
- 新增退款政策頁面。
- 確認價格方案頁已發布且內容正確。
- 在 Paddle 驗證完成前，確認正式環境的結帳按鈕已隱藏或停用。
- 確認網站內容清楚說明產品。
- 確認自訂網域已連接。
- 執行付款準備狀態檢查。
變更正式付款設定前，請先回報所有缺少的項目。
如果 verification 還沒完成，你可以：
對讀者來說，最穩妥的做法是：先把產品頁、法務頁和 checkout（結帳） flow 都準備好，再送審。
金流不是成功付款才需要 UI（使用者介面）。你還要設計邊界狀態。
請設計 LaunchNote 的帳務狀態。
狀態：
- 免費版
- 試用中
- 有效
- 逾期未付
- 已取消但仍在付費週期內
- 已到期
針對每個狀態，請定義：
- 儀表板橫幅文案。
- 啟用哪些功能。
- 顯示哪個行動呼籲。
- 資料是否仍可存取。
- 是否允許發布新項目。
使用者取消訂閱但仍有已付費時間時，不要立即撤銷存取權限。
常見原則：
Lovable 可以幫你做 UI（使用者介面）和狀態判斷，但你要決定商業規則。
金流完成後，通常要寄 email：
Lovable 的 Resend connector 是 workspace（工作區）-level connection，使用你自己的 Resend account 和 API key（API 金鑰）。Workspace（工作區） admins 和 owners 可以建立 connection。Resend usage 和 billing 由 Resend 帳號負責。
先寫 email plan：
請規劃 LaunchNote 使用 Resend 發送的交易型信件。
信件事件：
- 歡迎新使用者。
- 團隊邀請。
- 更新日誌項目已發布。
- 訂閱已啟用。
- 付款失敗警告。
- 試用期即將結束提醒。
針對每封信，請提出：
- 觸發事件。
- 收件者。
- 主旨。
- 所需資料。
- 必須立即發送，或可以延後發送。
- 失敗處理方式。
先不要實作。
實作提示詞：
請把 LaunchNote 信件工作流程連接到 Resend。
需求：
- 使用既有的 Resend 工作區連線。
- 註冊後寄送歡迎信。
- 管理員邀請成員時寄送團隊邀請信。
- 向專案成員寄送更新日誌發布通知信。
- 訂閱變成 past_due 時寄送帳務警告信。
安全：
- 不要在前端程式碼暴露 Resend API Key。
- 信件必須從後端邏輯發送。
可靠性：
- 記錄信件發送成功和失敗。
- 信件發送失敗時，在儀表板顯示不阻斷流程的警告。
Production（正式上線） 前要確認：
圖 11-2：AI 功能應透過 Cloud backend 或 Edge Function 執行，讓 API key、成本控制、錯誤處理與結果保存留在伺服器端。
Lovable 的 built-in AI connector 可以讓 app 使用 AI features，不需要你自己建立 provider API key（API 金鑰）。AI calls 透過 secure backend（後端）edge function 執行，不直接從 browser 呼叫。每個 project（專案）會有 Lovable-managed API key（API 金鑰），AI activity 可在 Cloud → AI 監控。
這很方便，但仍然要設計產品規則。
LaunchNote 可以加的 AI 功能：
AI feature plan：
請規劃 LaunchNote 的 AI 功能。
請使用 Lovable 內建 AI Connector。
功能：
- 為更新日誌項目產生簡短摘要。
- 把技術說明改寫成使用者容易理解的繁體中文。
- 把項目分類為功能、改善、修正或安全性。
針對每個功能，請定義：
- 使用者輸入。
- AI 輸出。
- 輸出儲存位置。
- 使用者能否在發布前編輯。
- 模型選擇假設。
- 成本和速率限制風險。
- 失敗狀態。
先不要實作。
實作提示詞：
請為更新日誌項目新增 AI 摘要產生功能。
需求：
- 使用 Lovable 內建 AI Connector。
- AI 呼叫必須透過後端邏輯執行，不能直接從瀏覽器呼叫。
- 根據項目內容產生精簡的繁體中文摘要。
- 儲存前，讓使用者審查並編輯摘要。
- 把最終摘要儲存到資料庫。
- 顯示載入、成功和失敗狀態。
- AI 使用量回傳 402 或 429 時，顯示清楚的錯誤，並讓使用者繼續手動操作。
不要在使用者審查前自動發布 AI 產生的文字。
注意兩個錯誤碼：
402 Payment Required: workspace（工作區）credits 不足。429 Too Many Requests: rate limit。AI 失敗時，產品不能卡死。使用者應該仍可手動編輯內容。
Google Maps、Slack、Notion、Airtable 這些 connector 看起來不同，其實共同問題很像：
Google Maps Platform connector 適合 geocoding、routes、places、interactive maps。文件裡描述 two-key model：
Managed by Lovable 適合 prototype（原型），但不是 production（正式上線）。使用 custom domain 或正式上線時，要改用 own credentials，並在 Google Cloud 管理 billing、API enablement 和 key restrictions。
提示詞：
請在公開網站新增門市位置地圖。
請使用 Google Maps Platform。
需求：
- 地址搜尋使用 Places Autocomplete。
- 在互動式地圖上顯示位置。
- 透過 Connector Gateway 執行伺服器端地理編碼。
- 不要直接從瀏覽器呼叫私人伺服器 API。
- 如果要使用自訂網域正式上線，請提醒我使用自己的 Google Maps 憑證和參照網址限制。
Slack connector 適合送通知、讀 channel、產生 digest。Bot connection 通常是推薦路線，private channel 需要先 invite bot。
提示詞：
請為 LaunchNote 新增 Slack 通知。
當更新日誌項目發布時：
- 向設定好的 Slack 頻道發送結構化訊息。
- 包含標題、摘要、作者和公開 URL。
- 使用 Bot 連線。
- 記錄成功和失敗。
- 如果是私人頻道，請提醒我邀請 Lovable Bot。
Slack 通知失敗時，不要阻擋發布。
不要讓 Slack 失敗阻止核心產品流程。通知失敗可以重試或提示，但 changelog publish 應該已經完成。
Notion app connector 讓你的 deployed app 在 runtime 讀寫 Notion pages 和 databases。它和 Notion chat connector 不同，後者是讓 Lovable Agent 建置時讀 Notion 文件。
Notion permission 是 opt-in。Integration 只能看到被明確 share 的 pages 和 databases。
提示詞：
請使用 Notion 作為 LaunchNote 說明文章的內容來源。
需求：
- 從名為「Help Center」的共用 Notion 資料庫讀取文章。
- 依 slug 呈現公開文章頁面。
- 支援分類篩選。
- 使用快取或處理載入狀態，避免 Notion 回應緩慢時公開網站一片空白。
- Notion 內容無法取得時，顯示友善的錯誤訊息。
不要把 Notion 當作帳務或訂閱資料的唯一依據。
Airtable connector 使用 Personal Access Token。PAT 的 scopes 和 base access 決定 app 能做什麼。這很適合把 Airtable 當 source of truth，再用 Lovable 做 custom UI（使用者介面）。
提示詞：
請使用 Airtable 作為輕量 CRM 儀表板的資料依據。
需求：
- 從名為「Sales CRM」的 Airtable Base 讀取聯絡人和交易資料。
- 讓內部使用者更新交易狀態。
- 只要求儀表板需要的欄位。
- 妥善處理 Airtable 速率限制。
- 清楚顯示同步錯誤。
安全：
- 使用既有 Airtable Connector。
- 不要在前端程式碼暴露 Personal Access Token。
- Token 的權限範圍應限制在必要的最少 Base 和操作。
圖 11-3：Connector 連線與工具權限要分開管理；對會寫資料、設定 auth 或使用 secret 的動作，應依風險選擇逐次核准。
Lovable integrations 文件把整合分成三類：
App Connectors = 已部署應用程式執行時會呼叫的能力
Chat Connectors = Lovable Agent 建置時讀取上下文
Any API = 自訂或第三方 API
這三者不要混淆。
如果你的 app 要在使用者操作時送 Slack message，這是 App connector。
如果你要讓 Lovable Agent 在建置時讀你的 Notion product spec，這是 Chat connector。
如果某個服務沒有正式 connector，但提供 HTTP API，你可以用 Any API pattern：把 key 放 Secrets，建立 Edge Function，從 frontend（前端）呼叫 Edge Function。
Any API 提示詞：
請使用後端函式整合這個外部 API。
API 用途：
結帳時驗證 VAT 號碼。
需求：
- 把 API Key 儲存在 Secrets。
- 建立呼叫外部 API 的 Edge Function。
- 前端呼叫 Edge Function，不直接呼叫外部 API。
- 呼叫 API 前先驗證輸入。
- 處理逾時、無效回應和速率限制錯誤。
- 記錄失敗，但不要暴露私人資料。
不要把 API Key 放進前端程式碼或 VITE 變數。
這個 pattern 可以用在大多數沒有內建 connector 的服務。
請為 LaunchNote 規劃 Paddle 金流。
請使用 Paddle 作為金流服務商。
方案：
- 免費版：1 個專案、10 筆已發布項目。
- Pro：每月 19 美元、5 個專案、不限項目數量、自訂網域、AI 摘要。
- 團隊版：每月 49 美元、不限專案數量、團隊成員、Slack 通知。
請提出：
- 價格方案頁配置。
- 產品與價格設定。
- 訂閱狀態。
- 權益規則。
- 資料庫欄位。
- 測試情境。
- 正式上線檢查清單。
先不要實作。
為什麼有效：
請為 LaunchNote 新增 Paddle 付款功能。
需求：
- 只使用 Paddle。
- 建立 Pro 和團隊版月繳訂閱。
- 把購買紀錄綁定已登入使用者。
- 儲存訂閱狀態與方案權益。
- 新增帳務頁面。
- 新增客戶入口網站按鈕。
- 為 active、trialing、past_due、canceled 和 expired 狀態新增儀表板橫幅。
不要加入其他金流服務商。
正式上線前，請先顯示設定和驗證步驟。
為什麼有效：
請使用 Resend 新增交易型信件。
事件：
- 註冊後寄送歡迎信。
- 團隊邀請。
- 更新日誌發布通知。
- 付款失敗警告。
需求：
- 使用後端邏輯發送。
- 使用既有 Resend 連線。
- 不要在前端程式碼暴露 API Key。
- 記錄成功和失敗。
- 信件發送失敗時，不要阻擋核心操作。
為什麼有效：
請為更新日誌項目新增 AI 摘要產生功能。
需求：
- 使用 Lovable 內建 AI Connector。
- AI 呼叫必須透過後端邏輯。
- 根據項目內容產生繁體中文摘要。
- 儲存前，讓使用者檢查並編輯。
- 儲存最終摘要。
- 處理 402 和 429 錯誤。
- 如果 AI 失敗，仍保留手動編輯功能。
不要自動發布 AI 產生的文字。
為什麼有效：
請安全整合一個外部 API。
API：
[描述服務與端點]
需求：
- 把憑證儲存在 Secrets。
- 建立用於伺服器端呼叫的 Edge Function。
- 呼叫 API 前先驗證輸入。
- 處理逾時、速率限制與無效回應。
- 向前端回傳結構化錯誤。
- 記錄失敗，但不要暴露 Secrets 或敏感使用者資料。
不要從瀏覽器直接呼叫這個 API。
為什麼有效：
替 LaunchNote 加上付費與兩個外部整合。
使用 Pattern 1 產生 Paddle payment plan。
預期結果：
使用 Pattern 2 實作 Paddle payments。
預期結果：
使用 Pattern 3 加上 welcome email 和 changelog published email。
預期結果：
使用 Pattern 4 加上 AI summary。
預期結果：
Checkout（結帳） 成功只是起點。你還要處理 subscription state、entitlement（權益）、customer portal、cancellation、past_due 和 refund。
本書主線是 Paddle。多 provider 會讓新手在 KYC、稅務、webhook（事件回呼）、subscription model 裡迷路。
付費流程一定要測失敗付款。真實世界不會只有 successful payment。
Lovable 文件提醒，products 和 prices 應透過 Lovable 管理。直接在 provider dashboard（儀表板） 改，可能造成 test/live ID 或 context mismatch。
任何 secret 都應該走 Secrets 與 backend（後端）function。VITE_ 變數是 browser-exposed，不是 secret。
Slack 或 Email 失敗不應該讓 changelog publish 失敗，除非那個外部服務本身就是產品核心。
AI 產生內容應該讓使用者 review。尤其是 public changelog、客服信、付款通知這類使用者可見內容。
不要太早整合金流或外部 API，如果：
整合會增加真實世界複雜度。等產品核心流程穩定後再接，通常比較省時間。
讀完本章後，建議用自己的專案情境繼續追問 Lovable 或本書作者：
嗨！我是 Wolke，曾任 Google Developer Expert（GDE，2019–2023） 與 LINE API Expert。我熱衷於研究 AI Agent、n8n 自動化工作流及全端開發架構，致力於將 AI 技術轉化為實際的生產力工具。
如果你喜歡這篇文章，歡迎透過以下方式與我交流，獲取更多技術實戰內容：
📚 技術著作：《實用的 Gemini API 開發點子書》，帶你運用 Gemini App、Google AI Studio、Gemini CLI 與 Antigravity IDE，打造 AI Agent 與實用產品。
📝 技術部落格：歡迎追蹤我的 Medium，我會持續分享 Agentic Automation、架構設計與實際開發的踩坑心得。
🎤 技術講座：我持續受邀至技術社群及研討會，分享 AI Agent、自動化工作流、DevOps 與全端開發實戰。曾於 2026 年 6 月 26 日的 DevOpsDays Taipei 2026 主講「不再只是寫腳本！讓 AI 代理人成為你的 SRE 最佳夥伴」工作坊。
如果你的企業、社群或學校正在尋找相關主題講者，歡迎私訊與我聯繫、洽談講座合作！
🎁 免費送 Lovable 額度給讀者！
我每個月會開放 10 個名額，每人 50 點 Lovable 額度，讓大家實際動手打造自己的網站或 App。
參加方式：
確認後，我會邀請你加入 Lovable workspace 並設定 50 點額度。名額有限，送完為止！
iThome鐵人賽
看影片追技術