Integrating Athia
On this page
Athia needs two things from you: live or recurrent transaction data, so it can operate against what is happening now, and a historical dump, a one-time backfill, so your baselines come from your own population. The history has to be attempt-level: every attempt, not every approved order, with declines, retries, 3DS outcomes, settlement and disputes where you have them. On DEUNA orchestration both already exist; otherwise start with what you can send today and add to it later.
Two layers: intelligence and execution#
Athia works in two layers; you do not need both.
- Intelligence, Strategist, the smart dashboards and Ask Athia, running on the data you send whatever path it arrives by, even with no transaction ever routed through DEUNA orchestration.
- Execution, agents acting on a transaction: in real time inside the payment flow through DEUNA orchestration (routing, message composition and retries), or in batch by scoring scheduled recurring charges before they run.
The question is where your data lives, not which tier you are on. All four answers deliver the full intelligence layer. Only DEUNA orchestration lets agents decide inside the payment flow in real time, though batch execution for recurring billing rides the file path. The paths combine, and Athia deduplicates across them, so more coverage sharpens the answers rather than gating them.
How much history to send#
| History sent | What it buys you |
|---|---|
| One month | Little more than a snapshot |
| Three months | Usable baselines |
| Six months | Typical for a first use case |
| Twelve months | Seasonality and the full chargeback cycle |
Chargebacks arrive 30 to 180 days after the transaction, so twelve months is the minimum where disputes are in scope. For a first proof of concept, 30 to 90 days of the right fields, transactions, decline codes and BIN, beats a year of the wrong ones.
The minimum to start
The minimum that switches a use case on: transaction_id or order_id, an attempt_id linking attempts to one order, amount, currency, a UTC auth_timestamp and the transaction status. Then the decline signal, which is what makes the data intelligent rather than descriptive: processor_id, decline_code_raw, auth_code on approvals, gateway_txn_id and retry_sequence with parent_txn_id.
You need not rename columns; your Athia team maps yours on ingest. The full field specification is in Athia Data Dictionary.
Integration paths#
Every path delivers the full intelligence layer; only DEUNA orchestration lets agents execute inside the payment flow.
| Path | What it is | Who sets it up | Freshness |
|---|---|---|---|
| DEUNA Orchestration | Athia reads what DEUNA already processes | Nobody | Live |
| Offline Data Transfer | Files you deliver, or a read grant on your warehouse or data lake | Your data team or warehouse admin | Per delivery or per read |
| Provider Connectors | Athia polls your providers, or receives their webhooks | Your Athia team, with a credential you issue | Near real time for transactional data, bounded by the provider |
Combining paths#
Athia deduplicates across paths on transaction and attempt identifiers, so overlapping coverage is safe, the same transaction from a connector and a warehouse view is one record, not two. Cost data arrives separately, as an in-product CSV upload against an Athia template.
Security and compliance#
Athia runs on DEUNA's platform security controls, access control, encryption, monitoring, incident response, documented in DEUNA platform security. Full card numbers and CVV are never collected on any path: cards are BIN plus last four digits, plus expiry, fingerprint or PAR where available, and CVV and AVS only as match / no-match response codes, so exclude full PAN columns before delivery. Personal identifiers may be hashed, tokenized or generalized; residency is scoped at setup; a data processing agreement precedes any transfer.