為預約系統接駁 FPS 或其他電子支付，重點不在付款按鈕，而在於先議定款項、預約和記錄如何保持一致。以下是實務而概括的考慮，具體要求視乎所選的支付服務商、銀行或收單機構，請向對方確認。
付款流程由誰負責
涉及付款的預約會經過四個步驟：訂單、收款、退款和收據。每一步都應指定負責人，並訂明以哪個系統的記錄為準。
- 訂單：由預約系統決定銷售內容、時段和價錢。
- 收款：由支付服務商確認是否真的收到款項。不應只因客戶返回你的網站，就把預約標示為已付款。
- 退款：訂明誰可以發起退款、誰負責批核，以及是經支付服務商處理，還是在系統以外辦理。
- 收據：訂明由哪個系統發出收據、內容包括甚麼，以及如何補發。
另外要決定付款處理期間時段保留多久，之後如何釋出。
對賬和例外情況
正常付款並不難，設計時真正需要花心思的是例外情況。以下各項，請先議定如何發現和處理：
- 重複扣款：客戶付款兩次，或同一個付款確認收到多次。每張訂單使用唯一的參考編號，並令系統重複收到確認時也不會出錯。
- 逾時或結果不明：客戶已付款但系統沒有收到確認，或情況相反。可設「待確認」狀態，並在釋出或取消預約前，先向支付服務商查詢結果。
- 部分退款：客戶只取消同一訂單中的其中一項預約。須確保退款金額、預約狀態和收據一致。
建議定期對賬，把預約記錄與支付服務商的報表及結算記錄互相核對，並指定專人跟進對不上的項目。Webhook 可以及時通知付款事件，但不保證一定送達，所以仍應設定定時核對。
交易資料的權限和審計
付款資料只應讓有需要的人查看。為前線職員、財務和管理員分別設定角色，並決定誰可以查閱、匯出或退款。同時保留審計記錄，列明誰在何時更改了預約、退款或價錢。儲存的付款資料不要超出支付服務商整合所需，API 金鑰等機密資料亦不應放在程式碼或共用文件內。
與會員、ERP 及門禁整合，毋須重寫
多數場地已有會員名單、會計軟件或門禁系統，一般不必重寫。可以把預約系統視為整條流程的其中一環，並在可行時以 API 或定時匯出連接其他系統：
- 會員：決定會員身分和折扣是直接讀取現有名單，還是複製到預約系統。
- ERP 或會計：議定傳送哪些欄位（例如訂單編號、金額和付款日期），以及傳送頻率。
- 門禁：確認預約已付款後才開放進出權限，預約取消或退款時須同步收回。
可參閱系統整合解說，以及 technine.io 的系統整合及自動化服務。
上線檢查清單
- 已設定測試商戶帳戶和測試環境，並與正式環境分開
- 測試個案涵蓋付款成功、失敗、取消、逾時、重複扣款和部分退款
- 以接近真實的資料檢查收據、通知和報表
- 已檢視角色、權限和審計記錄
- 已議定對賬流程和例外情況負責人
- 切換計劃：時間、待命人員、處理進行中預約的方法，以及還原方案
- 支付服務商的支援聯絡方法，以及內部上報途徑
常見問題
接駁 FPS 或電子支付，要重做整個預約系統嗎？
不一定。不少現有系統可以加入付款步驟，並連接現有記錄。工作量視乎現有系統如何儲存預約資料，以及工作流程是否清晰。
技術和合規要求應由誰確認？
應向你的支付服務商、銀行或收單機構查詢，並諮詢貴公司的財務或法律顧問。本文不能代替他們的意見。
預約應該在付款前還是付款後確認？
視乎業務模式。不少場地會先短暫保留時段，收到款項後才確認。無論如何選擇，都應預先訂明保留時間和釋出規則。