---
title: "用AI打造支付功能前必須先決定的7件事"
locale: zh-hant
category: how_to
category_name: "操作教學"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/ai-payment-feature-7-core-decisions
published_at: 2026-07-22T08:42:09+09:00
---

# 用AI打造支付功能前必須先決定的7件事

> AI可以快速產生支付程式碼，但支付功能的安全性取決於訂單狀態、退款期限、部分退款、防止重複付款等政策設計。尤其是韓國電子商務服務，必須在開發需求中明確反映撤回申購、退款延遲利息、退款規定告知、避免暗黑模式等事項。

## Key Points

- 支付功能不只是單純的信用卡授權功能，而是連結訂單、結算、退款、客戶應對與法律告知的營運系統。
- 訂單狀態應定義為等待付款、付款完成、取消、退款進行中、退款完成等，讓客戶與營運人員能以相同意義理解。
- 在韓國電子商務中，一般需要考慮消費者的撤回申購期間、業者的退款處理期限，以及延遲利息規定。
- 防止重複付款僅靠停用按鈕並不足夠，還需要伺服器端的冪等性金鑰、訂單鎖定與支付授權重複檢查。
- 隱藏退款規定和取消方法，或讓解約變得困難的設計，會損害客戶信任，並提高暗黑模式監管風險。

## 核心摘要

把付款功能交給 AI 時，最危險的提示詞就是單純要求「幫我加上付款」。付款不是收錢的程式碼，而是負責金流的營運、會計、客服系統。

從技術上來說，AI 可以快速實作付款視窗串接、呼叫授權 API、接收 webhook、儲存訂單。然而，如果沒有先決定以下政策，實際服務中就可能發生幽靈訂單、重複付款、退款延遲、客服中心爆量、法律告知遺漏等問題。

| 決策領域 | 事前必須決定的問題 | 失敗時的風險 |
|---|---|---|
| 訂單狀態 | 訂單會依序經過哪些狀態？ | 已付款但沒有訂單的幽靈訂單發生 |
| 退款期限 | 如何反映撤回要約與退款處理期限？ | 違反法定期限、延遲利息、爭議風險 |
| 部分退款 | 如何計算部分商品退貨、優惠券、運費？ | 營運人員每次都要手動計算，客戶不信任 |
| 重複付款 | 如何防止同一筆訂單被收取兩次付款？ | 客戶依信用卡帳單提出不滿，信任下降 |
| 失敗 안내 | 如何告知超過額度、餘額不足、認證失敗？ | 重試轉換率下降，不必要的詢問增加 |
| 付款紀錄 | 客戶在哪裡確認付款與退款狀態？ | 客服中心詢問增加，狀態不透明 |
| 退款告知 | 退款規定與取消按鈕要放在哪裡？ | 黑暗模式爭議、法規風險 |

## 1. 訂單狀態設計：狀態就是營運語言

製作付款功能時，訂單狀態不能只有「訂單完成」一種。實際訂單會經過付款嘗試、授權、取消、退款、失敗、逾期等多個階段。

### 建議狀態範例

| 狀態代碼範例 | 顯示給客戶的狀態 | 意義 |
|---|---|---|
| `payment_pending` | 等待付款 | 訂單已建立但付款尚未完成 |
| `paid` | 付款完成 | 付款授權已完成，訂單有效 |
| `payment_failed` | 付款失敗 | 付款嘗試失敗，需要判斷是否可重試 |
| `cancel_requested` | 取消申請 | 客戶已申請取消，等待處理中 |
| `cancelled` | 取消完成 | 付款前訂單取消或授權取消已完成 |
| `refund_requested` | 退款申請 | 付款後的退款申請已受理 |
| `refund_processing` | 退款進行中 | 正在處理退款核准或付款方式退款 |
| `partially_refunded` | 部分退款完成 | 訂單金額中僅部分已退款 |
| `refunded` | 退款完成 | 退款處理已完成 |
| `expired` | 訂單逾期 | 等待付款時間已過，訂單失效 |

### 狀態設計原則

- 不要把訂單狀態與付款狀態視為完全相同。訂單可能存在但付款失敗，付款也可能已授權但訂單儲存失敗。
- 每一次狀態變更都要留下發生時間、處理者、原因、付款交易識別碼、退款交易識別碼。
- 客戶畫面、管理員畫面、客服應對話術必須使用相同的狀態定義。
- 狀態轉移應設計為單向，例外復原則以另外的管理員權限留下紀錄後處理。

