Acceptance Agent
The Acceptance Agent is the Athia agent that maximizes authorization success. It acts on every transaction in real time, using machine learning and reinforcement learning to decide rather than following rules someone maintains, and every outcome that comes back updates it, so its decisions stay current as issuer behavior and your traffic mix shift. This page covers Athia's execution layer, the agent acting inside the payment flow. Athia's intelligence layer, covered in Athia Features, runs on the data you send whatever path it arrives by, whether or not you ever deploy an agent.
How the agent decides
The two deployments differ in one thing: who posts the outcome back. In the fully automated path the agent is consulted inside the orchestration call, so there is no separate service in the payment path. When DEUNA holds the processor connections, outcomes return on their own. In batch, the scored file is run by you or by DEUNA, and the agent stops improving the moment status stops coming back. Batch is for merchant-initiated recurring billing, not for checkout traffic.
The lifecycle of one transaction, from the agent's decision to the outcome that trains its next one. The dashed path is the fail-open route.
Every decision starts from the same picture: the card and its BIN, the issuing bank, the amount and currency, what this customer has done with you before, the time of day, and what happened the last time a transaction that looked like this one was sent. The agent weighs all of it, and it learns which parts of it matter for your traffic, which is rarely the same as what matters in general.
Start with three you can watch happen.
Which processor gets the transaction
A static routing table sends a whole segment to one processor and keeps sending until someone edits it. The agent holds no table. It learns which processor actually wins for each combination of card, issuing bank and amount, and it holds that view for every combination at once, refreshed by every result that comes back. When a processor quietly starts declining a segment it used to approve, traffic moves before anyone has opened a dashboard.
How the payment message is composed
Certain card types and banks approve only when the message is composed exactly the way they expect, and one wrong field comes back looking like an ordinary decline. Nobody publishes those rules. The agent finds them in your own decline data and corrects the message on its way out, with nothing for you to write and no release to ship.
Whether a decline is worth retrying
A retry rule treats every decline alike and spends processing fees on transactions that were never coming back. The agent reads a decline for what it actually means, retries the ones worth retrying, picks the moment, and lets the rest go. A retry it does take is decided fresh rather than resent.
Those three are simply the easiest to put into words. The agent is a single model, and what it weighs to arrive at any one of them runs a good deal wider than the three descriptions suggest. It also keeps widening, because every outcome teaches it something no rule would have been written to look for. Ask your Athia team what it is deciding on your account today.
How you deploy it
The two deployments differ in one thing: who posts the outcome back. In the fully automated path the agent is consulted inside the orchestration call, so there is no separate service in the payment path. When DEUNA holds the processor connections, outcomes return on their own. In batch, the scored file is run by you or by DEUNA, and the agent stops improving the moment status stops coming back. Batch is for merchant-initiated recurring billing, not for checkout traffic.
Who holds what in each deployment. The thick arrow marks the status callback the merchant owns.
| Fully automated | Batch | |
|---|---|---|
| Who executes the payment | DEUNA | You, or DEUNA on your behalf |
| What you integrate | DEUNA checkout or payments orchestration | A file exchange, no integration |
| Latency | Real time, inside the payment flow | Not real time; run before billing |
| Scope | All transactions | MIT recurring billing only |
| Processor connections | Managed by DEUNA | Yours, or DEUNA's |
Fully automated
Integrate once with DEUNA checkout or payments orchestration. The agent is consulted inside the orchestration decision rather than as a separate service call, so there is no extra hop in your authorization path and no ML integration work on your side. DEUNA manages the processor connections and the agent covers every transaction. Start with Integrate DEUNA's orchestration platform and the DEUNA Payments overview.
Batch
For merchant-initiated (MIT) recurring billing, and not real time. You deliver a file of scheduled charges before they are processed, the agent scores every row, and a result file comes back.
What you send, per scheduled charge
| Field | Type | Description |
|---|---|---|
merchant_reference | String | Your identifier for the charge, echoed back on the result row |
card_bin | String | Card BIN, first six or eight digits |
last_four_digits | String | Last four digits of the card |
issuing_bank | String | Issuing bank, where you have it |
payment_amount | Decimal | Scheduled amount, in major units |
currency_code | String | ISO 4217 currency code |
scheduled_date | ISO 8601 string | When the charge is due, UTC |
What comes back, per row
| Field | Description |
|---|---|
merchant_reference | Your identifier, unchanged, so you can join the result to your record |
recommended_processor | The processor most likely to approve this charge |
message_configuration | How to compose the payment message for that processor |
retry_guidance | Whether and when to retry if it declines |
expected_approval_rate | The agent's expectation for this row, so you can sort by it |
Apply the file with your own processor connections, or have DEUNA run the payments. The agent is trained on your historical data before launch.
This schema is a proposal, not a fixed contract. It is where the conversation starts, not a specification you have to build to. Send what your systems already produce, under whatever names they already use. Your Athia team maps your columns on ingest, agrees the file format and cadence with you, and works through the integration alongside your team. If a field is expensive for you to produce, say so during scoping rather than building around it.
What the agent needs to learn
The agent is pre-trained on your own history, so a historical transaction dump is required before it goes live. The paths for delivering it are in Integrating Athia, and the fields it expects are defined in Athia Data Dictionary.
After launch, outcomes must keep flowing back continuously. This is automatic when DEUNA processes the payment, because DEUNA sees the result. Where you keep execution, including batch, posting the status of every transaction the agent scored back to DEUNA is your responsibility, or its decisions stop improving.
Going live
DEUNA runs these steps with you. At each one DEUNA brings the evidence and you decide whether to go further. You are approving a readout, not operating a testing framework.
- You deliver your historical data, and DEUNA confirms field coverage with you against the data dictionary.
- You choose a deployment, and DEUNA completes the integration with your team, including the status callback wherever you keep payment execution.
- You see the agent's judgment before it carries volume. How that is done depends on the deployment, and the two are not the same exercise. See below.
- Once you approve that evidence, DEUNA moves to a controlled experiment on live volume, control and treatment cohorts with traffic weights you agree, shifted gradually as results hold.
What step 3 looks like, by deployment
| Deployment | How the agent is proven before it carries volume |
|---|---|
| Fully automated | Shadow mode. The agent scores your live traffic and records the decision it would have made, while DEUNA orchestration submits the transaction on your existing static rule configuration. The payment is processed normally; what is withheld is the agent's decision, not the transaction. You compare the two afterwards on your own volume. |
| Batch | A scored file you do not apply. The agent scores a real file of scheduled charges and returns the result, and you run the charges your usual way. The comparison is the same, but nothing is live at any point because the file is decided ahead of billing. |
Runtime behavior for each decision is documented in DEUNA Orchestration.
Fail open. If the agent does not answer inside its latency budget, the transaction proceeds on your static rule configuration. A slow or unavailable agent never blocks a payment.
Updated about 23 hours ago