EC M&Aの決済引継ぎ – 未入金・チャージバック・留保金を精算し、受注を止めないクロージング実務

決済クロージングの全体像を一枚にする

最初の成果物は、システム構成図でも契約一覧でもなく、「一件の注文がどの主体と残高を通るか」を示す決済フローマップです。購入者、ECカート、モール、決済代行会社（PSP）、カード会社・アクワイアラ、銀行、会計、返金窓口を並べ、各地点に注文ID、決済ID、出荷番号、入金バッチID、会計伝票番号を記します。買収対象が事業だけなら旧法人と新法人を別の色にし、株式譲渡なら法人は同じでも権限者・銀行口座・秘密鍵の変更点を区別します。

この図を作る理由は、契約上の承継と資金上の承継が一致しないからです。例えばカートの所有権を買主へ移しても、変更前に確定した売上が旧法人の決済残高へ入り続けることがあります。反対に入金口座だけ先に変えると、旧法人が負うべき返金が新法人の将来売上から相殺される場合があります。図には「誰が操作できるか」だけでなく、「誰の債権か」「誰の残高から控除されるか」「誰が証拠を保持するか」を記載します。

フローマップの版は契約締結時ではなくクロージング直前まで更新します。DD中に「決済はShopify Paymentsのみ」と説明されても、実データを見るとPayPal、後払い、代引、休眠中の旧PSP、海外通貨口座が残っていることがあります。ゼロ件の決済手段も削除せず、停止済み、休眠、解約未了、将来請求の有無を付記すると、クロージング後の予期しない請求や個人アカウント依存を発見できます。

注文日・出荷日・売上確定日・入金日を混同しない

決済引継ぎの議論が噛み合わない最大の原因は、関係者が「売上日」を別々の意味で使うことです。マーケティング担当は注文日、物流担当は出荷日、決済担当はcapture日、会計担当は収益認識日、資金担当は銀行入金日を見ています。クロージング条件に「基準日以後の売上は買主に帰属する」とだけ書くと、どの時計を採るかで金額が変わります。

決済方式ごとの時計を先に定義する

• 即時capture型: 注文時に売上確定しても、欠品キャンセルや発送前返金が後から発生します。
• 出荷時capture型: 注文前受け時点は与信枠だけで、分納時に複数の決済へ分かれることがあります。
• コンビニ・銀行前払い: 注文はあっても未入金なら債権・在庫引当の扱いが異なります。入金後未出荷は履行負担が残ります。
• 後払い・BNPL: 与信主体、加盟店への立替時点、購入者の支払時点が分かれ、返品時の取消手順もサービス別です。
• 代金引換: 配送会社の回収から振込まで時間差があり、受取拒否・再配達・現金差異が残ります。
• モール決済: モールが売上・手数料・広告・ポイント・返金を一括相殺するため、店舗の注文額と銀行入金額は一致しません。

基準日に採るべき時計は、取引の実態と契約で決めます。例えば「基準日前に受注し、基準日後に買主が在庫を使って出荷する注文」は、注文売上を売主へ残すだけでは買主の原価と履行負担が無償になります。売上帰属を出荷時点に合わせる、売主売上のまま買主へ履行手数料と商品原価を支払う、又は未出荷注文を価格調整へ入れるという複数案があります。税務・会計上の認識を案件当事者だけで断定せず、最終方式を会計・税務専門家と照合します。

ASBJの収益認識に関する会計基準の適用指針は、返品権付き販売に関して、企業が権利を得ると見込む対価、返金負債、返品される商品を回収する権利に係る資産等の考え方を示しています。M&Aの価格精算は会計処理そのものではありませんが、返品見込を無視して銀行入金だけを「確定売上」とする危険を理解する基礎になります。

90日前：決済手段・契約主体・口座を全量棚卸しする

クロージング90日前を目安に、直近24か月の注文データから決済方法コードを抽出し、契約書、請求書、管理画面、銀行明細の四方向で存在確認します。ヒアリングだけでは、過去のキャンペーン用アカウント、越境向けウォレット、退職者名義のPayPal、開発会社が管理するテスト兼本番アカウント、モール内の複数店舗が漏れます。取引ゼロでも解約していなければ、料金、個人情報、秘密鍵又は負残高が残る可能性があります。

「使っていない」を残高ゼロと同義にしない

休眠決済には、過去取引への返金、係争中の異議申立て、一定期間後に解除される留保、請求予定の月額料金、未精算の外貨、証拠提出期限が残ることがあります。棚卸しでは最終決済日だけでなく、最終返金日、最後の異議申立ての解決日、留保解除予定日、解約申請日を分けます。管理画面を閉じる前にCSVと通知メールを保存し、誰が法定・税務・契約上の保管を担うかを決めます。

内部統制上は、売主が作った台帳を買主がサンプル再実施します。売上上位3決済、取引件数上位、返金率上位、直近追加、外貨、個人名義を必須サンプルにすると、金額だけでは見えない重大な移管障害を拾えます。台帳に載らない銀行入金があれば入金摘要から逆引きし、逆に台帳上のサービスで入金実績がない場合は請求書や残高保留を確かめます。

75日前：株式譲渡と事業譲渡で決済の切替方式を分ける

株式譲渡では対象法人が存続するため、加盟店契約が形式上継続する場合があります。しかし、実質的支配者、代表者、商号、所在地、銀行口座、取扱商品、ドメイン、取引量が変われば届出や再審査が必要なことがあります。「法人番号が同じだから連絡不要」と判断せず、契約条項と決済会社の回答を保存します。反対に事業譲渡では、決済債権や加盟店契約が当然に移ると決めつけず、新法人での申込・審査・実装を基本シナリオに置きます。