## 2. 撤回要約與法定退款期限：不是政策，而是法律要求

如果在韓國經營面向消費者的電子商務，必須考量《電子商務等消費者保護相關法律》。一般而言，消費者可在一定期間內撤回要約，業者則必須在退款請求或返還程序之後，於規定期限內退還款項。

實務中特別重要的標準如下。

- 原則上，消費者可自收到商品等法律所定基準日起 7日內撤回要約。
- 業者在發生退款事由後，必須於法定期限內退還款項；若延遲，可能產生延遲賠償金或延遲利息問題。
- 數位內容、客製化商品、因使用而價值顯著降低的商品等可能屬於例外，但若要適用例外，必須慎重確認事前告知與同意等要件。
- 實際適用可能因商品類型、契約方式、提供給消費者的告知、是否開始使用而不同，因此需要法務審查。

### 轉換為開發需求的方法

法律標準只寫在條款文字裡是不夠的，也必須轉換為系統需求。

| 法律、政策要求 | 系統需求 |
|---|---|
| 判斷是否可於 7日內撤回要約 | 以訂單收貨日或服務提供日為基準，自動計算可退款期間 |
| 需要於 3個營業日內處理退款 | 在管理員畫面顯示退款申請日與處理截止日 |
| 退款延遲風險 | 顯示即將到期、超過期限提醒 |
| 需要告知例外商品 | 付款前明確標示為退款限制商品，並儲存同意紀錄 |
| 需要因應爭議 | 保存條款版本、告知時間、同意時間、客戶 IP 或帳號紀錄 |

## 3. 部分退款規則：優惠券、運費、稅務要先定義

部分退款比全額取消複雜得多。一次訂購多項商品後只退回其中一部分時，必須決定原本套用的折扣與運費要如何分攤。

### 必須決定的項目

- 如何分配各商品的付款金額
- 訂單整體優惠券是否按商品比例分攤
- 特定商品優惠券是否只套用於該商品
- 免運條件不再成立時，是否扣除運費
- 如何區分單純變心退貨運費與商品瑕疵退貨運費
- 點數、積分、禮品卡付款部分要依什麼順序退款
- 部分退款後，稅務發票、現金收據、收據標示要如何變更

### 部分退款計算範例

| 項目 | 金額 |
|---|---:|
| A 商品 | 30,000원 |
| B 商品 | 70,000원 |
| 訂單整體優惠券 | -10,000원 |
| 實際付款金額 | 90,000원 |

如果按商品金額比例分攤優惠券，A 商品會分攤 3,000원 折扣，B 商品會分攤 7,000원 折扣。此時若只退款 A 商品，退款基準金額不是 30,000원，而是 27,000원。如果有免運條件、退貨運費、各付款方式退款限制，最終退款金額可能會再不同。

答案不只一個。重要的是事先決定一致的規則，並在客戶付款前或申請退款前，告知到能讓客戶理解。

## 4. 防止重複付款：只停用按鈕是不夠的

重複付款是客戶最快發現的付款事故。客戶會先看到信用卡授權簡訊與信用卡帳單，而不是服務內部的訂單狀態。同一筆訂單若被付款兩次，信任會大幅下降。

### 發生原因

- 客戶連續點擊付款按鈕
- 付款後立即重新整理或按返回
- 因行動網路延遲而重新傳送相同請求
- 付款授權回應成功，但服務伺服器儲存失敗
- webhook 與客戶端重新導向同時變更訂單狀態

### 防禦設計

| 防禦裝置 | 說明 |
|---|---|
| 客戶端按鈕鎖定 | 付款按鈕點擊後防止再次點擊，但僅作為輔助手段使用 |
| 伺服器端訂單鎖定 | 針對相同訂單 ID，避免同時執行付款授權請求 |
| 冪等性鍵 | 使用識別碼，讓同一付款請求即使傳送多次，也只產生一次結果 |
| 唯一交易編號 | 以資料庫限制條件防止訂單號與付款交易編號重複儲存 |
| 基於狀態的驗證 | 對已經是 `paid` 的訂單阻止追加授權請求 |
| webhook 重複處理 | 即使相同 webhook 事件來了多次，也只發生一次狀態變更 |

