購物網站怎麼串電子發票？付款、開立、作廢與折讓流程圖

購物網站怎麼串電子發票？付款、開立、作廢與折讓流程圖

內容目錄 顯示
加入為 Google 偏好來源

一筆測試訂單顯示付款成功，發票服務也回傳「已受理」，不代表電商電子發票串接已經驗收完成。網站還要知道這次付款是否真的符合開票條件，保存訂單與發票的唯一對應，持續取得上傳結果，遇到退款時再依實際情況作廢或開立折讓單。

因此，串接的核心不是把一組 API 金鑰貼進後台，而是先決定每個訂單事件要產生什麼發票動作，再保存服務商與財政部平台的處理結果。少了其中一層，就可能發生重複開票，付款成功卻漏開，或網站顯示已完成，但發票資料仍在等待上傳的落差。

來源：財政部《電子發票實施作業要點》、財政部《電子發票 Turnkey 上線前自行檢測作業》與秒站電子發票設定教學（查證 2026-07-24）。官方資料用來確認電子發票系統、防重、漏上傳、錯誤處理及上傳結果檢測責任；本文將這些要求轉成購物網站的流程設計方法，不取代主管稽徵機關、會計師或稅務代理人的個案判斷。

電商電子發票串接是什麼？

電商電子發票串接，是把購物網站的交易事件轉成正確的發票動作，送到電子發票服務，再把處理結果寫回訂單與對帳紀錄的完整流程。它至少包含「辨識事件，決定動作，傳送資料，確認結果」四個步驟，不能只用「付款後呼叫開票 API」概括。

先分清楚訂單事件、發票動作與處理結果

同一筆交易在三套系統中，會有三種不同語言：

  1. <strong>訂單事件</strong>：例如付款成功，付款失敗，取消訂單，全部退款或部分退款。這一層描述交易發生了什麼事。
  2. <strong>發票動作</strong>：例如開立，作廢，開立折讓，作廢折讓，查詢或重新傳送。這一層描述系統接下來要做什麼。
  3. <strong>處理結果</strong>：例如請求未送出，服務商拒絕，服務商已受理，等待上傳，平台檢核成功或平台回覆錯誤。這一層描述動作走到哪裡。

API 是傳遞指令的管道，不會替商家決定稅務規則

API 是 Application Programming Interface，中文常譯為應用程式介面。白話來說，它是一套讓購物網站把開票資料送到發票服務，並接收處理結果的規則。

來源：光貿電子發票 API 文件（查證 2026-07-24）。文件目前將 OrderId 列為不可重複的訂單編號，並提供發票狀態查詢；本文只用它說明單一服務商的實作例，不把欄位長度、端點或狀態碼通用到其他廠商。

防止重複開票要靠冪等設計，不是禁止人工重按

冪等性對應英文 Idempotency，意思是同一個業務請求即使因逾時或重送執行多次，也不會多產生一張發票。它不是某一把通用的「防重金鑰」，而是唯一業務編號、資料庫狀態、服務商規則與重送流程共同形成的結果。

  1. 網站先用「商店識別＋訂單編號＋發票動作」建立唯一請求。
  2. 傳送前檢查本地端是否已有成功結果，或已有處理中的同類請求。
  3. 連線逾時時先查詢原請求狀態，不立刻換新編號再開一次。
  4. 只有確認原請求沒有成立，且符合重送規則時，才進入重新傳送。

金流、訂單、網站、加值中心與財政部如何分工？

購物網站發生漏開或重複開票時，最常見的溝通問題是每個人都說「自己的系統顯示成功」。原因不是某一方一定有錯，而是金流成功、訂單完成、開票請求受理及平台存證成功，本來就是不同事件。專案開始前應先做責任分工表，並為每一段指定可查詢的證據。

