Orquestación de DEUNA
Comprender cómo los datos de orquestación existentes de DEUNA permiten a Athia sin una integración adicional de datos de comerciantes.
En esta página
Esta página está destinada a los comerciantes que desean utilizar Athia y la orquestación de DEUNA juntos. Si DEUNA no forma parte de su flujo de pagos, la capa de inteligencia sigue funcionando completamente con los datos que envía; comience con Integración de Athia instead.
Los datos de nivel de intento que necesita Athia se generan por sí mismo la capa de orquestación, y los agentes actúan en las mismas vías. No hay archivos que entregar, no se requiere acceso a almacén y no hay credenciales del proveedor que emitir.
Esta página cubre la capa de ejecución de Athia, los agentes que toman decisiones dentro del flujo de pagos. La capa de inteligencia de Athia, que se cubre en Características de Athia, funciona con los datos que envía, independientemente del camino, y no depende de nada que se describa aquí.
Cómo funcionan los agentes en su tráfico#
El agente se consulta dentro de la decisión de orquestación, y no como una llamada de servicio separada. Las transacciones entran en la orquestación de DEUNA a través del tipo de integración que haya elegido.
Las decisiones del agente se basan en resultados reales, en lugar de reglas que alguien debe mantener. Agente de Aceptación Utiliza aprendizaje automático y aprendizaje por refuerzo para decidir transacción por transacción, en tiempo real.
Siempre en modo de fallo, según sus propias reglas. Si un agente no responde dentro de su presupuesto de latencia, la transacción se envía a la configuración de regla estática que ya tiene en la orquestación de DEUNA. Esa configuración es suya, permanece en su lugar, independientemente de si un agente está activo, y es lo que la transacción vuelve a utilizar. Nunca hay un agente que pueda bloquear un pago, y ningún fallo deja una transacción sin una decisión de enrutamiento.
¿Qué porcentaje de su volumen enruta?#
No tiene que mover todo de una vez, y la mayoría de los comerciantes no lo hacen.
Todos los intentos pasan por DEUNA
Athia visualiza intentos, rechazos, reintentos, enrutamiento y resultados de liquidación en un solo flujo. No existe una ruta de ingestión de historial de pagos separada para operar.
DEUNA solo ve la porción enrutada
El tráfico enviado directamente a tus procesadores es invisible hasta que lo ingieres. DEUNA puede ejecutar la función de recuperación o prueba, pero Athia necesita el contexto fuera de línea para comparar la población completa correctamente.
Para cualquier configuración parcial, ese contexto ingerido por separado es el tráfico que nunca llegó a DEUNA.
| A. Volumen total | B. Una parte del volumen | |
|---|---|---|
| Volumen enrutado a DEUNA | Todo | Una porción definida |
| Lo que ve Athia | Cada intento, rechazo, reintento y liquidación | Solo la porción que enruta |
| Lo que debe ingerir | Nada | El contexto alrededor de la porción |
| Opciones de optimización | Selección de procesador, reintento, configuración de mensajes | Las opciones que se aplican a la porción |
A. Volumen total a través de la orquestación de DEUNA
Todo su tráfico fluye a través de las tuberías de DEUNA, por lo que tanto el procesamiento como el enrutamiento son superficies de optimización. Athia ve cada intento, cada rechazo, cada reintento y cada liquidación sin que necesite realizar ningún trabajo de ingestión.
B. Una parte del volumen a través de la orquestación de DEUNA
Dos formas son comunes, y ambas son pilotos que crecen.
Rechazos suaves solamente. Su procesador principal mantiene los primeros intentos, y la orquestación de DEUNA recibe los rechazos suaves para la recuperación. El punto de partida más estrecho posible: DEUNA solo toca transacciones que su propia pila ya ha abandonado.
Un experimento A/B. Una parte de su tráfico enruta a la orquestación de DEUNA y el resto permanece en su configuración actual, por lo que se comparan de forma similar en su propio volumen en lugar de contra un punto de referencia. La parte se acuerda con usted y solo se mueve cuando los resultados lo demuestran.
El contexto mínimo para una configuración de rechazo suave o reintento solamente, por intento original:
| campo | Tipo | Descripción |
|---|---|---|
payment_transaction_id | String | Identificador del intento original, utilizado para vincular el reintento a él |
psp_name | String | Proveedor al que se envió el intento original |
psp_error_code | String | Código de rechazo del proveedor |
psp_error_message | String | Texto de la razón del rechazo del proveedor |
payment_amount | decimales | Monto de la operación |
currency_code | String | Código de moneda ISO 4217 |
card_bin | String | Número BIN de la tarjeta, los primeros seis o ocho dígitos |
last_four_digits | String | Los últimos cuatro dígitos de la tarjeta |
payment_timestamp | Cadena de texto ISO 8601 | Hora del intento original, en UTC |
Estos son los nombres que utiliza Athia; envíe los equivalentes de sus propios sistemas y su equipo de Athia los mapeará.
Para un experimento A/B, el requisito es más amplio: Athia necesita la rama de control también, al mismo nivel de detalle, o las ramas no son comparables. Su equipo de Athia acuerda el conjunto de campos con usted antes de que comience el experimento.
Ingiere ese contexto a través de cualquier camino en Integración de Athia.
Si no enruta a través de la orquestación de DEUNA#
Cadena Athía Cadena Agente de Aceptación Cadena
Comenzar#
Cadena
- Confirme su configuración de orquestación. DEUNA lo verifica con usted.
- Monto del intento Cadena Integración de Athia.
- Cadena BIN de la tarjeta, los primeros seis o ocho dígitos
- Cadena Cómo se hace depende de su alcance, y se describe en Cadena ISO 8601.
La integración de orquestación en sí#
documentada en la documentación de desarrolladores de DEUNA:
- Pagos DEUNA, lo que hace la plataforma de orquestación
- Integrar la plataforma de orquestación de DEUNA, la integración en sí