- 登入
- 註冊
購物網站怎麼串電子發票？付款、開立、作廢與折讓流程與驗收｜秒站 x 即站力
內容目錄
顯示
一筆測試訂單顯示付款成功，發票服務也回傳「已受理」，不代表電商電子發票串接已經驗收完成。網站還要知道這次付款是否真的符合開票條件，保存訂單與發票的唯一對應，持續取得上傳結果，遇到退款時再依實際情況作廢或開立折讓單。
因此，串接的核心不是把一組 API 金鑰貼進後台，而是先決定每個訂單事件要產生什麼發票動作，再保存服務商與財政部平台的處理結果。少了其中一層，就可能發生重複開票，付款成功卻漏開，或網站顯示已完成，但發票資料仍在等待上傳的落差。
來源：財政部《電子發票實施作業要點》、財政部《電子發票 Turnkey 上線前自行檢測作業》與秒站電子發票設定教學（查證 2026-11-05）。官方資料用來確認電子發票系統、防重、漏上傳、錯誤處理及上傳結果檢測責任；本文將這些要求轉成購物網站的流程設計方法，不取代主管稽徵機關、會計師或稅務代理人的個案判斷。
只需要外部收款連結時，發票可以怎麼安排？
若官網負責介紹，付款另用立即付連結，可評估其電子發票加值，支援商家自有 ezPay、光貿或 Giveme 帳號。這套是 pay 平台串接，不是秒站購物車自動附贈；Giveme 沒有測試環境與自動折讓，要特別安排正式開票及手動異動。
功能與限制來源：立即付教學資源與商家操作教學（2026 年 11 月 5 日核對）。
先看立即付開票、退款與服務商限制，並確認哪個系統負責開立，避免官網與收款頁重複開票。
先到即站力立即付建立商店，或在秒站建立網站或商店，準備商品、服務與網站資訊；接著到 SLP 申請 SHOPLINE Payments。核准後回到原平台設定金鑰並完成串接，再測試付款、退款與對帳。可申請信用卡 2.4% 合作方案，最終費率、支付方式與條件依審核結果，稅額與其他費用依核准契約確認；數字與付款方式先核對秒站合作費率表。
電商電子發票串接是什麼？
電商電子發票串接，是把購物網站的交易事件轉成正確的發票動作，送到電子發票服務，再把處理結果寫回訂單與對帳紀錄的完整流程。它至少包含「辨識事件、決定動作、傳送資料、確認結果」四個步驟，不能只用「付款後呼叫開票 API」概括。
先分清楚訂單事件、發票動作與處理結果
同一筆交易在三套系統中，會有三種不同語言：
- 訂單事件：例如付款成功、付款失敗、取消訂單、全部退款或部分退款。這一層描述交易發生了什麼事。
- 發票動作：例如開立、作廢、開立折讓、作廢折讓、查詢或重新傳送。這一層描述系統接下來要做什麼。
- 處理結果：例如請求未送出，服務商拒絕，服務商已受理，等待上傳，平台檢核成功或平台回覆錯誤。這一層描述動作走到哪裡。
API 是傳遞指令的管道，不會替商家決定稅務規則
API 是 Application Programming Interface，中文常譯為應用程式介面。白話來說，它是一套讓購物網站把開票資料送到發票服務，並接收處理結果的規則。
來源：光貿電子發票 API 文件（查證 2026-11-05）。文件目前將 OrderId 列為不可重複的訂單編號，並提供發票狀態查詢；本文只用它說明單一服務商的實作例，不把欄位長度、端點或狀態碼通用到其他廠商。
防止重複開票要靠冪等設計，不是禁止人工重按
冪等性對應英文 Idempotency，意思是同一個業務請求即使因逾時或重送執行多次，也不會多產生一張發票。它不是某一把通用的「防重金鑰」，而是唯一業務編號、資料庫狀態、服務商規則與重送流程共同形成的結果。
- 網站先用「商店識別＋訂單編號＋業務事件識別＋發票動作」建立唯一請求。同一事件重送沿用識別；同張訂單的不同部分退款各有事件 ID，不能用訂單編號加動作合併成一筆。
- 傳送前檢查本地端是否已有成功結果，或已有處理中的同類請求。
- 連線逾時時先查詢原請求狀態，不立刻換新編號再開一次。
- 只有確認原請求沒有成立，且符合重送規則時，才進入重新傳送。
金流、訂單、網站、加值中心與財政部如何分工？
購物網站發生漏開或重複開票時，最常見的溝通問題是每個人都說「自己的系統顯示成功」。原因不是某一方一定有錯，而是金流成功、訂單完成、開票請求受理及平台存證成功，本來就是不同事件。專案開始前應先做責任分工表，並為每一段指定可查詢的證據。
| 角色 | 主要負責什麼 | 不代表什麼 | 驗收時應取得的證據 |
|---|---|---|---|
| 營業人與會計窗口 | 決定開票時點、B2B 或 B2C 資料、稅別、退貨處理及人工覆核原則 | 不代表已完成程式串接 | 書面事件規則、例外處理表及會計確認紀錄 |
| 金流服務 | 回傳授權、請款、付款與退款等金流結果 | 付款成功不等於發票已開立；退款成功也不等於原發票已處理 | 金流交易編號、付款狀態、退款金額及事件時間 |
| 訂單系統 | 保存商品、買受人、金額、付款、出貨及退款狀態 | 訂單改成「完成」不代表外部發票服務已成功 | 訂單歷程、狀態變更來源、操作者及時間 |
| 網站串接層 | 把訂單事件映射成發票動作，簽署並傳送請求，保存回覆，查詢結果及告警 | HTTP 連線成功不代表發票業務處理成功 | 唯一請求編號、去識別化日誌、回傳內容，重送與告警紀錄 |
| 加值服務中心或發票服務 | 接收與檢核開票資料，依服務範圍配號、傳輸、保存或提供查詢 | 收到 API 請求不代表財政部平台已完成檢核 | 發票號碼、服務商處理狀態、上傳結果及錯誤明細 |
| 財政部電子發票整合服務平台 | 接收與檢核符合規範的電子發票資料，提供相關整合性服務 | 不管理購物網站訂單，也不替商家決定何時開票 | 平台成功回覆、查詢結果及符合規範的留存紀錄 |
付款成功只解答「錢的狀態」
金流系統可以告訴網站授權是否成功，款項是否已請領，或退款是否受理。它無法單獨決定買受人資料是否完整，訂單是否要拆票，以及此刻是否符合商家的開票規則。
訂單系統要保存事件歷程，不能只看最後狀態
一張顯示「已退款」的訂單，可能歷經部分退款後再全部退回，也可能只是金流退款成功，但發票折讓仍待處理。若資料庫只保存最後狀態，就無法重建每一次金額變動與對應的發票動作。
網站串接層是翻譯者，也是防重與告警的第一道控制
網站串接層一邊理解訂單事件，一邊依服務商規格組成請求。除了正常開立，它還要處理資料檢核、機密資訊保護、逾時查詢、錯誤分類、防重、人工接手與告警。
加值中心受理後，還要繼續確認上傳結果
財政部作業要點將加值服務中心定義為經核准提供電子發票系統及相關加值服務的營業人，並要求其與整合服務平台介接，負責交換與上傳電子發票資料，或接收相關資訊。購物網站透過加值中心開票時，仍應確認服務合約涵蓋哪些工作，以及哪一種狀態才代表平台已成功接收。
來源：財政部《電子發票實施作業要點》與財政部《電子發票 Turnkey 上線前自行檢測作業》（查證 2026-11-05）。當日正式檢測文件為 2026 年 8 月 20 日 v4.8.1，適用 MIG 4.1 的 Turnkey 傳輸，要求確認結果、處理錯誤及比對筆數；採加值中心 API 時，狀態名稱、查詢與完成條件仍依所選服務商文件及契約確認，不把 Turnkey 的代碼當跨廠商標準。
哪些訂單事件要對應開立、作廢、折讓、註銷與重送？
訂單狀態與發票動作不能做成一對一的名稱對照。例如「已退款」只說明款項處理結果，沒有告訴系統是全額或部分退款，原發票是否已完成平台存證，是否曾開立折讓單，以及會計上應採哪一種處理方式。
| 訂單或系統事件 | 判斷前提 | 常見的候選動作 | 自動化前必須確認 | 完成證據 |
|---|---|---|---|---|
| 建立訂單但尚未付款 | 尚未到依法確認的開票時點，且沒有其他應開立事由 | 不開票，持續等待 | 哪些付款方式會延後確認，訂單多久失效 | 訂單仍無發票請求 |
| 付款失敗或付款前取消 | 原發票不存在，亦無已發貨或預收款等應開立事由 | 不因這次失敗付款建立新發票 | 沒有其他成功付款交易與同訂單綁定 | 付款失敗紀錄及無開票紀錄 |
| 付款或履約條件已確認 | 原發票不存在，買受人資料完整 | 建立開票請求 | 依適用稅務規定確認的開票時點、交易金額、稅別及買受人資料 | 發票號碼與平台成功狀態 |
| 收到重複付款通知 | 同一交易可能已處理 | 查詢原請求，不建立新發票 | 唯一業務編號與本地端處理狀態 | 查詢結果及未新增發票 |
| 發票請求逾時 | 無法判斷原請求是否成立 | 先查詢，再依結果決定是否重送 | 服務商查詢方式、重送規則及防重能力 | 原請求結果或同一業務請求的重送結果 |
| 發票已開立，整筆交易取消或全額退回 | 要確認發票狀態、交易時間、申報狀況及既有折讓 | 作廢或開立全額折讓單，由個案規則決定 | 會計確認，加上買受人同意與服務商限制 | 作廢或折讓完成狀態及同意紀錄 |
| 發票已開立，只有部分商品或金額退回 | 原發票保留部分有效交易 | 依實際退回內容開立折讓單 | 退回品項、數量、未稅金額、稅額及原發票 | 折讓單號碼、金額與平台成功狀態 |
| 發票內容有誤 | 要分辨資料是否錯誤，交易是否變動，以及是否已申報 | 依規定作廢重開、申請更正或其他核准程序 | 錯誤類型、發票狀態、買受人處理情形及主管機關要求 | 正確的新紀錄與原紀錄處理證據 |
| 字軌無效、重號或用盡 | 系統不能合法取得可用發票號碼 | 暫停自動開立並告警 | 當期電子發票專用字軌、剩餘號碼及配號資料 | 告警及補正紀錄，以及恢復開票測試 |
| 服務商或平台回覆資料錯誤 | 原請求尚未成功 | 修正資料後重送同一業務動作 | 錯誤碼，以及可修改欄位及原請求是否成立 | 錯誤已排除且最終狀態成功 |
開立時點先依法確認，再映射網站事件
「處理中」「已付款」「已完成」在不同購物系統可能代表不同事情。先依營業稅法第 32 條及適用的銷售憑證時限確認開立時點，再把合法時點映射到網站事件；商家不能單靠後台設定，任意把已到期的開票延後。以一般買賣業銷售貨物為例，原則於發貨時開立，發貨前已預收的貨款則於收款時先開；特殊交易及約定仍須按適用規定確認。財政部買賣業開立時點說明、營業稅法第 32 條。財政部的網購案例談的是符合條件的發票延後寄發，與延後開立不同；電子發票還要遵守獨立的存證期限。
全額退款不代表每次都能直接作廢
全額退款只表示款項全部退回，不能單獨決定發票處理。原發票若已開立，系統還要看發票是否已申報，是否已有折讓紀錄，以及適用的服務商與稅務程序。某些情況可以作廢，某些情況則要用全額折讓或其他程序處理。
部分退款要回到原發票逐項核對
部分退款通常不能把整張原發票作廢，因為仍有一部分交易成立。系統要把退款品項與原發票內容連回來，計算實際退回的銷售額及稅額，再依規定開立折讓單。
註銷不是一般退款流程的替代名稱
依財政部 2026 年 9 月 17 日版 MIG 4.1：F0501 是平台存證作廢發票，F0701 是平台存證註銷發票，G0401 是平台存證開立折讓證明單，不能互換。F0701 章節明示，應記載事項錯誤及銷貨退回、掉換或折讓，不能用註銷功能代替適用處理。實作要按交易事實、當前介接環境與服務商文件決定，不再以舊 MIG 4.0 當現行唯一依據。
來源：財政部《電子發票實施作業要點》、財政部《統一發票使用辦法》與財政部《電子發票資料交換標準訊息建置指引 MIG 4.1》（查證 2026-11-05）。現行規範涵蓋發票開立及更正，也涵蓋作廢及銷貨退回或折讓，並要求相關資訊傳輸與留存；MIG 文件分別定義 F0501 作廢發票、F0701 註銷發票及 G0401 折讓證明單。本文表格是系統需求分析框架，實際動作仍須依交易事實、發票狀態、服務商規格及專業稅務判斷確認。
開立、折讓與上傳存證，要分開設期限
「開立時點」與「開立後多久上傳」是兩個時鐘。即使系統每天有對帳，若只看是否排進佇列，仍可能錯過平台存證期限。自 2025 年 1 月 1 日起的現行規定，電子發票銷貨退回或折讓經雙方合意後，應由賣方開立電子折讓並依限存證；輔導期已在 2025 年 6 月 30 日結束。
| 要核對的事 | 當日規範與系統做法 |
|---|---|
| 發票開立時點 | 先依交易適用的銷售憑證時限設定事件，不能拿付款失敗、尚未出貨或鑑賞期當通用延後理由。 |
| 開立、更正、作廢或折讓的存證 | 由該次發票開立、更正、作廢或折讓單開立的翌日起算：買受人為營業人 7 日內，非營業人 2 日內；末日遇星期六、日、國定假日或其他休息日不延長。 |
| 買受人同意及證明 | 依電子發票實施作業要點，保存同意訊息與相關證明文件至少 5 年；這不表示把完整金鑰或不必要個資寫入日誌。 |
| 對帳與告警 | 在每次事件記錄法定到期日、服務商狀態、平台結果及負責人；到期前仍未有完成證據就告警，不能把「受理中」當完成。 |
假設 2026 年 11 月 6 日星期五開立給非營業人的電子發票，翌日 7 日算第 1 日，8 日星期日算第 2 日；不能自行順延到星期一。這是日數示例，不是實際開票紀錄；如有不可抗力等特殊事由，須依時限表的補正申請規定辦理，不是系統自動展延。
依據：財政部存證資訊範圍及時限表、電子折讓由賣方開立之令及電子發票實施作業要點第九點，2026-11-05 核對。
哪些情境可以自動處理，哪些需要人工覆核？
自動化的判斷標準不是「這個動作常不常發生」，而是輸入是否完整，結果是否可逆，以及發生錯誤時能否被系統可靠攔下。條件單純，結果明確，而且狀態可供查詢的事件適合自動處理；涉及稅務判斷、跨期、金額分攤或資料衝突的事件，應先停在人工覆核佇列。
| 情境 | 建議模式 | 可以自動化的部分 | 應轉人工的條件 |
|---|---|---|---|
| 已驗證付款且首次開票 | 條件式自動 | 資料檢核與防重，接著送出，查詢並寫回結果 | 買受人資料缺漏、稅別不明、金額不一致或字軌異常 |
| 重複付款通知 | 自動查詢 | 以唯一交易識別查詢原請求並忽略重複事件 | 查到多張發票或本地紀錄與服務商不一致 |
| 暫時性連線失敗 | 自動查詢後有限重送 | 依退避規則查詢，確認未成立後重送 | 查詢無法判定，連續失敗超過門檻或回覆互相衝突 |
| 格式或必填欄位錯誤 | 自動攔截 | 在送出前檢查統編、載具、捐贈碼及金額格式 | 顧客提供的資料互相衝突，或修改會改變發票類型 |
| 全額退款 | 條件式自動或人工 | 蒐集原發票和退款資料，以及既有折讓狀態 | 跨期、已申報、已有折讓，買受人不同意或規則無法唯一判定 |
| 部分退款 | 以人工覆核起步 | 自動計算候選折讓明細與剩餘可折讓金額 | 多次退款、折扣分攤、運費退回、組合商品或計算差額 |
| B2B 買受人資料變更 | 人工覆核 | 驗證統一編號格式及保存異動紀錄 | 發票已開立，買方已接收或資料涉及更正程序 |
| 海外、零稅率或特殊稅別 | 人工覆核 | 蒐集國別、交易與證明資料 | 稅別或適用條件尚未由專業人員確認 |
| 字軌異常或平台狀態矛盾 | 暫停自動化 | 發出告警，停止新請求，並產出待處理清單 | 管理者確認並完成補正前，一律不自動恢復 |
正常開立可以自動化，但要有五道閘門
一筆訂單要自動開票，至少應通過五項檢查：
- 付款或其他核定的開票事件已由伺服器端證據確認。
- 訂單金額、稅額與明細已凍結，沒有待處理的取消或退款。
- 買受人需要的統編、載具或捐贈資料已通過適用檢核。
- 同一業務事件沒有成功或處理中的開票請求。
- 正式環境、有效字軌與服務商連線狀態都可使用。
B2C 與 B2B 只描述交易對象，不能代替流程判斷
B2C 是 Business-to-Consumer，直譯為企業對消費者，常用來描述買受人為一般消費者的交易。B2B 是 Business-to-Business，直譯為企業對企業，常用來描述買賣雙方都是營業人的交易。
退款自動化應從「輔助判斷」開始
初次上線時，可以讓系統自動蒐集原發票狀態、退款金額、退回品項與歷次折讓，再產生候選動作給人確認。等團隊累積足夠案例，確認規則沒有灰區，再把其中條件單純的類型改成自動執行。
自動重送必須設定停止條件
重送不是每隔幾分鐘重打一遍同一支 API。系統要先區分連線逾時、可修正的資料錯誤、權限錯誤及服務商已受理但尚未完成。只有確認原請求未成立，且錯誤類型允許重試時，才進入有限次數的重送。
來源：財政部《電子發票 Turnkey 上線前自行檢測作業》、光貿電子發票 API 文件與綠界作廢折讓發票 API 文件（查證 2026-11-05）。官方檢測文件要求字軌、重號、漏上傳、錯誤訊息及傳輸結果檢核；兩家服務商文件顯示實際端點、欄位、狀態與限制並不相同。本文因此只提供自動化控制原則，不把單一廠商的 API 行為寫成通則。
電子發票串接前要準備哪些資料、字軌、帳號與權限？
串接前要準備的不只是一組 API 密鑰。完整輸入至少分成四包：營業與稅務資料、電子發票字軌、結帳與訂單規則，以及服務商的測試與正式介接資料。四包資料少一包，工程團隊即使能送出請求，也可能無法完成合法開立與對帳。
營業與稅務資料先由負責人確認
第一包資料回答「誰在開票，以及這筆交易應如何記錄」。至少要確認賣方統一編號、營業人使用電子發票的適用程序、常見交易稅別、開票時點，以及遇到特殊交易時由誰判斷。
電子發票字軌要確認來源、期別與分配方式
電子發票字軌不是網站自行產生的一串號碼。串接前要確認正式營運可使用的電子發票專用字軌，也要確認目前期別與配號方式，並記錄可用餘量及異常通知人。若採服務商自動配號，也要知道服務商如何處理即將用盡、期別切換與配號失敗。
結帳資料要先定義 B2B、B2C、載具與捐贈規則
結帳頁會決定網站能否取得正確的買受人資料。規格至少要涵蓋一般消費者，也要涵蓋需要統編的企業買受人、手機條碼或其他載具，以及捐贈碼。每一種選項都要定義必填欄位、格式檢查、互斥關係與錯誤提示。
測試與正式介接資料要分開保存
測試環境與正式環境應有不同的設定組，至少分開保存下列資料：
- 環境名稱及服務商。
- 測試或正式統一編號與商家識別。
- 發票動作使用的 API 網址，以及查詢網址與通知網址。
- 密鑰版本與啟用日期，以及負責保管的人員。
- 來源主機或網路白名單。
- 配號模式與字軌設定。
- 告警收件人及人工覆核窗口。
如何從訂單狀態機與 API 設定走到正式驗收？
正式驗收不是完成一筆測試開票，而是證明正常事件能完成，重複與錯誤事件不會多開，退款能進入正確流程，而且訂單筆數能與服務商及平台結果對上。可以依「畫出狀態，定義映射，設定環境，執行測試，完成首批對帳」五個階段推進。
訂單狀態機先畫出允許的移動方向
State Machine 直譯為狀態機。白話來說，它是一張規則圖，列出一筆訂單現在處於什麼狀態，收到什麼事件後可以移到哪裡，以及移動時要執行什麼動作。
事件映射表要寫清楚輸入、動作與輸出
每條狀態轉換都要形成一列需求。輸入要記錄原訂單狀態與事件來源，也要包含交易金額及原發票狀態；動作則要明確寫成開立、查詢、作廢、折讓或轉人工；輸出要留下新狀態與發票號碼，也要保存服務商回覆、平台結果及日誌。
測試環境設定完成後先跑連線與權限檢查
進入業務測試前，先確認測試程式確實讀到測試設定。可以在不顯示密鑰的前提下，記錄環境名稱、商家識別末幾碼、密鑰版本及 API 主機，讓測試人員辨認目前沒有連到正式資料。
正常與例外案例要用同一張測試矩陣驗收
測試矩陣至少要涵蓋以下十種情境：
| 測試情境 | 預期發票行為 | 必須驗證的防錯點 | 驗收證據 |
|---|---|---|---|
| 首次付款成功 | 建立一張發票並取得最終成功結果 | 交易金額符合預期，買受人與稅別也相符 | 訂單歷程、發票號碼及平台結果 |
| 同一付款通知重送兩次 | 查詢原請求，不新增發票 | 唯一業務編號生效 | 通知兩次，發票仍為一張 |
| 開票請求送出後逾時 | 先查詢原請求，再決定是否重送 | 結果未知時不換新編號開票 | 查詢紀錄、重送決策及最終結果 |
| 統編或載具資料錯誤 | 送出前攔截，或明確進入錯誤狀態 | 不以預設值掩蓋顧客輸入錯誤 | 欄位錯誤訊息及無新發票 |
| 全額退款 | 依核定規則作廢、折讓或轉人工 | 不只用退款金額決定動作 | 原發票狀態、決策紀錄及完成結果 |
| 部分退款 | 依退回明細建立折讓候選或折讓單 | 累計折讓不超過可折讓餘額 | 品項、金額、稅額及折讓結果 |
| 服務商回覆可修正錯誤 | 修正後以原業務事件重送 | 不產生第二張發票 | 錯誤、修正、重送與查詢歷程 |
| 字軌無效或用盡 | 停止新開票並告警 | 不自行產生號碼，不無限重試 | 告警、待辦及恢復測試 |
| 正式密鑰誤放測試環境 | 測試立即停止 | 設定檢查能辨識環境不符 | 阻擋紀錄及密鑰更換紀錄 |
| 訂單與平台筆數不一致 | 產生差異清單，不宣告驗收完成 | 每一筆差異都有狀態與負責人 | 對帳表、差異原因及處理期限 |
重複開票、漏開、資料錯誤、退款與資安風險如何控管？
電子發票串接最危險的狀況，不一定是 API 無法正常連線。連線失敗通常看得見，系統半成功卻沒有留下可追查狀態，反而更容易造成重複開票、漏開或帳務不一致。
用「預防、偵測、停止、復原」管理每一項風險
可以先建立一張風險登錄表：
| 風險 | 預防機制 | 偵測證據 | 停止條件 | 復原方式 |
|---|---|---|---|---|
| 同一訂單重複開票 | 唯一業務編號與防重鎖 | 同一事件出現多筆請求或多張發票 | 查到既有成功或結果未知 | 查詢原請求，確認唯一結果 |
| 符合條件的訂單漏開 | 開票佇列與每日對帳 | 訂單完成但沒有開票請求 | 超過允許等待時間 | 補建待辦，確認後以原事件處理 |
| 買受人或金額資料錯誤 | 送出前欄位檢核 | 服務商拒絕或人工對帳差異 | 欄位互相衝突或金額不平 | 修正來源資料後重新覆核 |
| 退款動作錯誤 | 先查原發票與累計異動 | 退款金額與發票異動不一致 | 規則不能唯一判定 | 轉人工決定作廢或折讓流程 |
| 字軌或權限失效 | 到期前告警與環境檢查 | 服務商回覆拒絕或可用量異常 | 連續錯誤超過門檻 | 停止新請求，補正後跑回歸測試 |
| 密鑰或個人資料外洩 | 最小權限與日誌遮罩 | 異常存取或日誌出現敏感欄位 | 疑似外洩即停用 | 換發密鑰，清查範圍並驗證恢復 |
重複開票要從業務事件防重
付款通知可能重送，工作佇列可能重新執行，管理員也可能在等待時手動按一次開票。若三條路徑各自產生新請求，API 本身即使沒有故障，也可能出現多張發票。
- 資料庫不允許同一業務編號建立兩筆有效請求。
- 工作者送出前取得防重鎖，確認沒有其他程序正在處理。
- 發生逾時時先查原請求，不立刻換一個新編號重送。
漏開要靠正向清單找出來
只看失敗日誌找不到「根本沒有建立請求」的訂單。漏開偵測要從訂單端建立正向清單：先逐一找出符合開票條件的訂單，再比對每一筆是否有對應的開票請求與平台結果。
- 假設某日應處理訂單 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 元。
退款總額對上了，還要核對含稅與未稅欄位
上例的 300 元是假設全部來自原發票商品的退款，所以用來示範金流、訂單與發票異動的總額對帳；它不是任何服務商欄位都可直接填入的通用數字。先逐項確認退回品項、數量、折扣分攤、運費及原稅別，再依所選文件換成正確欄位。
| 資料來源或欄位 | 實際金額口徑 | 驗收時看什麼 |
|---|---|---|
| 金流退款金額 | 實際退回的款項；不是未稅銷售額欄位。 | 保存退款事件及可對應的退回明細；若含其他費用或差額，說明為何與發票異動不同。 |
| 綠界 B2C 通知折讓 AllowanceAmount | 該端點定義為折讓單含稅總額，需大於 0 並不超過可折讓餘額。 | 核對該 API 版本及各品項加總，不把此定義搬到其他廠商。 |
| 財政部 MIG 4.1 G0401 的 TotalAmount | 國內營業人為不含稅進貨額合計；營業稅合計另列 TaxAmount，兩者須依文件填整數。 | 不能因名稱叫 TotalAmount，就把金流退款含稅額直接當未稅合計；境外電商另有填法，本文不混用。 |
應稅、零稅率或免稅的原票明細不能全部乘同一個 5%；也要按規定處理四捨五入及多次退款後的剩餘金額。若原稅別、分攤或差額不能確認，先留人工覆核，不為了讓三邊數字看起來相等而改掉稅額。MIG 4.1 G0401，第 104–106 頁與綠界通知折讓的金額欄位。
折讓 API 回成功，仍可能只完成暫存
以綠界 B2C 的「線上開立折讓（通知開立）」為例，API 成功只代表暫存折讓資料；買受人點擊 Email 的同意連結時，折讓單才開立，再進入上傳流程。該連結有效 72 小時，正式文件也提醒測試環境不寄 Email。因此，驗收要分開記錄「已送同意通知、買受人已同意、折讓已開立、平台存證完成」，並處理逾期或未同意；不能由一個成功碼推成已開立或已完成存證。這是該端點的例子，其他服務商依各自同意及通知方式驗收。綠界當期完整通知折讓流程。
同一案例換成全額退款，動作也不能直接複製
若退款金額改成 1,260 元，系統可以判定這是全額退款，卻仍不能只因金額相等就自動選擇作廢。還要確認原發票的處理與申報狀態，也要核對買受人身分、既有異動及商家核定流程。
案例驗收要看唯一性、完整性與可追溯性
成功付款案例證明唯一性：重複通知不會多開。部分退款案例證明完整性：金流、訂單與發票異動金額可以對上。兩個案例都要證明可追溯性：經授權且有需要的人員，能依職責從業務事件找到請求、服務商結果、平台狀態與核准紀錄。
來源：財政部《統一發票使用辦法》、綠界作廢折讓發票 API 文件與綠界查詢發票確認 API 文件（查證 2026-11-05）。法規用來確認電子發票異動要依交易事實與適用程序處理；所引綠界文件分別為 B2B 存證作廢折讓與 B2B 交換查詢發票確認，後者確認買受人接收資訊，不是通用 B2C 平台上傳成功查詢；平台存證仍另核服務商狀態及官方接收結果。案例中的狀態名稱、唯一業務編號與金額皆為本文示意，不是服務商固定欄位。
內文精華總結
- 電商電子發票串接是什麼：電商電子發票串接，是把購物網站的交易事件轉成正確的發票動作，送到電子發票服務，再把處理結果寫回訂單與對帳紀錄的完整流程。
- 先分清楚訂單事件、發票動作與處理結果：「付款成功」不等於「發票已開立」，「服務商收到請求」也不等於「財政部平台已完成存證」。
- API 是傳遞指令的管道，不會替商家決定稅務規則：API 是 Application Programming Interface，中文常譯為應用程式介面。
- 防止重複開票要靠冪等設計，不是禁止人工重按：冪等性對應英文 Idempotency，意思是同一個業務請求即使因逾時或重送執行多次，也不會多產生一張發票。
想把電商電子發票串接規劃成能長期營運的網站？
先用秒站建立可操作的網站，再依實際內容、功能與營運需求調整。你可以先試用，查看方案，或從真實案例確認適合自己的方向。
- 4 小時免費試用：不必信用卡，先確認後台與編輯流程是否適合。
- 查看秒站方案：標準方案 NT$24,000、專業方案 NT$36,000、輕電商方案 NT$48,000 首年費用。主方案含稅，網域、加購與第三方費用另計；站內金流與電子發票依專業方案，實體物流依輕電商方案，服務商資格、費用與加值另行確認。
- 瀏覽真實網站案例：從不同產業的內容、版型與功能安排找參考。
組織收款要先分清發票與捐款收據
立即付發票加值是交易發票工具，不會自動產生捐款收據、抵稅證明或徵信名冊。協會、基金會及宗教團體應先由團隊確認個案資格，再依線上捐款資格與收據規劃安排憑證責任。
延伸閱讀
電子發票系列文章
秒站現在不只是一套版型。你可以從現成架構快速開始，用頁面編輯器以拖曳和複製區塊的方式調整版面；需要更高自由度時，也能和 AI 協作，把自製頁面放進 Vibe 畫布。不同頁面可依需求搭配；正式發布前仍須核對內容、版面與互動。
秒站所說的「輕電商」，輕的是適用的營運量級，不是功能。電商行銷百寶箱把商品上架、折價券、訂單通知、付款與運送規則，以及折扣活動集中在同一套後台，再接上金流、發票與物流，讓中小品牌建立從商品上架到訂單溝通的銷售流程；購物點數屬另行加購與開通的模組，不因串好發票就自動包含。
重點整理
電商電子發票串接是什麼？
電商電子發票串接，是把購物網站的交易事件轉成正確的發票動作，送到電子發票服務，再把處理結果寫回訂單與對帳紀錄的完整流程。它至少包含「辨識事件、決定動作、傳送資料、確認結果」四個步驟，不能只用「付款後呼叫開票 API」概括。
付款成功，就代表發票已開立嗎？
「付款成功」不等於「發票已開立」，「服務商收到請求」也不等於「財政部平台已完成存證」。網站若只保存一個「已開票」勾選值，就無法分辨請求是否仍在排隊，傳輸失敗，或已經取得平台成功結果。較穩定的資料設計，會分成七個欄位：訂單編號、發票服務商、發票號碼、動作類型、請求時間、服務商回覆及平台狀態。實際欄位名稱與狀態碼依服務商文件為準，不應把某一家廠商的代碼直接當成跨廠商標準。
API 會替商家決定開票時點嗎？
API 是應用程式介面，負責傳送資料與接收結果，不替商家決定稅務規則。先依適用的銷售憑證時限確認開立時點，再映射到付款、發貨或其他合法事件；一般買賣業銷售貨物原則於發貨時開立，但發貨前已預收的貨款應於收款時先開，不能只靠後台狀態延後。退款採作廢、折讓或其他程序，也要先依交易事實與原票狀態確認。
如何避免重送造成重複開票？
冪等性對應英文 Idempotency，意思是同一個業務請求即使因逾時或重送執行多次，也不會多產生一張發票。它不是某一把通用的「防重金鑰」，而是唯一業務編號、資料庫狀態、服務商規則與重送流程共同形成的結果。財政部現行作業要點要求電子發票系統具備防止字軌號碼開立錯誤、重複及漏未上傳的檢核功能。當日 v4.8.1／MIG 4.1 的 Turnkey 自行檢測文件也把重號、漏上傳、錯誤回應與每日筆數比對列為檢測項目。
金流、訂單、網站、加值中心與財政部如何分工？
金流負責付款結果；訂單系統保存交易與退款事件；網站串接層依規則決定發票動作並防止重複；加值中心依契約接收、交換及上傳資料；財政部平台負責接收與檢核。每一步都要留下事件 ID、時間與處理結果，才能對帳。
可以依付款完成頁直接開票嗎？
金流系統可以告訴網站授權是否成功，款項是否已請領，或退款是否受理。它無法單獨決定買受人資料是否完整，訂單是否要拆票，以及此刻是否符合商家的開票規則。網站也不能只憑顧客回到付款完成頁就開票。顧客可能中途關閉頁面，付款頁也可能被重整；正式流程應以可驗證的伺服器端通知或主動查詢結果更新付款狀態，再依已確認的商業規則建立開票請求。不同金流商的通知、查詢與重送規格不同，必須以實際介接文件為準。
退款後為什麼還要保存訂單事件？
一張顯示「已退款」的訂單，可能歷經部分退款後再全部退回，也可能只是金流退款成功，但發票折讓仍待處理。若資料庫只保存最後狀態，就無法重建每一次金額變動與對應的發票動作。至少要能回答：狀態由誰在什麼時間改變，金額從多少變成多少，哪一個事件觸發發票動作，以及該動作最後取得什麼結果。這份歷程同時是客服查單、會計對帳與工程除錯的共同依據。
發票串接需要記錄哪些除錯資訊？
網站串接層一邊理解訂單事件，一邊依服務商規格組成請求。除了正常開立，它還要處理資料檢核、機密資訊保護、逾時查詢、錯誤分類、防重、人工接手與告警。日誌不應直接記錄完整 API 金鑰、簽章密鑰、載具明碼或不必要的個人資料。實務上要留下足以追查的請求識別、訂單編號、動作、時間與去識別化結果，同時把秘密放在受權限控管的設定環境，避免「為了除錯」反而造成資料外洩。
可以等鑑賞期結束，才開立電子發票嗎？
不能把鑑賞期當成通用延後開票理由。先依營業稅法及適用的銷售憑證時限確認；一般買賣業銷售貨物原則於發貨時開立，預收貨款則於收款時先開。符合條件的實體發票緩寄，也不等於可以緩開；電子發票還有獨立的存證期限。
電子發票與折讓資料多久內要傳輸存證？
現行時限表對發票開立、更正、作廢或開立電子折讓單，從該次事件翌日起算：買受人為營業人 7 日內，非營業人 2 日內；末日遇週末或國定假日等休息日不延長。系統要逐事件追完成結果，不把服務商受理中當存證成功；特殊補正依主管機關規定申請。
退款金額可以直接填進發票 API 的 TotalAmount 嗎？
要先看該欄位的定義。綠界 B2C 通知折讓的 AllowanceAmount 是含稅總額；MIG 4.1 G0401 的 TotalAmount 對國內營業人卻是未稅進貨額合計，營業稅合計另列 TaxAmount。先對原票品項、稅別、折扣與運費及剩餘可折讓額，不能只因名稱相似就互抄，也不能全部乘 5% 代替核稅。
折讓 API 回傳成功，就代表折讓已開立了嗎？
不一定。綠界 B2C 通知折讓端點成功僅代表暫存，消費者點擊 Email 同意連結才開立，之後仍要確認上傳結果；該連結 72 小時有效，測試環境不寄 Email。分別記錄通知、同意、開立與平台結果，依服務商文件處理未同意、逾期或失敗，不能套一個成功碼到所有服務。