角色主要負責什麼不代表什麼驗收時應取得的證據
營業人與會計窗口決定開票時點、B2B 或 B2C 資料、稅別、退貨處理及人工覆核原則不代表已完成程式串接書面事件規則、例外處理表及會計確認紀錄
金流服務回傳授權，請款，付款與退款等金流結果付款成功不等於發票已開立；退款成功也不等於原發票已處理金流交易編號，付款狀態，退款金額及事件時間
訂單系統保存商品，買受人，金額，付款，出貨及退款狀態訂單改成「完成」不代表外部發票服務已成功訂單歷程，狀態變更來源，操作者及時間
網站串接層把訂單事件映射成發票動作，簽署並傳送請求，保存回覆，查詢結果及告警HTTP 連線成功不代表發票業務處理成功唯一請求編號，去識別化日誌，回傳內容，重送與告警紀錄
加值服務中心或發票服務接收與檢核開票資料，依服務範圍配號，傳輸，保存或提供查詢收到 API 請求不代表財政部平台已完成檢核發票號碼，服務商處理狀態，上傳結果及錯誤明細
財政部電子發票整合服務平台接收與檢核符合規範的電子發票資料，提供相關整合性服務不管理購物網站訂單，也不替商家決定何時開票平台成功回覆，查詢結果及符合規範的留存紀錄

付款成功只解答「錢的狀態」

金流系統可以告訴網站授權是否成功，款項是否已請領，或退款是否受理。它無法單獨決定買受人資料是否完整，訂單是否要拆票，以及此刻是否符合商家的開票規則。

訂單系統要保存事件歷程，不能只看最後狀態

一張顯示「已退款」的訂單，可能歷經部分退款後再全部退回，也可能只是金流退款成功，但發票折讓仍待處理。若資料庫只保存最後狀態，就無法重建每一次金額變動與對應的發票動作。

網站串接層是翻譯者，也是防重與告警的第一道控制

網站串接層一邊理解訂單事件，一邊依服務商規格組成請求。除了正常開立，它還要處理資料檢核、機密資訊保護、逾時查詢、錯誤分類、防重、人工接手與告警。

加值中心受理後，還要繼續確認上傳結果

財政部作業要點將加值服務中心定義為經核准提供電子發票系統及相關加值服務的營業人，並要求其與整合服務平台介接，負責交換與上傳電子發票資料，或接收相關資訊。購物網站透過加值中心開票時，仍應確認服務合約涵蓋哪些工作，以及哪一種狀態才代表平台已成功接收。

來源：財政部《電子發票實施作業要點》與財政部《電子發票 Turnkey 上線前自行檢測作業》（查證 2026-07-24）。官方文件要求確認傳輸結果，處理錯誤訊息並核對上傳筆數；加值中心 API 的實際狀態名稱，查詢方式與完成條件，仍須依所選服務商的正式文件及契約確認。

哪些訂單事件要對應開立、作廢、折讓、註銷與重送？

訂單狀態與發票動作不能做成一對一的名稱對照。例如「已退款」只說明款項處理結果，沒有告訴系統是全額或部分退款，原發票是否已完成平台存證，是否曾開立折讓單，以及會計上應採哪一種處理方式。

訂單或系統事件判斷前提常見的候選動作自動化前必須確認完成證據
建立訂單但尚未付款還沒達到商家設定的開票時點不開票，持續等待哪些付款方式會延後確認，訂單多久失效訂單仍無發票請求
付款失敗或付款前取消原發票不存在不開票沒有其他成功付款交易與同訂單綁定付款失敗紀錄及無開票紀錄
付款或履約條件已確認原發票不存在，買受人資料完整建立開票請求商家核定的開票時點、交易金額、稅別及買受人資料發票號碼與平台成功狀態
收到重複付款通知同一交易可能已處理查詢原請求，不建立新發票唯一業務編號與本地端處理狀態查詢結果及未新增發票
發票請求逾時無法判斷原請求是否成立先查詢，再依結果決定是否重送服務商查詢方式、重送規則及防重能力原請求結果或同一業務請求的重送結果
發票已開立，整筆交易取消或全額退回要確認發票狀態、交易時間、申報狀況及既有折讓作廢或開立全額折讓單，由個案規則決定會計確認，加上買受人同意與服務商限制作廢或折讓完成狀態及同意紀錄
發票已開立，只有部分商品或金額退回原發票保留部分有效交易依實際退回內容開立折讓單退回品項、數量、未稅金額、稅額及原發票折讓單號碼、金額與平台成功狀態
發票內容有誤要分辨資料是否錯誤，交易是否變動，以及是否已申報依規定作廢重開、申請更正或其他核准程序錯誤類型，發票狀態，買受人處理情形及主管機關要求正確的新紀錄與原紀錄處理證據
字軌無效、重號或用盡系統不能合法取得可用發票號碼暫停自動開立並告警當期電子發票專用字軌、剩餘號碼及配號資料告警及補正紀錄，以及恢復開票測試
服務商或平台回覆資料錯誤原請求尚未成功修正資料後重送同一業務動作錯誤碼，以及可修改欄位及原請求是否成立錯誤已排除且最終狀態成功

