AIで決済機能を作る前に決めるべき7つのこと

核心要約

AIに決済機能を任せるとき、最も危険なプロンプトは単に「決済を付けて」と依頼することです。決済はお金を受け取るコードではなく、お金の流れに責任を持つ運用・会計・カスタマーサポートのシステムです。

技術的には、決済画面連携、承認 API 呼び出し、Webhook 受信、注文保存をAIが素早く実装できます。しかし、次の方針が決まっていなければ、実際のサービスでは幽霊注文、二重決済、返金遅延、カスタマーセンターの問い合わせ急増、法的告知漏れの問題が発生する可能性があります。

1. 注文状態設計：状態こそが運用言語である

決済機能を作るとき、注文状態を「注文完了」だけにしてはいけません。実際の注文は、決済試行、承認、キャンセル、返金、失敗、期限切れのような複数の段階を経ます。

推奨状態の例

状態設計の原則

• 注文状態と決済状態を完全に同じものとは見なしません。注文は存在するが決済が失敗することもあり、決済は承認されたが注文保存が失敗することもあります。
• すべての状態変更には、発生時刻、処理者、理由、決済取引識別子、返金取引識別子を残します。
• 顧客画面、管理者画面、カスタマーセンターの対応文言が同じ状態定義を使用する必要があります。
• 状態遷移は一方向に設計し、例外復旧は別途管理者権限で記録を残して処理します。

2. 申込み撤回と法定返金期限：方針ではなく法的要件である

韓国で消費者向け電子商取引を運営するなら、電子商取引等における消費者保護に関する法律を考慮する必要があります。一般的に消費者は一定期間内に申込み撤回を行うことができ、事業者は返金要請または返還手続きの後、定められた期限内に代金を返金しなければなりません。

実務で特に重要な基準は次のとおりです。

• 消費者は原則として、財貨などの供給を受けた日など、法律で定められた基準日から7日以内に申込み撤回を行うことができます。
• 事業者は返金事由が発生した後、法定期限内に代金を返金しなければならず、遅延した場合は遅延賠償金または遅延利息の問題が生じる可能性があります。
• デジタルコンテンツ、オーダーメイド商品、使用により価値が著しく減少する商品などは例外になり得ますが、例外を適用するには事前告知と同意などの要件を慎重に確認する必要があります。
• 実際の適用は、商品類型、契約方式、消費者に提供した告知、使用開始の有無によって変わり得るため、法務レビューが必要です。

開発要件に変える方法

法的基準は約款文言にだけ書いておくだけでは不十分です。システム要件にも変える必要があります。

3. 部分返金ルール：クーポン、配送料、税金を事前に定義する

部分返金は全体キャンセルよりはるかに複雑です。複数の商品を一度に注文した後、一部だけ返品する場合、もともと適用された割引と配送料をどのように分けるかを決める必要があります。

必ず決めるべき項目

• 商品別の決済金額をどのように配分するのか
• 注文全体クーポンを商品別に比例配分するのか
• 特定商品クーポンは該当商品にのみ適用するのか
• 送料無料条件が満たされなくなったとき、配送料を差し引くのか
• 顧客都合の返品配送料と商品不良の返品配送料をどのように区別するのか
• ポイント、積立金、ギフトカード決済分をどの順序で返金するのか
• 部分返金後、税金計算書、現金領収書、領収書表記をどのように変更するのか

部分返金計算の例

クーポンを商品金額の比率で配分すると、A 商品には3,000ウォン、B 商品には7,000ウォンの割引が配分されます。このとき A 商品だけを返金する場合、返金基準金額は30,000ウォンではなく27,000ウォンです。送料無料条件、返品配送料、決済手段別の返金制限があれば、最終返金額はさらに変わる可能性があります。

正解は一つではありません。重要なのは、一貫したルールを事前に定め、顧客が決済前または返金申請前に理解できるよう告知することです。

4. 二重決済防止：ボタン無効化だけでは不十分である

二重決済は、顧客が最も早く発見する決済事故です。顧客はサービス内部の注文状態よりも、カード承認メッセージとカード明細を先に見ます。同じ注文が二度決済されると、信頼は大きく低下します。

発生原因

• 顧客が決済ボタンを連続クリックする
• 決済直後に更新したり、戻るを押したりする
• モバイルネットワーク遅延により同じリクエストが再送信される
• 決済承認レスポンスは成功したが、サービスサーバーへの保存が失敗する
• Webhook とクライアントリダイレクトが同時に注文状態を変更する

防御設計

AIに決済コードを依頼するときは、「重複クリック防止」ではなく「同一注文に対する決済承認と決済完了処理は冪等に動作しなければならない」と明示するのがよいです。

5. 決済失敗案内文言：失敗は事故ではなく正常な流れである

決済失敗は毎日発生する正常な状況です。限度額超過、残高不足、カード認証失敗、パスワードエラー、3D Secure 認証失敗、簡単決済アプリの無応答、ネットワークエラーはいずれもよくあるケースです。

