電気自動車充電の事前承認と払い戻しに関するガイド

1. 電気自動車の充電時に支払い保留が発生する理由

充電セッションの開始時点では、事業者は最終的なエネルギー供給量や期間を把握していない場合があります。事前承認は、変動料金が発生するサービスを提供する前に資金が利用可能かどうかを確認する一つの方法です。ただし、これは唯一の方法ではありません。ウォレット、プリペイド残高、口座請求など、それぞれ異なるワークフローが採用されています。

承認金額は、文書化された営業方針を反映したものであるべきです。不必要に高い保留金額はドライバーの不満を招く可能性があり、一方、想定されるセッションに対して金額が低すぎると、回収リスクが生じる可能性があります。最適な方法は、対象となる顧客層、決済プロバイダー、平均セッション数、およびサポートされている決済方法によって異なります。

基本的な区別については、以下を参照。 Stripeの個別の認証とキャプチャに関するドキュメントその文書には、利用可能な決済方法と認証の有効期限が記載されています。ただし、すべての決済ゲートウェイや現地決済方法で同じルールが適用されるという意味ではありません。

2. 承認、キャプチャ、キャンセル、返金は別々に管理する。

これらの用語が重要なのは、次の対応が現在の状態によって異なるためです。開始されなかったセッションは、承認のキャンセルが必要になる場合があります。完了して記録されたセッションで料金が誤っている場合は、一部返金が必要になる場合があります。どちらの場合も「返金済み」と表現すると、ドライバーは銀行の明細書が異なる理由が分からず困惑することになります。

支払い状況と請求状況は分けて管理する必要があります。「請求完了」は集金が成功したことを証明するものではなく、「支払い承認済み」は電力が供給されたことを証明するものではありません。記録には、これら2つのプロセスを同一の事象として扱うことなく、関連付ける必要があります。

3. 通常のセッションフローを設計する

お支払い前に、料金表、追加料金、および仮押さえ金額を分かりやすい言葉で表示してください。仮押さえは一時的なものであり、最終的な料金はセッションによって異なることを説明してください。この情報は、利用規約のページだけでなく、ドライバーが支払いを決定する場所に記載してください。

承認後、課金開始を要求し、充電器からの適切な証拠を待ちます。セッション識別子と支払い参照番号を一緒に保存してください。合意されたワークフロー内で充電器が起動しない場合は、有用なステータスを表示し、定義されたキャンセルまたは調査プロセスに従ってください。

セッション終了後、記録されたデータと適用される料金に基づいて料金を計算します。サポートされているキャプチャアクションを実行し、その結果を記録して、最終金額を記載した領収書を発行します。領収書には、サイト、コネクタ、期間、課金数量、およびサポートルートを明記する必要があります。

簡略化した例として、オペレーターが$30を承認し、検証済みのセッション料金が$8.40であるとします。プロバイダーが合意済みの部分キャプチャワークフローをサポートしている場合、システムは$8.40を徴収し、未使用の承認額はプロバイダーのルールに従って処理します。これはあくまで例示であり、推奨される保留金額ではありません。

4. 旅が中断した場合に何が起こるかを定義する

認証は成功したが、充電器が開始要求を拒否した場合を考えてみましょう。プラットフォームは、支払い承認を充電サービスの完了と解釈してはなりません。失敗した開始を関連する支払いと関連付け、文書化されたキャンセルポリシーに従う必要があります。

もう一つのよくあるケースは、充電終了時の接続途絶です。最終的なメーター値が、支払いワークフローで想定されているよりも遅れて届く場合があります。最終金額を捏造することなく、システムがどのように待機、再試行、またはエスカレーションするかを定義してください。ローカルデータが復元可能な場合は、合意された照合プロセスを通じてその証拠を使用してください。

セッション料金は、初回認証料金を超える場合もあります。プラットフォームが単純に高額な料金を徴収できるとは限らないため、注意が必要です。プロバイダーのサポート状況や契約内容によっては、追加認証、段階的認証、または別の料金徴収方法が必要になる場合があります。サービス開始前に、これらの動作を決定しておきましょう。

認証がキャプチャ前に期限切れになった場合は、所有者が指定された特定の例外として処理してください。サポートされる有効期間はプロバイダーによって異なるため、統合では、普遍的にハードコードされた期限ではなく、プロバイダーの支払い状況と有効期限情報を使用する必要があります。

5. 払い戻し専用の監査可能なワークフローを設ける

払い戻しは、既に徴収済みの支払いから始まります。事業者は、払い戻しの理由、承認された金額、および元の取引へのリンクを必要とします。システムは、誰が払い戻しを要求したか、必要に応じて誰が承認したか、そしてプロバイダーが要求を承認、完了、または拒否したかを記録する必要があります。