開立時點應由營業規則決定，不由狀態名稱猜測

「處理中」「已付款」「已完成」在不同購物系統可能代表不同事情。有的商家付款確認後開票，有的交易還要經過人工接單或其他履約條件。技術團隊不能看到狀態叫「完成」，就假設它等於法規上的開票時點。

全額退款不代表每次都能直接作廢

全額退款只表示款項全部退回，不能單獨決定發票處理。原發票若已開立，系統還要看發票是否已申報，是否已有折讓紀錄，以及適用的服務商與稅務程序。某些情況可以作廢，某些情況則要用全額折讓或其他程序處理。

部分退款要回到原發票逐項核對

部分退款通常不能把整張原發票作廢，因為仍有一部分交易成立。系統要把退款品項與原發票內容連回來，計算實際退回的銷售額及稅額，再依規定開立折讓單。

註銷不是一般退款流程的替代名稱

財政部 MIG 4.0 文件把平台存證註銷發票列為 F0701，與平台存證作廢發票 F0501 是不同訊息。白話來說，註銷與作廢不是購物網站可以任意互換的兩個按鈕。

來源：財政部《電子發票實施作業要點》、財政部《統一發票使用辦法》與財政部《電子發票資料交換標準訊息建置指引 MIG 4.0》（查證 2026-07-24）。現行規範涵蓋發票開立及更正，也涵蓋作廢及銷貨退回或折讓，並要求相關資訊傳輸與留存；MIG 文件分別定義 F0501 作廢發票、F0701 註銷發票及 G0401 折讓證明單。本文表格是系統需求分析框架，實際動作仍須依交易事實、發票狀態、服務商規格及專業稅務判斷確認。

哪些情境可以自動處理，哪些需要人工覆核？

自動化的判斷標準不是「這個動作常不常發生」，而是輸入是否完整，結果是否可逆，以及發生錯誤時能否被系統可靠攔下。條件單純，結果明確，而且狀態可供查詢的事件適合自動處理；涉及稅務判斷、跨期、金額分攤或資料衝突的事件，應先停在人工覆核佇列。

情境建議模式可以自動化的部分應轉人工的條件
已驗證付款且首次開票條件式自動資料檢核與防重，接著送出，查詢並寫回結果買受人資料缺漏、稅別不明、金額不一致或字軌異常
重複付款通知自動查詢以唯一交易識別查詢原請求並忽略重複事件查到多張發票或本地紀錄與服務商不一致
暫時性連線失敗自動查詢後有限重送依退避規則查詢，確認未成立後重送查詢無法判定，連續失敗超過門檻或回覆互相衝突
格式或必填欄位錯誤自動攔截在送出前檢查統編、載具、捐贈碼及金額格式顧客提供的資料互相衝突，或修改會改變發票類型
全額退款條件式自動或人工蒐集原發票和退款資料，以及既有折讓狀態跨期，已申報，已有折讓，買受人不同意或規則無法唯一判定
部分退款以人工覆核起步自動計算候選折讓明細與剩餘可折讓金額多次退款、折扣分攤、運費退回、組合商品或計算差額
B2B 買受人資料變更人工覆核驗證統一編號格式及保存異動紀錄發票已開立，買方已接收或資料涉及更正程序
海外、零稅率或特殊稅別人工覆核蒐集國別、交易與證明資料稅別或適用條件尚未由專業人員確認
字軌異常或平台狀態矛盾暫停自動化發出告警，停止新請求，並產出待處理清單管理者確認並完成補正前，一律不自動恢復

正常開立可以自動化，但要有五道閘門

一筆訂單要自動開票，至少應通過五項檢查：

  1. 付款或其他核定的開票事件已由伺服器端證據確認。
  2. 訂單金額、稅額與明細已凍結，沒有待處理的取消或退款。
  3. 買受人需要的統編、載具或捐贈資料已通過適用檢核。
  4. 同一業務事件沒有成功或處理中的開票請求。
  5. 正式環境、有效字軌與服務商連線狀態都可使用。

