URUB
URUB
相談→
URUB / ARTICLE / チャージバック発生後に証拠を探し回らない|注文別・争点別「反…
#チャージバック#不正注文対策#決済運用#証跡管理#CS#定期購入

チャージバック発生後に証拠を探し回らない|注文別・争点別「反証パケット台帳」の作り方(Shopify・カート共通)

2026-10-04
ON THIS PAGE▼
  1. 01反証パケット台帳は「証拠一覧」ではなく「争点への回答表」にする
  2. 02通知を受けた当日に確定する5項目
  3. 03争点別に切り替える証跡セット
  4. 04ファイルを回収し、提出順に編集する手順
  5. 05Shopifyとカート共通で、保存場所を分けて設計する
  6. 06発生後の台帳を、次回のための保存設計に変える
  7. 07参考情報

チャージバックへの対応は、配送追跡番号を提出して終わる作業ではありません。カード会社から示された異議理由に対して、「この注文で、いつ、何が起きたか」を第三者が追える形にして提出する必要があります。

そのために有効なのが、注文番号ごとに証跡を束ね、さらに争点との対応関係を記録する反証パケット台帳です。ここでいうパケットとは、単なるファイル置き場ではなく、提出資料の選定理由・保存元・取得担当・提出状況まで含む1件単位の管理票を指します。

Shopifyはチャージバック・照会への回答期間が通常7〜21日であると案内しています。ただし、実際の期限と提出方法は通知内容、決済手段、理由コードによって異なります。通知を受け取ったら、まず管理画面や決済代行会社の案内に記載された期限を正としてください。Shopify Help Center(確認対象:2026年10月4日)

反証パケット台帳は「証拠一覧」ではなく「争点への回答表」にする

証跡を集めても、提出資料が争点に結び付いていなければ、担当者が説明を組み立て直すことになります。台帳の起点は「持っているデータ」ではなく、通知に書かれた異議理由・理由コード・提出期限です。

たとえば、未着の主張であれば配送記録が中心になります。一方、定期購入を「解約したのに請求された」とする主張なら、配送完了だけで契約状態や解約依頼への応答を説明することはできません。申込時の条件、更新通知、解約日時、CS対応の順に確認できる記録が必要になります。

台帳はスプレッドシート、データベース、受注管理システムのいずれでも構いません。重要なのは、次の項目を注文ごとに固定することです。

項目記載内容
案件ID社内用の一意な番号。注文番号とは分けてもよい
注文番号・決済IDカートの注文番号、決済代行会社の取引ID、サブスクリプションID
通知情報通知日、提出期限、理由コード、異議申立て窓口
争点分類不正利用、未着、返金、商品相違、定期購入など
主張への回答「○月○日に配送済み」「○月○日に返金済み」など、事実を短く記す
証跡IDファイル名または保管URL。本文中の引用箇所も記録する
保存元Shopify、決済代行会社、配送会社、CSツール、メール、サブスクアプリなど
取得担当・取得日時誰が、いつ取得した版か
提出優先度必須、補強、保留の3区分
提出状態未回収、確認中、提出済み、提出対象外

「提出状態」と「保存済み」を分ける点が重要です。保存されているが今回の争点には不要な資料と、提出すべきなのに未回収の資料を区別できます。

通知を受けた当日に確定する5項目

期限が短い案件では、資料集めを始める前に判断を固定します。最初の30分から1時間で、少なくとも次を台帳に転記します。

  1. 提出期限とタイムゾーン:社内締切は、外部期限の1営業日前などに設定します。
  2. 異議理由・理由コード:顧客の主張を推測で言い換えず、通知の原文も保存します。
  3. 決済の受付主体:Shopify Payments、外部決済、モール、後払いなど、提出先を確認します。
  4. 対象範囲:対象の注文、請求、部分返金、定期購入の更新回を特定します。
  5. 提出形式:画面入力、ファイル添付、文字数・ファイル数の上限、使用可能な形式を確認します。

通知メールだけを案件の正本にせず、管理画面または決済代行会社の異議申立て画面でも期限・理由・対象金額を照合してください。通知の転送や担当交代があっても、確認元を台帳に残せます。

この時点で、反論文を書き始めないことも大切です。最初に「何を証明する案件か」を決めてから、証跡を回収します。反論文は、証跡IDが揃った後に作成した方が、記載と添付の不整合を抑えられます。

