Athia Connectors
On this page
Athia is not limited to a list of supported processors. If your provider can produce the data, Athia can read it. Nothing about your processing stack has to Athia needs your payment data. It does not need a particular way of getting it.
Most clients send it from their warehouse or as scheduled file exports, and that is the path we recommend. It works for every processor you use, it is one path rather than one connection per provider, and it does not depend on what any provider chooses to expose.
Direct provider connectors exist as a convenience where they save your data team an export. They are an option, not a requirement, and nothing in Athia works differently depending on which path the data arrived by.
The recommended path#
Send Athia the data you already hold, either as a read grant on your warehouse or data lake, or as files delivered to SFTP or S3.
- It covers every processor at once, including any that has no connector.
- One specification, one delivery, rather than a separate credential and a separate console per provider.
- History and the live feed come from the same place, so there is no separate backfill to arrange.
- Your field names stay yours. Your Athia team maps them on ingest.
See Offline Data Transfer for how to set it up.
Direct provider connectors#
Where a provider exposes a reporting credential, Athia can read from it directly instead. This saves your data team the export, and for transactional data it can be fresher than a scheduled delivery. It reads only: no connector can authorize, capture, refund or void a payment.
You issue a read-only credential in the provider's own console and paste it into Athia under Settings → Connections → Add Connection. Name the connection, set the Schedule, paste the credential, and click Verify Connection. Each provider's manual gives the exact console path, the scopes and the fields, because credential requirements are not the same twice.
Connect it yourself: Stripe, Adyen, Braintree, Checkout.com, PayPal Direct, EBANX, PPRO.
Set up with your Athia team, because they deliver by file or need account-side provisioning: Amex, Worldpay, Chase, dLocal.
If your provider is not listed#
This is routine, and it is not a limitation.
Your Athia team works directly with your data and engineering teams to agree what you can export and how it reaches us, then maps your fields on ingest. There is no schema for you to conform to first and no waiting on the provider to grant anything. Once the data lands, every Athia capability behaves exactly as it would on a direct connection.
If a connector for that provider appears later, moving to it changes nothing you have already built. Athia deduplicates across paths, so both can run at once during a cutover.
Anti-fraud and cost data#
Sift, Kount, Chargeblast and Cybersource Fraud add the fraud and dispute signals behind each decision, and are set up with your Athia team. Fraud-engine declines never reach a processor, so they sit outside acceptance rate: connecting a fraud source is what separates "our rules blocked it" from "the issuer declined it". Chargeblast carries dispute alerting signals only, not full decision data.
Fee data arrives as an in-product CSV upload against an Athia template, so routing recommendations can account for what each route costs. See Cost Data Uploads.
How fresh your data can be#
Freshness is decided by the provider and by the data type, not by a setting in Athia.
Authorizations, declines and captures are produced as they happen, so they can be near real time on any path. Settlement, payouts, fees and interchange do not exist until the provider closes a batch or issues a statement, so they arrive daily, weekly or monthly by nature, and no connector makes them earlier.
The Schedule on a connection is therefore a ceiling on how often Athia asks, not a floor on how fresh the answer is. Asking faster than the source produces data adds load and no information.
| Data | Typically produced | Sensible cadence |
|---|---|---|
| Authorizations and declines | As they happen | 15 to 30 minutes if you are watching declines live, otherwise 1 to 3 hours |
| Captures and refunds | As they happen, confirmed later in reports | 1 to 3 hours |
| Disputes | 30 to 180 days after the transaction | 6 to 24 hours |
| Settlement and payouts | When a batch or reconciliation cycle closes | 12 to 24 hours |
| Fees and interchange | On the statement cycle, often monthly | 24 hours |
History reach is the provider's cap, not a setting. Stripe caps historical sync at one year and PPRO is forward-only. Anything older than a connector will replay is loaded once as files, on the same specification as the recurrent feed.
Troubleshooting#
| Symptom | What to do |
|---|---|
| A provider you use is not in the catalog | Expected. Send the data instead. See Offline Data Transfer |
Connection status is ERROR right after Verify | The credential scope is too narrow, or it was issued in the wrong environment. Reissue it with reporting and transaction read in the environment you process in |
Connection is ACTIVE but no data after the first sync | The provider's reporting window or history cap has not been reached. Wait for a second sync; for older history, load it as files |
| More rows than orders for the same order | One order was routed to more than one provider, so per-provider views hold one row per provider per order. Group by provider rather than counting rows. See Athia Data Dictionary |
| Card fields show only a BIN and last four | Expected. Athia never collects full PAN or CVV. CVV and AVS are available as match / no-match response codes |