銀行API是銀行開放給外部系統呼叫的程式介面，讓企業系統或經授權的服務透過網路查詢帳戶與交易資料、接收入帳通知，或在特定條件下發起交易，不必再靠人工登入網路銀行下載明細。台灣常聽到的「開放銀行」，依金管會新聞稿，是鼓勵業者以自願自律方式，分「公開資料查詢」「消費者資訊查詢」「交易面資訊」三階段推動。企業常見的串接需求是對帳與付款通知，能用哪些功能、怎麼申請，要以往來銀行的說明為準。銀行 API 也和讓顧客在網站付款的金流服務不同，規劃前先分清楚自己要解決的是哪一個問題。
銀行API能做什麼：查詢、通知與交易
銀行提供的 API 依用途大致可分三類，實際開放哪些項目、適用哪些帳戶，各家銀行不同：
- 查詢類：帳戶餘額、交易明細、匯率或分行資訊等。對帳系統主要依賴這一類，定時取回入帳明細與訂單比對。
- 通知類：若銀行提供，有款項入帳或扣款完成時，會主動通知企業指定的網址，系統收到後即時更新訂單狀態。
- 交易類：由企業系統送出轉帳或付款請求。牽涉資金移動，銀行可能要求額外的授權與控管機制。
如果往來銀行沒有提供 API，也可能提供對帳檔下載或檔案傳輸服務，系統定時匯入檔案再比對，即時性較低，但同樣能減少人工核對。先問清楚銀行有哪些服務形式，再決定系統要怎麼接。
開放銀行是什麼：金管會的三階段推動
依金管會核備開放銀行第三階段交易面資訊規範的新聞稿，台灣的開放銀行採鼓勵業者自願自律的方式，分三階段推動：
| 階段 | 名稱 | 新聞稿說明 |
|---|---|---|
| 首階段 | 公開資料查詢 | 已上線 |
| 次階段 | 消費者資訊查詢 | 已上線 |
| 第三階段 | 交易面資訊 | 開放存款、信用卡、貸款、支付及手機門號轉帳等五種業務種類 |
第三階段的規範，是銀行公會的業務面自律規範與財金公司的技術與資安標準，經金管會核備；有意願與第三方服務提供者（TSP）合作辦理的銀行，要檢附書件向金管會申請。新聞稿也強調，推動須兼顧個人資料保護、資訊安全控管及消費者權益保障。
換句話說，開放銀行是銀行與經核准的合作業者之間的制度安排，一般企業若只是想讓自家系統讀取自己帳戶的入帳資料，要詢問的是往來銀行提供的企業服務，而不是去申請成為合作業者。
企業常見的串接需求：對帳與付款通知
入帳對帳
收款筆數多的企業，常見的痛點是每天人工比對網銀明細與訂單。串接後的流程可以設計成：
- 系統定時取回入帳明細，或接收銀行的入帳通知。
- 依事先定義的規則比對訂單或應收帳款，例如金額、付款識別碼、匯款日期與備註。
- 比對成功就自動標記已收款，並通知業務或出貨單位。
- 金額不符、重複匯款或找不到對應訂單的款項，進入例外清單由人工確認。
規則訂得越清楚，例外清單越短，所以付款識別方式要在串接前和銀行、財務一起確認。
付款結果通知
企業對外付款時，系統可以接收銀行回傳的處理結果，更新應付帳款狀態。付款的申請與審核應在企業內部系統完成並留下紀錄，再依銀行規定的授權方式送出，不要讓單一帳號就能完成整筆付款。
銀行API和金流服務差在哪
兩者都和錢有關，但解決的問題不同。讓顧客在網站上刷卡、用行動支付或超商代碼付款，屬於金流服務；申請、審核與測試上線的流程，可以參考金流串接的流程整理。
| 面向 | 銀行API | 金流服務 |
|---|---|---|
| 主要用途 | 存取企業帳戶資料、接收入帳與交易結果 | 讓顧客在網站或 App 完成付款 |
| 面對的對象 | 企業內部的財務、訂單或會計系統 | 前台結帳流程與消費者 |
| 申請窗口 | 往來銀行 | 金流業者或收單機構 |
代為收款再撥付給商家的業務另有法規規範。電子支付機構管理條例第四條列出代理收付實質交易款項、收受儲值款項等業務，第五條規定非電子支付機構不得經營這些業務，例外是本條例或其他法律另有規定，或只經營代理收付實質交易款項、所保管代理收付款項總餘額未逾主管機關所定一定金額，且未經營收受儲值款項或國內外小額匯兌；逾一定金額時，要依規定期限向主管機關申請電子支付機構許可。企業若想在自己的平台上替他人收款，應先確認適用的規定，以主管機關公告或專業意見為準，不能只當成技術問題處理。
安全與授權：串接前要確認的事
銀行資料涉及資金與個人資料，個資法第二條所定義的個人資料就包含財務情況。串接時至少要確認以下幾點：
- 授權方式：若銀行採用 OAuth 授權架構，依其標準，應用程式取得的是有特定範圍與期限的存取權杖，而不是使用者的帳號密碼。金鑰與權杖的差別與保管方式，可參考API Key 與 Token 的差別。
- 傳輸加密：所有呼叫走 HTTPS，以 TLS 加密用戶端與伺服器之間的通訊。
- 必要權限：只申請需要的功能，查詢與交易權限分開，測試與正式金鑰分開保管。
- 通知驗證：收到銀行通知時，依銀行規格驗證來源與內容，不能只看收到的資料就更新帳務。
- 紀錄與稽核：保留每次呼叫的時間、結果與操作人員，異常時才查得出原因。
銀行也可能有自己的資安要求，例如憑證、來源 IP 限制或簽章方式，以銀行提供的規格文件為準。
銀行API串接怎麼規劃：從詢問到上線
- 盤點需求：列出要串的帳戶、要取得的資料、更新頻率，以及要寫進哪個系統。
- 詢問往來銀行：確認提供的服務形式、申請條件、需要的文件與費用，申請與簽約由企業向銀行辦理。
- 取得規格與測試環境：拿到 API 文件、測試帳號與測試資料，確認欄位、錯誤代碼與呼叫限制。
- 訂定對帳與例外規則：財務、業務與系統開發方一起確認比對邏輯與例外處理流程。
- 開發與測試：除了成功情境，也要測重複通知、逾時、金額不符與銀行端維護時段。
- 上線與監控：設定失敗通知與每日對帳報表，保留人工補登的途徑。
欄位對應、重送規則等通用的串接細節，和其他系統的 API 串接做法相同，可以一起寫進規格書。
常見問題
中小企業可以申請銀行API嗎？
要看往來銀行是否提供，以及對企業規模、帳戶類型與申請文件的要求。建議先洽詢銀行的企業服務窗口，申請條件與費用以銀行說明為準。
開放銀行和銀行API是同一件事嗎？
不完全相同。銀行API泛指銀行提供的程式介面；開放銀行是金管會鼓勵業者自願自律、分三階段推動，由銀行與合作業者依自律規範與技術標準開放資料與服務的機制。
沒有銀行API還能自動對帳嗎？
可以。若銀行提供對帳檔下載或檔案傳輸，系統可定時匯入檔案，依同樣的規則比對訂單與入帳，只是即時性較低，匯入時也要檢查檔案格式是否變動。
串接銀行API會增加帳戶風險嗎？
風險主要來自權限與金鑰管理。只申請必要的功能、查詢與交易權限分開、金鑰不寫在程式碼裡，並定期檢查呼叫紀錄，可以降低被濫用的機會。
銀行API串接的時程怎麼估？
時程取決於銀行申請與審核、規格文件與測試環境是否完整、內部系統要改動的範圍，以及對帳規則的複雜度。建議先完成需求盤點，再依實際規格排定時程。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
想把對帳或付款通知自動化，可以先整理目前的收款方式、帳戶與人工作業流程，再向往來銀行確認可用的服務。銀行服務的申請與審核由企業向銀行辦理，京采負責的是系統端：需求釐清、訂單或後台系統與銀行 API 的串接規劃與開發，以及測試與上線，詳細內容可參考網頁設計服務，或與我們聯繫討論。
