Full volume against a slice

--- updatedAt: 2026-08-08T01:31:50.000Z agentTools: projectIndex: https://docs.deuna.com/llms.txt --- # 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](https://docs.deuna.com/docs/athia-integration) 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](https://docs.deuna.com/docs/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 ```mermaid 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
the orchestration decision.
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](https://docs.deuna.com/docs/athia-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](https://docs.deuna.com/docs/athia-integration). 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](https://docs.deuna.com/docs/athia-integration). ## 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](https://docs.deuna.com/docs/athia) for how a recommendation reaches an MIT or a CIT transaction when DEUNA is not in the path, and [Acceptance Agent](https://docs.deuna.com/docs/athia-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. 1. **Confirm your orchestration setup.** DEUNA checks it with you. 2. **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](https://docs.deuna.com/docs/athia-integration). 3. **Load history.** Athia needs a historical dump to learn your baselines before the agent acts, and DEUNA works with your team on the delivery. 4. **Prove it before it carries volume.** How that is done depends on your scope, and is set out under [going live](https://docs.deuna.com/docs/athia-acceptance-agent#going-live). ## The orchestration integration itself Documented in the DEUNA developer docs: * [DEUNA Payments](https://docs.deuna.com/docs/deuna-payments), what the orchestration platform does * [Integrate DEUNA's orchestration platform](https://docs.deuna.com/docs/integrate-deuna), the integration itself