發票作廢的串接主要是透過「交易退款」API，並以特定欄位 invoice_state 設值為 6 來表示發票作廢（註銷）。特約商店、經銷商兩種模式發票作廢串接的差異主要在 API 位址及驗證身份欄位，整體流程與欄位結構相似：

兩模式主要差異在參數中是否帶入 agent_uid，以及 API 基本路徑不同，但使用的命令與參數結構一致，均以 api/refund 串接，invoice_state=6 指示發票作廢。

發票折讓（部分退貨/退款的電子發票折讓）操作，需走「交易退款」API 模式，並透過適當資料欄位組合來指定折讓明細。折讓的重點是針對原訂單部分金額進行退款並註記折讓，系統將自動處理電子發票折讓流程。

發票折讓串接流程

• 串接路徑：特約商店 Store 模式用 https://ka.usecase.cc/api/init，經銷商 Agent 模式用 https://ka.usecase.cc/api/agent。
• 條件：必須基於原交易訂單，發送「api/refund」命令。

POST資料結構

1. 帶入原訂單的 uid（MYPAY 交易流水號）、key（交易驗證碼）。
2. 設定 refund 金額（cost，為折讓金額）。
3. 設定 invoice_state = 6（代表折讓處理）。
4. 在 items 欄位中明確列出本次折讓的商品明細（如部分退款時僅列部分商品或數量）。

工作流程與注意事項

發票作廢操作（即「發票折讓」與「發票註銷」），流程需依照訂單建立後的退款或折讓動作完成。作廢發票的正確步驟是利用「交易退款」API，並在資料結構中設定發票處理參數。

發票作廢操作說明

• 必須針對原交易訂單發動退款，API 路徑特約商店 Store 模式為 https://ka.usecase.cc/api/init，經銷商 Agent 模式為 https://ka.usecase.cc/api/agent，並呼叫 cmd = "api/refund"。
• 在 postData 欄位中，帶入原訂單的「uid」（MYPAY交易流水號）以及「key」（交易驗證碼），並且在退款資料裏設定 invoice_state 或相關欄位，表明此次退款屬於「發票作廢」情境。
• 退款單內容必須包含原發票明細（商品資訊、售價等），否則作廢流程無法完整，目前參考範例可設定成：
  • invoice_state = 6（代表作廢或折讓狀態）
  • 退款商品資訊於 items 內正確標明。

注意事項

• 只有成功完成退款動作，才會觸發發票作廢（折讓）流程。
• 若原發票有折讓或其他特殊處理，需依照 API 文件的「發票作廢/折讓」設定所有必要參數，否則系統不會正確註記作廢。
• 作廢僅對「未作廢」發票有效，不得重複註銷同一張發票。

發動發票折讓的方式本質上類似，都是透過「交易退款（api/refund）」API發起折讓請求，但特約商店、經銷商兩模式在使用身分、API介接端點、必要參數等細節上有差異：

發票折讓發動方法（共通點）

• 折讓由「交易退款 API」發起，帶入折讓相關參數（invoice_state 指定為折讓狀態，退款商品明細 items 須與原發票相符）
• 送出資料前需以 AES 256 加密，並以 HTTPS POST 送出
• 發票折讓資料由系統送至財政部電子發票平台完成折讓作業
• 折讓金額與商品明細需與交易、發票一致，支持部分折讓

特約商店 vs 經銷商差異點

結論

• 兩者發動折讓流程原理一致，均透過「交易退款 API」帶入折讓資料發起請求，且均需要加密與 HTTPS 連線安全保護
• 經銷商串接多了 agent_uid 欄位，需要使用經銷商身份金鑰與介接端點，且可代替特約商店執行折讓
• 特約商店則直接使用 store_uid 及其金鑰介接官方 API 端點
• 開發時需根據串接身分取用正確API端點與認證資訊，折讓參數與資料格式本質無異

總之，特約商店與經銷商在技術發動發票折讓的方式上是同源的流程，差別在於 API 介接身分與端點配置，發票折讓參數使用方式是一致的。