跳至主要內容
XSIS
客戶專區索取方案

企業與整合

卡片支付

卡片支付：從終端機到收單機構，再回到總帳

EMV 終端機與支付閘道透過 ISO 8583 或 API 串接收單機構，結算檔案在 ERP 中對帳。

與工程師交流檢視合作模式

藍圖

卡片支付：收銀台授權，稍後結算，在 ERP 中對帳終端機或結帳頁向閘道發起請求，閘道向收單機構發起請求，收單機構再路由至卡組織與發卡機構。結算檔案稍後到達，並與 ERP 中的銷售及費用核對。逾時會觸發撤銷，避免重複向客戶扣款。POSEMV 終端機或線上結帳晶片、感應式與電子商務閘道支付閘道權杖化與路由銀行收單機構授權與結算第三方卡組織與發卡機構核准或拒絕ERPERP銷售、費用與撥款XSIS整合層結算解析與核對人員支付營運團隊對帳不符、爭議與拒付1EMV · REST/JSON2ISO 85833ISO 85834ISO 85835SFTP6REST/JSON7ISO 8583 04008

卡片支付：收銀台授權，稍後結算，在 ERP 中對帳

終端機或結帳頁向閘道發起請求，閘道向收單機構發起請求，收單機構再路由至卡組織與發卡機構。結算檔案稍後到達，並與 ERP 中的銷售及費用核對。逾時會觸發撤銷，避免重複向客戶扣款。

  • 主流程
  • 非同步
  • 異常路徑
8 步流程

流程逐步說明

  1. 從 EMV 終端機或線上結帳 到 支付閘道：授權請求，經由 EMV · REST/JSON（主流程）。
  2. 從 支付閘道 到 收單機構：授權，經由 ISO 8583（主流程）。
  3. 從 收單機構 到 卡組織與發卡機構：已路由至發卡機構，經由 ISO 8583（主流程）。
  4. 從 收單機構 到 支付閘道：已核准或拒絕，經由 ISO 8583（非同步）。
  5. 從 收單機構 到 整合層：結算與費用檔案，經由 SFTP（非同步）。
  6. 從 整合層 到 ERP：已結算銷售、費用與撥款，經由 REST/JSON（主流程）。
  7. 從 支付閘道 到 EMV 終端機或線上結帳：逾時無回應：自動撤銷，經由 ISO 8583 0400（異常路徑）。
  8. 從 整合層 到 支付營運團隊：結算不符或拒付（異常路徑）。

概述

這是一筆卡片支付的路徑：從終端機或線上結帳，到收單機構、卡組織與發卡機構，再回傳。客戶在收銀台等待應答。款項扣除手續費後，稍後以結算檔案形式到達，必須與您 ERP 中的銷售紀錄核對。

參考設計透過支付閘道傳送授權請求：閘道將卡片權杖化，並透過 ISO 8583 或收單機構的 API 將請求路由至收單機構。結算與手續費檔案由整合層接收，與原始銷售核對，並作為銷售、手續費與撥款入帳到 ERP。

該設計也涵蓋出錯的情況。未在規定時間內得到應答的請求會被撤銷，避免重複向客戶扣款。對帳不符的結算或拒付會連同原始銷售紀錄轉交您的支付營運團隊。

流程如何運作

  1. 從終端機或結帳開始

    EMV 終端機讀取晶片卡或感應式卡片，或由線上結帳透過代管頁面取得卡資訊，並向閘道傳送授權請求。

  2. 透過閘道授權

    閘道用權杖替換卡號，並透過 ISO 8583 或收單機構的 API 將授權請求傳送給收單機構。

  3. 路由至發卡機構

    收單機構透過卡組織將請求路由至發卡機構，由其核准或拒絕。

  4. 回傳應答

    核准或拒絕的結果沿同一路徑回傳終端機或結帳，並附上回應代碼。

  5. 接收結算

    收單機構隨後傳送結算與手續費檔案，由整合層接收並驗證。

  6. 核對並入帳

    整合層將已結算交易與原始銷售核對，並把銷售、手續費與撥款入帳到 ERP。

