チャージバックへの対応は、配送追跡番号を提出して終わる作業ではありません。カード会社から示された異議理由に対して、「この注文で、いつ、何が起きたか」を第三者が追える形にして提出する必要があります。
そのために有効なのが、注文番号ごとに証跡を束ね、さらに争点との対応関係を記録する反証パケット台帳です。ここでいうパケットとは、単なるファイル置き場ではなく、提出資料の選定理由・保存元・取得担当・提出状況まで含む1件単位の管理票を指します。
Shopifyはチャージバック・照会への回答期間が通常7〜21日であると案内しています。ただし、実際の期限と提出方法は通知内容、決済手段、理由コードによって異なります。通知を受け取ったら、まず管理画面や決済代行会社の案内に記載された期限を正としてください。Shopify Help Center(確認対象:2026年10月4日)
証跡を集めても、提出資料が争点に結び付いていなければ、担当者が説明を組み立て直すことになります。台帳の起点は「持っているデータ」ではなく、通知に書かれた異議理由・理由コード・提出期限です。
たとえば、未着の主張であれば配送記録が中心になります。一方、定期購入を「解約したのに請求された」とする主張なら、配送完了だけで契約状態や解約依頼への応答を説明することはできません。申込時の条件、更新通知、解約日時、CS対応の順に確認できる記録が必要になります。
台帳はスプレッドシート、データベース、受注管理システムのいずれでも構いません。重要なのは、次の項目を注文ごとに固定することです。
| 項目 | 記載内容 |
|---|---|
| 案件ID | 社内用の一意な番号。注文番号とは分けてもよい |
| 注文番号・決済ID | カートの注文番号、決済代行会社の取引ID、サブスクリプションID |
| 通知情報 | 通知日、提出期限、理由コード、異議申立て窓口 |
| 争点分類 | 不正利用、未着、返金、商品相違、定期購入など |
| 主張への回答 | 「○月○日に配送済み」「○月○日に返金済み」など、事実を短く記す |
| 証跡ID | ファイル名または保管URL。本文中の引用箇所も記録する |
| 保存元 | Shopify、決済代行会社、配送会社、CSツール、メール、サブスクアプリなど |
| 取得担当・取得日時 | 誰が、いつ取得した版か |
| 提出優先度 | 必須、補強、保留の3区分 |
| 提出状態 | 未回収、確認中、提出済み、提出対象外 |
「提出状態」と「保存済み」を分ける点が重要です。保存されているが今回の争点には不要な資料と、提出すべきなのに未回収の資料を区別できます。
期限が短い案件では、資料集めを始める前に判断を固定します。最初の30分から1時間で、少なくとも次を台帳に転記します。
通知メールだけを案件の正本にせず、管理画面または決済代行会社の異議申立て画面でも期限・理由・対象金額を照合してください。通知の転送や担当交代があっても、確認元を台帳に残せます。
この時点で、反論文を書き始めないことも大切です。最初に「何を証明する案件か」を決めてから、証跡を回収します。反論文は、証跡IDが揃った後に作成した方が、記載と添付の不整合を抑えられます。
同じ注文情報でも、提出価値は争点で変わります。以下は提出内容を決定するための整理です。「必須」は常に採用すべきという意味ではなく、当該の主張に回答するために優先確認する資料を示します。提出可否は通知の要求事項を優先してください。
優先する証跡
配送完了は取引履行の補強にはなりますが、それだけで購入者本人性を説明する資料にはなりません。IPアドレス、端末情報、認証結果などを取得できた場合も、意味づけを推測で補わず、表示された事実として提出します。
優先する証跡
追跡画面は後日表示が変わる場合もあるため、案件対応時にPDF化または画面保存し、取得日時を台帳に記録します。追跡番号だけでなく、注文番号と配送番号の対応も1枚で確認できる状態にします。
優先する証跡
ここでは「返金したはず」という社内メモではなく、決済システム上の返金処理記録が中心です。返金処理とカード明細への反映時期は別になる場合があるため、返金実行日時と、顧客への案内内容を混同しません。
優先する証跡
現在の商品ページを出力するだけでは、購入当時の表示を示せないことがあります。商品説明、価格、画像、販売条件を更新する運用なら、公開時のPDFやHTML、CMSの変更履歴など、購入時点を特定できる保存物を別途残す設計が必要です。
Stripeの異議申立て資料例では、定期購入に関して、申込時に同意した条件、更新・解約・返金規約、解約記録・確認、解約方法、更新前通知、利用・問い合わせ記録を分けて例示しています。Stripe Documentation(確認対象:2026年10月4日)
優先する証跡
時系列が最重要です。「解約処理日」「次回請求日」「更新通知日」を同じタイムゾーンで並べます。サブスクリプションアプリの状態だけでは、顧客への表示や通知内容が分からない場合があるため、アプリ履歴、メール配信履歴、購入時表示を別証跡として扱います。
証拠の量を増やすより、審査者が確認しやすい順序にする方が重要です。1案件を以下の順番で組み立てます。
案件要約には、注文番号、決済ID、異議理由、対象金額、結論、時系列の要点、添付一覧を記載します。結論は評価語を避け、証跡で確認できる事実に限定します。
結論:対象注文は2026年10月1日に発送され、配送会社の追跡記録では10月3日に配達完了となっている。
根拠:E-03 配送追跡記録、E-04 注文・配送番号対応表
「注文→決済→通知→出荷→配達→問い合わせ→返金または解約」の順に、出来事と証跡IDを並べます。時系列に空白がある箇所は、説明で埋めずに「記録未確認」として台帳へ戻します。
未着なら配送記録、返金なら返金取引記録、定期購入なら条件・通知・解約記録を先に置きます。社内の検討メモ、関係の薄い過去注文、編集可能な表だけの提出は、原則として優先度を下げます。
提出先の指示に反しない範囲で、カード番号など不要な機微情報は露出させません。一方で、注文番号、日時、金額、顧客との対応関係まで伏せると資料の照合性が落ちます。マスキング後のPDFは、別担当者が注文情報と照合して読めるかを確認します。
ファイル名も統一します。
案件ID_証跡ID_種別_取得日.pdf
CB-20261004-001_E-03_配送追跡_20261004.pdf
CB-20261004-001_E-07_解約確認メール_20261004.pdf
Shopifyでは、Shopify Paymentsの異議申立てにおいて一部の注文情報が追加され得ます。しかし、メール、チャット、規約同意、配送写真、外部アプリのイベント履歴など、管理画面外の情報は自動で揃う前提にしない方が安全です。実際に何が表示・添付対象となるかは、案件画面で確認してください。Shopify Help Center
保存先は、少なくとも次の4層に分けると回収責任を置きやすくなります。
| 層 | 主な記録 | 確認担当 |
|---|---|---|
| 受注・決済 | 注文、決済ID、返金、認証表示 | 受注・経理担当 |
| 配送・提供 | 追跡、受領、利用・提供ログ | 物流・サービス運営担当 |
| 表示・契約 | 商品ページ、規約、同意、定期条件、通知 | EC運営・法務確認担当 |
| 顧客対応 | メール、チャット、電話要約、返品・解約依頼 | CS担当 |
ecforce、makeshop、BASE、EC-CUBE、futureshop、カラーミーショップなど、カートが異なる場合も、台帳項目は共通化できます。ただし、注文情報をどこまで出力できるか、決済事業者への提出窓口がどこかはサービス構成によって変わります。「カートから取得」「決済代行会社から取得」「外部ツールから取得」を台帳の保存元に明記し、担当者の記憶に依存させないことが必要です。
案件が終わったら、結果だけでなく「どの証跡の回収に時間がかかったか」を振り返ります。勝敗を単一の資料の効果と断定する必要はありません。提出期限内に、争点に対応した資料を再現できたかを評価します。
見直しでは次を確認します。
月次で全注文の証跡を手作業で複製する必要はありません。商品ページ・規約の公開時保存、定期購入イベントのエクスポート可否確認、配送追跡の保存タイミングなど、後から再現できなくなる情報から優先して設計します。
反証パケット台帳の目的は、異議申立ての結果を保証することではありません。理由コードごとに異なる確認事項を、期限内に漏れなく説明できる状態にすることです。注文番号、争点、証跡ID、保存元、担当、提出状態を結び付けておけば、担当交代やカート・決済手段の変更があっても、証跡回収の手順を引き継ぎやすくなります。
記事では答えきれない個別の状況にもお応えします。