暗号資産決済の問い合わせ対応：顧客から安全に確認資料を集めるチェックリスト

顧客から「支払ったのに、注文が未払いのままです」と言われたら、再度の支払いを求めるのではなく、確認資料を集めることから始めましょう。 暗号資産決済の問い合わせ対応では、送金と注文を照合できる情報が必要です。ただし、リカバリーフレーズ、秘密鍵、ウォレットのパスワードは一切必要ありません。

この記事は、デジタル商品、サービス、会員権を販売する事業者向けです。問い合わせの受付から担当者への引き継ぎまでを扱うもので、資金の回収を約束するものではありません。販売者に推奨する対応手順であり、Yolfiが自動で提供するサポート機能や資金回収機能を説明するものではありません。

決済確認に役立つ最小限の資料を集める

非公開の問い合わせ案件を1件作成し、注文の参照番号、支払い時に選択したネットワーク、トランザクションハッシュがあればその値を尋ねます。購入の全過程を顧客に再現してもらうのではなく、自社で保存している決済ページの情報を照合の基準にしてください。

トランザクションハッシュはウォレットの秘密情報ではありませんが、氏名やメールアドレスと結び付くと、顧客の金融活動が分かってしまうことがあります。公開コメントではなく、非公開の問い合わせ案件内で管理してください。1件の送金で確認できることについて、ウォレットの全履歴を求めてはいけません。

問題解決のためにウォレットへのアクセスを求めない

最初の返信で、対応範囲を明確に伝えます。サポートにリカバリーフレーズ、秘密鍵、ウォレットのパスワード、ワンタイムログインコード、顧客端末の遠隔操作は必要ありません。過去の支払いを確認するために、「修復」サイトへのウォレットの取り込み、説明のないメッセージへの署名、トークン使用の承認を顧客に求めないでください。

MetaMaskの公式サポート案内では、サポートチームがSecret Recovery Phraseを尋ねることは決してないと明記し、突然届くダイレクトメッセージへの注意を促しています。自社の決済問い合わせの受付でも、秘密情報を求めないという同じ原則を適用してください。ウォレット提供元の代理として対応しているかのように伝えてはいけません。

顧客が誤って秘密情報を送ってきた場合は、その案件へのアクセスを制限し、ログや社内チャットに転記しないでください。ウォレット提供元が公開している、ウォレットの侵害時の公式手順に速やかに従うよう伝えます。問い合わせメッセージを削除しても、流出した鍵の安全性は戻りません。

「未送信」と「送信済みだが未解決」を区別する

トランザクションハッシュがあるか確認します。決済ページ、QRコード、ウォレットの確認画面があるだけでは、送金がネットワークに送信された証拠にはなりません。送信前にウォレットで操作を取り消したり、処理に失敗したりした場合、調査対象となるブロックチェーン上の支払い自体が存在しない可能性があります。

取引所の出金参照番号は、ブロックチェーンのトランザクションハッシュではなく、サービス内部の識別番号である場合があります。そのサービスの公式アプリで出金状況を確認するよう顧客に依頼してください。処理待ちの出金を販売者の入金確認済みとして扱ったり、到着時刻を確約したりしてはいけません。

ハッシュがある場合は、決済時に選択したネットワークで確認します。問い合わせに添付されたリンクにウォレットを接続するのではなく、信頼できるエクスプローラーへ自分でアクセスしてください。公開取引の閲覧にウォレットの接続は不要です。送金先、資産、送金額、取引結果を販売者の記録と照合します。トークンの送金では、取引に表示されるネイティブ通貨の金額だけでなく、トークンの送金詳細を確認してください。

別のネットワークで成功した取引や、見慣れたシンボルでもコントラクトが異なるトークンは、自動的に該当する支払いとして扱えるものではありません。その場で資金回収の手順を考えるのではなく、誤ったネットワークでの支払いに関するチェックリストに沿って例外対応を進めてください。

支払いの試行を販売上の注文と照合する

販売上の注文、決済の試行、ブロックチェーン上の送金を分けて管理します。同じ購入に対して、顧客が複数回の決済を試みることがあります。再利用可能なリンクは商品購入への入口を示すもので、必ずしも特定の顧客の一意の注文を表すわけではありません。

YolfiのAPI Checkoutドキュメントでは、再利用可能な固定価格のPaylinksと、動的な注文用にサーバー側で作成するCheckout Sessionsを区別しています。単独のセッションにPaylinkは必要ありません。サポートでは、その決済フローで実際に保存された参照情報を使い、もともと作成されないオブジェクトがないという理由で問い合わせを断らないようにしてください。

