替代方案 / White-label
尋找 white-label 支付 gateway 替代方案
White-label 的意思，會因販售者而天差地遠——有時只是在 checkout 上放一個 logo 的位置，有時是一整間由您營運的支付公司。兩者之間的差距就是價值所在，而且在 demo 中很少看得出來。以下這些問題能讓差異現形。
評估
六個問題，讓差異現形。
實際上有多少介面是屬於您的？
付款頁面、商家後台、營運主控台、電子郵件、收據，以及它們所使用的網域。任何仍帶有供應商名稱的地方，都是讓您的商家得知真正營運者是誰的地方。
是真正的多商家架構，還是單一帳戶加子帳戶？
從一開始就以多商家架構打造的平台，提供進件、分級、權限與隔離。由單一商家產品改裝而來的平台，這些只會出現在產品藍圖裡。
您能自行建立定價嗎？
依商家、支付方式、幣別、交易量級距分別設定，失敗交易還能有不同的處理方式。如果定價只是一張固定表格，你的商業模式就是供應商的，而不是你自己的。
PCI 範疇落在誰身上？
採用 SaaS 時，處理卡片資料的環節應由對方承擔，並由你的商家繼承。若部署在自己的基礎架構上，則轉由你承擔——兩種做法都合理，但你得清楚自己買的是哪一種。
能自帶收單機構嗎？
你現有的合作關係與費率，通常正是你能夠成立的原因。只能路由到自家通道的平台，是另一種、而且規模小得多的方案。
只有 SaaS，還是能部署在自己的基礎架構？
如果監理機關或風險委員會終究會要求系統部署在你的內部環境，請現在就問清楚到底可不可行，而不是等到商家資料都遷移完才發現。
你真正買的是什麼
買的不是結帳頁，而是一門你能自己營運的支付事業。這包括商家生命週期（進件、文件、分級、權限配置、既有商家的遷移）、資金面（費用建構、結算、滾動保證金、對帳、帳單）、營運面（角色、權限、稽核、佇列、追蹤），以及卡組織規範陸續生效時，讓這一切持續保持最新的工程能力。平台只要缺了其中任何一塊，就得由你自己來蓋，而這正是你原本想避開的事。
- 01完整的商家生命週期，而不只是付款頁面
- 02依照你的定價建構的費用與結算
- 03具備角色、稽核與追蹤的營運主控台
- 04由別人承擔卡組織規範與認證
太晚才得到答案的問題
既有商家資料的遷移、已儲存的卡片是否以 token 形式轉移、各種部署方式下你的 PCI 狀態會如何，以及你需要的連接器尚不存在時由誰來開發。這些在 demo 裡都看不到，卻決定了平台在第二年是否適合你，而且每一項，正派的供應商都能在你簽約前給出具體答案。
- 01既有商家資料如何轉移，以及需要多久
- 02已儲存的卡片是以 token 遷移，還是重新建立
- 03你需要的連接器由誰開發與認證
- 04各種部署方式下，你的 PCI 狀態會變成什麼
Protocore 的定位
我們的 white-label 平台這樣回答這六個問題：任何畫面上都不會出現 Protocore；從第一行程式碼起就是多商家架構，進件、分級與權限配置一應俱全；費用是建構出來的，而非固定不變；處理卡片資料的環節在 SaaS 上由我們負責，在地端部署則由你負責；你的收單機構可與我們的並行接入，新的收單機構則作為專案的一部分開發；並可部署為 SaaS、部署到你的雲端，或部署在地端。結算看起來不對時回應你的，正是寫出這套系統的團隊——我們是產品工作室，這才是「專屬支援」通常所指的誠實版本。
- 01你的品牌貫穿每個介面，包括網域
- 02原生多商家設計，完整生命週期一併包含
- 03你的收單機構、你的定價、你的部署方式
- 04掌握平台的工程師，隨時找得到人
FAQ
值得向任何廠商提出的問題。
在你的品牌與網域下提供付款頁面、商家後台與營運主控台，外加商家進件、你自己的定價與結算。只要其中任何一項仍顯示供應商名稱，或強制套用供應商的商業模式，那就只是換了品牌的結帳頁，而不是 white-label 平台。
視你所處業務與市場的要求而定——軟體供應商並非受監理的一方。多數業者使用自己的收單資格，或由他人引介的收單機構。請明確詢問供應商是否位於資金流之中，因為這會改變答案。
應該要能，而且是批次遷移，已儲存的卡片以 token 形式轉移，新舊平台並行運作，直到舊平台完成最後的結算。簽約前請先索取遷移計畫——沒做過的供應商只會抽象地描述。
除非有特定因素迫使你另作選擇，否則選 SaaS：例如監理機關、銀行或風險委員會要求系統置於你的內部環境。地端部署會把 PCI 範疇與營運負擔轉給你，這是實實在在的成本，只有在確實必要時才值得付出。