不正行為対策のカスタマイズ
不正行為の検出、プロバイダーの決定、ルーティング、および結果フィードバックの設計、テスト、および運用を、ブラウザの結果に依存せずに実行します。
エンドツーエンドの意思決定システムとして、不正行為の制御をカスタマイズします。 許可された信号を収集し、構成されたプロバイダーに意思決定を要求し、その意思決定を支払いアクションに変換し、確認された結果を返してモデルを改善します。
不正行為の意思決定ライフサイクル#
01 · observe
承認された信号を収集
選択したプロバイダーがサポートする、正確な注文、顧客、販売者、住所、およびデバイスのコンテキストを送信します。
02 · assess
リスク評価
DEUNAは、構成された支払い戦略のポイントで、アクティブな不正行為接続を呼び出します。
03 · act
ポリシーの適用
承認、認証の要求、レビュー保留、異なるルーティング、または標準化された結果に基づいて、継続、拒否します。
04 · confirm
支払い状態の調整
履行前に、信頼できる支払い状態または検証済みウェブフックを使用します。
05 · learn
結果の返却
合意された不正利用およびチャージバックの結果を送信し、プロバイダーがモデルのパフォーマンスを評価できるようにする。
フロー図
リスクレベルだけでは支払い結果は決定されない。低リスクの取引でも、決済プロセッサによって拒否される可能性があり、認証が完了しても、承認が失敗する可能性もある。不正利用、認証、および支払い状態をそれぞれ別のフィールドとして保持する。
カスタマイズタスクを選択#
デバイスフィンガープリント設定された不正利用または決済プロバイダーが期待するデバイス識別子を生成し、送信する。Web and supported SDK flowsシャドウモード新しいモデルが顧客体験に影響を与える前に、プロバイダーによる生産環境でのトラフィックに関する決定を比較する。Observe without blockingフィードバックを外す合意された過去のチャージバックの結果を送信し、チャージバック管理とフィードバックの収集を混同しない。Email or provisioned SFTP決済戦略不正利用の評価を、承認の前後で実行し、サポートされている結果ごとにアクションを定義する。Decision to action不正利用ステータス不正行為の評価を、金融ライフサイクルと手動レビューの状態から分離して実施します。State and decisionsプロバイダー機能各不正行為対策プロバイダーの公開状況と接続ガイドを確認します。Country and capability filters
不正行為が発生する場所を特定します。#
| 配置 | 保護するもの | 主なトレードオフ | 必要な対応 |
|---|---|---|---|
| 承認前 | ポリシーに基づいて拒否された試行をプロセッサに送信しない | 不正行為のタイムアウトは、承認が確立される前に支払いを遅らせたり、停止したりする可能性があります。 | タイムアウトとフォールバック動作を定義し、支払い結果を自作しないでください。 |
| 承認後 | プロバイダーがプロセッサと承認コンテキストを評価できるようにします。 | 承認された場合、リスクが注文を拒否した場合、承認を無効にする必要がある場合があります。 | 履行を保留し、無効化またはキャプチャの結果を確認します。 |
| シャドウモード | 支払い決定を変更せずに、プロバイダーを監視します。 | 結果は観察的なものであり、黙って強制として機能してはなりません。 | 比較メトリクスとライブルーティング入力の区別を明確にしてください。 |
| 手動レビュー | 最終処理前に、人間またはプロバイダによるレビューを追加 | 顧客および処理フローが、より長く保留状態になる | 「 manual_review 未解決として扱い、後で確定された状態を使用する |
使用する 動的な認証 不正結果が、3DSなどの検証制御を選択した場合、 手動レビュー 保留されたトランザクションに対して使用します。 3DS 発行者認証に関する動作
シグナル契約#
必要なデータのみを送信してください。送信するデータは、選択したプロバイダーによって正確で、許可されており、サポートされている必要があります。 必要なフィールドがすべて含まれているからといって、必ずしもより良い結果が得られるとは限りません。
| シグナルグループ | 例 | 統合ルール |
|---|---|---|
| 注文 | 金額、通貨、商品、配送、割引 | バックエンドで処理された注文と一貫した合計を表示する |
| Cliente | 安定した顧客情報、注文履歴、連絡先情報 | 秘密の認証情報や関連のない個人情報をフリーテキストフィールドに入れないでください |
| デバイス | プロバイダとの互換性のあるフィンガープリントまたはデバイスセッション識別子 | サポートされているクライアントフローで生成し、同じ注文試行に紐付けます |
| マーケットプレイス | 販売者識別子と承認された販売者属性 | 確認 marketplace_sellers プロバイダーが実際に利用するフィールド |
| 結果 | 支払い結果、確認された不正行為、または合意されたチャージバックの状態 | DEUNAのトランザクション識別子を使用して、一意に送信 |
安全な展開#
- サポートを確認してください。 公開されている機能と商用契約から、プロバイダー、市場、チャネル、および評価場所を選択してください。
- ポリシーを定義してください。 各サポートされているプロバイダーの結果、タイムアウト、レスポンスなし、および手動レビューの結果について、対応アクションを記述してください。
- シグナルをマッピングします。 送信するすべてのフィールドについて、 authoritative なソース、形式、同意の根拠、およびフォールバックを文書化してください。
- サンドボックスで検証します。 低、中、高、利用不可、タイムアウト、重複、および不正なシグナルの場合をテストします。
- 影モードで比較します。 新しいプロバイダーまたはモデルを本番環境に移行する前に、カバレッジと不一致を測定します。
- 段階的にリリースします。 承認、チャレンジ、レビュー、誤検知、詐欺、および支払い結果をまとめて監視します。
- フィードバックループを完了します。 承認された結果を チャージバックフィードバックワークフローを通じて返します。.
運用チェックリスト#
- プライベートなプロバイダーの認証情報を、ブラウザまたはモバイルコードではなく、DEUNA Adminまたは保護されたバックエンドに保存してください。
- 詐欺評価、支払い試行、注文、および後の結果を、安定した識別子と関連付けます。
- リトライ操作を冪等にします。クライアント側のタイムアウトは、評価または支払いが行われたことを意味しません。
- サポートのために必要な元のプロバイダーの参照を保持し、ビジネスロジックにのみ正規化された決定を公開します。
- デバイスデータの欠落、評価遅延、利用不可な応答、意思決定のずれ、およびフィードバック処理の失敗に関するアラート。
- プロバイダー、SDK、マーケット、または必要な信号が変更された場合に、戦略を再検証してください。