メインコンテンツへスキップ
このページで
Specialized payment agent

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
Acceptance Optimization Agent

This page covers Athia's execution layer, the agent acting inside the payment flow. Athia's intelligence layer, covered in Athia の機能、送信されたデータに基づいて動作します。 どのような経路でデータが到着しても、エージェントをデプロイしたかどうかに関わらず、動作します。

エージェントがどのように決定するか#

トランザクションのライフサイクル、エージェントの決定から結果を学習し、次のトランザクションに適用するまで。破線は、失敗時のフォールバックパスです。

すべての決定は、カードとその BIN、発行銀行、金額と通貨、この顧客があなたとどのような関係にあるか、その日の時間、そしてこのトランザクションが類似したものとして送信された最後の時間という同じ状況から始まります。エージェントはこれらすべてを考慮し、どの部分が重要かを学習します。 あなたの トラフィック、これは一般的に重要ではないものが多い。

まず、3つの状態を観察してください。

どのプロセッサがトランザクションを受け取るか

静的なルーティングテーブルは、1つのプロセッサにセグメント全体を送信し、誰かが編集するまで送信を続けます。エージェントはテーブルを持っていません。エージェントは、カード、発行銀行、金額の各組み合わせに対して、どのプロセッサが実際に成功するかを学習し、その情報を各組み合わせに対して一度に保持し、結果が返されるたびに更新します。プロセッサが以前承認していたセグメントを静かに拒否し始めた場合、誰もダッシュボードを開く前に、トラフィックが移動します。

支払いメッセージの構成方法

特定のカードの種類や銀行は、メッセージが期待される形式で構成されている場合にのみ承認しますが、わずかな誤りでも通常の拒否として表示されます。これらのルールは公開されていません。担当者は、拒否データからこれらのルールを特定し、必要に応じてメッセージを修正します。これにより、お客様は何も入力したり、リリースを送信したりする必要がなくなります。

注文がDEUNAによって拒否される場合に、再試行する価値があるかどうか

再試行ルールは、すべての拒否を同じように扱い、無効なトランザクションに対して処理手数料を請求します。担当者は、拒否メッセージの意味を正しく解釈し、再試行する価値のあるトランザクションのみを再試行し、適切なタイミングで処理し、残りのトランザクションは処理しません。再試行は、毎回新たに決定されます。

これらは単に説明しやすい3つのケースです。担当者は単一のモデルであり、特定のケースに到達するために考慮される要素は、これらの3つの説明よりもはるかに広範です。また、常に進化しており、すべての結果から学習しています。お客様のアスティアチームに、現在お客様のアカウントでどのような判断が行われているかを確認してください。

導入方法#

各導入における責任範囲。太線は、商社が所有するステータスコールバックを示しています。

完全に自動化バッチ処理
支払い処理を実行する主体DEUNAお客様、またはお客様の代理
統合するものはDEUNA チェックアウトまたは決済オーケストレーションファイル交換、統合不要
レイテンシーリアルタイム、決済フロー内リアルタイムではありません。請求処理前に実行
範囲すべてのトランザクションMITの定期課金のみ
プロセッサとの接続Managed by DEUNA自分のもの、またはDEUNAのもの

完全に自動化

DEUNA チェックアウトまたは決済オーケストレーションとの一度統合。担当者は、オーケストレーションの意思決定プロセス内でコンサルテーションとして使用され、個別のAPI呼び出しではなく、認証パスへの追加のステップや、お客様側のML統合作業は不要です。DEUNAがプロセッサとの接続を管理し、担当者がすべてのトランザクションを処理します。まずは DEUNAのオーケストレーションプラットフォームの統合 と DEUNA Paymentsの概要.

バッチ処理

For 商用利用(MIT)の定期課金、リアルタイムではない。 処理前に、課金スケジュールを含むファイルを提供し、担当者が各行を評価し、結果ファイルが返されます。

送信する内容(1回あたりの情報)

フィールドType説明
merchant_referenceString取引の識別子(チャージ用)が、結果行に返されます。
card_binStringカード BIN、最初の6桁または8桁
last_four_digitsStringカードの最後の4桁
issuing_bankString発行銀行(カードが利用できる銀行)
payment_amount小数点予定された金額、主要単位
currency_codeStringISO 4217 通貨コード
scheduled_dateISO 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は証拠を提供し、あなたは進めるかどうかを決定します。 これは、テストフレームワークを操作するのではなく、設定を確認することです。

  1. 過去のデータを提供し、DEUNAはデータ辞書との照合により、フィールドのカバー範囲を確認します。
  2. デプロイメントを選択し、DEUNAはチームとの統合を完了し、支払い実行の場所でステータスコールバックを行います。
  3. エージェントの判断を、ボリュームが開始される前に確認できます。 その方法は、デプロイメントによって異なり、これらは異なる作業です。詳細は下記を参照してください。
  4. その証拠を承認した場合、DEUNAは 制御された実験 ライブボリューム、制御、および治療グループに対して、合意したトラフィックの重みで、徐々にシフトします。

デプロイメントによるステップ3の動作

デプロイメントエージェントがボリュームを開始する前に証明される方法
完全に自動化シャドウモード。 エージェントはライブトラフィックをスコアリングし、DEUNAのオーケストレーションが既存の静的なルール構成でトランザクションを送信します。決済は通常通りに処理されます。変更されるのはエージェントの判断ではなく、トランザクションです。その後、あなたは独自のボリュームでそれらを比較します。
バッチ処理スコアリングされたファイルは適用されません。 エージェントは、スケジュールされた課金に関する実際のファイルをスコアリングし、結果を返します。あなたは通常の方法で課金を実行します。比較は同じですが、ファイルが決定されるまで、何もライブではありません。

各意思決定の実行時の動作は、 DEUNAオーケストレーション.