一部返金は、料金の一部のみを修正する必要がある場合に有効です。例えば、エネルギー料金は有効でも、誤って適用された待機料金を返金する必要がある場合などです。取引履歴を密かに書き換えるのではなく、元の領収書を保管し、調整内容を記録してください。

Stripeの返金に関するドキュメント 未完了の支払いのキャンセルと、完了した支払いの返金を区別し、保留中または失敗した結果について説明します。実際のプロバイダーの状態に基づいてサポート手順を構築します。送信された返金リクエストが、自動的にドライバーにお金が届いたことを約束するメッセージになるべきではありません。

プロバイダーと発行銀行の条件が許す場合を除き、確定的なリリース時間や返金時間を約束することは避けてください。システムがどのような処理を行ったかを説明し、顧客が後日確認できるよう支払い参照番号を提供してください。

6. 繰り返し発生するイベントや遅延するイベントに対して、統合が耐性を持つようにする

支払い通知は運用設計の一部であり、バックグラウンド処理ではありません。ドライバーがブラウザを閉じたり、モバイル接続が切断されたり、決済プロバイダーが画面上の課金画面の更新が停止した後にイベントを送信したりする可能性もあります。それでもバックエンドは正しい財務状態に到達する必要があります。

検証済みのプロバイダー通知を使用し、必要に応じて現在の支払い対象を確認してください。イベント識別子を記録し、重複処理を防ぎ、順序が前後するイベントにも対応できるようにしてください。通知が繰り返されても、二重の請求や返金が発生しないようにしてください。

StripeのWebhookに関するドキュメント 非同期イベント処理、署名検証、配信に関する考慮事項について説明します。実装は、選択したプロバイダーの要件に従う必要があります。運用面では、スタッフは未解決のケースをキューに格納する必要があり、通知漏れを隠す緑色のダッシュボードは望ましくありません。

既存の EV充電API統合ガイド プラットフォームと決済システムおよび業務システムを連携させるためのより広範なコンテキストを提供します。プロジェクトスコープ内で決済状態モデルを明確に定義してください。

7. セッション、支払い、および決済記録を照合する

便利な日次レビューでは、充電器が配達した内容、ドライバーに請求された金額、プロバイダーが決済のために報告した内容という3つのビューを連携させます。金額と概算時間だけでなく、安定した識別子を使用してレコードを照合します。2人の異なるドライバーが、同じ料金でセッションを行うことも容易にあり得ます。

支払いが完了していないセッション、対応するセッションがない支払い、重複したキャプチャ、および解決待ちの払い戻しにフラグを立てます。それぞれの例外を調査できるチームに割り当てます。財務部門は、プロバイダー手数料と決済調整がどのように表示されるかを理解しておく必要があります。

カードによる直接決済とローミング決済は異なる関係です。ドライバーが外部のモビリティプロバイダーを通じて請求した場合、商取引の照合はパートナーの記録と請求書に依存する場合があります。そのワークフローについては、以下を参照してください。 CDRから和解までのローミング和解ガイド 既存のカード決済手続きをそのまま適用するのではなく、別の方法を採用した。

8. 発売前に不快なケースをテストする

承認拒否、承認成功後の開始失敗、通常の部分キャプチャ、重複コールバック、遅延した最終セッションレコード、および期限切れの承認について、制御されたテストを実行します。全額返金と部分返金、および保留中または失敗した返金を追加します。

いずれの場合も、ドライバーメッセージ、課金セッションの状態、プロバイダーの支払い状態、および財務記録の4つの項目を確認してください。これら4つすべてが一貫した内容を示す必要があります。技術的に成功したAPIリクエストであっても、表現が誤ったイベントを記述している場合、顧客体験を混乱させる可能性があります。

サポートスタッフに保留中の取引に関する説明を事前に練習させておきましょう。顧客から不必要な銀行情報を要求することなく、承認情報、最終請求額、関連する参照番号などを確認できるようにしておくべきです。

よくある質問

電気自動車の充電料金には追加料金がかかりますか？

保留は資金を確保するものであり、必ずしも追加の請求完了を意味するものではありません。ドライバーは、金額が保留中か決済済みかを確認する必要があります。事業者は最終領収書を発行し、徴収した金額と確認済みのセッション料金との間に不一致がないか調査する必要があります。

すべての決済方法で事前承認を利用できますか？

いいえ。サポート状況は、決済方法、プロバイダー、加盟店の設定、地域によって異なります。一部の決済プロセスでは、プリペイド、即時決済、またはアカウント請求モデルが必要となる場合があります。特定の決済体験を宣伝する前に、実際の統合状況を確認してください。

払い戻しが保留になるのはなぜですか？

結果はプロバイダーと取引状況によって異なり、完了には発行銀行が関与する場合があります。サポートチームは、返金リクエストと完了した返金を区別し、調査時にはプロバイダーの参照情報を使用する必要があります。