出現故障時

  • 未及時收到應答

    如果閘道未在收單機構的時限內收到回應，會傳送撤銷，即 ISO 8583 0400 訊息或其等效 API 呼叫，確保客戶不會為未完成的銷售付款。

  • 付款遭拒

    回應代碼附帶清晰提示到達收銀台或結帳頁面。我們監控拒絕率；若驟升且指向技術故障，會觸發警示。

  • 結算不符

    結算金額與銷售不符，或有銷售卻無結算，會連同雙方紀錄一併進入複核清單，交予您的支付營運團隊。

  • 持卡人對付款提出爭議

    收單機構的爭議報告會匯入系統，並與原始銷售和結算關聯，使您的團隊能在一處以證據回應。

標準與系統

銀行標準與通道
  • SFTP (H2H)
支付
  • ISO 8583
  • EMV
  • EMV 3-D Secure
  • PCI DSS
整合
  • REST
  • Webhooks

問題與解答

閘道與收單機構有什麼不同？

收單機構是為您處理卡片支付並撥付款項的銀行或特許機構。閘道是其前端的技術服務，負責接收來自終端機和結帳頁面的請求、權杖化卡片並進行路由。部分供應商兩者兼營。該設計對兩種情形都適用，並清楚區分這兩個角色。

連結到此問題

這能讓卡資料不進入我們的系統嗎？

這正是該設計的目標。卡號由經過認證的終端機或代管支付頁面蒐集，並在閘道處替換為權杖，因此您的 POS、ERP 與資料儲存系統只會看到權杖。這縮小了 PCI DSS 適用於您 IT 環境的範圍。最終範圍由您的評鑑人員確認。

連結到此問題

每個收單機構的 ISO 8583 都一樣嗎？

不一樣。ISO 8583 定義的是結構，而每個收單機構或網路都會發布自己的欄位、訊息類型與代碼規範。因此我們依據收單機構的規範建置，並執行其認證測試。在收單機構前增加一層閘道 API 可以隱藏這些差異，對零售商而言通常更簡單。

連結到此問題

為什麼結算晚於銷售到達？

授權只是預留資金。收單機構按批次結算，扣除其手續費及卡組織費用後，按其自身時間表撥款。因此該設計將授權與結算視為兩個獨立事件並進行核對，使財務能夠看到已售出什麼、已結算什麼，以及還有多少尚未到帳。

連結到此問題

貴公司支援線上支付的 EMV 3-D Secure 嗎？

支援。對於線上卡片支付，我們透過閘道整合 EMV 3-D Secure，使發卡機構能夠在監理或風險要求時對持卡人進行身分驗證。我們在結帳流程中處理挑戰驗證與無摩擦流程，並用供應商的測試卡對兩者進行測試。

連結到此問題

我們可以使用多家支付供應商嗎？

可以。整合層維護統一的內部支付模型，並對映到各供應商，因此您可以按通路、國家或卡類型路由，或在供應商之間轉移交易量。每家供應商仍需要各自的整合與認證，我們會逐家規劃。

連結到此問題

相關

從對話開始，而不是從合約開始。

告訴我們您需要建置、串接與防護什麼。架構師會與您逐項討論，然後建議從何處入手。

預約免費會談索取方案

後續流程

  1. 約定時間

    我們的團隊會透過電子郵件與您約定會談時間。

  2. 諮詢前會談

    一次免費 30 分鐘線上預諮詢：我們盤點您的目標、系統與限制條件。

  3. 就緒評估

    在免費 48 小時就緒評估中，首席架構師對照 6 項就緒定義檢查您的專案，並建議合適的路線。

  4. 選擇路線

    範圍就緒的專案會收到一份有約束力的方案 3–5 個工作天內。概念階段的專案從 Blueprint Studio 開始。已上線系統若出現故障、缺乏文件或需要整合，則先進行 1–2 週 的診斷。Blueprint Studio 與診斷服務各收取固定費用，費用在方案中列明。