向 AI 要求付款程式碼時，最好不要只說「防止重複點擊」，而要明確寫出「同一筆訂單的付款授權與付款完成處理必須以冪等方式運作」。

## 5. 付款失敗 안내 文案：失敗不是事故，而是正常流程

付款失敗是每天都會發生的正常情況。超過額度、餘額不足、信用卡認證失敗、密碼錯誤、3D Secure 認證失敗、簡易付款 App 無回應、網路錯誤，都是常見案例。

不好的 안내 是以「發生錯誤」結束的文案。客戶不知道是否已付款、是否可以再按一次、訂單是否會消失。

### 안내 文案範例

| 情況 | 建議 안내 |
|---|---|
| 餘額不足 | 因付款方式餘額不足，付款未完成。請選擇其他付款方式，或確認餘額後再試一次。 |
| 超過額度 | 因超過信用卡額度或單次付款額度，付款失敗。請在發卡公司 App 確認額度，或使用其他信用卡付款。 |
| 認證失敗 | 付款認證未完成，因此訂單會維持等待付款狀態。可於 30分鐘內再次付款。 |
| 網路錯誤 | 付款結果確認延遲中。為防止重複付款，請稍後確認付款紀錄。 |
| 訂單逾期 | 等待付款時間已過，訂單已逾期。請重新選擇商品並下單。 |

### 失敗 안내 的核心要素

- 明確說明付款是否實際上未完成。
- 告知訂單會保留多久。
- 안내 是否可以重試，或是否需要使用其他付款方式。
- 顯示向客服中心詢問時所需的訂單號。
- 如果付款結果不確定，不要一律引導重新付款，而要提供確認中狀態。

## 6. 付款紀錄頁面：減少客服中心負擔的核心畫面

如果沒有付款紀錄頁面，客戶會為了確認付款、取消、退款狀態而詢問客服中心。付款紀錄不是單純的收據畫面，而是讓客戶確認自己金錢目前狀態的信任裝置。

### 付款紀錄頁面應包含的資訊

- 訂單號
- 訂單日期時間與付款日期時間
- 商品名稱、數量、選項
- 付款方式與授權號或交易識別碼
- 商品金額、折扣、運費、點數使用金額、最終付款金額
- 目前訂單狀態與退款狀態
- 退款申請日、退款核准日、預計退款完成日
- 是否可取消或退款
- 收據、交易明細、現金收據確認連結
- 向客服中心詢問時所需的資訊

### 與營運者畫面的連結

客戶畫面與管理員畫面必須看到相同資料。如果客戶看到的是「退款進行中」，但管理員畫面顯示「處理完成」，客服應對就會混亂。狀態名稱可以用不同方式表達，但內部狀態代碼與轉移規則必須只有一套。

## 7. 退款規定告知位置：藏起來就不是政策，而是風險

退款規定只放在條款頁面的角落是不夠的。客戶在做出付款決定的畫面上，必須能輕易確認可退款期間、退款限制條件、取消方法。

### 好的告知位置

- 商品詳細頁的價格或購買按鈕附近
- 購物車或訂單畫面
- 付款按鈕正上方的條款與退款規定同意區域
- 付款完成頁面
- 我的頁面中的訂單詳細畫面
- 退款申請畫面

### 應避免的設計

- 註冊與付款可以一次完成，但解約或退款只能透過客服中心電話辦理的設計
- 把取消按鈕藏在多個步驟深處的設計
- 付款後才顯示退款限制條件的設計
- 以會讓客戶誤解的方式配置按鈕顏色、文案、順序的設計
- 免費試用結束後，未明確告知會自動付款的設計

這類設計不只會傷害客戶體驗，也可能被評為黑暗模式。尤其取消與解約的難度，最好設計成與註冊和付款的難度差異不要太大，這樣比較安全。

## 要包含在給 AI 的提示詞中的檢查清單

向 AI 開發工具要求實作付款功能時，應像下面一樣先傳達政策。

### 付款功能提示詞範例