悪い案内は「エラーが発生しました」で終わる文言です。顧客は決済されたのか、もう一度押してよいのか、注文が消えるのか分かりません。

案内文言の例

失敗案内の核心要素

• 決済が実際に完了していないのかを明確に伝えます。
• 注文が維持される時間を知らせます。
• 再試行してよいのか、別の決済手段を使うべきなのかを案内します。
• カスタマーセンターに問い合わせる際に必要な注文番号を表示します。
• 決済結果が不確実な場合、無条件に再決済を誘導せず、確認中の状態を提供します。

6. 決済履歴ページ：カスタマーセンターを減らす核心画面である

決済履歴ページがないと、顧客は決済、キャンセル、返金状態を確認するためにカスタマーセンターに問い合わせます。決済履歴は単なる領収書画面ではなく、顧客が自分のお金の現在状態を確認するための信頼装置です。

決済履歴ページに含める情報

• 注文番号
• 注文日時と決済日時
• 商品名、数量、オプション
• 決済手段と承認番号または取引識別子
• 商品金額、割引、配送料、ポイント使用額、最終決済額
• 現在の注文状態と返金状態
• 返金申請日、返金承認日、返金完了予定日
• キャンセルまたは返金の可否
• 領収書、取引明細書、現金領収書の確認リンク
• カスタマーセンター問い合わせ時に必要な情報

運用者画面との連携

顧客画面と管理者画面は同じデータを見る必要があります。顧客には「返金処理中」と見えているのに、管理者画面では「処理完了」と表示されていると、カスタマーセンター対応が混乱します。状態名は異なる表現にできますが、内部状態コードと遷移ルールは一つでなければなりません。

7. 返金規定の告知位置：隠すと方針ではなくリスクになる

返金規定は約款ページの片隅に置くだけでは不十分です。顧客が決済判断を下す画面で、返金可能期間、返金制限条件、キャンセル方法を簡単に確認できる必要があります。

良い告知位置

• 商品詳細ページの価格または購入ボタン付近
• カートまたは注文書画面
• 決済ボタンのすぐ上にある約款および返金規定の同意領域
• 決済完了ページ
• マイページの注文詳細画面
• 返金申請画面

避けるべき設計

• 登録と決済は一度でできるが、解約や返金はカスタマーセンターへの電話でしかできないようにする設計
• キャンセルボタンを複数段階の奥に隠す設計
• 返金制限条件を決済後になって初めて見せる設計
• 顧客が誤解するようにボタンの色、文言、順序を配置する設計
• 無料体験終了後の自動決済の事実を明確に知らせない設計

このような設計は顧客体験を損なうだけでなく、ダークパターンと評価される可能性があります。特にキャンセルと解約の難易度は、登録と決済の難易度と大きく変わらないように設計するのが安全です。

AIに渡すプロンプトに含めるチェックリスト

AI開発ツールに決済機能の実装を依頼するときは、以下のように方針を先に伝える必要があります。

決済機能プロンプトの例

韓国の消費者向け電子商取引サービスの決済機能を実装して。
次の方針を必ず反映して。

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に問い返させることができます。

運用者画面に必要な機能

決済機能は顧客画面だけでは完成しません。返金とキャンセルは毎日処理される運用業務であるため、管理者画面が必ず必要です。

決済データモデルの最小構成

サービスごとにデータ構造は異なりますが、少なくとも以下のレベルのデータは分離しておくのがよいです。

重要なのは、決済承認金額、返金金額、注文総額を上書きしないことです。お金に関する値は、可能であれば履歴と取引単位で保存しておくことで、後から帳簿と顧客対応が一致します。

リリース前チェックリスト

• 同じ注文に対して決済ボタンを10回押しても、決済は1回だけ承認されるか？
• 決済承認後にサーバー保存が失敗した場合、復旧できるか？
• 決済 Webhook が同じイベントを複数回送っても、重複処理されないか？
• 顧客が決済失敗理由と再試行方法を理解できるか？
• 決済待ち注文が一定時間後に自動で期限切れになるか？
• 部分返金金額がクーポン、ポイント、配送料方針と一致しているか？
• 返金申請日から処理期限までが管理者画面に表示されるか？
• 返金規定が決済前画面で簡単に確認できるか？
• デジタルコンテンツまたは返金制限商品には事前告知と同意ログがあるか？
• 顧客がマイページで決済履歴と返金状態を直接確認できるか？

結論

AIは決済機能のコードを素早く作ることができます。しかし、安全かつ合法的に運用される決済システムは、コード以前の方針決定から始まります。

注文状態、法定返金期限、部分返金計算式、二重決済防止、決済失敗案内、決済履歴ページ、返金規定の告知位置を先に整理したうえでAIに実装を任せれば、はるかに安定した結果を得ることができます。決済は「お金を受け取る機能」ではなく、「お金に責任を持つ機能」という観点で設計しなければなりません。