Skip to main content
Use the @bijection/connectors/authorize-net entrypoint to declare Authorize.Net resources.

​
Availability

This page describes the pinned source package. Published availability is unestablished for this artifact. Source build and package availability.

​
Resources and modes

Declare a resource in application code, then bind deployment-specific settings and credentials. See typed resources, connections and source inspection.

​
Settled batches

​
pull: Settled batch list over carried 31-day settlement windows

The following example matches configuration standard.

​
Configuration: standard

Case: authorize-net/batches/pull/standard. Connection and resource configuration are declared by this exact case. Credential kind: authorize-net. Keep credential material in the private credential inventory. Inspect the complete configuration contract below for settings and conditional requirements.
Native admission analysis is available for this exact declaration. Collection: batches
Recorded checks Hosted qualification: unestablished for this catalog configuration. Installed connections report their own identity, authority and current status.

​
Settled transactions

​
pull: Transactions of each settled batch, 1,000 per page, over carried settlement windows

The following example matches configuration refreshed.

​
Configuration: standard

Case: authorize-net/transactions/pull/standard. Connection and resource configuration are declared by this exact case. Credential kind: authorize-net. Keep credential material in the private credential inventory. Inspect the complete configuration contract below for settings and conditional requirements.
Native admission analysis is available for this exact declaration. Collection: transactions
Recorded checks Hosted qualification: unestablished for this catalog configuration. Installed connections report their own identity, authority and current status.

​
Configuration: refreshed

Case: authorize-net/transactions/pull/refreshed. Connection and resource configuration are declared by this exact case. Credential kind: authorize-net. Keep credential material in the private credential inventory. Inspect the complete configuration contract below for settings and conditional requirements.
Native admission analysis is available for this exact declaration. Collection: transactions
Recorded checks Hosted qualification: unestablished for this catalog configuration. Installed connections report their own identity, authority and current status.

​
Provider guidance

Compiled declaration examples and configuration details are published in the connector reference. Transaction reporting by settlement batch, declared from Authorize.Net’s API reference (read 2026-10-21).

​
Connection and credential

The connection is fixed at https://api.authorize.net/ with credential kind authorize-net (authorizeNet.credential). The sandbox origin is https://apitest.authorize.net; this recipe declares production only. The operator configures the API login ID and transaction key as a body-fields envelope; the recipe never declares it:
Every call is POST /xml/v1/request.api with a JSON body whose single top-level member is the operation (getSettledBatchListRequest, …). The host writes merchantAuthentication: {name, transactionKey} as that member’s first field. No request here names merchantAuthentication. Authorize.Net translates the JSON to XML, where element order is the schema’s, and the guest-built body’s field order is not guaranteed to survive (bodies pass through a value encoding that may sort keys). Every request therefore names only fields whose alphabetical order is the schema order:
  • getSettledBatchListRequest: firstSettlementDate, lastSettlementDate. includeStatistics (schema order before them) is omitted, so batch statistics are not read.
  • getTransactionListRequest: batchId, then paging with limit, offset. sorting (schema order before paging) is omitted, so the listing is in Authorize.Net’s default order.
  • getTransactionDetailsRequest: transId.
  • getMerchantDetailsRequest: nothing.
Identity is getMerchantDetailsRequest’s gatewayId (a numeric string naming the gateway account). authenticateTestRequest answers Ok without naming any account, so it is not used. The merchant name is not kept.