```text
請實作面向韓國消費者的電子商務服務付款功能。
請務必反映以下政策。

1. 訂單狀態使用 payment_pending, paid, payment_failed, cancel_requested, cancelled, refund_requested, refund_processing, partially_refunded, refunded, expired。
2. 等待付款的訂單在 30分鐘後變更為 expired。
3. 同一筆訂單只允許 1筆付款授權，並使用伺服器端訂單鎖定與冪等性鍵。
4. 付款 webhook 可能重複接收，因此相同事件 ID 只處理一次。
5. 儲存退款申請日、退款處理截止日、處理者、原因、退款交易編號。
6. 部分退款以各商品實際付款金額為基準計算，訂單整體優惠券依商品金額比例分攤。
7. 付款失敗時，依失敗原因回傳給客戶的 안내 文案。
8. 讓客戶可在我的頁面確認付款紀錄與退款狀態。
9. 付款前顯示退款規定連結與同意核取方塊，並儲存同意時間與條款版本。
10. 如果有尚未決定的政策，請在撰寫程式碼前先提問。
```

最後一句「如果有尚未決定的政策，請先提問」很重要。退款是否自動核准、管理員核准權限、運費扣除方式等人容易遺漏的政策，可以讓 AI 反問確認。

## 營運者畫面需要的功能

付款功能不能只靠客戶畫面完成。退款與取消是每天都會處理的營運工作，因此一定需要管理員畫面。

| 管理員功能 | 需要的理由 |
|---|---|
| 退款等待清單 | 為了不漏掉必須處理的退款案件 |
| 法定處理期限顯示 | 為了降低退款延遲風險 |
| 期限將至、超過警告 | 為了讓營運者立即知道 3個營業日等內部標準 |
| 退款原因選擇 | 為了單純變心、商品瑕疵、錯誤配送等統計與費用分攤 |
| 部分退款計算預覽 | 為了減少營運者手動計算錯誤 |
| 處理紀錄 | 為了因應爭議與稽核 |
| 權限管理 | 為了限制退款核准與強制狀態變更 |

## 付款資料模型的最低構成

每個服務的資料結構都不同，但至少最好將以下程度的資料分開保存。

| 資料表或物件 | 核心欄位 |
|---|---|
| 訂單 | 訂單 ID、客戶 ID、訂單狀態、訂單金額、折扣金額、運費、建立日期時間、逾期日期時間 |
| 訂單商品 | 商品 ID、商品名稱、選項、數量、各商品金額、各商品折扣分攤金額 |
| 付款 | 付款 ID、訂單 ID、付款方式、授權號、授權金額、付款狀態、授權日期時間 |
| 退款 | 退款 ID、訂單 ID、退款金額、退款原因、退款狀態、申請日期時間、完成日期時間 |
| 狀態歷程 | 對象 ID、先前狀態、變更後狀態、變更者、變更原因、變更日期時間 |
| 條款同意 | 條款種類、條款版本、是否同意、同意日期時間、客戶 ID |

重要的是不要覆寫付款授權金額、退款金額、訂單總額。與金錢相關的值，盡可能以歷程與交易單位保存，之後帳簿與客服應對才會對得上。

## 上線前檢查清單

- 對同一筆訂單按下付款按鈕 10次，付款是否只授權 1次？
- 付款授權後如果伺服器儲存失敗，是否可以復原？
- 即使付款 webhook 多次傳送相同事件，是否不會重複處理？
- 客戶是否能理解付款失敗原因與重試方法？
- 等待付款的訂單是否會在一定時間後自動逾期？
- 部分退款金額是否與優惠券、點數、運費政策一致？
- 從退款申請日到處理截止日，是否會顯示在管理員畫面？
- 退款規定是否能在付款前畫面輕易確認？
- 數位內容或退款限制商品是否有事前告知與同意紀錄？
- 客戶是否能在我的頁面直接確認付款紀錄與退款狀態？

## 結論

AI 可以快速製作付款功能的程式碼。但安全且合法營運的付款系統，始於程式碼之前的政策決策。

先整理訂單狀態、法定退款期限、部分退款計算式、防止重複付款、付款失敗 안내、付款紀錄頁面、退款規定告知位置，再把實作交給 AI，就能得到穩定得多的結果。付款不是「收錢的功能」，而是「負責金錢的功能」，應以這個觀點來設計。

## FAQ

### 要求 AI 製作付款功能時，最先需要決定的是什麼？
最先需要決定訂單狀態與付款狀態的流程。必須定義等待付款、付款完成、付款失敗、取消請求、退款進行中、退款完成等狀態，AI 才能建立安全的資料結構與畫面流程。

