替代方案 / Checkout
尋找託管式 checkout 替代方案
多數人尋找新的 checkout 供應商，並不是為了功能，而是因為需要的支付方式沒有支援、對帳太痛苦，或是結算出問題時沒人回應。這一頁是一份檢核清單，無論您接下來評估哪一家，包括我們，都值得拿來逐項檢視。
評估
六個問題，看出差異。
哪些支付方式能放在同一頁？
不是簡介上的數量，而是您的客戶真正會用到、並且呈現在同一頁的方式。放在重新導向之後，或需要另行整合的支付方式，最終都會被冷落。
最後收到的是什麼幣別？
如果答案因支付方式而異，您買到的就是一個對帳難題。請明確詢問加密貨幣或跨境付款，最後會以什麼幣別入帳到您的帳戶。
您需要承擔多少 PCI 範疇？
真正的託管頁面，即使嵌入您自己的版面，也能讓卡片資料遠離您的伺服器。請詢問您的系統會儲存哪些資料，以及這會讓您的評估變成什麼樣子。
是否從頭到尾只有一個參考編號？
Checkout、收據、webhook、撥款與退款，都應該帶有您提供的參考編號。若要在系統之間對應兩組識別碼，月底結算就容易出錯。
遷移實際上需要做什麼？
已儲存的卡片應以 token 形式遷移，讓訂閱用戶無須重新輸入資料；在舊供應商完成結算期間，兩家供應商也應能並行運作。
出問題時，誰來回應？
客服窗口，與撰寫結算程式碼的團隊，是兩種截然不同的產品。當撥款看起來不對勁時，這個差異就是唯一重要的事。
人們為什麼離開 checkout 供應商
很少是因為費率更低。實際上通常是四個原因之一：客戶要求的支付方式供應商不肯新增、對帳模式讓財務團隊害怕月底、支援關係在最關鍵的時刻失靈，或是支付世界不斷前進，產品藍圖卻停滯不前。找出哪一項是您的原因，就是整個評估的重點——一個在其他三項表現出色的供應商，換過去依然是錯的選擇。
- 01客戶想要、卻遲遲不會推出的支付方式
- 02每個月讓人耗費數天的對帳工作
- 03結算出問題時沒有人負責
- 04產品跟不上支付方式的演進
更換供應商的實際成本
整合的成本比團隊預期的低，但周邊事項的成本比預期的高。下單呼叫與 webhook 處理通常一週就能完成；真正需要規劃的是後續的長尾事項——不能中斷的已儲存卡片與訂閱、仍須沿舊供應商通道退回的退款，以及兩套系統同時運作的期間。任何值得更換的供應商，都應該在簽約前就能說明這些事項，而不是之後。
- 01整合：一個下單端點、一次重新導向、一個簽章 webhook
- 02長尾事項：已儲存卡片、訂閱、處理中的退款、並行運作
- 03退款一律沿原收款通道退回
Protocore Gateway 的定位
上述六個問題，我們這樣回答：卡片、錢包、銀行轉帳、本地支付方式、先買後付與 USDC 都在同一頁；一律以歐元結算；即使欄位嵌入您的版面，處理卡片的範圍仍由我們負責；從 checkout 到銀行帳單，全程使用同一個參考編號；已儲存卡片以 token 形式遷移，兩家供應商並行運作；而回答問題的人，就是撰寫這套系統的人。是否值得更換，取決於前述四個原因中哪一個是您的——如果是為了更低的費率，我們多半不是合適的選擇。
- 01所有支付方式集中一頁，以單一歐元金額結算
- 02從 checkout 到撥款再到退款，使用同一個訂單參考編號
- 03遷移規劃包含並行運作與 token
- 04背後是產品工作室，而非客服層級
FAQ
值得向任何廠商提出的問題。
可以，而且遷移期間應該這麼做。新訂單導向新供應商，舊供應商則繼續完成自己所處理付款的結算與退款——退款一律沿原收款通道退回，因此舊的整合會一直保留，直到最後一個退款期限結束。
不應該。已儲存的卡片會以 token 形式在供應商之間遷移。如果您有訂閱業務，這是最重要的一個問題——讓所有已儲存卡片失效的遷移，只會造成客戶流失，算不上遷移。
整合通常一週即可完成。真正決定時程的是周邊計畫——並行運作、token 遷移，以及舊供應商的最後一個退款期限——通常以週計，而不是以月計。
那就先請您目前的供應商給一個上線日期，再進行任何評估。為了一種支付方式而更換供應商，工程量大、收益卻有限，除非同一場對話中也暴露了上述其他三個問題。
用這份清單檢視我們。
在我們的 demo checkout 完成一筆真實付款，然後告訴我們，您目前的供應商在這六個問題中哪幾項不及格。我們會坦白告訴您，這次更換是否值得您投入這一季的時間。