​
What is read

  • batches.pull reads getSettledBatchListRequest over windows of at most 31 days (Authorize.Net’s limit), bounds in UTC (Z), inclusive at both ends. A lastSettlementDate at 00:00:00 would include that whole day, so a window ends at 23:59:59 one second before the next window begins. A batch is keyed by batchId and keeps settlementTimeUTC, settlementState (settledSuccessfully, settlementError or pendingSettlement), paymentMethod, marketType and product.
  • transactions.pull walks the same windows. For each it lists the settled batches (retained as data) and reads each batch’s getTransactionListRequest, 1,000 per page; paging.offset is the 1-based page number, and a batch ends on a page shorter than 1,000 (or once totalNumInResultSet, when it is an integer, is reached). A transaction is keyed by transId and keeps transactionStatus as stated, submitTimeUTC, settleAmount, accountType, accountNumber (already masked by Authorize.Net, such as XXXX1111), invoiceNumber and the batchId it was listed under.
  • With refreshEvery, every published transaction is read again by getTransactionDetailsRequest, which is how a status change outside the revisit window (an eCheck return, for example) is seen. The details answer is mapped onto the listing’s fields: payment.creditCard.cardType or eCheck (for payment.bankAccount) as accountType, the masked card or bank account number, order.invoiceNumber and batch.batchId. That this mapping gives the same accountType spelling as the listing is unverified. An answer that is not Ok, names another transaction or no batch leaves the key unresolved.

​
Passes and position

Both collections carry a JSON position (sync.carry). A pass walks from start (first pass) or revisitHours (default 48, 1 to 744) before where the last finished pass stopped, to the second the pass began, one window per step, and a finished pass carries its end. A failed pass carries nothing. While a transactions pass walks, its position holds the window, up to 100 batch ids still to read, the last batch fully read (after), whether more batches were listed than held (more), and the page of the first held batch; once the held ids are read, the window’s batches are listed again and reading continues after after (batch ids compare as integers). The position stays far below 4,096 bytes.

​
Answers and refusals

Every answer is HTTP 200 with messages.resultCode Ok or Error. A page answering Error is refused, never published. The response contract also classifies documented codes: E00001 and E00104 (processing error, maintenance) are transient; E00005 to E00008 refuse the credential; E00011 is a credential without the Transaction Details API permission. An empty listing is Ok with I00004 and no list member, which reads as no rows. Authorize.Net prefixes JSON answers with a UTF-8 byte order mark, which the engine ignores when decoding.

​
Exactness

Authorize.Net’s JSON answers write settleAmount as a JSON number (1018.88, 0.00); its translated samples show a string. A fractional JSON number has been through a double before any contract check sees it, so settleAmount cannot be declared exact and is not exact by contract. The reader keeps a string verbatim and a number as the shortest text that round-trips it, which equals the decimal Authorize.Net sent, without trailing zeros (0.00 becomes 0), whenever that decimal has at most 15 significant digits; Authorize.Net documents amounts of up to 15 digits, and a number needing more is refused. That argument is the recipe’s, not the engine’s.

​
Finality

Authorize.Net’s developer forum says a settle amount does not change once settled; the API reference does not say so, and statuses can change (returned eCheck items, for example), which is what revisitHours and refreshEvery re-read. A batch’s state can also move from pendingSettlement. Rows carry no version (version: none): a re-read row replaces the observation. Nothing is withdrawn.

​
Limits and not built

  • firstSettlementDate cannot precede January 1 two years before the current year; an older start fails the first pass.
  • Authorize.Net publishes no rate limit, so no backoff or budget is declared.
  • Unsettled transactions (getUnsettledTransactionListRequest), batch statistics, the sandbox origin and any write are not built.
  • Webhooks are not built: X-ANET-Signature is an HMAC-SHA512 of the body and no ingress scheme computes SHA-512.
Nothing here has run against Authorize.Net or been qualified.

​
Provider references

Provider references and prerequisites are maintained in the connector guidance above. No separate provider-documentation review date is recorded.

​
Source and evidence

Canonical connector source, native analysis and check receipts. Connector artifact: 905888ea276a2a28e36981a79e8142b2547ea451c3e63162cb6915ad4a7d1305. The resource declaration examples above are compiled and compared with exact catalog declarations. Recorded checks apply only to their source, declaration and runtime identities. Configure a connection and inspect its status to establish deployment-specific readiness.