B2C 與 B2B 只描述交易對象，不能代替流程判斷

B2C 是 Business-to-Consumer，直譯為企業對消費者，常用來描述買受人為一般消費者的交易。B2B 是 Business-to-Business，直譯為企業對企業，常用來描述買賣雙方都是營業人的交易。

退款自動化應從「輔助判斷」開始

初次上線時，可以讓系統自動蒐集原發票狀態、退款金額、退回品項與歷次折讓，再產生候選動作給人確認。等團隊累積足夠案例，確認規則沒有灰區，再把其中條件單純的類型改成自動執行。

自動重送必須設定停止條件

重送不是每隔幾分鐘重打一遍同一支 API。系統要先區分連線逾時，可修正的資料錯誤，權限錯誤及服務商已受理但尚未完成。只有確認原請求未成立，且錯誤類型允許重試時，才進入有限次數的重送。

來源：財政部《電子發票 Turnkey 上線前自行檢測作業》、光貿電子發票 API 文件與綠界作廢折讓發票 API 文件（查證 2026-07-24）。官方檢測文件要求字軌、重號、漏上傳、錯誤訊息及傳輸結果檢核；兩家服務商文件顯示實際端點、欄位、狀態與限制並不相同。本文因此只提供自動化控制原則，不把單一廠商的 API 行為寫成通則。

電子發票串接前要準備哪些資料、字軌、帳號與權限？

串接前要準備的不只是一組 API 密鑰。完整輸入至少分成四包：營業與稅務資料、電子發票字軌、結帳與訂單規則，以及服務商的測試與正式介接資料。四包資料少一包，工程團隊即使能送出請求，也可能無法完成合法開立與對帳。

營業與稅務資料先由負責人確認

第一包資料回答「誰在開票，以及這筆交易應如何記錄」。至少要確認賣方統一編號、營業人使用電子發票的適用程序、常見交易稅別、開票時點，以及遇到特殊交易時由誰判斷。

電子發票字軌要確認來源、期別與分配方式

電子發票字軌不是網站自行產生的一串號碼。串接前要確認正式營運可使用的電子發票專用字軌，也要確認目前期別與配號方式，並記錄可用餘量及異常通知人。若採服務商自動配號，也要知道服務商如何處理即將用盡、期別切換與配號失敗。

結帳資料要先定義 B2B、B2C、載具與捐贈規則

結帳頁會決定網站能否取得正確的買受人資料。規格至少要涵蓋一般消費者，也要涵蓋需要統編的企業買受人、手機條碼或其他載具，以及捐贈碼。每一種選項都要定義必填欄位、格式檢查、互斥關係與錯誤提示。

測試與正式介接資料要分開保存

測試環境與正式環境應有不同的設定組，至少分開保存下列資料：

  • 環境名稱及服務商。
  • 測試或正式統一編號與商家識別。
  • 發票動作使用的 API 網址，以及查詢網址與通知網址。
  • 密鑰版本與啟用日期，以及負責保管的人員。
  • 來源主機或網路白名單。
  • 配號模式與字軌設定。
  • 告警收件人及人工覆核窗口。

如何從訂單狀態機與 API 設定走到正式驗收？

正式驗收不是完成一筆測試開票，而是證明正常事件能完成，重複與錯誤事件不會多開，退款能進入正確流程，而且訂單筆數能與服務商及平台結果對上。可以依「畫出狀態，定義映射，設定環境，執行測試，完成首批對帳」五個階段推進。

訂單狀態機先畫出允許的移動方向

State Machine 直譯為狀態機。白話來說，它是一張規則圖，列出一筆訂單現在處於什麼狀態，收到什麼事件後可以移到哪裡，以及移動時要執行什麼動作。

事件映射表要寫清楚輸入、動作與輸出

每條狀態轉換都要形成一列需求。輸入要記錄原訂單狀態與事件來源，也要包含交易金額及原發票狀態；動作則要明確寫成開立，查詢，作廢，折讓或轉人工；輸出要留下新狀態與發票號碼，也要保存服務商回覆、平台結果及日誌。

測試環境設定完成後先跑連線與權限檢查

