財務チームがSaaSサブスクリプションの支払い用にバーチャルカードを割り当てます。
2か月後、更新料金が別のカードから請求されました。
その日のチェックアウト時に、誰もその2枚目のカードを入力していません。それでは、サービス提供者が選択した支払い方法を無視したのでしょうか？
必ずしもそうとは限りません。
加盟店のアカウントには、役割の異なる複数の支払い方法が登録されている場合があります。
- メインまたはデフォルトの支払い方法
- バックアップの支払い方法
- 特定のサブスクリプションに紐付けられたカード
- すでに請求書に関連付けられている支払い方法
一部のサービスでは、支払いに失敗すると、利用可能な別の支払い方法を使って再試行します。一方、そのような処理を行わないサービスもあります。
確実な答えは、加盟店の請求設定、請求書、通知、取引記録から確認できます。この記事では、デフォルトカードとバックアップカードの違い、更新決済に失敗した後に起こり得ること、そして同じ請求書を誤って二重に支払わないための方法を解説します。
支払い方法はどのレベルに設定されるのか
SaaSアカウントでは、支払い方法が複数のレベルで保存されている場合があります。
- アカウントレベルのデフォルト
- サブスクリプションレベルの支払い方法
- 請求書レベルの決済方法
- バックアップまたは代替の支払い方法
そのため、
デフォルトカード：•••• 4821
と表示されていても、すべてのサブスクリプションや請求書でそのカードが使われるとは限りません。
以前から利用しているサブスクリプションが別の支払い方法に紐付いたままになっている場合があります。また、未払いの請求書にはすでに独自の決済方法が設定されていることがあり、マーケットプレイスでは別のバックアップ設定が管理されている場合もあります。
重要なサブスクリプションについては、具体的なプラン、最新の請求書、次回の更新日、そして加盟店が使用すると案内している支払い方法を確認してください。
重要なのは、
「デフォルトカードは何か？」
ではなく、
「この特定のサブスクリプションまたは請求書は、どのカードで支払われるのか？」
という点です。
メインカードの支払いに失敗するとどうなるのか
継続課金に失敗した場合、その後の処理は加盟店が独自の請求設定に基づいて決定します。
考えられる対応には、次のようなものがあります。
- 同じカードで再試行する
- 認証を要求する
- 支払い失敗の通知を送る
- 請求書を未払いのままにする
- 利用可能なバックアップ方法での決済を試みる
再試行のタイミングや順序は、プロバイダーによって異なります。
バックアップカードが登録されているからといって、すべてのサブスクリプションでそのカードが使われるとは限りません。また、メインカードが拒否されたからといって、必ずバックアップカードに請求されるわけでもありません。
重要なSaaSサービスについては、別のカードが自動的にサブスクリプションを維持してくれると考えるのではなく、販売者が実際にどのようなフォールバックルールを設定しているのかを確認してください。
例：1つのサブスクリプションに2枚のカード
ある会社が、月額90ユーロのプロジェクト管理サービスのサブスクリプションにカードAを使用しているとします。
カードBは一般的な運営予算用で、利用可能なバックアップカードとして登録されています。
更新日にカードAの利用可能な残高または利用枠が不足していました。加盟店はまずカードAで決済を試み、その後、フォールバック設定に従ってカードBに請求しました。
財務チームはカードBに90ユーロの請求があることを確認し、重複請求だと考えます。一方、プロジェクト担当者にはカードAの支払い失敗を知らせるメールが届いています。
この2つのイベントは、同じ請求書に関連している可能性があります。
再度支払う前に、次の点を確認してください。
- カードAの支払いは完了したのか、それとも失敗しただけなのか？
- カードBによって請求書の支払いは完了したのか？
- 加盟店側で請求書が支払い済みになっているか？
カードBだけで支払いが完了している場合、支出を希望するカードに移すためだけに、カードAから同じ請求書を再度支払わないでください。
次回の更新に備えて加盟店の設定を変更し、今回の支出については社内の会計処理で対応します。
両方のカードに同じ請求書に対する完了済みの請求が表示されている場合は、加盟店に取引単位での説明を求めてください。
予期しないバックアップ請求が必ずしも不正利用とは限らない
バックアップの支払い方法は、数か月前に有効化されていたり、以前の決済トラブルの際に追加されていたりする可能性があります。
財務チームが予期しないカードで更新請求を確認した場合は、次の情報を収集してください。
- 請求書番号
- サブスクリプションID
- メインカードでの決済試行のステータス
- バックアップ設定
- 請求額
- 請求期間
- 加盟店の支払い履歴
そのうえで、その請求が承認済みの事業上の支出に該当するかどうかを確認します。
バックアップカードが別のチームやコストセンターに属している場合、それは加盟店による不正な取引ではなく、予算配分の問題である可能性があります。
支払いを正当なサブスクリプションや請求書と紐付けられない場合は、カードプロバイダーが定める通常のセキュリティおよび異議申し立ての手続きに従ってください。
デフォルト、バックアップ、交換カードは異なる
デフォルトカードは、今後の購入や特定の請求プロファイルに適用される場合があります。
バックアップカードは、優先される支払い方法で決済できなかった場合に使用される可能性がある、別の利用可能な支払い方法です。
交換カードは、カード情報が変更された後も支払いを継続できるようにするためのものです。
これらは同じものではありません。
アカウントレベルのデフォルトカードを変更しても、以前から利用しているサブスクリプションが更新されるとは限りません。新しいカードを追加しただけでは、自動的にバックアップカードになるとは限りません。また、一般的なウォレットからカードを削除しても、すべての既存サブスクリプションからそのカードが切り離されるとは限りません。
カードの変更がすべての場所に適用されたと判断する前に、サブスクリプションと請求書のレベルで加盟店の設定を確認してください。
カードの通知だけでは請求書の支払い完了を意味しない
カードへの通知だけでは、加盟店が正常に支払いを回収したことを証明できません。
取引には次のような状態があります。
- 保留中
- オーソリ済み
- 取り消し済み
- 売上確定済み
- 返金済み
同時に、加盟店側では請求書が未払いのまま表示され、その後、別のカードで再度決済を試みる場合があります。
支払いを照合するには、次の情報を比較してください。
カードのステータス → 請求書のステータス → 請求書番号 → 決済完了済みの支払い
一方のカードに一時的なオーソリが表示され、その後消えて、別のカードに確定済みの支払いが表示されている場合、実際に完了した請求は1件だけである可能性があります。
同じ請求書を二重に支払わない
更新決済に失敗した後、すぐに対応してしまうことは、よくあるミスの1つです。
財務チームには、
- カードAで支払い失敗の通知が届く
- その後、カードBで90ユーロの請求通知が届く
という状況が発生します。
そこで誰かがカードAからさらに90ユーロを手動で支払ってしまいます。
これによって、実際の二重支払いが発生する可能性があります。
その代わりに、まず加盟店の請求書を確認し、関連するすべての支払い試行を次のように整理してください。
- 失敗
- オーソリ済み
- 取り消し
- 売上確定
- 返金済み
両方のカードに同じ請求書に対する確定済みの取引が表示されている場合は、加盟店に追加の支払いを追跡してもらい、返金されるのか、またはクレジットとして処理されるのかを確認してください。
プッシュ通知だけを頼りに判断しないことが重要です。
確認しておきたい3つの設定
1. 古いサブスクリプションが元のカードを使い続けている
アカウントレベルのデフォルトカードは変更されていますが、長期間利用しているサブスクリプションが古いカードに紐付いたままになっています。
実際のサブスクリプションを開き、マスクされた支払いカードを確認してください。
2. 未払いの請求書にすでに決済方法が設定されている
請求書がすでに発行された後に、会社がデフォルトカードを変更します。
その請求書では、以前の支払い方法や再試行の経路が引き続き使用される場合があります。
新しいデフォルトカードがすぐに適用されると考えるのではなく、対象となる請求書を個別に確認してください。
3. サブスクリプションがマーケットプレイスによって管理されている
会社が開発者のWebサイトで支払いカードを更新しましたが、そのサブスクリプションはもともとアプリマーケットプレイスを通じて購入されたものです。
マーケットプレイスには独自のメインカードとバックアップカードの設定がある場合があります。
誤った支払いプロファイルを変更する前に、最初の領収書と請求アカウントを確認してください。
重要なサブスクリプションには明確な支払いルールを設定する
すべてのSaaS製品に自動的なフォールバック決済が必要なわけではありません。
重要なインフラサービスでは、管理されたバックアップカードを設定することで、サービスの中断を防ぎやすくなります。
一方、優先度の低いツールや実験的なサービスでは、次のような運用を選択する場合があります。
支払い失敗 → チームに通知 → 手動承認が必要
重要なサブスクリプションごとに、次の情報を記録してください。
- メインの支払い方法
- バックアップ方法（ある場合）
- 予定されている更新金額
- 更新日
- 担当するコストセンター
- 通知を受け取る担当者
また、カードの変更、チーム変更、料金変更、決済失敗などが発生した後には、設定を見直してください。
バックアップカードが、明確な承認ルールのないまま複数の部署で利用できる、管理者不在の「緊急用カード」にならないようにすることも重要です。
Buveiで継続的なSaaS決済を管理する方法
Buveiバーチャルカードを利用すると、企業は継続的なSaaS支出を、ベンダー、チーム、目的などに応じて分けて管理できます。
専用カードを利用することで、継続的な請求を識別し、照合しやすくなります。
利用可能な場合、カードの記録から、どのカードで決済が試行されたのか、取引金額、日付、そして関連するカード取引が完了したかどうかを確認できます。
ただし、SaaSプロバイダーが引き続き管理するのは次の項目です。
- 支払い方法の優先順位
- バックアップ決済の利用可否
- 再試行の動作
- サブスクリプション設定
- 請求書の回収処理
加盟店の請求書とカードの記録を一緒に管理しておけば、予期しない更新請求が発生した場合でも、その理由を説明しやすくなります。
次に予期しない請求が発生したときの簡単なチェックリスト
SaaSの更新料金が予期しないカードに請求された場合：
- 加盟店と使用されたカードを確認する。
- 関連する請求書を見つける。
- 各カードの取引が保留中なのか、確定済みなのかを確認する。
- どの支払い方法がメインだったのかを確認する。
- メインカードでの決済試行がどうなったのかを確認する。
- バックアップ決済が有効になっていたか確認する。
- どの支払いによって請求書が決済されたのかを確認する。
- 必要に応じて、今後の加盟店側の設定を修正する。
1件の有効な支払いによって請求書が別の社用カードで決済されていた場合は、設定を修正し、社内でその支出を適切に処理してください。
同じ請求書に対して2件の支払いが完了していた場合は、加盟店に修正を依頼してください。
取引を有効なサブスクリプションや請求書と紐付けられない場合は、カードプロバイダーのセキュリティおよび異議申し立ての手続きに従ってください。
まとめ
バックアップカードは、単なる緊急時の選択肢ではありません。加盟店の請求ルールに基づいて利用される可能性のある、もう1つの支払い経路です。
企業は次の点を把握しておく必要があります。
- どのサブスクリプションをカバーできるのか
- どのカードがメインなのか
- 誰がバックアップ決済を承認したのか
- 誰が通知を受け取るのか
予期しない更新請求が発生した場合は、次の流れを確認してください。
サブスクリプション → 請求書 → メインカードでの決済試行 → バックアップ設定 → 決済完了済みの支払い
これらの記録が一致すれば、2枚のカードの明細だけから推測することなく、その請求が発生した理由をより簡単に説明できます。
