Integrating Athia
Choose a supported Athia data-ingestion path, prepare historical and recurrent transaction data, and validate coverage.
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.
Already in DEUNA
No data build is required. Athia can use the existing payment history for intelligence and execute decisions directly in the live orchestration flow.
Files
Deliver scheduled attempt-level data through SFTP or S3. Athia uses it for intelligence and can return batch decisions for recurring billing.
Warehouse
Connect Snowflake, Databricks, BigQuery, or Redshift so Athia can build intelligence from governed warehouse data.
Providers
Authorize supported processors and platforms so Athia can poll the required history with merchant-provided credentials.
You can combine paths. Athia reconciles overlapping records by stable attempt identifiers and timestamps. Provide processor-cost data separately with the agreed cost template so financial recommendations use your actual economics.
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.