進入業務測試前，先確認測試程式確實讀到測試設定。可以在不顯示密鑰的前提下，記錄環境名稱、商家識別末幾碼、密鑰版本及 API 主機，讓測試人員辨認目前沒有連到正式資料。

正常與例外案例要用同一張測試矩陣驗收

測試矩陣至少要涵蓋以下十種情境：

測試情境預期發票行為必須驗證的防錯點驗收證據
首次付款成功建立一張發票並取得最終成功結果交易金額符合預期，買受人與稅別也相符訂單歷程、發票號碼及平台結果
同一付款通知重送兩次查詢原請求，不新增發票唯一業務編號生效通知兩次，發票仍為一張
開票請求送出後逾時先查詢原請求，再決定是否重送結果未知時不換新編號開票查詢紀錄、重送決策及最終結果
統編或載具資料錯誤送出前攔截，或明確進入錯誤狀態不以預設值掩蓋顧客輸入錯誤欄位錯誤訊息及無新發票
全額退款依核定規則作廢、折讓或轉人工不只用退款金額決定動作原發票狀態、決策紀錄及完成結果
部分退款依退回明細建立折讓候選或折讓單累計折讓不超過可折讓餘額品項、金額、稅額及折讓結果
服務商回覆可修正錯誤修正後以原業務事件重送不產生第二張發票錯誤、修正、重送與查詢歷程
字軌無效或用盡停止新開票並告警不自行產生號碼，不無限重試告警、待辦及恢復測試
正式密鑰誤放測試環境測試立即停止設定檢查能辨識環境不符阻擋紀錄及密鑰更換紀錄
訂單與平台筆數不一致產生差異清單，不宣告驗收完成每一筆差異都有狀態與負責人對帳表、差異原因及處理期限

重複開票、漏開、資料錯誤、退款與資安風險如何控管？

電子發票串接最危險的狀況，不一定是 API 無法正常連線。連線失敗通常看得見，系統半成功卻沒有留下可追查狀態，反而更容易造成重複開票、漏開或帳務不一致。

用「預防，偵測，停止，復原」管理每一項風險

可以先建立一張風險登錄表：

風險預防機制偵測證據停止條件復原方式
同一訂單重複開票唯一業務編號與防重鎖同一事件出現多筆請求或多張發票查到既有成功或結果未知查詢原請求，確認唯一結果
符合條件的訂單漏開開票佇列與每日對帳訂單完成但沒有開票請求超過允許等待時間補建待辦，確認後以原事件處理
買受人或金額資料錯誤送出前欄位檢核服務商拒絕或人工對帳差異欄位互相衝突或金額不平修正來源資料後重新覆核
退款動作錯誤先查原發票與累計異動退款金額與發票異動不一致規則不能唯一判定轉人工決定作廢或折讓流程
字軌或權限失效到期前告警與環境檢查服務商回覆拒絕或可用量異常連續錯誤超過門檻停止新請求，補正後跑回歸測試
密鑰或個人資料外洩最小權限與日誌遮罩異常存取或日誌出現敏感欄位疑似外洩即停用換發密鑰，清查範圍並驗證恢復

重複開票要從業務事件防重

付款通知可能重送，工作佇列可能重新執行，管理員也可能在等待時手動按一次開票。若三條路徑各自產生新請求，API 本身即使沒有故障，也可能出現多張發票。

  1. 資料庫不允許同一業務編號建立兩筆有效請求。
  2. 工作者送出前取得防重鎖，確認沒有其他程序正在處理。
  3. 發生逾時時先查原請求，不立刻換一個新編號重送。

漏開要靠正向清單找出來

只看失敗日誌找不到「根本沒有建立請求」的訂單。漏開偵測要從訂單端建立正向清單：先逐一找出符合開票條件的訂單，再比對每一筆是否有對應的開票請求與平台結果。

  • 應處理訂單：42 筆。
  • 已成功：39 筆。
  • 合理等待中：2 筆。
  • 沒有請求：1 筆。
  • 去向核對：39 ＋ 2 ＋ 1 ＝ 42 筆。
  • 當日完成率：39 ÷ 42 × 100％，約為 92.9％。

資料錯誤不能用預設值悄悄補過

