添加Fazzaco到桌面

添加Fazzaco到桌面

下次可從電腦桌面直接訪問Fazzaco

立即添加
繁體中文

Exactly:支付閘道、報表與經紀商支付流程

來源: Fazzaco

Exactly 提供線上支付閘道、商戶帳戶、報表工具和批次付款服務。經紀商評估支付基礎設施時,需要弄清客戶入金如何被接收、紀錄和對帳,以及適用的付款服務如何融入自身獨立的出金控制。實際服務範圍取決於業務模式、簽約主體和獲批市場。

Exactly 支付閘道官網頁面

圖片:Exactly 官網。

支付閘道處於什麼位置

Exactly 將其閘道描述為幫助線上企業收款和查看報表的工具,官網列出了託管結帳頁和 API 整合頁面兩種方式。閘道只是支付鏈條的一部分,鏈條還可能包括商戶帳戶、收單機構、支付網路,以及經紀商自己的客戶帳簿。

比較功能前,經紀商應先繪製完整入金路徑:客戶選擇可用方式,完成必要的身分驗證並查看付款狀態;營運團隊則需要可靠的交易編號和狀態,才能將款項計入正確帳戶。客戶返回經紀商網站,本身並不能證明資金已經結算。

Exactly 官網主要面向電商商戶。這不代表所有外匯或差價合約企業均可獲批。具體主體、業務、國家和客戶群能否準入,仍須由服務方確認。

託管結帳頁與整合頁面

Exactly 的閘道頁面介紹了由支付系統營運的託管結帳頁,以及通過 API 整合的頁面。前者將客戶帶到服務方控制的支付頁面,後者讓商戶對周邊介面有更多設計空間。兩種方式都需要測試跳轉、客戶提示和返回經紀商系統的事件。

品牌外觀只是其中一項。團隊還應詢問敏感銀行卡資訊由誰收集、客戶會存取哪些域名、身分驗證失敗如何顯示,以及客戶如何返回待處理或被拒絕的交易。可用整合方式及合規範圍應與服務商和收單合作方確認。

Exactly 還提及 CMS 插件和 API 整合。經紀商不應假設面向零售商店的插件可以直接滿足交易入口網站需求;開發團隊應索取當前文件和測試環境,並明確閘道事件、CRM 編號與交易帳戶紀錄之間的對應關係。

支付方式、幣種與結算

官網列出銀行卡、數位錢包、銀行轉帳和多幣種處理能力。不同頁面使用的覆蓋數量並不完全一致,不能替代適用於特定商戶的最新清單。支援的方式、交易幣種和結算幣種可能隨國家、法人主體和審批結果變化。

上線前,應按目標市場索取逐項矩陣,明確客戶資格、最低和最高金額、費用、處理時間、結算幣種及退款規則。匯率適用方式,以及可能存在的準備金或扣留安排,也應寫入合約。

支付授權、扣款和結算應分別比較。授權成功不一定意味著資金已不可撤銷地到帳。財務團隊需要知道費用、撤銷交易和結算批次如何反映在報表中,以及資金何時可用於履行自身付款義務。

儀表板與對帳

Exactly 介紹了可配置報表、角色權限、操作追蹤和 CSV 匯出的儀表板。單筆交易視圖有助於客服調查入金問題,而結算和餘額報表服務於財務對帳。採購方應核實每類視圖包含的欄位及紀錄保存期限。

有效的對帳演練應追蹤少量測試交易,從客戶請求到閘道事件、經紀商帳簿和結算報表。測試中可包含相同金額的交易、付款被拒、撤銷和延遲狀態更新。客戶重複嘗試時,僅按金額匹配可能將入金對應到錯誤紀錄。

查看紀錄、修改配置和批准資金操作應由不同權限控制。團隊應詢問權限能否按主體或團隊設置、變更如何留痕,以及整合不可用時如何獲取報表,並在實際簽約配置中驗證。

批次付款與異常處理

Exactly 的批次付款頁面介紹了手動添加收款人、導入 CSV 和通過 REST API 連接等方式,面向多個收款人的批處理場景。但公開介紹本身並未證明經紀商可以將其用於所有客戶出金,具體用途需要在準入時確認。

批處理會改變營運風險:同一文件可能同時包含有效和無效交易,因此團隊需要逐筆狀態,而不只是整批結果。測試應確認重複請求如何識別、錯誤如何修正,以及待處理或失敗付款如何重試才不會重複付款。

處理客戶出金前,經紀商應規定身分核驗、收款目標驗證、審批權限和客戶通知。還應確認服務商的截單時間、可用付款路徑及退回款項的處理方式,並將原始出金與後續調整關聯起來。

安全、爭議與各方責任

Exactly 的閘道頁面介紹了反詐欺控制、PCI DSS 合規和 3D Secure 2。這些屬於廠商資料,並不證明每筆交易均安全,也不意味著商戶沒有合規義務。採購方應索取適用於相關主體和服務範圍的當前證明,再評估自身對支付資訊的處理責任。

身分驗證、詐欺監測和拒付爭議可能由不同參與方負責。雙方應約定誰接收爭議通知、如何收集證據、適用哪些時限,以及爭議金額如何影響商戶餘額。付款被拒時,客服也需要回答客戶,同時避免披露不必要的安全資訊。

團隊還應了解憑證如何簽發和輪換、所選儀表板角色是否支援雙重認證,以及安全事件如何通知。有關阻止詐欺或免除合規工作的宣傳,不能取代合約中的責任劃分和獨立評估。

商務與實施清單

Exactly 表示價格會按客戶情況制定。比較報價時,應覆蓋交易費、閘道費、貨幣轉換、結算時間、拒付成本、準備金、最低承諾和可能的整合或支援費用。需確認條款適用於實際簽約主體及支付方式,而不是只看一般示例。

評估領域需要向服務商確認
準入獲批業務模式、主體、國家及支付方式
整合託管或 API 流程、事件、測試及資料責任
營運交易編號、結算、撤銷及對帳
批次付款適用收款人、批次錯誤、重試與截單時間
治理安全證明、爭議處理、費用及合約責任

試點可選擇有代表性的入金,以及獲批情況下的小批次付款,逐筆追蹤客戶提示、支付狀態、經紀商帳簿和財務報表。這樣才能在擴展前,將 Exactly 的閘道和報表放到真實營運流程中,確認實際限制和各方責任。

創建
企業