Overview
The Authorize.Net connector provides transaction-reporting data from Authorize.Net. It is read-only and does not authorize, capture, refund, void, or otherwise modify transactions.
The connector provides data for:
Settled batches
Transactions within settled batches
Transaction details
Transaction line items
Currently unsettled transactions
Settled transaction data is hierarchical: batches are retrieved first, then transactions within each batch, and transaction details/line items are retrieved from those transactions.
Authentication
The connector requires:
login_id transaction_key
These are the Authorize.Net API Login ID and Transaction Key associated with the merchant account.
The connector currently connects to the Authorize.Net production endpoint:
https://api.authorize.net/xml/v1/request.api
Sandbox/test environments are not configurable in the current connector.
API Operations
All supported Authorize.Net reporting operations are sent to the same API endpoint using POST requests.
Operation | Purpose |
| Retrieves settled batches for a date range |
| Retrieves transactions belonging to a settled batch |
| Retrieves detailed information for a specific transaction |
| Retrieves transactions that have not yet settled |
Transaction line items do not use a separate API operation. They are extracted from the transaction-detail response.
Sync Behavior
Settled transactions
Settled data uses an incremental bookmark called last_started.
On the next run, the connector goes back a configurable number of days before that bookmark and re-fetches recent settlement data. The default overlap is:
4 days
This overlap is intentional and means recently loaded records may be returned again. The connector's unique keys are used to reconcile those repeated records.
On the first run, settled history begins from approximately:
1996-01-01
so an initial load can be significantly larger than subsequent runs.
Unsettled transactions
unsettled_transactions is handled differently. It is a full-replacement snapshot of the transactions currently considered unsettled by Authorize.Net.
As transactions settle, they disappear from this table on a future successful refresh.
Record Relationships
The main settled data follows this relationship:
settled_batches ↓ transactions ↓ transaction_details ↓ transaction_items
This matters when interpreting freshness and performance. For example, retrieving transaction_details requires the connector to first identify the relevant batches and transactions, then request the detail for each transaction individually.
Deletes
The connector does not explicitly synchronize deletes for historical settled data.
If a settled transaction or related record is removed or no longer returned by Authorize.Net, the connector does not generate a corresponding delete event.
unsettled_transactions is the exception because it is a full-replacement table. When a transaction is no longer unsettled, it naturally disappears from the next successful snapshot.
Nested Data
Some Authorize.Net fields contain complex structures such as:
Payment information
Customer/profile information
Subscription details
Billing and shipping information
Tax information
Fraud-filter information
These values may be stored as JSON rather than being flattened into individual columns. Consumers may need to parse those fields when building downstream models.
Known Limitations & Notable Behavior
Recent settled data is intentionally re-fetched. The default four-day overlap means duplicate source records between runs are expected and should be reconciled using the table's unique keys.
No explicit delete handling for settled history. Historical deletes are not propagated.
Unsettled transactions are a snapshot, not history. Once a transaction settles, it will disappear from the unsettled table.
Detailed transaction syncs can be slower. Transaction details require an additional API request for each individual transaction.
No connector-level retry/backoff logic is implemented. Temporary Authorize.Net failures may therefore cause incomplete or empty responses rather than being repeatedly retried.
API errors may sometimes appear as empty results. Several request operations return an empty result when the response is not successful rather than raising a distinct error. This is important when investigating unexpectedly empty tables.
Sandbox is not configurable. The connector currently points directly at the Authorize.Net production API endpoint.
The settled-date window logic deserves attention. The current implementation modifies the start date while calculating its 31-day window, which can cause the requested start and end dates to collapse to the same boundary. This is worth reviewing if historical settled data appears incomplete.