統一編號、載具識別、捐贈碼、交易金額及稅別一旦互相衝突，系統應阻擋送出或進入明確錯誤狀態。不要為了提高成功率，自動刪除統編，改用一般消費者格式，或把無法解析的稅別改成預設值。

一筆成功付款與一筆退款如何完整流轉？

下面兩個案例的目的，是把前面的責任分工、狀態機與驗收證據串起來。案例金額與識別碼都是示意，不代表特定服務商欄位，也不能取代營業人的會計及稅務判斷。

案例一：一筆付款成功後只開出一張發票

假設訂單 ORDER-20260903-001 的應開金額為新臺幣 1,260 元，顧客沒有輸入統編，選擇已完成格式驗證的手機條碼。商家規則是由伺服器端確認付款成功後建立開票事件。

  • 訂單金額為 1,260 元，付款確認金額也是 1,260 元。
  • 唯一業務編號只有一筆有效紀錄。
  • 第一個通知建立開票事件，第二個通知命中既有結果。
  • 服務商結果與平台查詢都指向同一張發票。
  • 訂單最終狀態、發票號碼與通知時間都有紀錄。

案例二：部分退款先產生候選動作，再由規則決定送出

延續同一張 1,260 元訂單。顧客後來退回其中一項 300 元商品，金流退款已成立，退款事件識別為 REFUND-001。假設商家的書面流程已確認，這類已開票的部分退款要先建立折讓候選資料，再由授權人員覆核後送出。

  • 原發票金額：1,260 元。
  • 先前累計折讓：0 元。
  • 本次退款候選金額：300 元。
  • 候選處理後餘額：1,260 － 0 － 300 ＝ 960 元。
  • 金流退款成功：300 元。
  • 訂單退款紀錄：300 元。
  • 發票異動完成：300 元。
  • 金額差異：300 － 300 ＝ 0 元。
  • 候選處理後餘額：960 元。

同一案例換成全額退款，動作也不能直接複製

若退款金額改成 1,260 元，系統可以判定這是全額退款，卻仍不能只因金額相等就自動選擇作廢。還要確認原發票的處理與申報狀態，也要核對買受人身分、既有異動及商家核定流程。

案例驗收要看唯一性、完整性與可追溯性

成功付款案例證明唯一性：重複通知不會多開。部分退款案例證明完整性：金流、訂單與發票異動金額可以對上。兩個案例都要證明可追溯性：任何人都能從業務事件找到請求、服務商結果、平台狀態與核准紀錄。

來源：財政部《統一發票使用辦法》、綠界作廢折讓發票 API 文件與綠界查詢發票確認 API 文件（查證 2026-07-24）。法規用來確認電子發票異動要依交易事實與適用程序處理；服務商文件用來確認實務上有作廢折讓及查詢確認等不同動作。案例中的狀態名稱、唯一業務編號與金額皆為本文示意，不是服務商固定欄位。

內文精華總結

  • 電商電子發票串接是什麼：電商電子發票串接，是把購物網站的交易事件轉成正確的發票動作，送到電子發票服務，再把處理結果寫回訂單與對帳紀錄的完整流程。
  • 先分清楚訂單事件、發票動作與處理結果：「付款成功」不等於「發票已開立」，「服務商收到請求」也不等於「財政部平台已完成存證」。
  • API 是傳遞指令的管道，不會替商家決定稅務規則：API 是 Application Programming Interface，中文常譯為應用程式介面。
  • 防止重複開票要靠冪等設計，不是禁止人工重按：冪等性對應英文 Idempotency，意思是同一個業務請求即使因逾時或重送執行多次，也不會多產生一張發票。

想把電商電子發票串接規劃成能長期營運的網站？

先用秒站建立可操作的網站，再依實際內容、功能與營運需求調整。你可以先試用，查看方案，或從真實案例確認適合自己的方向。

延伸閱讀

電子發票系列文章

秒站現在不只是一套版型。你可以從現成架構快速開始，用頁面編輯器拖曳、複製與調整版面；需要更高自由度時，也能和 AI 協作，把自製頁面放進 Vibe 畫布。上線速度與設計自由不必二選一。

秒站所說的「輕電商」，輕的是適用的營運量級，不是功能。電商行銷百寶箱把商品上架、折價券、購物點數、訂單通知、付款與運送規則，以及折扣活動集中在同一套後台，再接上金流、發票與物流，讓中小品牌建立從商品上架到訂單溝通的銷售流程。

