真理堂與亞諾討論奉獻系統 API 串接技術會議

  • 會議日期 : 2026年5月8日
  • 與會人員 : 怡如、明理、Joseph、旭倫、Deborah

本次會議討論真理堂與思遠科技在奉獻系統 API 串接上的困局、資料完整性的挑戰，以及評估更換金流平台的可能性。

    一、背景說明

    當初將【奉獻查詢】納入第一階段（Phase I）開發的背景摘要如下：

    • 回應牧者核心需求：數位轉型的初始規劃中，奉獻系統原本並未被排入 Phase I 的開發清單。後來之所以安排進來，是因為當時主牧們強烈表達希望系統能具備查詢奉獻的功能，牧者認為這對會友而言非常重要。
    • 採取「先查詢、不複雜」的策略：為了避免在第一階段就處理過於龐大且複雜的奉獻整體架構（如整合現金、匯款與多方金流）而影響其他進度，當時決定先以「查詢」功能為主，採取較簡單的 API 對接方式進行開發。

    這項功能的初衷是為了快速滿足牧者的期待與會友的需求，但在實際執行與思遠科技對接的過程中，才進一步發現資料零散與權限同步等深層的技術挑戰。

    二、現有奉獻系統的整合痛點
    • 資料分散問題： 目前奉獻管道包含線上信用卡（思遠）、現金及匯款，資料零散在不同系統中，導致財務彙整與報表統計極為困難。
    • API 串接邏輯與成本：
      • 思遠科技目前的 API 方案被認為過於複雜且以思遠為主體，要求教會系統配合其規則，有被「綁死」的風險。
      • 思遠針對此次串接報價高達 20 幾萬，團隊認為性價比不高。
    • 使用者體驗差： 現行流程在教會網站登錄後，轉到思遠平台需再次登錄。雖然希望透過 API 達成單一登入 (SSO)，但開發與溝通成本巨大。
    • 同步延遲風險： 若採逐筆即時同步，擔心會造成網路 IO 延遲，影響系統效能。
    三、核心策略轉向：「釜底抽薪」方案
    • 在地化資料庫建置： 團隊建議重新考量整體架構，將所有奉獻（線上、現金、匯款）資料先倒回教會自有的資料庫進行彙整與統計，再一併上傳至總會。
    • 以教會為中心： 強烈主張應以教會開發的新系統為中心，任何第三方廠商都必須配合教會定義的 API 規格，而非讓教會系統去適應廠商。
    • 解決對帳困擾： 若能實現資料在地化，未來所有報表與會友勾稽都不再是問題，也能減輕財務同工手動 K 資料與彙整的負擔。
    四、第三方平台評估：參考台北靈糧堂案例
    • 新方案引進：旭倫提到台北靈糧堂與新竹堂目前使用的奉獻系統（註：參考其他來源應為「甚好」平台），具備極佳的使用者體驗。
    • 優勢分析：
      • 極簡流程： 前端介面非常直觀，甚至無需註冊即可快速完成奉獻。
      • 報稅自動化： 已直接串接國稅局報稅系統。
      • 開發便利性： 工程師評估其串接難度遠低於思遠，可能一兩天就能搞定。
    • 決策考量： 若更換平台的成本與思遠的 API 開發費相當，且能換取更好的穩定性與費率，團隊傾向重新評估更換平台的可能性。
    五、歷史資料安全性確認

    • 資料所有權： 討論若終止與思遠合作，其線上奉獻資料是否能全數拿回。
    • 總會端備份： 明理哥確認總會的奉獻系統中保有全教會最完整的奉獻紀錄（包含思遠匯入的資料），因此即便思遠端資料無法完整取得，也有總會資料作為底氣。
    六、後續行動

    1. 市場研究： 請旭倫進一步調查台北靈糧堂所用系統的收費模式、抽成比例及技術串接方式，作為備案評估。
    2. 財務部確認： 由明理哥與財務部確認，總會系統的奉獻紀錄中是否有標註「奉獻管道」（例如：是否能區分出信用卡奉獻），以利後續資料遷移。
    3. 牧者溝通： 由怡如向錕梁牧師回報目前的技術轉折與架構考量，說明為何傾向「釜底抽薪」的方案而非僅做局部 API 串接。
    4. 三方會議預備： 若要繼續與思遠合作，需安排思遠、亞諾與教會三方線上會議，由教會/亞諾主導定義技術規格，要求廠商配合。