既存のEC事業譲渡と株式譲渡の違いを扱うコラムはアカウント・在庫・契約の引継ぎ全体を比較しています。本稿では、その判断を決済の三つの切替方式へ具体化します。

方式は決済手段ごとに異なって構いません。新規注文は新PSPへ切り替えつつ、旧定期契約の継続課金だけ旧環境で一定期間処理することもあります。ただし、顧客への販売主体表示、プライバシー通知、請求明細の表記、返金窓口、セキュリティ責任を曖昧にしてはいけません。並行稼働を選ぶなら、対象顧客、終了条件、最大期間、費用、障害時の権限、データ受渡しをTSAへ落とします。

決済契約以外の借入・資金サービスも確認します。Shopify公式の所有権変更案内は、Shopify CapitalやShopify Creditを利用中の場合に店舗を移転できないこと、Shopify Balanceが有効なら残高を空にしてサポートへ連絡すること、Shopify Paymentsの取引・入金履歴を出力すること等を案内しています。これは全サービス共通の規則ではありませんが、決済周辺の資金契約がカート所有権の変更を止め得る具体例です。

60日前：PSP・アクワイアラの審査をクリティカルパスに置く

新規契約又は重要属性変更が必要なら、審査完了をクロージングの前提条件又は明確な運用条件として管理します。申込みを後回しにしてサイトや在庫の移管を先に終えると、受注できても入金できない、カードだけ利用できない、定期課金を再開できないという状態になり得ます。申込前に決済会社へM&Aの事実を共有できるか、秘密保持とサイン前の情報開示範囲を案件担当者・弁護士と調整します。

審査パッケージは「会社資料」と「商流資料」を分ける

• 買主法人の登記、実質的支配者、代表者、所在地、銀行口座、許認可
• 対象サイトのURL、特商法表示、利用規約、返品・返金方針、プライバシー通知
• 商品カテゴリ、平均・最大単価、月間件数、予約・定期・越境の有無
• 仕入れ、在庫、出荷リードタイム、配送追跡、顧客対応の流れ
• 過去の不正利用率、チャージバック率、返金率、苦情、アカウント制限
• 新しいドメイン・IP・カート・プラグイン・3-Dセキュア・不正検知の構成

審査質問は回答日と根拠ファイルを残します。口頭で「問題ない」と言われた場合も、どの契約、どのMerchant ID、どの変更内容を前提にした回答かをメール等で確認します。審査が条件付きなら、取扱上限、留保、入金サイクル、禁止商材、追加書類、モニタリング期間を資金繰りへ反映します。

経済産業省の割賦販売法（後払分野）の概要・FAQは、カード番号の適切な管理と不正利用防止に関する「必要な措置」について、クレジットカード・セキュリティガイドライン又は同等以上の措置を講ずる必要があると説明しています。買収により運営主体が変わる場面では、旧加盟店がチェック済みだったという説明だけでなく、買主側のサイトと運用で対策が続く証拠を審査資料に含めます。

55日前：決済料率・早期入金・相殺を正常収益と資金繰りへ戻す

決済契約の承継可否と並行して、決済コストを注文単位へ戻します。契約書の表面料率だけでは、月額、トランザクション、返金、dispute、3-Dセキュア、外貨、越境、早期入金、端末・アプリ、最低利用、解約等の費用を捉えられません。モールでは広告、ポイント、物流、販促協賛が同じ精算書で控除されることもあるため、「入金額÷売上」だけを決済料率と呼ばず、控除コードを分類します。

売主の優遇料率が買主へ引き継がれない場合、同じ売上でも買収後EBITDAは下がります。反対に買主のグループ料率が適用できても、審査後でなければ確定しないことがあります。基本モデル、契約継続、買主新規、保守的条件の三つを並べ、価格評価にどの列を用いたかを明示します。早期入金は運転資金を軽くしますが、料率上乗せを正常費用から除外してよいかは、買収後も同じ資金調達が必要かで判断します。

相殺条項も契約書で確認します。PSPが過去取引の返金・dispute・手数料を将来payoutから控除できるなら、売主起因の負担が買主の新売上へ及ぶ可能性があります。同一法人の株式譲渡、旧契約を残す並行運用、新契約では状況が異なります。相殺範囲を法務が確認し、買主の最低現金、留保又は特別補償へ反映します。

正常化は単に費用を足し戻す作業ではありません。売主の一時的なdispute費用でも統制不備が続くなら買収後も発生します。買主の新規審査による初期留保は取得後の資金需要です。契約、原因、継続性を分け、利益調整と資金調整を混同しないことが重要です。

50日前：注文・決済・銀行の三台帳を取引単位で照合する

決済残高のDDは、管理画面の月次合計と銀行入金の月額が近いことを確認する作業ではありません。最低でも注文台帳、PSP取引台帳、銀行入金台帳を取得し、注文ID又は決済IDから一件単位へ降りられる照合表を作ります。モールの場合は、広告、ポイント、倉庫費、月額料金、返金等が同じ入金で相殺されるため、モール精算明細を第四の台帳として加えます。

決済残高ブリッジの計算線

期首決済残高に、期間中のcapture、取消、返金、チャージバック、異議申立て手数料、決済手数料、為替換算、留保への振替、留保解除、その他調整を加減し、銀行へのpayoutを差し引いて期末残高へつなぎます。Stripe公式の残高の概要報告書も、開始・終了残高と、charges、refunds、disputes、fees等の残高変動を照合する用途を説明しています。使用サービスがStripeでなくても、残高ブリッジの考え方は再計算可能な資料設計に役立ちます。

