WhatsApp Embedded Signup 完成後點驗收：後端核對清單
WhatsApp Embedded Signup 視窗顯示完成，只代表前端流程到達終點，並不代表租戶已經可用。後端仍須關聯今次 session、驗證 token、配對正確的 WhatsApp Business Account（WABA）、確認系統用戶權限與號碼路徑、訂閱 WABA，並讓一個真實 webhook 通過租戶路由與驗證。每項都應是獨立驗收關卡。
重點
FINISH_WHATSAPP_BUSINESS_APP_ONBOARDING代表 Coexistence 視窗完成，不代表後端整合全部成功。- Meta 官方 Embedded Signup collection 要求繼續取得共享 WABA、管理系統用戶、按適用路徑註冊號碼，以及訂閱 WABA webhook。
- 不可假設清單第一個 WABA 就是目標；必須與今次租戶及商業資產準確配對。
- 信用額度綁定只適用於 partner-paid 模式，並非所有整合的共同要求。
- 真正可用的訊號，是一個事件進入正確租戶並完成驗證、去重及回應。
Embedded Signup 完成後的驗收清單
Meta 的官方 Embedded Signup collection將瀏覽器流程與 Graph API 後續工作分開：取得共享 WABA、加入或核對系統用戶、註冊號碼、訂閱 app，以及在合作夥伴承擔帳單時共享信用額度。
這與現有的 Embedded Signup v4 遷移清單不同。遷移文章處理啟動設定與保留 Coexistence；本文由完成事件之後開始，定義後端顯示「已連接」前所需證據。
| 關卡 | 要保存的證據 | 失敗風險 |
|---|---|---|
| Session 關聯 | 租戶 ID、一次性 state、configuration ID、時間 | 結果可能綁到錯誤租戶 |
| Token 驗證 | app、scope、到期資料 | token 存在但無權管理 WABA |
| WABA 配對 | 符合商業情境的 WABA ID | 第一項可能屬於另一客戶 |
| 系統用戶 | system user 及必要 task | 視窗完成但 Graph API 失敗 |
| 號碼就緒 | phone-number ID 與註冊或 Coexistence 狀態 | 資產存在但訊息未就緒 |
| App 訂閱 | WABA 出現在 subscribed_apps | Meta 收到訊息但 webhook 不投遞 |
| 真實投遞 | 事件、租戶路由、驗證及回應 | 只有設定，沒有端到端證據 |
依次完成驗收關卡
1. 由伺服器 session 關聯前端結果
開啟 Meta 視窗前，由伺服器建立一次性 session，記錄租戶、操作者、configuration ID 及整合路徑。完成結果只接受一次；state 過期或不一致便拒絕。Token 不應進入瀏覽器 log、analytics 或 error report。
Coexistence 應記錄官方 FINISH_WHATSAPP_BUSINESS_APP_ONBOARDING event。其他 Embedded Signup 路徑按當前官方完成 contract 處理，不要單靠顯示文字或一個版本值分流。
2. 先驗證 token，再使用 asset ID
用 Meta token debugging 確認 token 屬於你的 app，並含有所需權限。非空 token 不等於授權成功。伺服器只保存 audit 與 renewal 所需最少資料，不把 token 原文寫入 log。
3. 準確配對目標 WABA
取得 business 可存取的 shared/client WABA，再以今次 session 的商業情境配對準確 WABA ID。多租戶系統不可依賴 array order。沒有精確配對時，保留 verification_required，不要靜默連接其他 asset。
4. 核對系統用戶及號碼路徑
官方 collection 提供 GET /{waba-id}/assigned_users 驗證目標 system user，亦要確認後端所需 task。標準 Cloud API 可能要註冊號碼；Coexistence 使用已連接 WhatsApp Business app 的號碼，應驗證目前狀態而非再次註冊。是否需要此雙介面模式，可參考 Coexistence 決策指南。
5. 訂閱 WABA 並證明真實投遞
以伺服器 credential 呼叫 POST /{waba-id}/subscribed_apps，然後再次讀取驗證。訂閱與號碼狀態要分開保存，因為兩者可獨立成功或失敗。
最後用受控測試訊息，讓真實 webhook 完成租戶 lookup、payload 驗證、去重及回應。如接收端使用 UnifyPort，可按 webhook 投遞及簽名驗證核對 raw body、X-Device-Timestamp、X-Device-Signature 與 endpoint 的 signing_secret。
UnifyPort 的承接範圍
UnifyPort 不會完成 Meta Embedded Signup，亦不會配置 WABA 權限、註冊 Cloud API 號碼、綁定信用額度或保留 Coexistence。需要這些官方 asset 的 Solution Partner 或 Tech Provider 應使用官方流程。
UnifyPort 的範圍較窄：連接一般 WhatsApp 帳號，把支援的 inbound message 標準化為 message.received。如真正需要的是入站 queue 而非替客戶配置 WABA，可比較三種 WhatsApp 入站路徑，再查看 WhatsApp 授權指南。
限制與取捨
此清單不能證明 Meta 商家資格、App Review、display name approval、號碼品質或 policy compliance；它們是獨立狀態。測試租戶通過亦不是所有客戶配置都能成功的證據。
非官方介面不能授予 Cloud API asset，也不能取代多租戶 SaaS 所需 Embedded Signup。相反，視窗完成亦不能證明租戶 mapping、retry、webhook receiver 或 billing boundary 正確。請把「前端完成」與「營運可用」設計成兩個狀態。
FAQ
FINISH_WHATSAPP_BUSINESS_APP_ONBOARDING 代表甚麼？
它代表 WhatsApp Business app onboarding 視窗到達官方完成狀態；後端仍須驗證 session、asset、權限、訂閱及真實投遞。
取得 Embedded Signup token 就可標示已連接嗎？
不可。仍須驗證 token，並配對準確 WABA、system user、號碼路徑及 webhook 訂閱。
每個整合都要綁定信用額度嗎？
不是。只有合作夥伴代付 Meta 帳單再向客戶結算時，才需要相關步驟。
Coexistence 號碼需要再次註冊嗎？
不需要。應驗證官方狀態與同步路徑，而不是重複標準號碼註冊。
最終驗收訊號是甚麼？
至少一個受控 webhook 進入正確租戶，並由接近 production 的 receiver 完成驗證與回應。
下一步
先按 Meta 官方 Embedded Signup collection實作關卡，再開放租戶。若只需要一般帳號入站，可評估 UnifyPort WhatsApp 授權路徑。
來源
官方來源核驗日期：2026-08-05。