{"content_id":"dtvo1yuy0p","slug":"ai-payment-feature-7-core-decisions","locale":"zh-hant","schema_type":"TechArticle","category":"how_to","category_name":"操作教學","title":"用AI打造支付功能前必須先決定的7件事","summary":"AI可以快速產生支付程式碼，但支付功能的安全性取決於訂單狀態、退款期限、部分退款、防止重複付款等政策設計。尤其是韓國電子商務服務，必須在開發需求中明確反映撤回申購、退款延遲利息、退款規定告知、避免暗黑模式等事項。","author":{"name":"injoys","url":"https://injoys.com/ko/about"},"key_points":["支付功能不只是單純的信用卡授權功能，而是連結訂單、結算、退款、客戶應對與法律告知的營運系統。","訂單狀態應定義為等待付款、付款完成、取消、退款進行中、退款完成等，讓客戶與營運人員能以相同意義理解。","在韓國電子商務中，一般需要考慮消費者的撤回申購期間、業者的退款處理期限，以及延遲利息規定。","防止重複付款僅靠停用按鈕並不足夠，還需要伺服器端的冪等性金鑰、訂單鎖定與支付授權重複檢查。","隱藏退款規定和取消方法，或讓解約變得困難的設計，會損害客戶信任，並提高暗黑模式監管風險。"],"content_markdown":"## 核心摘要\n\n把付款功能交給 AI 時，最危險的提示詞就是單純要求「幫我加上付款」。付款不是收錢的程式碼，而是負責金流的營運、會計、客服系統。\n\n從技術上來說，AI 可以快速實作付款視窗串接、呼叫授權 API、接收 webhook、儲存訂單。然而，如果沒有先決定以下政策，實際服務中就可能發生幽靈訂單、重複付款、退款延遲、客服中心爆量、法律告知遺漏等問題。\n\n| 決策領域 | 事前必須決定的問題 | 失敗時的風險 |\n|---|---|---|\n| 訂單狀態 | 訂單會依序經過哪些狀態？ | 已付款但沒有訂單的幽靈訂單發生 |\n| 退款期限 | 如何反映撤回要約與退款處理期限？ | 違反法定期限、延遲利息、爭議風險 |\n| 部分退款 | 如何計算部分商品退貨、優惠券、運費？ | 營運人員每次都要手動計算，客戶不信任 |\n| 重複付款 | 如何防止同一筆訂單被收取兩次付款？ | 客戶依信用卡帳單提出不滿，信任下降 |\n| 失敗 안내 | 如何告知超過額度、餘額不足、認證失敗？ | 重試轉換率下降，不必要的詢問增加 |\n| 付款紀錄 | 客戶在哪裡確認付款與退款狀態？ | 客服中心詢問增加，狀態不透明 |\n| 退款告知 | 退款規定與取消按鈕要放在哪裡？ | 黑暗模式爭議、法規風險 |\n\n## 1. 訂單狀態設計：狀態就是營運語言\n\n製作付款功能時，訂單狀態不能只有「訂單完成」一種。實際訂單會經過付款嘗試、授權、取消、退款、失敗、逾期等多個階段。\n\n### 建議狀態範例\n\n| 狀態代碼範例 | 顯示給客戶的狀態 | 意義 |\n|---|---|---|\n| `payment_pending` | 等待付款 | 訂單已建立但付款尚未完成 |\n| `paid` | 付款完成 | 付款授權已完成，訂單有效 |\n| `payment_failed` | 付款失敗 | 付款嘗試失敗，需要判斷是否可重試 |\n| `cancel_requested` | 取消申請 | 客戶已申請取消，等待處理中 |\n| `cancelled` | 取消完成 | 付款前訂單取消或授權取消已完成 |\n| `refund_requested` | 退款申請 | 付款後的退款申請已受理 |\n| `refund_processing` | 退款進行中 | 正在處理退款核准或付款方式退款 |\n| `partially_refunded` | 部分退款完成 | 訂單金額中僅部分已退款 |\n| `refunded` | 退款完成 | 退款處理已完成 |\n| `expired` | 訂單逾期 | 等待付款時間已過，訂單失效 |\n\n### 狀態設計原則\n\n- 不要把訂單狀態與付款狀態視為完全相同。訂單可能存在但付款失敗，付款也可能已授權但訂單儲存失敗。\n- 每一次狀態變更都要留下發生時間、處理者、原因、付款交易識別碼、退款交易識別碼。\n- 客戶畫面、管理員畫面、客服應對話術必須使用相同的狀態定義。\n- 狀態轉移應設計為單向，例外復原則以另外的管理員權限留下紀錄後處理。\n\n## 2. 撤回要約與法定退款期限：不是政策，而是法律要求\n\n如果在韓國經營面向消費者的電子商務，必須考量《電子商務等消費者保護相關法律》。一般而言，消費者可在一定期間內撤回要約，業者則必須在退款請求或返還程序之後，於規定期限內退還款項。\n\n實務中特別重要的標準如下。\n\n- 原則上，消費者可自收到商品等法律所定基準日起 7日內撤回要約。\n- 業者在發生退款事由後，必須於法定期限內退還款項；若延遲，可能產生延遲賠償金或延遲利息問題。\n- 數位內容、客製化商品、因使用而價值顯著降低的商品等可能屬於例外，但若要適用例外，必須慎重確認事前告知與同意等要件。\n- 實際適用可能因商品類型、契約方式、提供給消費者的告知、是否開始使用而不同，因此需要法務審查。\n\n### 轉換為開發需求的方法\n\n法律標準只寫在條款文字裡是不夠的，也必須轉換為系統需求。\n\n| 法律、政策要求 | 系統需求 |\n|---|---|\n| 判斷是否可於 7日內撤回要約 | 以訂單收貨日或服務提供日為基準，自動計算可退款期間 |\n| 需要於 3個營業日內處理退款 | 在管理員畫面顯示退款申請日與處理截止日 |\n| 退款延遲風險 | 顯示即將到期、超過期限提醒 |\n| 需要告知例外商品 | 付款前明確標示為退款限制商品，並儲存同意紀錄 |\n| 需要因應爭議 | 保存條款版本、告知時間、同意時間、客戶 IP 或帳號紀錄 |\n\n## 3. 部分退款規則：優惠券、運費、稅務要先定義\n\n部分退款比全額取消複雜得多。一次訂購多項商品後只退回其中一部分時，必須決定原本套用的折扣與運費要如何分攤。\n\n### 必須決定的項目\n\n- 如何分配各商品的付款金額\n- 訂單整體優惠券是否按商品比例分攤\n- 特定商品優惠券是否只套用於該商品\n- 免運條件不再成立時，是否扣除運費\n- 如何區分單純變心退貨運費與商品瑕疵退貨運費\n- 點數、積分、禮品卡付款部分要依什麼順序退款\n- 部分退款後，稅務發票、現金收據、收據標示要如何變更\n\n### 部分退款計算範例\n\n| 項目 | 金額 |\n|---|---:|\n| A 商品 | 30,000원 |\n| B 商品 | 70,000원 |\n| 訂單整體優惠券 | -10,000원 |\n| 實際付款金額 | 90,000원 |\n\n如果按商品金額比例分攤優惠券，A 商品會分攤 3,000원 折扣，B 商品會分攤 7,000원 折扣。此時若只退款 A 商品，退款基準金額不是 30,000원，而是 27,000원。如果有免運條件、退貨運費、各付款方式退款限制，最終退款金額可能會再不同。\n\n答案不只一個。重要的是事先決定一致的規則，並在客戶付款前或申請退款前，告知到能讓客戶理解。\n\n## 4. 防止重複付款：只停用按鈕是不夠的\n\n重複付款是客戶最快發現的付款事故。客戶會先看到信用卡授權簡訊與信用卡帳單，而不是服務內部的訂單狀態。同一筆訂單若被付款兩次，信任會大幅下降。\n\n### 發生原因\n\n- 客戶連續點擊付款按鈕\n- 付款後立即重新整理或按返回\n- 因行動網路延遲而重新傳送相同請求\n- 付款授權回應成功，但服務伺服器儲存失敗\n- webhook 與客戶端重新導向同時變更訂單狀態\n\n### 防禦設計\n\n| 防禦裝置 | 說明 |\n|---|---|\n| 客戶端按鈕鎖定 | 付款按鈕點擊後防止再次點擊，但僅作為輔助手段使用 |\n| 伺服器端訂單鎖定 | 針對相同訂單 ID，避免同時執行付款授權請求 |\n| 冪等性鍵 | 使用識別碼，讓同一付款請求即使傳送多次，也只產生一次結果 |\n| 唯一交易編號 | 以資料庫限制條件防止訂單號與付款交易編號重複儲存 |\n| 基於狀態的驗證 | 對已經是 `paid` 的訂單阻止追加授權請求 |\n| webhook 重複處理 | 即使相同 webhook 事件來了多次，也只發生一次狀態變更 |\n\n向 AI 要求付款程式碼時，最好不要只說「防止重複點擊」，而要明確寫出「同一筆訂單的付款授權與付款完成處理必須以冪等方式運作」。\n\n## 5. 付款失敗 안내 文案：失敗不是事故，而是正常流程\n\n付款失敗是每天都會發生的正常情況。超過額度、餘額不足、信用卡認證失敗、密碼錯誤、3D Secure 認證失敗、簡易付款 App 無回應、網路錯誤，都是常見案例。\n\n不好的 안내 是以「發生錯誤」結束的文案。客戶不知道是否已付款、是否可以再按一次、訂單是否會消失。\n\n### 안내 文案範例\n\n| 情況 | 建議 안내 |\n|---|---|\n| 餘額不足 | 因付款方式餘額不足，付款未完成。請選擇其他付款方式，或確認餘額後再試一次。 |\n| 超過額度 | 因超過信用卡額度或單次付款額度，付款失敗。請在發卡公司 App 確認額度，或使用其他信用卡付款。 |\n| 認證失敗 | 付款認證未完成，因此訂單會維持等待付款狀態。可於 30分鐘內再次付款。 |\n| 網路錯誤 | 付款結果確認延遲中。為防止重複付款，請稍後確認付款紀錄。 |\n| 訂單逾期 | 等待付款時間已過，訂單已逾期。請重新選擇商品並下單。 |\n\n### 失敗 안내 的核心要素\n\n- 明確說明付款是否實際上未完成。\n- 告知訂單會保留多久。\n- 안내 是否可以重試，或是否需要使用其他付款方式。\n- 顯示向客服中心詢問時所需的訂單號。\n- 如果付款結果不確定，不要一律引導重新付款，而要提供確認中狀態。\n\n## 6. 付款紀錄頁面：減少客服中心負擔的核心畫面\n\n如果沒有付款紀錄頁面，客戶會為了確認付款、取消、退款狀態而詢問客服中心。付款紀錄不是單純的收據畫面，而是讓客戶確認自己金錢目前狀態的信任裝置。\n\n### 付款紀錄頁面應包含的資訊\n\n- 訂單號\n- 訂單日期時間與付款日期時間\n- 商品名稱、數量、選項\n- 付款方式與授權號或交易識別碼\n- 商品金額、折扣、運費、點數使用金額、最終付款金額\n- 目前訂單狀態與退款狀態\n- 退款申請日、退款核准日、預計退款完成日\n- 是否可取消或退款\n- 收據、交易明細、現金收據確認連結\n- 向客服中心詢問時所需的資訊\n\n### 與營運者畫面的連結\n\n客戶畫面與管理員畫面必須看到相同資料。如果客戶看到的是「退款進行中」，但管理員畫面顯示「處理完成」，客服應對就會混亂。狀態名稱可以用不同方式表達，但內部狀態代碼與轉移規則必須只有一套。\n\n## 7. 退款規定告知位置：藏起來就不是政策，而是風險\n\n退款規定只放在條款頁面的角落是不夠的。客戶在做出付款決定的畫面上，必須能輕易確認可退款期間、退款限制條件、取消方法。\n\n### 好的告知位置\n\n- 商品詳細頁的價格或購買按鈕附近\n- 購物車或訂單畫面\n- 付款按鈕正上方的條款與退款規定同意區域\n- 付款完成頁面\n- 我的頁面中的訂單詳細畫面\n- 退款申請畫面\n\n### 應避免的設計\n\n- 註冊與付款可以一次完成，但解約或退款只能透過客服中心電話辦理的設計\n- 把取消按鈕藏在多個步驟深處的設計\n- 付款後才顯示退款限制條件的設計\n- 以會讓客戶誤解的方式配置按鈕顏色、文案、順序的設計\n- 免費試用結束後，未明確告知會自動付款的設計\n\n這類設計不只會傷害客戶體驗，也可能被評為黑暗模式。尤其取消與解約的難度，最好設計成與註冊和付款的難度差異不要太大，這樣比較安全。\n\n## 要包含在給 AI 的提示詞中的檢查清單\n\n向 AI 開發工具要求實作付款功能時，應像下面一樣先傳達政策。\n\n### 付款功能提示詞範例\n\n```text\n請實作面向韓國消費者的電子商務服務付款功能。\n請務必反映以下政策。\n\n1. 訂單狀態使用 payment_pending, paid, payment_failed, cancel_requested, cancelled, refund_requested, refund_processing, partially_refunded, refunded, expired。\n2. 等待付款的訂單在 30分鐘後變更為 expired。\n3. 同一筆訂單只允許 1筆付款授權，並使用伺服器端訂單鎖定與冪等性鍵。\n4. 付款 webhook 可能重複接收，因此相同事件 ID 只處理一次。\n5. 儲存退款申請日、退款處理截止日、處理者、原因、退款交易編號。\n6. 部分退款以各商品實際付款金額為基準計算，訂單整體優惠券依商品金額比例分攤。\n7. 付款失敗時，依失敗原因回傳給客戶的 안내 文案。\n8. 讓客戶可在我的頁面確認付款紀錄與退款狀態。\n9. 付款前顯示退款規定連結與同意核取方塊，並儲存同意時間與條款版本。\n10. 如果有尚未決定的政策，請在撰寫程式碼前先提問。\n```\n\n最後一句「如果有尚未決定的政策，請先提問」很重要。退款是否自動核准、管理員核准權限、運費扣除方式等人容易遺漏的政策，可以讓 AI 反問確認。\n\n## 營運者畫面需要的功能\n\n付款功能不能只靠客戶畫面完成。退款與取消是每天都會處理的營運工作，因此一定需要管理員畫面。\n\n| 管理員功能 | 需要的理由 |\n|---|---|\n| 退款等待清單 | 為了不漏掉必須處理的退款案件 |\n| 法定處理期限顯示 | 為了降低退款延遲風險 |\n| 期限將至、超過警告 | 為了讓營運者立即知道 3個營業日等內部標準 |\n| 退款原因選擇 | 為了單純變心、商品瑕疵、錯誤配送等統計與費用分攤 |\n| 部分退款計算預覽 | 為了減少營運者手動計算錯誤 |\n| 處理紀錄 | 為了因應爭議與稽核 |\n| 權限管理 | 為了限制退款核准與強制狀態變更 |\n\n## 付款資料模型的最低構成\n\n每個服務的資料結構都不同，但至少最好將以下程度的資料分開保存。\n\n| 資料表或物件 | 核心欄位 |\n|---|---|\n| 訂單 | 訂單 ID、客戶 ID、訂單狀態、訂單金額、折扣金額、運費、建立日期時間、逾期日期時間 |\n| 訂單商品 | 商品 ID、商品名稱、選項、數量、各商品金額、各商品折扣分攤金額 |\n| 付款 | 付款 ID、訂單 ID、付款方式、授權號、授權金額、付款狀態、授權日期時間 |\n| 退款 | 退款 ID、訂單 ID、退款金額、退款原因、退款狀態、申請日期時間、完成日期時間 |\n| 狀態歷程 | 對象 ID、先前狀態、變更後狀態、變更者、變更原因、變更日期時間 |\n| 條款同意 | 條款種類、條款版本、是否同意、同意日期時間、客戶 ID |\n\n重要的是不要覆寫付款授權金額、退款金額、訂單總額。與金錢相關的值，盡可能以歷程與交易單位保存，之後帳簿與客服應對才會對得上。\n\n## 上線前檢查清單\n\n- 對同一筆訂單按下付款按鈕 10次，付款是否只授權 1次？\n- 付款授權後如果伺服器儲存失敗，是否可以復原？\n- 即使付款 webhook 多次傳送相同事件，是否不會重複處理？\n- 客戶是否能理解付款失敗原因與重試方法？\n- 等待付款的訂單是否會在一定時間後自動逾期？\n- 部分退款金額是否與優惠券、點數、運費政策一致？\n- 從退款申請日到處理截止日，是否會顯示在管理員畫面？\n- 退款規定是否能在付款前畫面輕易確認？\n- 數位內容或退款限制商品是否有事前告知與同意紀錄？\n- 客戶是否能在我的頁面直接確認付款紀錄與退款狀態？\n\n## 結論\n\nAI 可以快速製作付款功能的程式碼。但安全且合法營運的付款系統，始於程式碼之前的政策決策。\n\n先整理訂單狀態、法定退款期限、部分退款計算式、防止重複付款、付款失敗 안내、付款紀錄頁面、退款規定告知位置，再把實作交給 AI，就能得到穩定得多的結果。付款不是「收錢的功能」，而是「負責金錢的功能」，應以這個觀點來設計。","content_html":"\u003ch2\u003e\n\u003ca href=\"#%E6%A0%B8%E5%BF%83%E6%91%98%E8%A6%81\" class=\"anchor\" id=\"核心摘要\"\u003e\u003c/a\u003e核心摘要\u003c/h2\u003e\n\u003cp\u003e把付款功能交給 AI 時，最危險的提示詞就是單純要求「幫我加上付款」。付款不是收錢的程式碼，而是負責金流的營運、會計、客服系統。\u003c/p\u003e\n\u003cp\u003e從技術上來說，AI 可以快速實作付款視窗串接、呼叫授權 API、接收 webhook、儲存訂單。然而，如果沒有先決定以下政策，實際服務中就可能發生幽靈訂單、重複付款、退款延遲、客服中心爆量、法律告知遺漏等問題。\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e決策領域\u003c/th\u003e\n\u003cth\u003e事前必須決定的問題\u003c/th\u003e\n\u003cth\u003e失敗時的風險\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"決策領域\"\u003e訂單狀態\u003c/td\u003e\n\u003ctd data-label=\"事前必須決定的問題\"\u003e訂單會依序經過哪些狀態？\u003c/td\u003e\n\u003ctd data-label=\"失敗時的風險\"\u003e已付款但沒有訂單的幽靈訂單發生\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"決策領域\"\u003e退款期限\u003c/td\u003e\n\u003ctd data-label=\"事前必須決定的問題\"\u003e如何反映撤回要約與退款處理期限？\u003c/td\u003e\n\u003ctd data-label=\"失敗時的風險\"\u003e違反法定期限、延遲利息、爭議風險\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"決策領域\"\u003e部分退款\u003c/td\u003e\n\u003ctd data-label=\"事前必須決定的問題\"\u003e如何計算部分商品退貨、優惠券、運費？\u003c/td\u003e\n\u003ctd data-label=\"失敗時的風險\"\u003e營運人員每次都要手動計算，客戶不信任\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"決策領域\"\u003e重複付款\u003c/td\u003e\n\u003ctd data-label=\"事前必須決定的問題\"\u003e如何防止同一筆訂單被收取兩次付款？\u003c/td\u003e\n\u003ctd data-label=\"失敗時的風險\"\u003e客戶依信用卡帳單提出不滿，信任下降\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"決策領域\"\u003e失敗 안내\u003c/td\u003e\n\u003ctd data-label=\"事前必須決定的問題\"\u003e如何告知超過額度、餘額不足、認證失敗？\u003c/td\u003e\n\u003ctd data-label=\"失敗時的風險\"\u003e重試轉換率下降，不必要的詢問增加\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"決策領域\"\u003e付款紀錄\u003c/td\u003e\n\u003ctd data-label=\"事前必須決定的問題\"\u003e客戶在哪裡確認付款與退款狀態？\u003c/td\u003e\n\u003ctd data-label=\"失敗時的風險\"\u003e客服中心詢問增加，狀態不透明\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"決策領域\"\u003e退款告知\u003c/td\u003e\n\u003ctd data-label=\"事前必須決定的問題\"\u003e退款規定與取消按鈕要放在哪裡？\u003c/td\u003e\n\u003ctd data-label=\"失敗時的風險\"\u003e黑暗模式爭議、法規風險\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#1-%E8%A8%82%E5%96%AE%E7%8B%80%E6%85%8B%E8%A8%AD%E8%A8%88%E7%8B%80%E6%85%8B%E5%B0%B1%E6%98%AF%E7%87%9F%E9%81%8B%E8%AA%9E%E8%A8%80\" class=\"anchor\" id=\"1-訂單狀態設計狀態就是營運語言\"\u003e\u003c/a\u003e1. 訂單狀態設計：狀態就是營運語言\u003c/h2\u003e\n\u003cp\u003e製作付款功能時，訂單狀態不能只有「訂單完成」一種。實際訂單會經過付款嘗試、授權、取消、退款、失敗、逾期等多個階段。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E5%BB%BA%E8%AD%B0%E7%8B%80%E6%85%8B%E7%AF%84%E4%BE%8B\" class=\"anchor\" id=\"建議狀態範例\"\u003e\u003c/a\u003e建議狀態範例\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e狀態代碼範例\u003c/th\u003e\n\u003cth\u003e顯示給客戶的狀態\u003c/th\u003e\n\u003cth\u003e意義\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"狀態代碼範例\"\u003e\u003ccode\u003epayment_pending\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"顯示給客戶的狀態\"\u003e等待付款\u003c/td\u003e\n\u003ctd data-label=\"意義\"\u003e訂單已建立但付款尚未完成\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"狀態代碼範例\"\u003e\u003ccode\u003epaid\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"顯示給客戶的狀態\"\u003e付款完成\u003c/td\u003e\n\u003ctd data-label=\"意義\"\u003e付款授權已完成，訂單有效\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"狀態代碼範例\"\u003e\u003ccode\u003epayment_failed\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"顯示給客戶的狀態\"\u003e付款失敗\u003c/td\u003e\n\u003ctd data-label=\"意義\"\u003e付款嘗試失敗，需要判斷是否可重試\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"狀態代碼範例\"\u003e\u003ccode\u003ecancel_requested\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"顯示給客戶的狀態\"\u003e取消申請\u003c/td\u003e\n\u003ctd data-label=\"意義\"\u003e客戶已申請取消，等待處理中\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"狀態代碼範例\"\u003e\u003ccode\u003ecancelled\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"顯示給客戶的狀態\"\u003e取消完成\u003c/td\u003e\n\u003ctd data-label=\"意義\"\u003e付款前訂單取消或授權取消已完成\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"狀態代碼範例\"\u003e\u003ccode\u003erefund_requested\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"顯示給客戶的狀態\"\u003e退款申請\u003c/td\u003e\n\u003ctd data-label=\"意義\"\u003e付款後的退款申請已受理\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"狀態代碼範例\"\u003e\u003ccode\u003erefund_processing\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"顯示給客戶的狀態\"\u003e退款進行中\u003c/td\u003e\n\u003ctd data-label=\"意義\"\u003e正在處理退款核准或付款方式退款\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"狀態代碼範例\"\u003e\u003ccode\u003epartially_refunded\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"顯示給客戶的狀態\"\u003e部分退款完成\u003c/td\u003e\n\u003ctd data-label=\"意義\"\u003e訂單金額中僅部分已退款\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"狀態代碼範例\"\u003e\u003ccode\u003erefunded\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"顯示給客戶的狀態\"\u003e退款完成\u003c/td\u003e\n\u003ctd data-label=\"意義\"\u003e退款處理已完成\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"狀態代碼範例\"\u003e\u003ccode\u003eexpired\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"顯示給客戶的狀態\"\u003e訂單逾期\u003c/td\u003e\n\u003ctd data-label=\"意義\"\u003e等待付款時間已過，訂單失效\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E7%8B%80%E6%85%8B%E8%A8%AD%E8%A8%88%E5%8E%9F%E5%89%87\" class=\"anchor\" id=\"狀態設計原則\"\u003e\u003c/a\u003e狀態設計原則\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e不要把訂單狀態與付款狀態視為完全相同。訂單可能存在但付款失敗，付款也可能已授權但訂單儲存失敗。\u003c/li\u003e\n\u003cli\u003e每一次狀態變更都要留下發生時間、處理者、原因、付款交易識別碼、退款交易識別碼。\u003c/li\u003e\n\u003cli\u003e客戶畫面、管理員畫面、客服應對話術必須使用相同的狀態定義。\u003c/li\u003e\n\u003cli\u003e狀態轉移應設計為單向，例外復原則以另外的管理員權限留下紀錄後處理。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#2-%E6%92%A4%E5%9B%9E%E8%A6%81%E7%B4%84%E8%88%87%E6%B3%95%E5%AE%9A%E9%80%80%E6%AC%BE%E6%9C%9F%E9%99%90%E4%B8%8D%E6%98%AF%E6%94%BF%E7%AD%96%E8%80%8C%E6%98%AF%E6%B3%95%E5%BE%8B%E8%A6%81%E6%B1%82\" class=\"anchor\" id=\"2-撤回要約與法定退款期限不是政策而是法律要求\"\u003e\u003c/a\u003e2. 撤回要約與法定退款期限：不是政策，而是法律要求\u003c/h2\u003e\n\u003cp\u003e如果在韓國經營面向消費者的電子商務，必須考量《電子商務等消費者保護相關法律》。一般而言，消費者可在一定期間內撤回要約，業者則必須在退款請求或返還程序之後，於規定期限內退還款項。\u003c/p\u003e\n\u003cp\u003e實務中特別重要的標準如下。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e原則上，消費者可自收到商品等法律所定基準日起 7日內撤回要約。\u003c/li\u003e\n\u003cli\u003e業者在發生退款事由後，必須於法定期限內退還款項；若延遲，可能產生延遲賠償金或延遲利息問題。\u003c/li\u003e\n\u003cli\u003e數位內容、客製化商品、因使用而價值顯著降低的商品等可能屬於例外，但若要適用例外，必須慎重確認事前告知與同意等要件。\u003c/li\u003e\n\u003cli\u003e實際適用可能因商品類型、契約方式、提供給消費者的告知、是否開始使用而不同，因此需要法務審查。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E8%BD%89%E6%8F%9B%E7%82%BA%E9%96%8B%E7%99%BC%E9%9C%80%E6%B1%82%E7%9A%84%E6%96%B9%E6%B3%95\" class=\"anchor\" id=\"轉換為開發需求的方法\"\u003e\u003c/a\u003e轉換為開發需求的方法\u003c/h3\u003e\n\u003cp\u003e法律標準只寫在條款文字裡是不夠的，也必須轉換為系統需求。\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e法律、政策要求\u003c/th\u003e\n\u003cth\u003e系統需求\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"法律、政策要求\"\u003e判斷是否可於 7日內撤回要約\u003c/td\u003e\n\u003ctd data-label=\"系統需求\"\u003e以訂單收貨日或服務提供日為基準，自動計算可退款期間\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"法律、政策要求\"\u003e需要於 3個營業日內處理退款\u003c/td\u003e\n\u003ctd data-label=\"系統需求\"\u003e在管理員畫面顯示退款申請日與處理截止日\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"法律、政策要求\"\u003e退款延遲風險\u003c/td\u003e\n\u003ctd data-label=\"系統需求\"\u003e顯示即將到期、超過期限提醒\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"法律、政策要求\"\u003e需要告知例外商品\u003c/td\u003e\n\u003ctd data-label=\"系統需求\"\u003e付款前明確標示為退款限制商品，並儲存同意紀錄\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"法律、政策要求\"\u003e需要因應爭議\u003c/td\u003e\n\u003ctd data-label=\"系統需求\"\u003e保存條款版本、告知時間、同意時間、客戶 IP 或帳號紀錄\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#3-%E9%83%A8%E5%88%86%E9%80%80%E6%AC%BE%E8%A6%8F%E5%89%87%E5%84%AA%E6%83%A0%E5%88%B8%E9%81%8B%E8%B2%BB%E7%A8%85%E5%8B%99%E8%A6%81%E5%85%88%E5%AE%9A%E7%BE%A9\" class=\"anchor\" id=\"3-部分退款規則優惠券運費稅務要先定義\"\u003e\u003c/a\u003e3. 部分退款規則：優惠券、運費、稅務要先定義\u003c/h2\u003e\n\u003cp\u003e部分退款比全額取消複雜得多。一次訂購多項商品後只退回其中一部分時，必須決定原本套用的折扣與運費要如何分攤。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E5%BF%85%E9%A0%88%E6%B1%BA%E5%AE%9A%E7%9A%84%E9%A0%85%E7%9B%AE\" class=\"anchor\" id=\"必須決定的項目\"\u003e\u003c/a\u003e必須決定的項目\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e如何分配各商品的付款金額\u003c/li\u003e\n\u003cli\u003e訂單整體優惠券是否按商品比例分攤\u003c/li\u003e\n\u003cli\u003e特定商品優惠券是否只套用於該商品\u003c/li\u003e\n\u003cli\u003e免運條件不再成立時，是否扣除運費\u003c/li\u003e\n\u003cli\u003e如何區分單純變心退貨運費與商品瑕疵退貨運費\u003c/li\u003e\n\u003cli\u003e點數、積分、禮品卡付款部分要依什麼順序退款\u003c/li\u003e\n\u003cli\u003e部分退款後，稅務發票、現金收據、收據標示要如何變更\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E9%83%A8%E5%88%86%E9%80%80%E6%AC%BE%E8%A8%88%E7%AE%97%E7%AF%84%E4%BE%8B\" class=\"anchor\" id=\"部分退款計算範例\"\u003e\u003c/a\u003e部分退款計算範例\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e項目\u003c/th\u003e\n\u003cth\u003e金額\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"項目\"\u003eA 商品\u003c/td\u003e\n\u003ctd data-label=\"金額\"\u003e30,000원\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"項目\"\u003eB 商品\u003c/td\u003e\n\u003ctd data-label=\"金額\"\u003e70,000원\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"項目\"\u003e訂單整體優惠券\u003c/td\u003e\n\u003ctd data-label=\"金額\"\u003e-10,000원\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"項目\"\u003e實際付款金額\u003c/td\u003e\n\u003ctd data-label=\"金額\"\u003e90,000원\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e如果按商品金額比例分攤優惠券，A 商品會分攤 3,000원 折扣，B 商品會分攤 7,000원 折扣。此時若只退款 A 商品，退款基準金額不是 30,000원，而是 27,000원。如果有免運條件、退貨運費、各付款方式退款限制，最終退款金額可能會再不同。\u003c/p\u003e\n\u003cp\u003e答案不只一個。重要的是事先決定一致的規則，並在客戶付款前或申請退款前，告知到能讓客戶理解。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#4-%E9%98%B2%E6%AD%A2%E9%87%8D%E8%A4%87%E4%BB%98%E6%AC%BE%E5%8F%AA%E5%81%9C%E7%94%A8%E6%8C%89%E9%88%95%E6%98%AF%E4%B8%8D%E5%A4%A0%E7%9A%84\" class=\"anchor\" id=\"4-防止重複付款只停用按鈕是不夠的\"\u003e\u003c/a\u003e4. 防止重複付款：只停用按鈕是不夠的\u003c/h2\u003e\n\u003cp\u003e重複付款是客戶最快發現的付款事故。客戶會先看到信用卡授權簡訊與信用卡帳單，而不是服務內部的訂單狀態。同一筆訂單若被付款兩次，信任會大幅下降。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E7%99%BC%E7%94%9F%E5%8E%9F%E5%9B%A0\" class=\"anchor\" id=\"發生原因\"\u003e\u003c/a\u003e發生原因\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e客戶連續點擊付款按鈕\u003c/li\u003e\n\u003cli\u003e付款後立即重新整理或按返回\u003c/li\u003e\n\u003cli\u003e因行動網路延遲而重新傳送相同請求\u003c/li\u003e\n\u003cli\u003e付款授權回應成功，但服務伺服器儲存失敗\u003c/li\u003e\n\u003cli\u003ewebhook 與客戶端重新導向同時變更訂單狀態\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E9%98%B2%E7%A6%A6%E8%A8%AD%E8%A8%88\" class=\"anchor\" id=\"防禦設計\"\u003e\u003c/a\u003e防禦設計\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e防禦裝置\u003c/th\u003e\n\u003cth\u003e說明\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"防禦裝置\"\u003e客戶端按鈕鎖定\u003c/td\u003e\n\u003ctd data-label=\"說明\"\u003e付款按鈕點擊後防止再次點擊，但僅作為輔助手段使用\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"防禦裝置\"\u003e伺服器端訂單鎖定\u003c/td\u003e\n\u003ctd data-label=\"說明\"\u003e針對相同訂單 ID，避免同時執行付款授權請求\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"防禦裝置\"\u003e冪等性鍵\u003c/td\u003e\n\u003ctd data-label=\"說明\"\u003e使用識別碼，讓同一付款請求即使傳送多次，也只產生一次結果\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"防禦裝置\"\u003e唯一交易編號\u003c/td\u003e\n\u003ctd data-label=\"說明\"\u003e以資料庫限制條件防止訂單號與付款交易編號重複儲存\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"防禦裝置\"\u003e基於狀態的驗證\u003c/td\u003e\n\u003ctd data-label=\"說明\"\u003e對已經是 \u003ccode\u003epaid\u003c/code\u003e 的訂單阻止追加授權請求\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"防禦裝置\"\u003ewebhook 重複處理\u003c/td\u003e\n\u003ctd data-label=\"說明\"\u003e即使相同 webhook 事件來了多次，也只發生一次狀態變更\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e向 AI 要求付款程式碼時，最好不要只說「防止重複點擊」，而要明確寫出「同一筆訂單的付款授權與付款完成處理必須以冪等方式運作」。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#5-%E4%BB%98%E6%AC%BE%E5%A4%B1%E6%95%97-%EC%95%88%EB%82%B4-%E6%96%87%E6%A1%88%E5%A4%B1%E6%95%97%E4%B8%8D%E6%98%AF%E4%BA%8B%E6%95%85%E8%80%8C%E6%98%AF%E6%AD%A3%E5%B8%B8%E6%B5%81%E7%A8%8B\" class=\"anchor\" id=\"5-付款失敗-안내-文案失敗不是事故而是正常流程\"\u003e\u003c/a\u003e5. 付款失敗 안내 文案：失敗不是事故，而是正常流程\u003c/h2\u003e\n\u003cp\u003e付款失敗是每天都會發生的正常情況。超過額度、餘額不足、信用卡認證失敗、密碼錯誤、3D Secure 認證失敗、簡易付款 App 無回應、網路錯誤，都是常見案例。\u003c/p\u003e\n\u003cp\u003e不好的 안내 是以「發生錯誤」結束的文案。客戶不知道是否已付款、是否可以再按一次、訂單是否會消失。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%EC%95%88%EB%82%B4-%E6%96%87%E6%A1%88%E7%AF%84%E4%BE%8B\" class=\"anchor\" id=\"안내-文案範例\"\u003e\u003c/a\u003e안내 文案範例\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e情況\u003c/th\u003e\n\u003cth\u003e建議 안내\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"情況\"\u003e餘額不足\u003c/td\u003e\n\u003ctd data-label=\"建議 안내\"\u003e因付款方式餘額不足，付款未完成。請選擇其他付款方式，或確認餘額後再試一次。\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"情況\"\u003e超過額度\u003c/td\u003e\n\u003ctd data-label=\"建議 안내\"\u003e因超過信用卡額度或單次付款額度，付款失敗。請在發卡公司 App 確認額度，或使用其他信用卡付款。\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"情況\"\u003e認證失敗\u003c/td\u003e\n\u003ctd data-label=\"建議 안내\"\u003e付款認證未完成，因此訂單會維持等待付款狀態。可於 30分鐘內再次付款。\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"情況\"\u003e網路錯誤\u003c/td\u003e\n\u003ctd data-label=\"建議 안내\"\u003e付款結果確認延遲中。為防止重複付款，請稍後確認付款紀錄。\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"情況\"\u003e訂單逾期\u003c/td\u003e\n\u003ctd data-label=\"建議 안내\"\u003e等待付款時間已過，訂單已逾期。請重新選擇商品並下單。\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E5%A4%B1%E6%95%97-%EC%95%88%EB%82%B4-%E7%9A%84%E6%A0%B8%E5%BF%83%E8%A6%81%E7%B4%A0\" class=\"anchor\" id=\"失敗-안내-的核心要素\"\u003e\u003c/a\u003e失敗 안내 的核心要素\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e明確說明付款是否實際上未完成。\u003c/li\u003e\n\u003cli\u003e告知訂單會保留多久。\u003c/li\u003e\n\u003cli\u003e안내 是否可以重試，或是否需要使用其他付款方式。\u003c/li\u003e\n\u003cli\u003e顯示向客服中心詢問時所需的訂單號。\u003c/li\u003e\n\u003cli\u003e如果付款結果不確定，不要一律引導重新付款，而要提供確認中狀態。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#6-%E4%BB%98%E6%AC%BE%E7%B4%80%E9%8C%84%E9%A0%81%E9%9D%A2%E6%B8%9B%E5%B0%91%E5%AE%A2%E6%9C%8D%E4%B8%AD%E5%BF%83%E8%B2%A0%E6%93%94%E7%9A%84%E6%A0%B8%E5%BF%83%E7%95%AB%E9%9D%A2\" class=\"anchor\" id=\"6-付款紀錄頁面減少客服中心負擔的核心畫面\"\u003e\u003c/a\u003e6. 付款紀錄頁面：減少客服中心負擔的核心畫面\u003c/h2\u003e\n\u003cp\u003e如果沒有付款紀錄頁面，客戶會為了確認付款、取消、退款狀態而詢問客服中心。付款紀錄不是單純的收據畫面，而是讓客戶確認自己金錢目前狀態的信任裝置。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E4%BB%98%E6%AC%BE%E7%B4%80%E9%8C%84%E9%A0%81%E9%9D%A2%E6%87%89%E5%8C%85%E5%90%AB%E7%9A%84%E8%B3%87%E8%A8%8A\" class=\"anchor\" id=\"付款紀錄頁面應包含的資訊\"\u003e\u003c/a\u003e付款紀錄頁面應包含的資訊\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e訂單號\u003c/li\u003e\n\u003cli\u003e訂單日期時間與付款日期時間\u003c/li\u003e\n\u003cli\u003e商品名稱、數量、選項\u003c/li\u003e\n\u003cli\u003e付款方式與授權號或交易識別碼\u003c/li\u003e\n\u003cli\u003e商品金額、折扣、運費、點數使用金額、最終付款金額\u003c/li\u003e\n\u003cli\u003e目前訂單狀態與退款狀態\u003c/li\u003e\n\u003cli\u003e退款申請日、退款核准日、預計退款完成日\u003c/li\u003e\n\u003cli\u003e是否可取消或退款\u003c/li\u003e\n\u003cli\u003e收據、交易明細、現金收據確認連結\u003c/li\u003e\n\u003cli\u003e向客服中心詢問時所需的資訊\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E8%88%87%E7%87%9F%E9%81%8B%E8%80%85%E7%95%AB%E9%9D%A2%E7%9A%84%E9%80%A3%E7%B5%90\" class=\"anchor\" id=\"與營運者畫面的連結\"\u003e\u003c/a\u003e與營運者畫面的連結\u003c/h3\u003e\n\u003cp\u003e客戶畫面與管理員畫面必須看到相同資料。如果客戶看到的是「退款進行中」，但管理員畫面顯示「處理完成」，客服應對就會混亂。狀態名稱可以用不同方式表達，但內部狀態代碼與轉移規則必須只有一套。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#7-%E9%80%80%E6%AC%BE%E8%A6%8F%E5%AE%9A%E5%91%8A%E7%9F%A5%E4%BD%8D%E7%BD%AE%E8%97%8F%E8%B5%B7%E4%BE%86%E5%B0%B1%E4%B8%8D%E6%98%AF%E6%94%BF%E7%AD%96%E8%80%8C%E6%98%AF%E9%A2%A8%E9%9A%AA\" class=\"anchor\" id=\"7-退款規定告知位置藏起來就不是政策而是風險\"\u003e\u003c/a\u003e7. 退款規定告知位置：藏起來就不是政策，而是風險\u003c/h2\u003e\n\u003cp\u003e退款規定只放在條款頁面的角落是不夠的。客戶在做出付款決定的畫面上，必須能輕易確認可退款期間、退款限制條件、取消方法。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E5%A5%BD%E7%9A%84%E5%91%8A%E7%9F%A5%E4%BD%8D%E7%BD%AE\" class=\"anchor\" id=\"好的告知位置\"\u003e\u003c/a\u003e好的告知位置\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e商品詳細頁的價格或購買按鈕附近\u003c/li\u003e\n\u003cli\u003e購物車或訂單畫面\u003c/li\u003e\n\u003cli\u003e付款按鈕正上方的條款與退款規定同意區域\u003c/li\u003e\n\u003cli\u003e付款完成頁面\u003c/li\u003e\n\u003cli\u003e我的頁面中的訂單詳細畫面\u003c/li\u003e\n\u003cli\u003e退款申請畫面\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E6%87%89%E9%81%BF%E5%85%8D%E7%9A%84%E8%A8%AD%E8%A8%88\" class=\"anchor\" id=\"應避免的設計\"\u003e\u003c/a\u003e應避免的設計\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e註冊與付款可以一次完成，但解約或退款只能透過客服中心電話辦理的設計\u003c/li\u003e\n\u003cli\u003e把取消按鈕藏在多個步驟深處的設計\u003c/li\u003e\n\u003cli\u003e付款後才顯示退款限制條件的設計\u003c/li\u003e\n\u003cli\u003e以會讓客戶誤解的方式配置按鈕顏色、文案、順序的設計\u003c/li\u003e\n\u003cli\u003e免費試用結束後，未明確告知會自動付款的設計\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e這類設計不只會傷害客戶體驗，也可能被評為黑暗模式。尤其取消與解約的難度，最好設計成與註冊和付款的難度差異不要太大，這樣比較安全。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E8%A6%81%E5%8C%85%E5%90%AB%E5%9C%A8%E7%B5%A6-ai-%E7%9A%84%E6%8F%90%E7%A4%BA%E8%A9%9E%E4%B8%AD%E7%9A%84%E6%AA%A2%E6%9F%A5%E6%B8%85%E5%96%AE\" class=\"anchor\" id=\"要包含在給-ai-的提示詞中的檢查清單\"\u003e\u003c/a\u003e要包含在給 AI 的提示詞中的檢查清單\u003c/h2\u003e\n\u003cp\u003e向 AI 開發工具要求實作付款功能時，應像下面一樣先傳達政策。\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%E4%BB%98%E6%AC%BE%E5%8A%9F%E8%83%BD%E6%8F%90%E7%A4%BA%E8%A9%9E%E7%AF%84%E4%BE%8B\" class=\"anchor\" id=\"付款功能提示詞範例\"\u003e\u003c/a\u003e付款功能提示詞範例\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e請實作面向韓國消費者的電子商務服務付款功能。\n\u003c/span\u003e\u003cspan\u003e請務必反映以下政策。\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e1. 訂單狀態使用 payment_pending, paid, payment_failed, cancel_requested, cancelled, refund_requested, refund_processing, partially_refunded, refunded, expired。\n\u003c/span\u003e\u003cspan\u003e2. 等待付款的訂單在 30分鐘後變更為 expired。\n\u003c/span\u003e\u003cspan\u003e3. 同一筆訂單只允許 1筆付款授權，並使用伺服器端訂單鎖定與冪等性鍵。\n\u003c/span\u003e\u003cspan\u003e4. 付款 webhook 可能重複接收，因此相同事件 ID 只處理一次。\n\u003c/span\u003e\u003cspan\u003e5. 儲存退款申請日、退款處理截止日、處理者、原因、退款交易編號。\n\u003c/span\u003e\u003cspan\u003e6. 部分退款以各商品實際付款金額為基準計算，訂單整體優惠券依商品金額比例分攤。\n\u003c/span\u003e\u003cspan\u003e7. 付款失敗時，依失敗原因回傳給客戶的 안내 文案。\n\u003c/span\u003e\u003cspan\u003e8. 讓客戶可在我的頁面確認付款紀錄與退款狀態。\n\u003c/span\u003e\u003cspan\u003e9. 付款前顯示退款規定連結與同意核取方塊，並儲存同意時間與條款版本。\n\u003c/span\u003e\u003cspan\u003e10. 如果有尚未決定的政策，請在撰寫程式碼前先提問。\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e最後一句「如果有尚未決定的政策，請先提問」很重要。退款是否自動核准、管理員核准權限、運費扣除方式等人容易遺漏的政策，可以讓 AI 反問確認。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E7%87%9F%E9%81%8B%E8%80%85%E7%95%AB%E9%9D%A2%E9%9C%80%E8%A6%81%E7%9A%84%E5%8A%9F%E8%83%BD\" class=\"anchor\" id=\"營運者畫面需要的功能\"\u003e\u003c/a\u003e營運者畫面需要的功能\u003c/h2\u003e\n\u003cp\u003e付款功能不能只靠客戶畫面完成。退款與取消是每天都會處理的營運工作，因此一定需要管理員畫面。\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e管理員功能\u003c/th\u003e\n\u003cth\u003e需要的理由\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"管理員功能\"\u003e退款等待清單\u003c/td\u003e\n\u003ctd data-label=\"需要的理由\"\u003e為了不漏掉必須處理的退款案件\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"管理員功能\"\u003e法定處理期限顯示\u003c/td\u003e\n\u003ctd data-label=\"需要的理由\"\u003e為了降低退款延遲風險\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"管理員功能\"\u003e期限將至、超過警告\u003c/td\u003e\n\u003ctd data-label=\"需要的理由\"\u003e為了讓營運者立即知道 3個營業日等內部標準\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"管理員功能\"\u003e退款原因選擇\u003c/td\u003e\n\u003ctd data-label=\"需要的理由\"\u003e為了單純變心、商品瑕疵、錯誤配送等統計與費用分攤\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"管理員功能\"\u003e部分退款計算預覽\u003c/td\u003e\n\u003ctd data-label=\"需要的理由\"\u003e為了減少營運者手動計算錯誤\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"管理員功能\"\u003e處理紀錄\u003c/td\u003e\n\u003ctd data-label=\"需要的理由\"\u003e為了因應爭議與稽核\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"管理員功能\"\u003e權限管理\u003c/td\u003e\n\u003ctd data-label=\"需要的理由\"\u003e為了限制退款核准與強制狀態變更\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E4%BB%98%E6%AC%BE%E8%B3%87%E6%96%99%E6%A8%A1%E5%9E%8B%E7%9A%84%E6%9C%80%E4%BD%8E%E6%A7%8B%E6%88%90\" class=\"anchor\" id=\"付款資料模型的最低構成\"\u003e\u003c/a\u003e付款資料模型的最低構成\u003c/h2\u003e\n\u003cp\u003e每個服務的資料結構都不同，但至少最好將以下程度的資料分開保存。\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e資料表或物件\u003c/th\u003e\n\u003cth\u003e核心欄位\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"資料表或物件\"\u003e訂單\u003c/td\u003e\n\u003ctd data-label=\"核心欄位\"\u003e訂單 ID、客戶 ID、訂單狀態、訂單金額、折扣金額、運費、建立日期時間、逾期日期時間\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"資料表或物件\"\u003e訂單商品\u003c/td\u003e\n\u003ctd data-label=\"核心欄位\"\u003e商品 ID、商品名稱、選項、數量、各商品金額、各商品折扣分攤金額\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"資料表或物件\"\u003e付款\u003c/td\u003e\n\u003ctd data-label=\"核心欄位\"\u003e付款 ID、訂單 ID、付款方式、授權號、授權金額、付款狀態、授權日期時間\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"資料表或物件\"\u003e退款\u003c/td\u003e\n\u003ctd data-label=\"核心欄位\"\u003e退款 ID、訂單 ID、退款金額、退款原因、退款狀態、申請日期時間、完成日期時間\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"資料表或物件\"\u003e狀態歷程\u003c/td\u003e\n\u003ctd data-label=\"核心欄位\"\u003e對象 ID、先前狀態、變更後狀態、變更者、變更原因、變更日期時間\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"資料表或物件\"\u003e條款同意\u003c/td\u003e\n\u003ctd data-label=\"核心欄位\"\u003e條款種類、條款版本、是否同意、同意日期時間、客戶 ID\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e重要的是不要覆寫付款授權金額、退款金額、訂單總額。與金錢相關的值，盡可能以歷程與交易單位保存，之後帳簿與客服應對才會對得上。\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E4%B8%8A%E7%B7%9A%E5%89%8D%E6%AA%A2%E6%9F%A5%E6%B8%85%E5%96%AE\" class=\"anchor\" id=\"上線前檢查清單\"\u003e\u003c/a\u003e上線前檢查清單\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e對同一筆訂單按下付款按鈕 10次，付款是否只授權 1次？\u003c/li\u003e\n\u003cli\u003e付款授權後如果伺服器儲存失敗，是否可以復原？\u003c/li\u003e\n\u003cli\u003e即使付款 webhook 多次傳送相同事件，是否不會重複處理？\u003c/li\u003e\n\u003cli\u003e客戶是否能理解付款失敗原因與重試方法？\u003c/li\u003e\n\u003cli\u003e等待付款的訂單是否會在一定時間後自動逾期？\u003c/li\u003e\n\u003cli\u003e部分退款金額是否與優惠券、點數、運費政策一致？\u003c/li\u003e\n\u003cli\u003e從退款申請日到處理截止日，是否會顯示在管理員畫面？\u003c/li\u003e\n\u003cli\u003e退款規定是否能在付款前畫面輕易確認？\u003c/li\u003e\n\u003cli\u003e數位內容或退款限制商品是否有事前告知與同意紀錄？\u003c/li\u003e\n\u003cli\u003e客戶是否能在我的頁面直接確認付款紀錄與退款狀態？\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#%E7%B5%90%E8%AB%96\" class=\"anchor\" id=\"結論\"\u003e\u003c/a\u003e結論\u003c/h2\u003e\n\u003cp\u003eAI 可以快速製作付款功能的程式碼。但安全且合法營運的付款系統，始於程式碼之前的政策決策。\u003c/p\u003e\n\u003cp\u003e先整理訂單狀態、法定退款期限、部分退款計算式、防止重複付款、付款失敗 안내、付款紀錄頁面、退款規定告知位置，再把實作交給 AI，就能得到穩定得多的結果。付款不是「收錢的功能」，而是「負責金錢的功能」，應以這個觀點來設計。\u003c/p\u003e\n","tags":["AI 開發","付款系統","退款政策","電子商務法","黑暗模式"],"faqs":[{"question":"要求 AI 製作付款功能時，最先需要決定的是什麼？","answer":"最先需要決定訂單狀態與付款狀態的流程。必須定義等待付款、付款完成、付款失敗、取消請求、退款進行中、退款完成等狀態，AI 才能建立安全的資料結構與畫面流程。"},{"question":"為什麼把訂單狀態單純設為一個訂單完成會很危險？","answer":"因為實際付款有很多例外流程，例如失敗、取消、退款、到期等。如果狀態過於單純，可能會發生已付款但沒有訂單紀錄，或退款已完成但客戶畫面仍顯示付款完成的問題。"},{"question":"在韓國電子商務中，7 天申請撤回規定是否一定適用？","answer":"一般而言，消費者可以在法律規定的基準日起 7 天內申請撤回。不過，數位內容、客製化商品、因使用而價值降低的商品等可能屬於例外，因此需要包含事前告知與同意要件在內進行個別檢討。"},{"question":"退款應在何時之前處理？","answer":"在韓國電子商務中，業者必須在發生退款事由後於法定期限內退還款項；實務上，將 3 個營業日的基準反映在管理員畫面與通知中會比較安全。若延遲，可能會產生延遲賠償金問題，因此最好設置自動警告功能。"},{"question":"部分退款中最常出問題的項目是什麼？","answer":"整筆訂單優惠券、免運條件、退貨運費、點數使用金額、各商品折扣分攤經常成為問題。為了避免收到退款請求後由營運人員每次判斷，應事先訂定依各商品實際付款金額計算或按比例分攤等規則。"},{"question":"重複付款只要在前端停用按鈕就能防止嗎？","answer":"停用按鈕有幫助，但並不足夠。由於可能發生網路重試、重新整理、Webhook 重複接收，因此還需要伺服器端訂單鎖定、冪等性鍵、唯一交易編號限制條件、基於狀態的驗證。"},{"question":"付款失敗提示文案應包含什麼？","answer":"應包含付款是否尚未完成、失敗原因是什麼、是否可以再次嘗試、訂單會保留多久、諮詢時需要的訂單編號是什麼。如果只顯示發生錯誤的文案，會增加客戶流失與詢問。"},{"question":"為什麼付款紀錄頁面是必要的？","answer":"因為客戶必須能夠自行確認何時付款、付款金額是多少，以及退款進行到哪個階段。如果沒有付款紀錄頁面，所有確認請求都會湧向客服中心，客戶也可能覺得服務沒有妥善管理金流。"},{"question":"退款規定只放在條款頁面就足夠嗎？","answer":"並不足夠。客戶應能在決定購買的商品詳情、訂單、付款按鈕附近，輕鬆確認可退款期間與限制條件。如果隱藏退款規定，或讓取消按鈕難以找到，可能會引發黑暗模式爭議。"},{"question":"AI 提示詞中一定要放入的句子是什麼？","answer":"最好放入一句：如果有尚未決定的政策，請在撰寫程式碼前先提問。這句話是一項安全機制，能讓 AI 反問退款核准方式、運費扣除標準、狀態轉換例外等容易遺漏的政策。"},{"question":"管理員畫面需要哪些退款功能？","answer":"需要退款等待清單、申請日、處理截止日、期限即將到期通知、部分退款計算預覽、退款原因、處理者日誌、權限管理。退款是反覆性的營運工作，因此如果管理員畫面不完善，就難以遵守法定期限並維持客服品質。"},{"question":"數位內容付款也可以套用相同的退款規定嗎？","answer":"數位內容可能會因是否開始提供、事前告知及客戶同意而產生申請撤回限制的問題。因此必須在付款前畫面明確告知退款限制條件，並以記錄同意時間與條款版本的方式實作。"}],"sources":[{"url":"https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률","title":"國家法令資訊中心：關於電子商務等之消費者保護法律","type":"source"},{"url":"https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률시행령","title":"國家法令資訊中心：關於電子商務等之消費者保護法律施行令","type":"source"},{"url":"https://stripe.com/docs/idempotency","title":"Stripe Docs：冪等請求","type":"source"},{"url":"https://docs.tosspayments.com/guides/v2/get-started/payment-flow","title":"Toss Payments Docs：付款串接流程","type":"source"},{"url":"https://www.ftc.go.kr/","title":"公平交易委員會","type":"source"}],"images":[{"id":252,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjQ5NCwicHVyIjoiYmxvYl9pZCJ9fQ==--29af039afe5bc5fc5481b1fee11ed2dbd406a900/ai-bac80653.webp","is_representative":true,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"결제·배송·보안 아이콘과 연결된 중앙의 AI 두뇌 일러스트","caption":"AI 두뇌가 쇼핑, 카드 결제, 배송, 보안 등 결제 흐름의 요소와 연결되어 있다.","description":null},"en":{"alt":"Central AI brain connected to payment, shopping, delivery, security, and support icons","caption":"The illustration links an AI brain to key parts of an online payment flow.","description":null},"ja":{"alt":"決済、買い物、配送、セキュリティのアイコンにつながる中央のAI脳","caption":"AIの脳がオンライン決済フローの主要な要素につながっている。","description":null},"es":{"alt":"Cerebro de IA central conectado a iconos de pago, compras, entrega, seguridad y soporte","caption":"La ilustración conecta un cerebro de IA con partes clave del flujo de pago en línea.","description":null},"id":{"alt":"Otak AI di tengah terhubung ke ikon pembayaran, belanja, pengiriman, keamanan, dan dukungan","caption":"Ilustrasi ini menghubungkan otak AI dengan bagian penting dalam alur pembayaran online.","description":null},"pt":{"alt":"Cérebro de IA central conectado a ícones de pagamento, compras, entrega, segurança e suporte","caption":"A ilustração liga um cérebro de IA a etapas importantes do fluxo de pagamento online.","description":null},"zh-hant":{"alt":"中央 AI 大腦連接付款、購物、配送、安全與客服圖示","caption":"插圖呈現 AI 大腦與線上付款流程中的關鍵元素相連。","description":null}}},{"id":253,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjUwMCwicHVyIjoiYmxvYl9pZCJ9fQ==--a75febd0315285ecae10a5682f4409174d119e4c/ai-363d820f.webp","is_representative":false,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"결제 화면을 중심으로 보안, 분석, 구독, 배송, 오류 흐름이 연결된 일러스트","caption":"AI로 결제 기능을 설계할 때 고려할 핵심 요소들을 한눈에 보여준다.","description":null},"en":{"alt":"Checkout screen connected to panels for security, analytics, subscriptions, delivery, and errors","caption":"The illustration summarizes key areas to decide before building AI-powered payments.","description":null},"ja":{"alt":"決済画面を中心に、セキュリティ、分析、定期課金、配送、エラーがつながるイラスト","caption":"AIで決済機能を作る前に決めるべき要素を整理して示している。","description":null},"es":{"alt":"Pantalla de pago conectada con paneles de seguridad, análisis, suscripción, envío y errores","caption":"La ilustración resume aspectos clave antes de crear pagos con IA.","description":null},"id":{"alt":"Layar checkout terhubung ke panel keamanan, analitik, langganan, pengiriman, dan kesalahan","caption":"Ilustrasi ini merangkum hal penting sebelum membangun pembayaran dengan AI.","description":null},"pt":{"alt":"Tela de checkout conectada a painéis de segurança, análise, assinatura, entrega e erros","caption":"A ilustração resume decisões importantes antes de criar pagamentos com IA.","description":null},"zh-hant":{"alt":"結帳畫面連接安全、分析、訂閱、配送與錯誤流程面板的插圖","caption":"這張插圖概述用 AI 建立付款功能前需先決定的重點。","description":null}}}],"published_at":"2026-07-22T08:42:09+09:00","updated_at":"2026-07-22T08:42:09+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant"],"url":"https://injoys.com/en/articles/ai-payment-feature-7-core-decisions"}