全件照合が難しい場合、月次合計だけで妥協せず、層化サンプリングを使います。高額、返金、チャージバック、越境、定期、分納、クロージング前後、手動調整を必須層とし、残りから無作為抽出します。差異が見つかった層は母集団へ拡張し、差異率と金額を計算します。照合ロジック、使用列、除外理由を買主が再実行できるように残すことが、表計算ファイルの見栄えより重要です。

45日前：返金・チャージバックのテールを月齢別に測る

銀行へ入金済みであっても、その取引の経済的リスクが終わったとは限りません。顧客返品、配送事故、重複請求、未承認取引、商品説明との相違、定期購入の解約争い等により、後日返金又はチャージバックが発生します。Stripe公式の異議申立ての説明では、一般にカード保有者が元取引から120日以内に異議を申し立てられることが多い一方、将来提供のサービス等ではより長くなり得るとしています。これは一例であり、案件では決済会社・カードネットワーク・理由コード・提供時点に応じた期限を確認します。

直近24か月の返金と異議申立てを、元注文月からの経過月別に並べます。件数率だけでなく、元売上に対する金額率、勝敗、証拠提出の有無、理由、商品、配送会社、チャネルを集計します。月齢0〜1か月に返品が集中し、2〜4か月に不正利用、さらに後ろに予約商品や年間契約の争いが残るなら、テール負担の保護期間を一律30日にはできません。

勝率だけで準備金を小さくしないことも大切です。売主が過去の取引証拠を持ち、買主がPSP管理画面で回答する構造なら、両者の連携が遅れるだけで期限を失うことがあります。注文確認、規約同意、3-Dセキュア結果、IP・端末、配送追跡、受領、顧客とのやり取り、返金方針を誰がどの期間保存し、何時間以内に渡すかをTSAへ書きます。

Shopify公式のチャージバック監視の案内は、異議申立て結果にかかわらず活動状況がアカウント健全性評価に使われ、高い率が留保やネットワーク監視プログラム等の措置につながり得ると説明しています。買主は損失額だけでなく、移管後の承認率、資金拘束、アカウント継続へ与える影響を評価します。

40日前：留保金・保留・負残高を買収価格から切り離して見る

決済管理画面に表示される残高は、すべて自由に引き出せる現金ではありません。available、pending、reserve、hold、negative、外貨残高等を分け、解除条件と入金予定日を確認します。Stripe公式の残高と精算時期は、返金・異議申立て用残高と、一定期間払い出せないreserve balanceを説明しています。Shopify公式の留保の説明も、固定額型と取引割合型の留保例、返金・異議申立て等との関係を示しています。

留保金は「いずれ戻る売主の現金」とも「対象事業の運転資本」とも一意に決まりません。誰の過去取引を担保し、解除後にどの口座へ払い出され、解約や名義変更で条件が変わるかを確認します。事業譲渡で旧Merchant IDに残る留保が売主へ戻る一方、買主には新たな留保が設定されるなら、同じ事業を運営しても買主側に追加資金が必要です。譲渡対価へ旧留保を加えるだけでは資金需要を解決できません。

留保金の価値を三つに分解する

1. 名目残高: 基準日時点に管理画面が示すreserve又はholdの総額。
2. 回収見込: 解除前に返金・dispute・手数料・負残高へ充当される見込を控除した額。
3. 帰属価値: 回収見込から税務・契約・取得範囲を踏まえ、売主又は買主に帰属させる額。

解除予定表はPSPの通知書又は管理画面で裏付け、口頭説明だけにしません。留保がリスク再審査で延長・増額される可能性、最低残高、差押え等の法的保留、貸付回収との相殺、外貨換算を確認します。回収不能リスクが大きければ、固定価格へ入れず、実際の解除入金に連動する後日精算も選択肢です。

35日前：決済トークンの可搬性とPCIスコープを別々に確認する

定期購入やワンクリック購入では、カード番号そのものではなく決済会社が発行したトークンをカート側が保持することがあります。そこで「カード情報を保持していないから移管は簡単」と考えるのは早計です。トークンは決済会社、加盟店ID、接続アカウント、顧客ID、環境に結び付くことがあり、新しい法人又はPSPでそのまま利用できるとは限りません。可搬性はカート、旧PSP、新PSPの三者へ同じ質問票を送り、移行主体、対象件数、同意・通知、テスト方法、失敗時の再登録導線を書面で確認します。

トークン移行とPCI DSSの適用範囲も混同しません。決済画面を外部へ委託していても、ECサイト上のスクリプトが決済ページへ影響し得る構成では、該当する対策確認が必要です。PCI Security Standards CouncilのEC加盟店のSAQ A適格性に関するFAQは、埋込み型の外部決済フォームを用いるECチャネルにおけるスクリプト保護の考え方を説明しています。どのSAQが適切かは実装全体と契約先に確認し、記事だけで判定しないでください。

トークン移行の受入テストを顧客体験まで広げる

• 移行対象顧客数と成功件数が一致し、除外理由が説明できる。
• 本番相当の少額又は許容されたテストで、初回・継続・金額変更・解約・返金を通す。
• 3-Dセキュア又は追加認証が必要になった顧客の再登録導線を確認する。
• 請求明細の表記、決済通知メール、カスタマーポータルの販売主体が新体制と一致する。
• 移行ファイルを誰が生成・暗号化・受領・削除したかのログを保存する。

