DEUNA Orchestration

📘
If you use DEUNA's orchestration product, there is no additional development needed to enable Athia.

This page is for merchants who want to use Athia and DEUNA orchestration together. If DEUNA is not in your payment path, the intelligence layer still works in full on the data you send; start at Integrating Athia instead.

The attempt-level data Athia needs is produced by the orchestration layer itself, and agents act on the same rails. There are no files to deliver, no warehouse access to grant and no provider credentials to issue.

This page covers Athia's execution layer, agents deciding inside the payment flow. Athia's intelligence layer, covered in Athia Features, runs on the data you send by any path and does not depend on anything described here.

How agents run on your traffic

sequenceDiagram
    participant M as Merchant
    participant O as DEUNA orchestration with Athia agents
    participant P as Processor
    M->>O: Sends the payment request
    Note over O: The agent is consulted inside<br/>the orchestration decision.<br/>One service, one call.
    alt The agent answers inside its latency budget
        O->>P: Submits on the agent decision
    else The agent times out or is unavailable
        O->>P: Submits on your static rule configuration
    end
    P-->>O: Returns the outcome
    O-->>M: Returns the result
    Note over O: The outcome trains the next decision

The agent is consulted inside the orchestration decision, not as a separate service call. Transactions enter DEUNA orchestration through whichever integration type you have chosen.

The agent's decisions update from real outcomes rather than from rules someone has to maintain. The agent live today is Acceptance Agent. It uses machine learning and reinforcement learning to decide transaction by transaction, in real time.

Fail-open always, onto your own rules. If an agent does not answer inside its latency budget, the transaction is submitted on the static rule configuration you already have in DEUNA orchestration. That configuration is yours, it stays in place whether or not an agent is running, and it is what the transaction falls back to. No agent is ever in a position to block a payment, and no failure leaves a transaction without a routing decision.

How much of your volume you route

You do not have to move everything at once, and most merchants do not.

Full volume against a slice

Two pilot shapes are common: soft declines only, where DEUNA touches nothing your own stack has not already given up on, and an A/B split measured on your own volume. Both need the transactions that never reached DEUNA. Without them a soft-decline pilot is a model reasoning about failures with no view of the successes, and an A/B test has only one arm.

Visible to AthiaBlind spotContext you ingest separately

For any partial setup, that separately ingested context is the traffic that never reached DEUNA.

	A. Full volume	B. A portion of volume
Volume routed to DEUNA	All of it	A defined slice
What Athia sees	Every attempt, decline, retry and settlement	Only the slice you route
What you must ingest	Nothing	The context around the slice
Optimization levers	Processor selection, retry, message configuration	The levers that apply to the slice

A. Full volume through DEUNA orchestration

All of your traffic flows through DEUNA's pipes, so processing and routing are both optimization surfaces. Athia sees every attempt, every decline, every retry and every settlement with no ingestion work on your side.

B. A portion of volume through DEUNA orchestration

Two shapes are common, and both are pilots that grow.

Soft declines only. Your primary processor keeps first attempts, and DEUNA orchestration receives the soft declines for recovery. The narrowest possible start: DEUNA only ever touches transactions your own stack has already given up on.

An A/B experiment. A share of your traffic routes to DEUNA orchestration and the rest stays on your current configuration, so the two are compared like for like on your own volume rather than against a benchmark. The share is agreed with you and moves only as results hold.

📘
Both shapes need the offline transactions. DEUNA only sees what DEUNA processes. For the agent to keep training, and for the comparison to be honest, the transactions that did not go through DEUNA have to reach Athia by one of the paths on Integrating Athia. Without them, a soft-decline pilot is a model reasoning about failures with no view of the successes, and an A/B test has only one arm.

Minimum context for a soft-decline or retry-only setup, per original attempt:

Field	Type	Description
`payment_transaction_id`	String	Identifier of the original attempt, used to link the retry back to it
`psp_name`	String	Provider the original attempt was sent to
`psp_error_code`	String	Provider decline code
`psp_error_message`	String	Provider decline reason text
`payment_amount`	Decimal	Attempt amount
`currency_code`	String	ISO 4217 currency code
`card_bin`	String	Card BIN, first six or eight digits
`last_four_digits`	String	Last four digits of the card
`payment_timestamp`	ISO 8601 string	Time of the original attempt, UTC

These are the names Athia uses; send the equivalent from your own systems and your Athia team maps them.

For an A/B experiment the requirement is wider: Athia needs the control arm too, at the same grain, or the arms are not comparable. Your Athia team agrees the field set with you before the experiment starts.

Ingest that context through any path on Integrating Athia.

If you do not route through DEUNA orchestration

The full intelligence layer is available on every integration path. Strategist, smart dashboards and Ask Athia run on the data you send, so you get all of it without routing a single transaction through DEUNA orchestration. Routing is what adds execution inside the payment flow, and one execution shape, batch, is available outside it as a file exchange with no integration and no change to how you route. See Athia for how a recommendation reaches an MIT or a CIT transaction when DEUNA is not in the path, and Acceptance Agent for the batch file itself.

Getting started

DEUNA works through these steps with you. At each one DEUNA brings the evidence and you decide whether to go further.

Confirm your orchestration setup. DEUNA checks it with you.
Decide the scope. Full volume, a soft-decline slice, or an A/B experiment. If anything stays outside DEUNA, DEUNA identifies the context Athia is missing with you and agrees an ingestion path from Integrating Athia.
Load history. Athia needs a historical dump to learn your baselines before the agent acts, and DEUNA works with your team on the delivery.
Prove it before it carries volume. How that is done depends on your scope, and is set out under going live.

The orchestration integration itself

Documented in the DEUNA developer docs:

DEUNA Payments, what the orchestration platform does
Integrate DEUNA's orchestration platform, the integration itself