受取り最適化エージェント
承認プロセスの改善：サポートされたルーティング、決済メッセージ、および再試行の決定。
Push every transaction toward its highest approval.
Act on every transaction in real time using learned routing, payment-message, and retry decisions that stay current as issuer behavior and traffic mix shift.
- Smart routing
- Message optimization
- Intelligent retries
このページでは、支払いフロー内で動作するエージェントであるAthiaの実行レイヤーについて説明します。Athiaのインテリジェンスレイヤーについては、 Athia の機能、送信されたデータに基づいて動作します。 どのような経路でデータが到着しても、エージェントをデプロイしたかどうかに関わらず、動作します。
エージェントがどのように決定するか#
DEUNAは、試行に使用するカード、BIN、発行元、金額、通貨、顧客履歴、時間、および類似の状況に関する情報を提供します。
Athiaは、ルーティング、決済メッセージ、および再試行の動作を選択します。 タイムアウト予算を超えた場合、DEUNAは、静的なルールを適用します。
DEUNAは、2番目の商社側のサービス呼び出しを追加することなく、選択されたパスを実行します。
プロセッサの結果は、オーケストレーションを通じて返され、次の決定を改善します。
エージェントの決定から結果までのトランザクションのライフサイクル。 静的なルールは、フロー全体でフォールバックルートとして機能します。
すべての決定は、カードとその BIN、発行銀行、金額と通貨、この顧客があなたとどのような関係にあるか、その日の時間、そしてこのトランザクションが類似したものとして送信された最後の時間という同じ状況から始まります。エージェントはこれらすべてを考慮し、どの部分が重要かを学習します。 あなたの トラフィック、これは一般的に重要ではないものが多い。
まず、3つの状態を観察してください。
どのプロセッサがトランザクションを受け取るか
静的なルーティングテーブルは、1つのプロセッサにセグメント全体を送信し、誰かが編集するまで送信を続けます。エージェントはテーブルを持っていません。エージェントは、カード、発行銀行、金額の各組み合わせに対して、どのプロセッサが実際に成功するかを学習し、その情報を各組み合わせに対して一度に保持し、結果が返されるたびに更新します。プロセッサが以前承認していたセグメントを静かに拒否し始めた場合、誰もダッシュボードを開く前に、トラフィックが移動します。
支払いメッセージの構成方法
特定のカードの種類や銀行は、メッセージが期待される形式で構成されている場合にのみ承認しますが、わずかな誤りでも通常の拒否として表示されます。これらのルールは公開されていません。担当者は、拒否データからこれらのルールを特定し、必要に応じてメッセージを修正します。これにより、お客様は何も入力したり、リリースを送信したりする必要がなくなります。
注文がDEUNAによって拒否される場合に、再試行する価値があるかどうか
再試行ルールは、すべての拒否を同じように扱い、無効なトランザクションに対して処理手数料を請求します。担当者は、拒否メッセージの意味を正しく解釈し、再試行する価値のあるトランザクションのみを再試行し、適切なタイミングで処理し、残りのトランザクションは処理しません。再試行は、毎回新たに決定されます。
これらは単に説明しやすい3つのケースです。担当者は単一のモデルであり、特定のケースに到達するために考慮される要素は、これらの3つの説明よりもはるかに広範です。また、常に進化しており、すべての結果から学習しています。お客様のアスティアチームに、現在お客様のアカウントでどのような判断が行われているかを確認してください。
導入方法#
決定と実行をオーケストレーション内で
チェックアウトは、1つのリクエストをDEUNAに送信します。 Athiaは、プロセッサ、メッセージ、および再試行の動作を選択します。 DEUNAは決済を実行し、結果を自動的に返却します。 商社側のポストバックは不要です。
定期課金のための決定ファイル
商社によるスケジュールされた課金の場合、課金ファイルをスコアリングに使用します。 Athiaは、プロセッサ、メッセージ、再試行のガイダンス、および予想される承認率を返却します。 貴社またはDEUNAが決済を実行し、商社が最終ステータスを返却します。
主要な運用上の違いは、結果の所有権です。 完全自動化パスでは、DEUNAが自動的に結果を返却します。 バッチの場合は、商社が結果を返却する必要があります。
| 完全に自動化 | バッチ処理 | |
|---|---|---|
| 支払い処理を実行する主体 | DEUNA | お客様、またはお客様の代理 |
| 統合するものは | DEUNA チェックアウトまたは決済オーケストレーション | ファイル交換、統合不要 |
| レイテンシー | リアルタイム、決済フロー内 | リアルタイムではありません。請求処理前に実行 |
| 範囲 | すべてのトランザクション | MITの定期課金のみ |
| プロセッサとの接続 | Managed by DEUNA | 自分のもの、またはDEUNAのもの |
完全に自動化
DEUNA チェックアウトまたは決済オーケストレーションとの一度統合。担当者は、オーケストレーションの意思決定プロセス内でコンサルテーションとして使用され、個別のAPI呼び出しではなく、認証パスへの追加のステップや、お客様側のML統合作業は不要です。DEUNAがプロセッサとの接続を管理し、担当者がすべてのトランザクションを処理します。まずは DEUNAのオーケストレーションプラットフォームの統合 と DEUNA Paymentsの概要.
バッチ処理
For 商用利用（MIT）の定期課金、リアルタイムではない。 処理前に、課金スケジュールを含むファイルを提供し、担当者が各行を評価し、結果ファイルが返されます。
送信する内容（1回あたりの情報）
| フィールド | Type | 説明 |
|---|---|---|
merchant_reference | String | 取引の識別子（チャージ用）が、結果行に返されます。 |
card_bin | String | カード BIN、最初の6桁または8桁 |
last_four_digits | String | カードの最後の4桁 |
issuing_bank | String | 発行銀行（カードが利用できる銀行） |
payment_amount | 小数点 | 予定された金額、主要単位 |
currency_code | String | ISO 4217 通貨コード |
scheduled_date | ISO 8601 文字列 | 課金が期日となるUTC時間 |
返される内容（1行あたりの情報）
| フィールド | 説明 |
|---|---|
merchant_reference | あなたの識別子をそのまま使用し、結果を自分の記録に紐付けます。 |
recommended_processor | この課金を承認する可能性が高い決済プロバイダー |
message_configuration | 対象のプロセッサ向けの決済メッセージの作成方法 |
retry_guidance | 拒否された場合の再試行とそのタイミング |
expected_approval_rate | エージェントがこの行を期待する内容、これによりソートが可能 |
ご自身のプロセッサとの接続ファイルを使用するか、DEUNAが決済を実行します。導入前に、DEUNAは過去のデータに基づいてエージェントをトレーニングします。
エージェントが学習する必要があること#
エージェントは、既存の履歴に基づいて事前学習されているため、稼働前に履歴トランザクションのダンプが必要です。その提供方法は、 Athiaとの統合、およびAthiaが期待するフィールドは、 Athiaデータ辞書に定義されています.
ローンチ後、結果が継続的に返ってくる必要があります。これは、DEUNAが決済を処理することで自動的に行われます。DEUNAに結果を送信し、バッチ処理、およびエージェントが評価したすべての取引の状態をDEUNAに送信する責任は、あなたにあります。そうしないと、DEUNAの意思決定が改善されなくなります。
稼働開始#
DEUNAは、これらの手順をあなたと共同で実施します。 各ステップで、DEUNAは証拠を提供し、あなたは進めるかどうかを決定します。 これは、テストフレームワークを操作するのではなく、設定を確認することです。
- 過去のデータを提供し、DEUNAはデータ辞書との照合により、フィールドのカバー範囲を確認します。
- デプロイメントを選択し、DEUNAはチームとの統合を完了し、支払い実行の場所でステータスコールバックを行います。
- エージェントの判断を、ボリュームが開始される前に確認できます。 その方法は、デプロイメントによって異なり、これらは異なる作業です。詳細は下記を参照してください。
- その証拠を承認した場合、DEUNAは 制御された実験 ライブボリューム、制御、および治療グループに対して、合意したトラフィックの重みで、徐々にシフトします。
デプロイメントによるステップ3の動作
| デプロイメント | エージェントがボリュームを開始する前に証明される方法 |
|---|---|
| 完全に自動化 | シャドウモード。 エージェントはライブトラフィックをスコアリングし、DEUNAのオーケストレーションが既存の静的なルール構成でトランザクションを送信します。決済は通常通りに処理されます。変更されるのはエージェントの判断ではなく、トランザクションです。その後、あなたは独自のボリュームでそれらを比較します。 |
| バッチ処理 | スコアリングされたファイルは適用されません。 エージェントは、スケジュールされた課金に関する実際のファイルをスコアリングし、結果を返します。あなたは通常の方法で課金を実行します。比較は同じですが、ファイルが決定されるまで、何もライブではありません。 |
各意思決定の実行時の動作は、 DEUNAオーケストレーション.