トークンが移せない場合は、顧客へカード再登録を依頼する方法、旧環境で一定期間課金する方法、新しい支払リンクを送る方法等を比較します。再登録率を楽観せず、対象顧客の月次売上、解約率、メール到達率、サポート負荷、再同意の要否をモデルへ入れます。定期課金の売上価値を評価済みでも、再登録で大きく減るなら取得価格又はアーンアウト条件へ影響します。

30日前：3-Dセキュアと不正検知を旧環境の基準値から再現する

PSPを切り替えると、不正利用対策の設定と承認率が同時に変わります。安全側へ寄せ過ぎて正常顧客を拒否する、売上維持を優先して不正注文を通す、又は3-Dセキュアの例外・失敗処理を誤る可能性があります。旧環境のルール名をコピーするのではなく、直近12か月の承認、拒否、追加認証、手動審査、出荷停止、チャージバックを商品・金額・国・端末・新規既存顧客で分け、買主が許容するリスクへ再設計します。

経済産業省の加盟店における不正利用対策の在り方に関する検討会と配布資料は、決済前の不正ログイン対策、決済時のEMV 3-Dセキュア等を含む「線の考え方」や、加盟店のリスクに応じた対策を論点にしています。M&Aのリハーサルでは、機能の有無だけでなく、会員ログイン、注文、本人認証、出荷保留、事後監視まで一連の運用がつながるかを確かめます。

評価期間中に大型セールを重ねると、切替影響と需要変動を分けにくくなります。可能なら安定した期間に小規模トラフィックから開始し、主要商品・端末・ブラウザ・支払方法を通した後に割合を増やします。セールを動かせない事業では、代替決済、注文保留、CS増員、物流停止権限を事前に決めます。

25日前：クロージングを跨ぐ15取引類型を割り付ける

基準日前後の全注文を一つのルールで分けると例外処理が膨らみます。注文、入金、出荷、返品の状態を組み合わせ、少なくとも次の類型をカットオーバーマトリクスへ並べます。各行に販売主体、在庫負担、売上帰属、入金先、返金実行者、dispute対応者、顧客通知、会計伝票を割り当てます。

「設計例」は答えではありません。顧客規約、決済契約、譲渡スキーム、商品の所有権、会計・税務、システム制約により選択が変わります。重要なのは、各類型を誰かの善意の手作業へ残さず、注文データから抽出できる条件式と責任者を定めることです。基準時刻は日付だけでなくタイムゾーン、モール側時刻、バッチ締めを明記します。

マトリクスは契約別紙と運用手順の橋渡しになります。最終契約には原則を、別紙にはデータ項目と計算式を、ランブックには管理画面操作を置きます。三つを同じ版番号で結び、契約文言を変えたら抽出SQL・表計算・返金手順も更新します。

20日前：決済債権と将来負担を価格調整へ変換する

決済データを価格へ反映するときは、企業価値、現預金・有利子負債、運転資本、取得在庫、未履行負担、特別補償を重ねて数えないようにします。例えば出荷済みでPSP未入金の売上を運転資本の売掛金へ含め、さらに決済残高として譲渡対価へ加えると二重計上です。逆に入金済み未出荷注文を売上として評価しながら、買主が負担する商品原価・物流・返金を無視すると価値を過大に見ます。

ウォーターフォールを注文母集団から積む

1. 基準日時点の注文を前節の15類型へ分類する。
2. 各類型の総額、原価、税、送料、決済手数料、返金見込を計算する。
3. 会計上の売掛金・前受・返金負債・未払費用とPSP残高を照合する。
4. 通常運転資本に含める項目、ネットデット類似項目、個別精算項目を一度だけ割り付ける。
5. dispute等の不確実項目は、固定控除、留保、エスクロー、実額後日精算、特別補償を比較する。

正常運転資本の基準は季節性と入金サイクルを踏まえます。大型セール直後はpendingが増え、長期休暇前は銀行入金が遅れ、返品期は返金負債が膨らみます。単一月末の比率ではなく、決済方法別に12〜24か月の月次、可能なら日次で残高日数を見ます。EC事業の正常収益を扱う既存解説と接続し、決済手数料、返金、物流、広告を同じ注文採算へ戻すと、利益と現金の差を説明しやすくなります。

本稿の数式は交渉設計の例であり、会計・税務・法務上の結論ではありません。事業譲渡で債権を移す場合の対抗要件、消費税、契約上の相殺権、顧客への表示等は案件の専門家が確認します。

15日前：返金権限と異議申立て証拠をCSから受け渡す

返金は経理の振込処理ではなく、注文・出荷・顧客対応・在庫・決済を同時に更新する業務です。売主が旧PSPを操作し、買主が顧客対応をする並行期間では、誰が返金を承認し、どの残高から実行し、返品在庫を誰が受け取り、顧客へどの会社名で通知するかを明確にします。金額別の承認権限、全額・一部返金、送料、ポイント・クーポン、交換、再送、異議申立て中の返金制限をランブックへ記載します。

異議申立ては短い回答期限が設定される場合があるため、通知を旧担当者のメールだけに残せません。PSP通知、共有メール、チケット、Webhookを新旧担当へ二重化し、案件ごとに期限、理由コード、金額、証拠、提出状況、結果を管理します。売主が保持する過去証拠を買主が必要とするときは、個人情報の取扱いと目的を確認し、安全な共有場所とアクセス期限を決めます。