争点別に切り替える証跡セット

同じ注文情報でも、提出価値は争点で変わります。以下は提出内容を決定するための整理です。「必須」は常に採用すべきという意味ではなく、当該の主張に回答するために優先確認する資料を示します。提出可否は通知の要求事項を優先してください。

不正利用・本人性が争点の場合

優先する証跡

  • 注文日時、購入商品、請求・配送先、注文確認の記録
  • 決済時の認証・承認に関する記録。取得できる範囲は決済手段・決済代行会社の表示に従う
  • 顧客が注文を認識していることを示すメール、チャット、問い合わせ履歴
  • 高額品や役務提供なら、受領、利用、アカウント操作などに関する記録

配送完了は取引履行の補強にはなりますが、それだけで購入者本人性を説明する資料にはなりません。IPアドレス、端末情報、認証結果などを取得できた場合も、意味づけを推測で補わず、表示された事実として提出します。

商品未着・未提供が争点の場合

優先する証跡

  • 配送伝票、追跡履歴、配達日時、配送先
  • 受領確認、置き配写真、受領印など、配送会社から取得できる記録
  • デジタル商品・役務なら、提供日時、ログイン・利用・ダウンロード等の提供記録
  • 顧客からの配送先変更、再配達、受取に関する連絡

追跡画面は後日表示が変わる場合もあるため、案件対応時にPDF化または画面保存し、取得日時を台帳に記録します。追跡番号だけでなく、注文番号と配送番号の対応も1枚で確認できる状態にします。

返金未処理が争点の場合

優先する証跡

  • 返金日時、金額、対象明細、返金取引ID
  • 返金を案内したメールまたはCS記録
  • 返品受領日、返金条件、部分返金なら算定根拠

ここでは「返金したはず」という社内メモではなく、決済システム上の返金処理記録が中心です。返金処理とカード明細への反映時期は別になる場合があるため、返金実行日時と、顧客への案内内容を混同しません。

商品相違・説明と異なることが争点の場合

優先する証跡

  • 購入時点の商品ページ、商品名、仕様、バリエーション、価格
  • 注文時に選択されたSKU・オプション
  • 販売条件、返品条件、注意事項
  • 出荷商品を確認できるピッキング・検品記録、必要に応じて梱包記録
  • 問い合わせと交換・返品提案を含むCS対応履歴

現在の商品ページを出力するだけでは、購入当時の表示を示せないことがあります。商品説明、価格、画像、販売条件を更新する運用なら、公開時のPDFやHTML、CMSの変更履歴など、購入時点を特定できる保存物を別途残す設計が必要です。

定期購入の解約・継続請求が争点の場合

Stripeの異議申立て資料例では、定期購入に関して、申込時に同意した条件、更新・解約・返金規約、解約記録・確認、解約方法、更新前通知、利用・問い合わせ記録を分けて例示しています。Stripe Documentation(確認対象:2026年10月4日)

優先する証跡

  • 初回申込時のプラン、請求間隔、金額、初回・更新条件
  • 購入時に表示した定期条件・解約条件と、その同意記録
  • 更新前通知の送信日時・送信先・内容
  • 解約依頼の受信日時、解約処理日時、次回請求との前後関係
  • 顧客自身の解約操作またはCSによる代行処理の履歴
  • 解約確認、返金案内、継続利用・配送・問い合わせの記録

時系列が最重要です。「解約処理日」「次回請求日」「更新通知日」を同じタイムゾーンで並べます。サブスクリプションアプリの状態だけでは、顧客への表示や通知内容が分からない場合があるため、アプリ履歴、メール配信履歴、購入時表示を別証跡として扱います。

ファイルを回収し、提出順に編集する手順

証拠の量を増やすより、審査者が確認しやすい順序にする方が重要です。1案件を以下の順番で組み立てます。

1. 1ページ目に案件要約を置く

案件要約には、注文番号、決済ID、異議理由、対象金額、結論、時系列の要点、添付一覧を記載します。結論は評価語を避け、証跡で確認できる事実に限定します。

結論:対象注文は2026年10月1日に発送され、配送会社の追跡記録では10月3日に配達完了となっている。
根拠:E-03 配送追跡記録、E-04 注文・配送番号対応表

2. 時系列を作り、証跡IDを埋める

