託管收銀台（Hosted Checkout）整合
將客戶轉至由彩虹匯託管的付款頁面，並於您的伺服器接收付款結果。銀行卡資料於託管頁面輸入，而非您的網站。
適用對象： 希望接受銀行卡及電子錢包付款，而無須自行建立付款表格的商戶。
- 1
取得測試環境使用權限
測試環境憑證會於開戶期間發出。測試環境模擬交易處理，讓您在不涉及真實資金的情況下進行開發及測試。憑證只應儲存於您的伺服器。
- 2
於伺服器建立付款
當客戶準備付款時，您的伺服器發送付款請求，當中包括金額、貨幣、您的訂單參考編號、成功 URL、失敗 URL 及回調 URL。切勿從瀏覽器程式碼建立付款。
- 3
儲存付款令牌並轉址
回應會包含付款令牌及託管付款頁面的地址。請將令牌與訂單一併儲存，然後將客戶轉至該頁面。
- 4
處理客戶返回
客戶付款後會返回您的成功或失敗 URL。請向客戶顯示清晰的訊息，但切勿將客戶返回視為付款證明。客戶可能關閉瀏覽器或直接開啟該 URL。
- 5
於伺服器確認狀態
根據發送至您回調 URL 的回調更新訂單，並在履行訂單前以付款令牌透過 API 確認狀態。請參閱處理回調。
- 6
完成測試後申請正式上線
請於測試環境測試已批准、已拒絕及已放棄的付款，以及退款。正式環境使用權限須待合規、商業及技術審批完成後方會提供。欄位名稱及格式載於API 文件 (opens in a new tab)。
伺服器對伺服器 API 付款
透過彩虹匯 API 直接從您的伺服器建立及管理付款，包括兩步付款及退款。
適用對象： 正在建立自訂結帳流程，並能履行隨之而來的安全責任的開發團隊。
- 1
決定如何收集銀行卡資料
從您的伺服器發送原始銀行卡資料，會令您的系統納入支付卡行業數據安全標準（PCI DSS）的適用範圍，並須獲彩虹匯批准。請在開始開發前，於開戶期間確認您的方案。如您無須處理銀行卡資料，可考慮使用託管收銀台。
- 2
保護您的憑證及環境
API 憑證應保存在伺服器上，不得放入原始碼管理系統及用戶端程式碼。請為測試環境及正式環境使用不同憑證，並限制可讀取憑證的人員。
- 3
建立付款
發送付款請求，當中包括金額、貨幣、訂單參考編號及回調 URL。請將回應中的付款令牌與訂單一併儲存。
- 4
在稍後才確認金額或存貨時使用兩步付款
在付款請求中設定 needConfirmation，並在核實訂單後透過 API 確認或拒絕該付款。
- 5
安全處理錯誤及重試
為每次調用設定逾時。如遺失回應，請先以令牌查詢該付款，然後才重試，以免重試產生重複收費。
- 6
退款、爭議及餘額
以付款令牌作全額或部分退款。透過列表端點取得爭議資料，並透過餘額端點查核可用資金。
- 7
測試完整流程
申請正式上線前，請於測試環境測試批准、拒絕、確認、退款及回調。端點詳情載於API 文件 (opens in a new tab)。
處理回調
於您的伺服器接收付款狀態變更並安全處理，即使通知重複、延遲或不按次序送達亦然。
適用對象： 在彩虹匯整合中負責訂單履行及付款狀態的開發人員。
- 1
提供 HTTPS 端點
在您的伺服器提供接受 POST 請求的回調 URL。當付款狀態改變時（例如轉為 pending、approved 或 declined），彩虹匯會發送回調。
- 2
核實每項請求
請按API 文件 (opens in a new tab)所述方法核實真確性，並確認付款令牌屬於您的其中一張訂單。任何未通過核實的請求均應拒絕。
- 3
記錄回調並迅速回應 200
請以持久方式儲存回調，並以 HTTP 200 回應。耗時的工作（例如發送電郵或更新存貨）應於獨立程序中處理。非 200 的回應會導致系統重試該回調。
- 4
以冪等方式處理
同一回調可能多次送達。請以付款令牌及狀態作為處理依據，使同一訊息處理兩次的效果與處理一次相同。
- 5
遵從狀態次序
回調可能不按次序送達。切勿讓 pending 通知覆蓋已屬最終的 approved 或 declined 狀態。
- 6
與 API 對賬
履行訂單前，請透過 API 確認狀態。請定期檢查處於 pending 狀態時間較預期長的付款，以找出系統中斷期間遺漏的回調。請參閱設計可靠的付款回調。
定期付款
在客戶在場時收取首次付款，其後以定期付款令牌收取重複付款。
適用對象： 設有訂閱、分期付款或其他已協定重複收費的商戶。
- 1
與客戶協定條款
在首次付款前，向客戶顯示金額、頻率、開始日期及取消方法，並記錄客戶的同意。定期付款的可用性或因支付方式而異。
- 2
將首次付款標示為定期付款
以 recurring: true 建立客戶的首次付款。客戶會按一般方式，透過託管收銀台或您已獲批准的 API 流程完成付款。
- 3
儲存定期付款令牌
首次付款獲批後，回應會包含 recurringToken。請將其與客戶的協議一併安全儲存。該令牌並非卡號，但可用以向客戶收費，因此須妥為保護。
- 4
建立重複付款
每次收取其後的款項時，您的伺服器以定期付款令牌及協議下的應付金額建立付款。請一如處理其他付款般，透過回調處理結果。
- 5
處理拒絕交易及取消
請預先決定重複付款遭拒絕時會重試多少次，以及將如何聯絡客戶。客戶一旦取消，須立即停止收費。
- 6
測試整個週期
請於測試環境測試首次付款、成功的重複付款、遭拒絕的重複付款及取消。請求欄位載於API 文件 (opens in a new tab)。