証拠は「フォルダにある」では足りません。無作為に5件を選び、新担当者が通知受領から資料提出までを時計で測ります。商品ページが上書きされて購入時表示を再現できない、配送会社の保存期間が短い、退職者のDMに合意がある、APIでしか3DS結果を取得できない等の欠陥が出れば、クロージング前にエクスポート又は補完します。

12日前：越境・多通貨の決済残高を通貨別に封じ込める

越境ECでは、顧客が見る表示通貨、カードが承認される取引通貨、PSP残高通貨、銀行への入金通貨、会計機能通貨が異なることがあります。クロージング時に全通貨を円換算合計だけで渡すと、未実現換算、決済会社の換算手数料、返金時の為替差、負残高を隠します。Merchant IDと通貨ごとに期首残高、取引、返金、dispute、換算、payout、期末残高を作り、採用レートと時点を記録します。

返金は元取引通貨で行われても、PSP又は銀行残高の換算により円貨負担が元入金と異なる場合があります。Stripeの異議申立て資料にも、元決済時とチャージバック時の為替変動によりアカウント通貨での控除額が異なり得る例が示されています。契約上の具体的取扱いは対象PSPで確認し、テール留保を円固定するか、元通貨別に残すかを決めます。

海外取引を国内売上の延長として処理しない

• 国・地域ごとの販売主体、利用規約、返金窓口、税・関税表示を確認する。
• 現地ウォレット、海外PSP、マーケットプレイス、代理店の契約主体と残高を分ける。
• 制裁・禁止商材・本人確認等の審査質問に、買主の新しい支配・商流で回答する。
• 越境返品の送料、関税還付、配送追跡、返送不能商品の負担を価格表へ含める。
• 海外顧客の決済トークン・個人データの移行について適用法と契約を確認する。

為替差を売上成長と混同しないため、注文時レート、capture時レート、payout時レートを区分します。売主の会計換算方法とPSPレポートの換算方法が違えば差異が出ますが、説明できれば直ちに誤りではありません。説明不能な差、長期外貨残高、個人口座への海外入金は優先調査します。

越境EC事業の売却で確認される物流・表示・返品では海外販路全体を扱っています。本節ではそのうち、決済残高とクロージング精算に必要な通貨・返金・入金の線だけを抽出しています。

10日前：API鍵・Webhook・バッチ・会計連携を切替表へ落とす

決済画面が動いても、Webhook、返金、照合、会計連携が旧環境へ向いていれば完了ではありません。技術切替表は、秘密情報そのものを書かず、対象、旧所有者、新所有者、生成・登録・失効時刻、依存先、検証方法、切戻し条件を管理します。API公開鍵・秘密鍵、Webhook署名鍵、OAuth接続、SFTP、固定IP、MFA、通知メール、アプリ権限、会計・BI連携を含めます。

二重計上と通知欠落を同時に試験する

• 同じイベントを新旧エンドポイントが受けても注文状態を二重更新しない冪等性を確認する。
• Webhook再送、遅延、順序逆転、署名不一致時に監視へ上がるか試す。
• capture、取消、全額返金、一部返金、dispute、payoutを会計仕訳まで追う。
• 日付・通貨・消費税・手数料の丸めが旧レポートと一致するか、差異を説明する。
• 旧秘密鍵を失効した後も、必要な履歴を読める役割が残るか確認する。

切戻しは「旧鍵に戻す」だけでは成立しません。切替後に新環境で受けた注文を旧環境へ戻すと、二重captureや返金先誤りが起こります。切戻し可能な時点を、新規注文受付前、少量注文受付後、出荷開始後に分け、各時点で注文凍結、データ移送、顧客通知、手動決済の可否を決めます。不可逆点をGo/No-Go票へ明示します。

技術資料は開発会社任せにせず、買主の決済責任者と経理責任者が受入れます。決済成功のテスト注文だけでなく、入金レポートへ現れ、銀行に届き、会計と照合できるまで数営業日かかる場合があります。そのため本番相当テストはクロージング前倒しで行い、日付直前の一回で済ませません。

7日前：決済障害時の代替導線と受注停止条件を合意する

移行計画は正常系だけでなく、審査保留、PSP障害、Webhook遅延、3-Dセキュア失敗、銀行口座不備、不正注文急増、返金停止を想定します。障害時に複数PSPへ自動的に迂回する設計は便利ですが、二重請求、ルーティング規則、顧客同意、セキュリティ、会計照合を検証せず有効化してはいけません。単純な銀行振込や受注保留の方が安全な場合もあります。

停止条件は売上額だけでは決めません。同一注文の二重請求、カード情報保護の疑義、販売主体表示と請求主体の不一致、大量の誤出荷は、たとえ決済成功率が高くても停止対象です。一方、低比率の決済手段だけが停止し、顧客へ明確な代替を示せる場合は、限定運用が可能かもしれません。事業責任者、情報セキュリティ、法務、決済担当が事前に重大度を定義します。

顧客連絡テンプレートは障害原因を推測で断定せず、注文・請求状況、顧客が行うべきこと、重複操作を避ける案内、返金予定、問い合わせ先を明示します。旧売主の名称で通知が送られないよう送信者・署名・FAQを確認します。SNSでの広報と個別注文通知は役割を分けます。

復旧宣言の後も、障害時間帯の注文母集団を抽出してcapture、在庫、出荷、返金、会計まで追います。「画面が戻った」時点ではなく、データと資金の整合が確認できた時点でインシデントを閉じます。

5日前：本番相当リハーサルでGo・条件付きGo・延期を判定する

