Agent d'optimisation de l'acceptation

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

This page covers Athia's execution layer, the agent acting inside the payment flow. Athia's intelligence layer, covered in Caractéristiques d'Athia, s'exécute sur les données que vous envoyez, quel que soit le chemin par lequel elles arrivent, que vous déployiez ou non un agent.

Comment l'agent décide#

Le cycle de vie d'une transaction, depuis la décision de l'agent jusqu'au résultat qui entraîne la suivante. Le chemin en pointillés est la route d'ouverture en cas d'échec.

Chaque décision part de la même image : la carte et son BIN, la banque émettrice, le montant et la devise, ce que ce client a fait avec vous auparavant, l'heure de la journée et ce qui s'est passé la dernière fois qu'une transaction ressemblant à celle-ci a été envoyée. L'agent pèse tout cela et apprend quelles parties sont importantes pour lui. votre le trafic, qui est rarement le même que ce qui compte en général.

Commencez avec trois que vous pouvez voir se produire.

Quel processeur obtient la transaction

Une table de routage statique envoie un segment entier à un processeur et continue à l'envoyer jusqu'à ce que quelqu'un le modifie. L'agent ne tient aucune table. Il apprend quel processeur gagne réellement pour chaque combinaison de carte, de banque émettrice et de montant, et il conserve cette vue pour chaque combinaison à la fois, actualisée par chaque résultat qui revient. Lorsqu'un processeur commence discrètement à refuser un segment qu'il avait l'habitude d'approuver, le trafic se déplace avant que quiconque ait ouvert un tableau de bord.

Comment est composé le message de paiement

Certains types de cartes et certaines banques n'approuvent que lorsque le message est rédigé exactement comme prévu, et qu'un champ erroné revient, ressemblant à un refus ordinaire. Personne ne publie ces règles. L'agent les trouve dans vos propres données de refus et corrige le message lors de sa sortie, sans rien à écrire ni aucune autorisation à expédier.

Si un refus vaut la peine d'être réessayé

Une règle de nouvelle tentative traite chaque refus de la même manière et dépense des frais de traitement sur les transactions qui ne revenaient jamais. L'agent lit un refus pour ce qu'il signifie réellement, réessaye ceux qui valent la peine d'être réessayés, choisit le moment et laisse passer le reste. Une nouvelle tentative nécessaire est décidée avec fraîcheur plutôt que ressentiment.

Ces trois éléments sont tout simplement les plus faciles à exprimer. L’agent est un modèle unique, et ce qu’il pèse pour parvenir à l’un d’entre eux est bien plus large que ne le suggèrent les trois descriptions. Il ne cesse également de s’élargir, car chaque résultat lui enseigne quelque chose qu’aucune règle n’aurait été écrite pour rechercher. Demandez à votre équipe Athia ce qu’elle décide aujourd’hui concernant votre compte.

Comment le déployer#

Qui détient quoi dans chaque déploiement. La flèche épaisse marque le rappel de statut que possède le commerçant.

Entièrement automatisé

Intégrez une fois avec la caisse DEUNA ou l’orchestration des paiements. L'agent est consulté dans le cadre de la décision d'orchestration plutôt que dans le cadre d'un appel de service distinct. Il n'y a donc aucun saut supplémentaire dans votre chemin d'autorisation et aucun travail d'intégration ML de votre part. DEUNA gère les connexions du processeur et l'agent couvre chaque transaction. Commencez par Intégrez la plateforme d'orchestration de DEUNA et le Aperçu des paiements DEUNA.

Lot

Pour facturation récurrente initiée par le commerçant (MIT), et pas en temps réel. Vous fournissez un fichier de frais planifiés avant qu'ils ne soient traités, l'agent note chaque ligne et un fichier de résultats revient.

Ce que vous envoyez, par frais programmés

Ce qui revient, par ligne

Appliquez le fichier avec vos propres connexions de processeur ou demandez à DEUNA d'exécuter les paiements. L'agent est formé sur vos données historiques avant le lancement.

Ce que l'agent doit apprendre#

L'agent est pré-formé sur votre propre historique, un vidage de l'historique des transactions est donc requis avant sa mise en ligne. Les chemins pour le livrer sont en Intégrer Athia, et les champs qu'il attend sont définis dans Dictionnaire de données Athia.

Après le lancement, les résultats doivent continuer à revenir continuellement. Ceci est automatique lorsque DEUNA traite le paiement, car DEUNA voit le résultat. Lorsque vous continuez l'exécution, y compris par lots, la publication du statut de chaque transaction que l'agent a notée à DEUNA relève de votre responsabilité, sinon ses décisions cessent de s'améliorer.

En direct#

DEUNA réalise ces étapes avec vous. A chaque fois, DEUNA apporte les preuves et vous décidez si vous souhaitez aller plus loin. Vous approuvez une lecture et n'exploitez pas un cadre de test.

1. Vous fournissez vos données historiques et DEUNA confirme avec vous la couverture du terrain par rapport au dictionnaire de données.
2. Vous choisissez un déploiement et DEUNA complète l'intégration avec votre équipe, y compris le rappel de statut partout où vous maintenez l'exécution du paiement.
3. Vous voyez le jugement de l'agent avant qu'il ne porte du volume. La manière d’y parvenir dépend du déploiement, et les deux ne constituent pas le même exercice. Voir ci-dessous.
4. Une fois que vous avez approuvé ces preuves, DEUNA passe à un expérience contrôlée sur le volume en direct, les cohortes de contrôle et de traitement avec des pondérations de trafic que vous acceptez, déplacées progressivement à mesure que les résultats se maintiennent.

À quoi ressemble l'étape 3, par déploiement

Le comportement d'exécution de chaque décision est documenté dans Orchestration DEUNA.