固定商品の場合、Yolfiの決済リンクが支払いの入口になります。それでも、問い合わせ案件を該当する請求書や注文に結び付ける仕組みは必要です。ホスト型決済ページの完全なURLを公開しないでください。注文に関する情報が漏れたり、第三者がその決済ページを操作できたりする可能性があります。

二重払いを求めずに案件を適切な担当者へ回す

簡潔な判断記録を残します。想定していた内容、確認できた資料、次の対応の担当者、顧客への次回連絡時期を記載してください。連絡時期の約束は、ブロックチェーンでの決済完了や資金回収の保証ではありません。

• 送信の証拠がない場合： 再試行を提案する前に、ウォレットや送金サービスが実際に送金処理を送信したか確認します。
• 送金がまだ保留中の場合： 送金サービスやウォレットの公式案内に従って確認します。対応を早めるためという理由だけで、再度の支払いを求めてはいけません。
• 送金先、ネットワーク、資産が異なる場合： 元の支払い案内と送金の確認資料を保存し、担当者に引き継ぎます。資金回収を約束したり、ウォレットの秘密情報を求めたりしてはいけません。
• 支払いは記録されているが、注文が提供されていない場合： 購入者に再度決済してもらう前に、販売者の注文処理と商品・サービスの提供手順を調査します。
• 支払いの試行が期限切れ、または一致しない場合： 新しい試行を送金済みの資金の代わりとして黙って扱わず、期限切れ請求書の対応手順に従ってください。

YolfiのWebhookリファレンスは、商品・サービスの提供を開始する主要なトリガーをpayment.confirmedとしています。invoice.createdイベントは支払いの証拠ではありません。顧客のスクリーンショットやブラウザーのリダイレクトは参考情報にはなりますが、サーバー側で検証された支払い確認の代わりにはなりません。

エクスプローラーはブロックチェーン上で何が起きたかを確かめる助けになりますが、それだけでは自社アプリが支払いを照合したか、注文を提供したかは分かりません。支払いの調査と提供状況の調査は関連付けつつ、別々に扱ってください。

短く安全な初回返信テンプレートを使う

自社の問い合わせ窓口や案件番号に合わせて、次の文面を調整してください。

注文または請求書の参照番号、選択したネットワークとトークン、送金額、トランザクションハッシュがあればその値をお送りください。取引所から出金した場合は、取引所名と出金状況もお知らせください。無関係な残高や個人情報は伏せてください。リカバリーフレーズ、秘密鍵、ウォレットのパスワード、ログインコードは決して送らないでください。現在の支払いの試行を確認している間は、再度お支払いにならないようお願いいたします。決済記録と注文記録を確認した後に、状況をご連絡します。

返金を約束する前に、申請者と支払者の関係を確認し、返金審査チェックリストに従ってください。問い合わせが届いたというだけで、チャットに書かれた別のアドレスへ資金を送ることが許可されたわけではありません。

よくある質問

スクリーンショットで販売者への支払いを証明できますか？

それだけでは証明できません。送金予定、出金の保留状態、あるいは別の取引が表示されている可能性があります。注文を提供する前に、実際の送金を確認し、販売者の決済記録と照合してください。

トランザクションハッシュを尋ねても安全ですか？

通常、非公開の決済調査で尋ねるのは適切です。署名に使う秘密情報ではなく、公開ブロックチェーンの情報ですが、顧客と公開された金融活動を結び付ける可能性があります。必要な情報だけを集め、アクセスを制限してください。

サポートは顧客にウォレットの接続を求めるべきですか？

公開取引の閲覧や既存の決済記録の確認には必要ありません。別の正当な製品操作にウォレットが必要な場合は、通常の決済フローを通じてその操作を明確に説明してください。署名やトークン使用の承認を、日常的なサポート確認に見せかけてはいけません。

Yolfiやウォレット提供元は、どのような誤送金でも取り消せますか？

そう考えてはいけません。回収できるかどうかは、送金先、ネットワーク、資産、受取資金を誰が管理しているかによって異なります。どのようなサポート手順でも、トランザクションハッシュだけで取消しや回収を保証してはいけません。

まとめ：確認資料に基づく問い合わせ対応を

安全な決済問い合わせ対応では、少数の参照情報を集め、送金を独立して検証し、ウォレットの認証情報をさらすことなく次の対応を担当者に割り当てます。Yolfiの決済リンクに、顧客向けの明確な案内と非公開の確認資料チェックリストを組み合わせてください。未解決の注文を、秘密情報の共有や再度の支払いを促すきっかけではなく、調査すべき案件として扱えるようになります。