リハーサルは会議室で手順書を読み上げるだけではなく、許容された範囲で本番相当の注文、決済、取消、返金、入金レポート、通知を通す実証です。カード、主要代替決済、モバイル・デスクトップ、会員・ゲスト、国内・越境、定期、クーポン、分納から売上比率とリスクに応じてケースを選びます。テストデータは実注文と識別できるようにし、不要な個人情報や不正なカード利用を避けます。

条件付きGoには期限、責任者、資金上限、代替手段、顧客影響を必ず付けます。「クロージング後に対応」は条件ではありません。例えば後払いが未開通でも売上比率2%でカードへ誘導でき、法務・CS表示を直し、7日以内に再審査するなら条件付き実行を検討できます。一方、主要カードが使えず、代替が銀行振込だけなら、売上と顧客体験への影響を定量化して延期を検討します。

判定会議には事業責任者、経理、決済、開発、CS、物流、法務、M&A担当を入れます。一人の「問題ありません」ではなく、各ゲートの証拠URL又はファイル、未解決事項、残余リスクの受容者を議事録へ残します。

クロージング当日：資金と注文を止めないコントロールルームを動かす

当日は、法的クロージング時刻、ECサイト切替時刻、決済ルーティング変更時刻、銀行口座変更時刻を同一と決めつけません。先に責任主体の切替条件を契約で決め、その範囲内で顧客影響が最小になる技術時刻を選びます。タイムゾーン、モールの締め、夜間バッチ、週末・祝日、銀行営業日も加味します。

1. 直前スナップショットとして注文、決済残高、open返金・dispute、ユーザー権限を保存する。
2. 新規注文受付を継続するか短時間メンテナンスへ入るか、事前基準で判断する。
3. 販売主体、特商法表示、規約、プライバシー通知、請求表記を承認済み版へ切り替える。
4. 決済ルーティング、Webhook、通知、入金口座、MFA・権限をランブック順に変更する。
5. 本番相当の少額注文を実行し、注文台帳・PSP・通知・在庫・会計入口まで追跡する。
6. 旧新双方で15類型の件数と金額を抽出し、境界注文に欠落・重複がないか確認する。
7. Go宣言後も監視を継続し、不可逆点を越える前なら承認済み切戻しを発動する。

役割は「売主」「買主」では粗すぎます。決済設定を変える実行者、画面を読み上げる確認者、顧客影響を判断する事業責任者、資金帰属を確認する経理、契約条件との整合を見る法務、停止を決めるインシデント指揮者を分けます。チャットだけに記録せず、時刻、操作、結果、証拠、承認を一つのイベントログへ残します。

重大な障害時は売上だけで判断しません。二重請求、誤った販売主体での請求、カード情報保護の疑義、返金不能は短期売上より優先して止めるべき事象です。影響注文を隔離し、新規受付停止、代替決済、顧客通知、PSP連絡、ログ保全の順を事前に決めておきます。

D+1〜D+7：日次の決済残高ブリッジで境界注文を閉じる

クロージング後の最初の一週間は、売上ダッシュボードではなく、旧新双方の決済残高ブリッジを日次で更新します。注文件数、capture、取消、返金、dispute、手数料、留保、payoutをつなぎ、銀行入金まで追跡します。Shopify公式の入金と取引記録を照合する報告書の説明は、charges、refunds、disputes、adjustments、reserves & holds、payouts等の残高変動区分を示しています。使用プラットフォームに応じて列は変えても、総額から注文へ降りられる関係を維持します。

初週の差異は「移行なので仕方ない」と保留せず、24時間以内、3営業日以内、月次までの三段階で期限を付けます。二重capture、誤口座、返金失敗、Webhook欠落、税・通貨の誤りは即日扱いです。バッチ締めや銀行休日による時差は予定差異として別コードにし、予定日を過ぎたら自動的に未解決へ戻します。

境界注文を閉じるとは、売主と買主の精算だけではありません。顧客が正しい会社から商品・返金・サポートを受け、注文履歴と請求明細に矛盾がなく、会計仕訳が重複せず、個人情報アクセスが必要最小限になった状態を指します。未解決件数がゼロでなくても、母集団、金額、期限、責任者、資金保護が明らかなら管理可能です。

D+8〜D+30：返品・返金を旧新の資金帰属へ戻す

二週目以降は通常の返品が増え、クロージング時点の設計が試されます。顧客には組織変更を理由に返金を遅らせず、内部で売主負担・買主負担・共同負担を分類します。返金実行先が旧PSPしかない場合、買主CSが承認した案件を売主が何営業日以内に処理し、実行証拠を返すかをTSAのSLAで測ります。

返品商品は資金と別の経路を通ります。売主売上に係る商品が買主倉庫へ戻る場合、検品、再販、廃棄、メーカー返品の価値を誰へ帰属させるかを決めます。全額返金でも商品が再販可能なら、返金額をすべて売主負担にした上で返品在庫を買主が無償取得すると不均衡になることがあります。逆に衛生商品や開封品で価値がないなら、物流・廃棄費も含めます。

週次返品コホートで見込と実績を比較する

元注文週、商品、チャネル、返品理由、返金額、在庫回収価値、処理日数を集計し、クロージング時の返金見込と比較します。乖離が大きければ、商品不良、サイト切替の表示、配送遅延、CS混乱、決済失敗を切り分けます。M&A前の通常返品と移行起因の返品を分けることで、補償請求とPMI改善を混同しにくくなります。

• 返金受付からPSP実行までの中央値・最大日数
• 返金失敗と再実行件数、顧客への二重返金の有無
• 旧売上・新売上・不明に分類できない件数と金額
• 返品在庫の再販可能額、値下げ額、廃棄・返送費
• クーポン、ポイント、ギフト、送料を含む総負担