「注文→決済→通知→出荷→配達→問い合わせ→返金または解約」の順に、出来事と証跡IDを並べます。時系列に空白がある箇所は、説明で埋めずに「記録未確認」として台帳へ戻します。

3. 必須資料を先、補強資料を後に置く

未着なら配送記録、返金なら返金取引記録、定期購入なら条件・通知・解約記録を先に置きます。社内の検討メモ、関係の薄い過去注文、編集可能な表だけの提出は、原則として優先度を下げます。

4. 個人情報と読めなさを確認する

提出先の指示に反しない範囲で、カード番号など不要な機微情報は露出させません。一方で、注文番号、日時、金額、顧客との対応関係まで伏せると資料の照合性が落ちます。マスキング後のPDFは、別担当者が注文情報と照合して読めるかを確認します。

ファイル名も統一します。

案件ID_証跡ID_種別_取得日.pdf
CB-20261004-001_E-03_配送追跡_20261004.pdf
CB-20261004-001_E-07_解約確認メール_20261004.pdf

Shopifyとカート共通で、保存場所を分けて設計する

Shopifyでは、Shopify Paymentsの異議申立てにおいて一部の注文情報が追加され得ます。しかし、メール、チャット、規約同意、配送写真、外部アプリのイベント履歴など、管理画面外の情報は自動で揃う前提にしない方が安全です。実際に何が表示・添付対象となるかは、案件画面で確認してください。Shopify Help Center

保存先は、少なくとも次の4層に分けると回収責任を置きやすくなります。

層主な記録確認担当
受注・決済注文、決済ID、返金、認証表示受注・経理担当
配送・提供追跡、受領、利用・提供ログ物流・サービス運営担当
表示・契約商品ページ、規約、同意、定期条件、通知EC運営・法務確認担当
顧客対応メール、チャット、電話要約、返品・解約依頼CS担当

ecforce、makeshop、BASE、EC-CUBE、futureshop、カラーミーショップなど、カートが異なる場合も、台帳項目は共通化できます。ただし、注文情報をどこまで出力できるか、決済事業者への提出窓口がどこかはサービス構成によって変わります。「カートから取得」「決済代行会社から取得」「外部ツールから取得」を台帳の保存元に明記し、担当者の記憶に依存させないことが必要です。

発生後の台帳を、次回のための保存設計に変える

案件が終わったら、結果だけでなく「どの証跡の回収に時間がかかったか」を振り返ります。勝敗を単一の資料の効果と断定する必要はありません。提出期限内に、争点に対応した資料を再現できたかを評価します。

見直しでは次を確認します。

  • 購入時の商品・規約表示を、変更後も再現できるか
  • 定期購入の申込、更新通知、解約、返金を注文番号または顧客IDで関連付けられるか
  • CSツールの会話を案件単位で出力できるか
  • 追跡履歴をいつ、どの形式で保存するか決まっているか
  • 台帳の必須項目に空欄が残った原因は、権限、保管場所、運用のどれか
  • 個人情報を含む証跡の閲覧権限・保管期限が社内ルールに沿っているか

月次で全注文の証跡を手作業で複製する必要はありません。商品ページ・規約の公開時保存、定期購入イベントのエクスポート可否確認、配送追跡の保存タイミングなど、後から再現できなくなる情報から優先して設計します。

反証パケット台帳の目的は、異議申立ての結果を保証することではありません。理由コードごとに異なる確認事項を、期限内に漏れなく説明できる状態にすることです。注文番号、争点、証跡ID、保存元、担当、提出状態を結び付けておけば、担当交代やカート・決済手段の変更があっても、証跡回収の手順を引き継ぎやすくなります。

参考情報

FREE CONSULT

この課題、もっと詳しく相談したい方へ

記事では答えきれない個別の状況にもお応えします。

無料で相談する →
CONSULT/ 無料相談

Stuck?
Let's talk.

この記事を読んでも詰まったら、相談してみてください

記事では答えきれない個別の状況にもお応えします。まずはお気軽にどうぞ。

HOW IT WORKS

  1. 01
    フォームで送信
    お名前とご状況を簡単にお知らせください。
  2. 02
    担当者がご連絡
    1営業日以内に株式会社かいなよりご連絡します。
  3. 03
    無料でご相談
    まずは状況をヒアリングし、最適な方向性をご提案します。