重點整理

電商電子發票串接是什麼？

電商電子發票串接，是把購物網站的交易事件轉成正確的發票動作，送到電子發票服務，再把處理結果寫回訂單與對帳紀錄的完整流程。它至少包含「辨識事件，決定動作，傳送資料，確認結果」四個步驟，不能只用「付款後呼叫開票 API」概括。

先分清楚訂單事件、發票動作與處理結果要注意什麼？

「付款成功」不等於「發票已開立」，「服務商收到請求」也不等於「財政部平台已完成存證」。網站若只保存一個「已開票」勾選值，就無法分辨請求是否仍在排隊，傳輸失敗，或已經取得平台成功結果。較穩定的資料設計，會分成七個欄位：訂單編號，發票服務商，發票號碼，動作類型，請求時間，服務商回覆及平台狀態。實際欄位名稱與狀態碼依服務商文件為準，不應把某一家廠商的代碼直接當成跨廠商標準。

API 是傳遞指令的管道，不會替商家決定稅務規則要注意什麼？

API 是 Application Programming Interface，中文常譯為應用程式介面。白話來說，它是一套讓購物網站把開票資料送到發票服務，並接收處理結果的規則。API 能規定欄位格式、簽章方式與回傳內容，卻不會自動知道商家要在「付款完成」「出貨完成」還是其他時點開票，也不能替商家判斷某筆退款應作廢原發票或開立折讓單。開票時點、交易類型及退回處理，應先由營業人依實際交易與稅務規定確認，再由網站實作成事件規則。

防止重複開票要靠冪等設計，不是禁止人工重按要注意什麼？

冪等性對應英文 Idempotency，意思是同一個業務請求即使因逾時或重送執行多次，也不會多產生一張發票。它不是某一把通用的「防重金鑰」，而是唯一業務編號、資料庫狀態、服務商規則與重送流程共同形成的結果。財政部現行作業要點要求電子發票系統具備防止字軌號碼開立錯誤、重複及漏未上傳的檢核功能。Turnkey 自行檢測文件也把重號、漏上傳、錯誤回應與每日筆數比對列為檢測項目。

金流、訂單、網站、加值中心與財政部如何分工？

金流負責付款結果；訂單系統保存交易與退款事件；網站串接層依規則決定發票動作並防止重複；加值中心依契約接收、交換及上傳資料；財政部平台負責接收與檢核。每一步都要留下事件 ID、時間與處理結果，才能對帳。

付款成功只解答「錢的狀態」要注意什麼？

金流系統可以告訴網站授權是否成功，款項是否已請領，或退款是否受理。它無法單獨決定買受人資料是否完整，訂單是否要拆票，以及此刻是否符合商家的開票規則。網站也不能只憑顧客回到付款完成頁就開票。顧客可能中途關閉頁面，付款頁也可能被重整；正式流程應以可驗證的伺服器端通知或主動查詢結果更新付款狀態，再依已確認的商業規則建立開票請求。不同金流商的通知，查詢與重送規格不同，必須以實際介接文件為準。

訂單系統要保存事件歷程，不能只看最後狀態要注意什麼？

一張顯示「已退款」的訂單，可能歷經部分退款後再全部退回，也可能只是金流退款成功，但發票折讓仍待處理。若資料庫只保存最後狀態，就無法重建每一次金額變動與對應的發票動作。至少要能回答：狀態由誰在什麼時間改變，金額從多少變成多少，哪一個事件觸發發票動作，以及該動作最後取得什麼結果。這份歷程同時是客服查單、會計對帳與工程除錯的共同依據。

網站串接層是翻譯者，也是防重與告警的第一道控制要注意什麼？

網站串接層一邊理解訂單事件，一邊依服務商規格組成請求。除了正常開立，它還要處理資料檢核、機密資訊保護、逾時查詢、錯誤分類、防重、人工接手與告警。日誌不應直接記錄完整 API 金鑰、簽章密鑰、載具明碼或不必要的個人資料。實務上要留下足以追查的請求識別、訂單編號、動作、時間與去識別化結果，同時把秘密放在受權限控管的設定環境，避免「為了除錯」反而造成資料外洩。

分享此文章：

相關文章