### 為什麼把訂單狀態單純設為一個訂單完成會很危險？
因為實際付款有很多例外流程，例如失敗、取消、退款、到期等。如果狀態過於單純，可能會發生已付款但沒有訂單紀錄，或退款已完成但客戶畫面仍顯示付款完成的問題。

### 在韓國電子商務中，7 天申請撤回規定是否一定適用？
一般而言，消費者可以在法律規定的基準日起 7 天內申請撤回。不過，數位內容、客製化商品、因使用而價值降低的商品等可能屬於例外，因此需要包含事前告知與同意要件在內進行個別檢討。

### 退款應在何時之前處理？
在韓國電子商務中，業者必須在發生退款事由後於法定期限內退還款項；實務上，將 3 個營業日的基準反映在管理員畫面與通知中會比較安全。若延遲，可能會產生延遲賠償金問題，因此最好設置自動警告功能。

### 部分退款中最常出問題的項目是什麼？
整筆訂單優惠券、免運條件、退貨運費、點數使用金額、各商品折扣分攤經常成為問題。為了避免收到退款請求後由營運人員每次判斷，應事先訂定依各商品實際付款金額計算或按比例分攤等規則。

### 重複付款只要在前端停用按鈕就能防止嗎？
停用按鈕有幫助，但並不足夠。由於可能發生網路重試、重新整理、Webhook 重複接收，因此還需要伺服器端訂單鎖定、冪等性鍵、唯一交易編號限制條件、基於狀態的驗證。

### 付款失敗提示文案應包含什麼？
應包含付款是否尚未完成、失敗原因是什麼、是否可以再次嘗試、訂單會保留多久、諮詢時需要的訂單編號是什麼。如果只顯示發生錯誤的文案，會增加客戶流失與詢問。

### 為什麼付款紀錄頁面是必要的？
因為客戶必須能夠自行確認何時付款、付款金額是多少，以及退款進行到哪個階段。如果沒有付款紀錄頁面，所有確認請求都會湧向客服中心，客戶也可能覺得服務沒有妥善管理金流。

### 退款規定只放在條款頁面就足夠嗎？
並不足夠。客戶應能在決定購買的商品詳情、訂單、付款按鈕附近，輕鬆確認可退款期間與限制條件。如果隱藏退款規定，或讓取消按鈕難以找到，可能會引發黑暗模式爭議。

### AI 提示詞中一定要放入的句子是什麼？
最好放入一句：如果有尚未決定的政策，請在撰寫程式碼前先提問。這句話是一項安全機制，能讓 AI 反問退款核准方式、運費扣除標準、狀態轉換例外等容易遺漏的政策。

### 管理員畫面需要哪些退款功能？
需要退款等待清單、申請日、處理截止日、期限即將到期通知、部分退款計算預覽、退款原因、處理者日誌、權限管理。退款是反覆性的營運工作，因此如果管理員畫面不完善，就難以遵守法定期限並維持客服品質。

### 數位內容付款也可以套用相同的退款規定嗎？
數位內容可能會因是否開始提供、事前告知及客戶同意而產生申請撤回限制的問題。因此必須在付款前畫面明確告知退款限制條件，並以記錄同意時間與條款版本的方式實作。

## Sources

- [國家法令資訊中心：關於電子商務等之消費者保護法律](https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률)
- [國家法令資訊中心：關於電子商務等之消費者保護法律施行令](https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률시행령)
- [Stripe Docs：冪等請求](https://stripe.com/docs/idempotency)
- [Toss Payments Docs：付款串接流程](https://docs.tosspayments.com/guides/v2/get-started/payment-flow)
- [公平交易委員會](https://www.ftc.go.kr/)

## Images

![中央 AI 大腦連接付款、購物、配送、安全與客服圖示](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjQ5NCwicHVyIjoiYmxvYl9pZCJ9fQ==--29af039afe5bc5fc5481b1fee11ed2dbd406a900/ai-bac80653.webp)
![結帳畫面連接安全、分析、訂閱、配送與錯誤流程面板的插圖](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjUwMCwicHVyIjoiYmxvYl9pZCJ9fQ==--a75febd0315285ecae10a5682f4409174d119e4c/ai-363d820f.webp)