Agente di Ottimizzazione dell'Accettazione
Migliora i risultati di autorizzazione attraverso il routing, i messaggi di pagamento e le decisioni di retry.
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
Questa pagina copre il livello di esecuzione di Athia, l'agente che opera all'interno del flusso di pagamento. Il livello di intelligenza di Athia, trattato in Funzionalità di Athia, corre sui dati che invii qualunque percorso arrivi, sia che tu abbia mai implementato un agente.
Come decide l'agente#
DEUNA fornisce la carta, il BIN, l'emittente, l'importo, la valuta, la cronologia del cliente, l'ora e i risultati comparabili disponibili per la transazione.
Athia seleziona il percorso, il messaggio di pagamento e il comportamento di retry. Se supera il proprio budget di latenza, DEUNA applica le tue regole statiche.
DEUNA esegue il percorso selezionato senza aggiungere una seconda chiamata al servizio del lato merchant.
Il risultato del processore viene restituito tramite l'orchestrazione e migliora la decisione successiva.
Il ciclo di vita di una transazione, dalla decisione dell'agente al risultato che la allena, rappresenta un percorso completamente automatizzato. Le regole statiche rimangono il percorso di fallback durante l'intero flusso.
Ogni decisione parte dalla stessa immagine: la carta e il suo BIN, la banca emissione, la somma e la valuta, ciò che questo cliente ha fatto con voi prima, il tempo del giorno, e ciò che è accaduto l'ultima volta che una transazione che sembrava come questa è stata inviata. L'agente pesa tutto, e impara quali parti di esso importa per il tuo traffico, che è raramente lo stesso di ciò che conta in generale.
Inizia con tre puoi guardare accadere.
Quale processore ottiene la transazione
Una tabella di routing statico invia un intero segmento a un processore e continua a inviare fino a quando qualcuno lo modifica. L'agente non ha tavolo. Impara quale processore vince effettivamente per ogni combinazione di carta, emissione di banca e importo, e tiene quella vista per ogni combinazione subito, rinfrescata da ogni risultato che torna. Quando un processore inizia tranquillamente a diminuire un segmento che ha usato per approvare, il traffico si muove prima che qualcuno abbia aperto una dashboard.
Come si compone il messaggio di pagamento
Alcuni tipi di carte e banche approvano solo quando il messaggio è composto esattamente come si aspettano, e un campo sbagliato torna a guardare come un declino ordinario. Nessuno pubblica queste regole. L'agente li trova nei dati del tuo declino e corregge il messaggio sulla sua uscita, con nulla per voi di scrivere e nessuna release per spedire.
Se un declino vale la pena di riprovare
Una regola di retry tratta tutte le rimesse negative allo stesso modo e spende le commissioni per le transazioni che non vengono mai completate. L'agente legge ogni rimesse negativa e determina se è opportuno tentare di completarla, scegliendo il momento giusto e lasciando perdere quelle non valide. Il retry viene deciso in modo dinamico, non in base a regole predefinite.
Questi tre aspetti sono i più semplici da descrivere. L'agente è un modello unico, e i fattori che influenzano la sua decisione per ogni rimesse sono più ampi di quanto suggeriscano le tre descrizioni. Inoltre, l'agente continua ad apprendere, perché ogni risultato fornisce nuove informazioni. Chiedete al vostro team Athia come decide per il vostro account.
Come implementarlo#
Decisione ed esecuzione all'interno dell'orchestrazione
Il tuo checkout invia una singola richiesta a DEUNA. Athia sceglie il processore, il messaggio e il comportamento di retry; DEUNA esegue il pagamento e restituisce automaticamente il risultato. Non è necessario alcun postback dal merchant.
File di decisione per addebiti ricorrenti
Per addebiti programmati dal merchant, invia il file di addebito per la valutazione. Athia restituisce il processore, le indicazioni per il messaggio e il retry, e il tasso di approvazione previsto. Il tuo sistema o DEUNA eseguono i pagamenti e il merchant restituisce lo stato finale.
La principale differenza operativa è la proprietà del risultato: DEUNA lo restituisce automaticamente nel percorso completamente automatizzato; il merchant deve restituirlo in batch.
| Automazione completa | Batch | |
|---|---|---|
| Chi esegue il pagamento | DEUNA | Voi, o DEUNA per vostro conto |
| Cosa integrate | DEUNA checkout o orchestrazione dei pagamenti | Uno scambio di file, senza integrazione |
| Latenza | In tempo reale, durante il flusso di pagamento | Non in tempo reale; prima dell'elaborazione |
| Ambito | Tutte le transazioni | MIT (Recurring Billing) solo |
| Connessioni con i processori | Managed by DEUNA | Vostre, o DEUNA |
Automazione completa
Integrate con DEUNA checkout o orchestrazione dei pagamenti. L'agente viene consultato all'interno dell'orchestrazione, anziché come una chiamata di servizio separata, quindi non ci sono ulteriori passaggi nel vostro percorso di autorizzazione e non è necessario alcun lavoro di integrazione ML. DEUNA gestisce le connessioni con i processori e l'agente gestisce ogni transazione. Iniziate con l'integrazione della piattaforma di orchestrazione DEUNA e la panoramica dei pagamenti DEUNA.
Batch
per **pagamenti ricorrenti avviati dal cliente (MIT)**e non in tempo reale. Fornite un file con gli importi programmati prima che vengano elaborati, l'agente valuta ogni riga e restituisce un file di risultati.
Cosa inviate, per ogni importo programmato
| Campo | Tipo | Descrizione |
|---|---|---|
merchant_reference | String | Il vostro identificatore per l'importo, ripetuto nella riga di risultato |
card_bin | String | BIN della carta, i primi sei o otto cifre |
last_four_digits | String | Gli ultimi quattro cifre della carta |
issuing_bank | String | La banca emittente, dove è stata rilasciata |
payment_amount | Decimale | L'importo programmato, in unità principali |
currency_code | String | Codice di valuta ISO 4217 |
scheduled_date | Stringa ISO 8601 | Quando è previsto il pagamento, in UTC |
Cosa viene restituito, per riga
| Campo | Descrizione |
|---|---|
merchant_reference | Il vostro identificatore, invariato, in modo da poter collegare il risultato al vostro record |
recommended_processor | Il processore più probabile per approvare questa transazione |
message_configuration | Come comporre il messaggio di pagamento per quel processore |
retry_guidance | Se e quando tentare di ripetere in caso di rifiuto |
expected_approval_rate | L'aspettativa dell'agente per questa riga, in modo da poterla ordinare in base a essa |
Utilizzate il file con le vostre connessioni ai processori, oppure lasciate che DEUNA esegua i pagamenti. L'agente viene addestrato sui vostri dati storici prima del lancio.
Cosa deve imparare l'agente#
L'agente è pre-trained sulla tua storia, quindi è necessario un dump di transazione storica prima che vada in diretta. I percorsi per consegnarlo sono in Integrazione di Athia, e i campi che si aspettano sono definiti in Athia Data Dictionary.
Dopo il lancio, i risultati devono continuare a scorrere continuamente. Questo è automatico quando DEUNA elabora il pagamento, perché DEUNA vede il risultato. Dove si mantiene l'esecuzione, compreso il lotto, postando lo stato di ogni transazione l'agente ha segnato di nuovo a DEUNA è la vostra responsabilità, o le sue decisioni smettere di migliorare.
Vai in diretta#
La DEUNA fa questi passi con te. A ogni DEUNA porta le prove e decide se andare oltre. Stai approvando una lettura, non funzionando un quadro di prova.
- Consenti i tuoi dati storici e DEUNA conferma la copertura del campo con te contro il dizionario dati.
- Scegli una distribuzione e DEUNA completa l'integrazione con il tuo team, incluso il callback di stato ovunque tu mantieni l'esecuzione dei pagamenti.
- Vedete il giudizio dell'agente prima che porti volume. Il modo in cui si fa dipende dal dispiegamento, e i due non sono lo stesso esercizio. Vedi di seguito.
- Una volta approvata questa prova, la DEUNA si trasferisce ad una esperimento controllato su volume vivo, controllo e coorte di trattamento con i pesi del traffico si accetta, spostato gradualmente come i risultati tengono.
Quale passo 3 sembra, spiegando
| Distribuzione | Come l'agente è dimostrato prima che trasporta volume |
|---|---|
| Automazione completa | Modalità ombra. L'agente segna il traffico dal vivo e registra la decisione che avrebbe preso, mentre l'orchestrazione DEUNA presenta la transazione sulla configurazione delle regole statiche esistenti. Il pagamento viene elaborato normalmente; ciò che viene tenuto è la decisione dell'agente, non la transazione. Si confrontano i due dopo sul proprio volume. |
| Batch | Un file segnato che non si applica. L'agente segna un vero file di spese programmate e restituisce il risultato, e si esegue le spese il vostro modo solito. Il confronto è lo stesso, ma nulla è vivo in qualsiasi momento perché il file è deciso prima di fatturazione. |
Il comportamento di runtime per ogni decisione è documentato DEUNA Orchestration.