定期通販では次回課金通知、解約締め、発送準備の境界も点検します。サブスクECのKPI・契約・移行を扱う既存記事で継続率等の全体像を確認しつつ、本件では元注文・課金・返金の資金帰属へ落とし込みます。

D+31〜D+120：異議申立て・留保解除・旧アカウント終了を管理する

一か月を過ぎると、日常運用が安定する一方、過去取引の異議申立てや留保解除が散発的になります。担当者の異動やTSA終了で通知を見落としやすい時期です。案件一覧は元注文日、通知日、回答期限、理由、証拠担当、資金控除先、売主・買主負担、結果、精算日を保持し、週次から月次へ頻度を落としてもopen件数がゼロになるまで所有者を残します。

Stripe公式の異議申立てへの回答案内は、一般に回答期限が7〜21日程度になり得ること、期限までに回答しなければ敗訴扱いとなることを説明しています。実際の期限は管理画面・通知・契約で確認します。売主に証拠を求めている間に期限を失わないよう、通知から24時間以内の振分け、2営業日以内の証拠初回提出など案件規模に応じた内部期限を前倒しで置きます。

旧アカウントを閉じる四つの出口条件

1. 未出荷・未入金・未返金・open disputeの母集団がゼロ又は別管理へ正式移管済み。
2. 留保・保留・外貨・負残高の解除、精算、帰属が証憑で確定している。
3. 法令・税務・契約上必要な取引、請求、通知、監査ログを安全に保存した。
4. 旧API鍵、Webhook、MFA、ユーザー、銀行口座連携を失効し、失効後テストを行った。

終了日を「クロージング後90日」と固定するより、出口条件と最長日を併記します。留保解除が遅い場合に売主へ永久アクセスを残す必要はなく、決済会社から指定口座へ直接入金する、閲覧専用証跡を渡す、第三者精算人を置く等を検討できます。TSA延長時の追加費用と情報アクセス範囲も事前に決めます。

最終精算書には名目残高だけでなく、期間中の返金、dispute、手数料、留保変動、入金、税・為替、買主立替、売主作業費を取引IDで裏付けます。双方が承認した後、アカウント閉鎖証拠と最終ユーザー一覧を案件データルームへ格納します。

一つの想定案件で見る決済クロージングの組み立て方

以下は手順を理解するための架空例であり、実在の会社・案件・決済条件を示すものではありません。自社ECとモールで生活雑貨を販売するA社を、B社が事業譲渡で取得します。月商6,000万円のうち自社ECカードが55%、ウォレット10%、後払い5%、モール30%。返品期間30日、予約商品が売上の8%、旧PSPには600万円の留保があります。

最初の計画が失敗しそうになった理由

当初はクロージング日にカート所有権と銀行口座だけを変更する計画でした。しかし、事業譲渡のためB社は新加盟店審査が必要で、定期購入の決済トークンは一部のみ移行可能、予約商品のcaptureは発送時、モール入金には広告・ポイントが相殺され、留保はA社の旧アカウントへ120日後に解除される見込みでした。さらに返品対応はB社が行う一方、基準日前売上の返金は旧PSP残高から控除される構造でした。

チームは決済別に方式を分けました。新規自社EC注文はB社の新PSPへ切替え、移行できる定期トークンは検証後に移送。移せない顧客には30日前から再登録を依頼し、旧定期課金は最長60日の限定TSAとしました。予約注文は顧客表示と同意を確認した上で、出荷主体・売上・原価を注文単位で割り付けました。モールは既存規約と承認手続を確認し、入金バッチ単位でA社とB社を精算しました。

この例の学びは、すべてを同日に移すことが成功ではない点です。顧客への販売主体と新規資金は早期にB社へ寄せつつ、過去取引を閉じるために限定した旧環境を残しました。TSAは対象ID、最大期間、操作権、作業単価、証拠SLA、情報削除を細かく定め、漫然としたアカウント貸与を避けています。

売主がデータルームへ揃える決済資料

売主は「決済会社の管理画面を見せる」だけでなく、買主が残高とリスクを再計算できる資料を揃えます。個人情報・カード情報を必要以上に共有せず、匿名化、権限分離、閲覧ログ、段階開示を用います。画面キャプチャは基準日と対象Merchant IDが分かる形で保存し、CSVの抽出条件とタイムゾーンを付記します。

資料に欠落がある場合は、無理に「該当なし」とせず、取得不能の理由、代替証拠、影響母集団、復旧予定を記載します。例えば古い商品ページが復元できなければ、異議申立ての証拠弱化として評価し、別の注文確認メールや仕様書で補います。買主が質問しやすいよう、台帳各行から原本へのリンクを張ります。

売却準備全体の資料構成はD2Cブランドの売却準備と情報管理も参照できます。本稿の決済資料は、機密性が高い取引明細・個人情報・アクセス権を含むため、匿名資料、限定開示、原本閲覧の順を意識します。

買主が必ず再実施する決済DDの手続

買主は売主作成の表を受領して終わりにせず、計算と操作を限定サンプルで再実施します。まず銀行明細からPSP入金へ逆引きし、次にPSPのpayoutから個別決済、注文、出荷へ降ります。順方向と逆方向の両方を行うと、対象外店舗、簿外残高、注文ID欠落を見つけやすくなります。

