比較 / Checkout
託管式 checkout vs 自建 checkout
每位線上收款的商家都得回答一次：收集卡片資料的頁面，屬於你，還是屬於你的服務商？答案決定了你的 PCI 範圍、新增支付方式的速度，以及卡組織新規上路時由誰來處理。這與其說是技術選擇，不如說是在決定團隊這一年該把時間花在哪裡。
方案對比
七個關鍵問題
Dimension
託管式 checkout
自建 checkout
PCI 範圍
極小。收集卡片資料的頁面屬於服務商，你的伺服器只會看到 token，不會接觸卡號——通常是最輕量的自我評估。
由你負責。直接處理卡片資料會讓你的系統納入範圍，隨之而來的是設計、評估與每年重新認證。
首筆付款所需時間
數天。建立訂單、導向跳轉、處理一個 webhook——多數工作在於決定付款成功後要做什麼。
數個月，而且困難在於長尾：3-D Secure、錢包付款視窗、錯誤狀態、重試，以及每種支付方式的邊緣情況。
新增支付方式
靠設定。新的支付方式隨平台推出，開啟即可；頁面自動適應，你這邊不需要發版。
每次都是一個專案——整合、認證、介面開發，以及每種方式都要長期維護的承諾。
體驗掌控度
高，但有界線：品牌、版面選項、自有網域，以及需要在你的頁面內完成付款時使用的嵌入式欄位——範圍取決於服務商開放的功能。
完全掌控。如果你的 checkout 需要做真正特殊的事，不會受制於任何人的限制。
轉換率優化
直接承襲。支付方式排序、在地化、錢包支援與重試行為，隨平台進步而改善，你不必自己做實驗。
要靠自己爭取。針對你特定的漏斗，你可以把通用頁面優化得更好——前提是你有足夠流量，也有能做好這件事的人。
持續跟上變化
服務商的事。卡組織新規、SCA 變更、瀏覽器與錢包更新，都以平台更新的方式到位。
路線圖上永遠有一項待辦——這份工作沒有盡頭，通常要等到出問題才會被排上優先順序。
實際成本
依交易計費，透明且與交易量成正比。
工程師薪資加上認證費用，在首筆付款前就要投入，之後每年持續——成本通常被低估一個數量級。
01
託管式 checkout 何時勝出
對大多數企業、大多數時候都是如此。如果支付只是你收款的方式，而不是你販售的產品，那麼 checkout 頁面就不是你的優勢所在——自行維護的代價，還以最不顯眼的方式支付：一部分工程資源被長期占用，用在卡組織新規與支付方式整合上，而不是你的產品。託管頁面還能一舉化解 PCI 問題，這正是自建最大的隱藏成本。
- 01支付是創造營收的手段，而不是產品本身
- 02你希望卡片資料完全不在範圍內，而不只是小心處理
- 03新的支付方式應該自動上線，你這邊不需要發版
- 04你的工程師把時間花在客戶購買的東西上更有價值
02
自建何時勝出
當 checkout 本身就是產品時。為他人處理支付的平台、流程特殊到託管頁面無法呈現的企業，以及交易量大到千分之幾的轉換率提升就超過支付團隊薪資的團隊——這些情況確實存在，也足以支持自建。若監管立場要求處理卡片資料的環節必須位於自身範圍內，同樣如此。低於這個規模，自建往往只是用高昂的代價，重新發現託管式 checkout 為何存在。
- 01支付就是產品——你代他人處理交易
- 02交易量夠大，邊際轉換率的收益高於團隊成本
- 03監管機關或風險委員會要求該環節位於你的範圍內
- 04你的流程確實特殊，任何託管頁面都無法呈現
03
Protocore 的定位
Protocore Gateway 是託管式的解答，常見的彈性選項已內建，不需另外購買：可在我們的網域或你的網域上運行頁面；流程需要時，把付款欄位嵌入你自己的版面；或在你的 App 中以原生方式呈現同一個 checkout。信用卡、錢包、銀行轉帳與 USDC 集中在同一頁，並以同一筆訂單編號結算為單一歐元金額。如果你真正的答案是第三種——你想當服務商，而不是商家——同一平台也提供 whitelabel 方案，通常比從零打造閘道划算。
- 01託管頁面、自有網域、嵌入式欄位或 App 內——同一套整合
- 02信用卡、錢包、轉帳與 USDC 集中於同一頁，以 EUR 結算
- 03從 checkout 到收據再到銀行明細，全程同一個訂單編號
- 04想當服務商而不是商家時，可採用 whitelabel 方案