1. 直近月末と大型セール月末の決済残高ブリッジを原データから再計算する。
2. 高額・返金・dispute・予約・分納・外貨・手動調整を層化抽出する。
3. 売上上位PSPについて、新法人での審査・入金・返金テストを観察する。
4. 留保・保留の解除条件を通知原本又は決済会社回答で確認する。
5. トークン移行の対象数、成功数、除外数、再登録売上影響を再計算する。
6. 過去disputeを一件選び、新担当者が期限内に証拠を再構成できるか測る。
7. API鍵を見ずに権限一覧、ローテーション、Webhook署名、ログを確認する。
8. 15類型の境界注文を抽出するクエリ又は表計算条件を再実行する。

サンプル不一致は件数だけでなく性質を評価します。1件の個人口座入金やカード情報を含むログは、金額が小さくても重大です。手数料の丸め差のような軽微な差は、母集団へ拡張して定量化できれば管理できます。発見事項を「金額」「業務停止」「法令・契約」「顧客影響」「再発可能性」の五軸で評価し、価格、前提条件、誓約、補償、PMIへ振り分けます。

EC全体の調査項目はEC事業デューデリジェンスのチェックリストで俯瞰できます。決済調査では、その総合表のうち受注・入金・会計を、取引IDと時間差が追える粒度まで深掘りします。

最終契約・TSAへ決済テールをどう書くか

契約書に「決済アカウントを引き継ぐ」とだけ書いても、技術・資金・顧客対応は動きません。最終契約では取得対象となる決済債権・残高・契約・データを特定し、基準日前後の注文帰属、価格調整、誓約、表明保証、補償、TSAを相互参照させます。具体的な文案は弁護士が案件に合わせて作成しますが、事業チームは次の論点を判断材料として渡します。

表明保証は「問題がない」という抽象文だけでなく、開示基準日、対象アカウント、重要性、売主の知識範囲を調整します。既知のopen disputeや留保を開示した上で、実額精算又は特別補償へ移す方が、事実を隠して一般表明へ押し込むより運用しやすくなります。補償請求には通知・防御・和解の主導権、顧客対応を遅らせない例外を設けます。

TSAは旧アカウント貸与契約ではありません。許された操作、担当者、MFA端末、アクセス時間、返金上限、証拠提出期限、障害連絡、ログ、個人情報、費用、再委託、終了・延長、アカウント閉鎖を定めます。売主の従業員が退職する可能性も考え、代替担当と権限移行を用意します。

買収後30日で見る決済KPIは売上だけでは足りない

PMI初月のダッシュボードには、売上・承認率だけでなく、顧客影響、資金、統制、テールを同時に載せます。切替前4週間、前年同週、予算と比較し、大型セール、曜日、商品構成の影響を注記します。平均値だけでは障害を薄めるため、日次と決済方法別に見ます。

閾値は業界平均を借りるだけでなく、対象会社の正常期、決済会社の条件、買主のリスク許容から設定します。例えば承認率が1ポイント下がっても不正損失が大きく減れば許容できる場合があり、売上が増えても留保と返金が急増すれば現金は悪化します。数値の所有者と具体的な是正権限を結び付けます。

EC M&A後のPMIで止まりやすい運営移管では初月全体の引継ぎを扱っています。決済ダッシュボードはその中の受注・CS・物流・会計を横断する監視面として位置付け、決済チームだけの指標に閉じません。

決済論点と併せて読むEC M&Aの実務ガイド

決済クロージングは単独では完結しません。取得範囲、収益、定期顧客、サイト所有権、総合DDを先に確認すると、どの注文・残高を決済表へ入れるかが明確になります。次の公開記事はそれぞれ異なる入口を持つため、本稿の表を作る前後に必要なものだけ参照してください。

• ShopifyストアのM&Aで確認すべき契約・データ・引継ぎ：店舗所有権、データ、周辺契約の全体像を確認する。
• EC事業のM&Aで見るEBITDAと利益の質：決済手数料・返品・物流を正常収益へ戻す。
• サブスクECのM&Aで確認するKPI・契約・移行：継続課金と顧客コホートの前提を整理する。
• EC事業譲渡と株式譲渡の違い：取得スキームによる契約・債権の扱いを比較する。
• EC事業のデューデリジェンス完全チェックリスト：決済以外の在庫、契約、データ、運営を漏れなく見る。
• EC M&A後のPMIと初月対応：Day 1以後の組織・運営移管へ接続する。

内部記事の記載時点と本稿の事実確認日は異なります。特にプラットフォーム規約、決済審査、法令・ガイドラインは必ず最新の公式資料へ戻り、案件の契約書と管理画面を優先してください。

EC M&Aの決済引継ぎ – 最終チェックリストと結論

EC M&Aの決済引継ぎで最も危険なのは、サイトが表示され、テストカードが一度通ったことを完了とみなすことです。真の完了は、基準日前後の注文について販売主体、履行、売上、入金、返金、異議申立て、証拠、会計が一貫し、主要決済が買主の責任で運用され、旧アカウントが出口条件に沿って閉じられる状態です。

最終判断: 日付を守ることより、主要決済が新責任主体で再現可能であり、過去取引のテールが金額・期限・責任者付きで封じ込められていることを優先します。未解決事項があるなら隠さず、延期、条件付きGo、限定TSA、価格留保のいずれで受けるかを投資委員会と契約書で一致させます。

本稿のEC M&Aの決済引継ぎの手順は、特定の決済会社の承認や法的結論を保証するものではありません。それでも、注文IDを中心に資金と証拠を結び、買主が再実施できる状態を作れば、「売上はあるのに入金できない」「返金だけが買主へ残る」「旧担当の退職でdisputeに答えられない」という移行事故を大幅に減らせます。