By E-commerce 4 Internet Marketers Editorial
Analysis. This article separates documented Authorize.net status-page facts about early September 2026 API connection and CreateTransaction disruptions from editorial interpretation for website owners and developers who sell regulated or high-risk products and run order systems that retry payments, consume webhooks, and reconcile unsettled captures. Facts below are attributed to Authorize.net's public status page, Authorize.net webhook and payment-transaction developer documentation, the Error 11 Support Center article on duplicate transactions, and Transaction Reporting documentation. Post Incident Report links for these incidents require Support Center login and are not quoted here. This is not legal, PCI, or underwriting advice.
Facts. INC26930042 API Connection/Endpoint Service Disruption
Authorize.net published an incident titled "API Connection/Endpoint Service Disruption" on its status page under Incident #: INC26930042.
The investigating update (posted 7 September 2026, 10:44 UTC) stated that Authorize.net was aware of an issue affecting the Authorize.net API Service, that clients may experience errors or delays when sending or receiving API requests, and that the issue could impact payment processing and transaction status updates. Reported Start Time in that update was 05 September 2026, 12:37 GMT.
The monitoring update (posted 7 September 2026, 12:39 UTC) stated that a fix had been implemented and that Authorize.net was monitoring closely, that the issue had been mitigated, and that customers were again able to use the Authorize.net API Service as expected. That update listed Reported Start Time as 05 September 2026, 12:37 GMT and Reported End Time as 07 September 2026, 12:12 GMT.
The resolved update (posted 8 September 2026, 09:07 UTC) stated that the issue affecting the Authorize.net API Service had been fully resolved, that Authorize.net was conducting an internal review to mitigate future occurrences, and repeated the same Reported Start Time and Reported End Time. Impact wording in the resolved update said customers were able to use the Authorize.net API Service as normal. A later postmortem-style status update pointed merchants to a Support Center Post Incident Report (login required). This article does not invent root-cause detail beyond the public impact language.
Facts. INC26988612 CreateTransaction API calls Failing
Authorize.net separately published "CreateTransaction API calls Failing" under Incident #: INC26988612. The resolved update (posted 13 September 2026, 04:05 UTC) stated that an issue affecting Authorize.net API services had been fully resolved, that Authorize.net was conducting an internal review, and listed Reported Start Time as 09/13/2026, 02:07 GMT and Reported End Time as 09/13/2026, 02:41 GMT. Impact wording said clients may experience issues when processing transactions via the API. A postmortem update appeared on the status history around 17 September 2026 with a Support Center Post Incident Report link (login required). That shorter window is distinct from INC26930042 and should not be conflated with the multi-day API Connection/Endpoint disruption earlier in the month.
Facts. Documented Authorize.net webhook delivery and retries
Authorize.net's Webhooks documentation states that webhooks are automated notifications generated by system events (including payment, customer profile, subscription, and fraud-filter events), that webhook notifications replace the Silent Post method, and that webhooks should be used in conjunction with Authorize.net reporting APIs. For additional transaction details or the current status of a transaction, the docs direct merchants to call getTransactionDetails.
Signature verification is documented as follows. Merchants must configure a Signature Key in the Merchant Interface. Authorize.net forms an HMAC-SHA512 hash of the webhook notification body using that Signature Key and sends the hash in the custom header X-ANET-Signature. Clients should recompute the hash and reject notifications when the hashes do not match.
Notification retries are documented in the same guide. If a notification attempt fails, Authorize.net retries up to 10 times until it receives HTTP 200 OK from the merchant server. The documented schedule is three retries at three-minute intervals, three more at eight-hour intervals, and four at 48-hour intervals. After all attempts are exhausted without a successful response, Authorize.net assumes the webhook URL is out of service, sets that webhook's status to inactive, and stops sending notifications to the registered URL. The docs advise responding with HTTP 200 as soon as the notification is received and before back-end processing, because delaying the 200 until processing completes risks inactivation if that processing fails.
The Webhooks REST API also documents notification history retrieval, including queries filtered by deliveryStatus=Failed, and retrieval of a specific notification's payload and retry history. Payment event types documented for enrollment include net.authorize.payment.authorization.created, net.authorize.payment.authcapture.created, net.authorize.payment.capture.created, net.authorize.payment.refund.created, net.authorize.payment.priorAuthCapture.created, and net.authorize.payment.void.created, among customer, subscription, and fraud events. The payload field merchantReferenceId corresponds to the API refId field for matching notifications to requests.
Facts. Duplicate window and Error 11 (not a full idempotency key)
Authorize.net's Payment Transactions documentation lists a createTransactionRequest per-transaction setting named duplicateWindow. The setting is described as time in seconds to check for subsequent duplicate requests of the transaction, intended to help prevent accidental double-billing, with a maximum value of 28800 (8 hours). The setting is submitted under transactionSettings as settingName duplicateWindow with a string settingValue.
Authorize.net Support Center article Error 11 (Response Reason Code 11, "A duplicate transaction has been submitted") states that duplicates are identified by matching submitted data fields (including API Login ID, card or bank account identifiers, transaction type, amount, invoice number, customer ID, name and address fields, and the duplicate window itself). If any of those fields change, Authorize.net will not treat the requests as duplicates. The default duplicate window when no value is sent is 120 seconds (two minutes). The largest accepted value is 28800 seconds. Setting the window to 0 or a negative number disables enforcement for software-submitted transactions. Virtual Terminal transactions always use a two-minute window. When the duplicate-window field is submitted with the request, Error 11 responses can include the original transaction ID and related authorization details. Without that field, Authorize.net states it will not return those original-transaction details even on a duplicate.
This article does not claim that duplicateWindow or refId is a Stripe-style client idempotency key. The documented behavior is field-matching within a time window.
Facts. Transaction reporting surfaces for reconciliation
Authorize.net's Transaction Reporting documentation describes APIs for Settled Batch List, Transaction List, Unsettled Transactions List (up to 1000 of the most recent transactions), Customer Profile Transactions List, Transaction Details (complete transaction information via methods such as getTransactionDetails), Batch Statistics, and Merchant Details. Authorize.net automatically groups transactions into a batch every 24 hours for settlement. Webhook docs explicitly position these reporting methods as the companion path when a notification's snapshot is incomplete or when current status must be confirmed after timeouts, retries, or delayed delivery.
Interpretation. Why multi-day API errors hurt high-risk order stacks
The following points are editorial interpretation grounded in the documented behaviors above, not additional Authorize.net claims about either September incident.
High-risk and regulated sellers (CBD, supplements, telehealth, nicotine, tactical, and similar catalogs) often couple checkout to strict fulfillment gates, age or license checks, and processor scrutiny of refund and chargeback ratios. Interpretation. A multi-day window of API errors or delays (as described in INC26930042's investigating update) creates ambiguous order states. The storefront may show a failed checkout while a later retry succeeds, or a timeout may hide an approved createTransactionRequest. Without idempotent client design and reconciliation, support teams ship twice, refund incorrectly, or leave paid orders stuck in "pending payment."
Interpretation. The shorter CreateTransaction incident on 13 September 2026 shows a second failure mode. Even a sub-hour outage can produce a burst of browser retries and cart double-submits. Error 11 and duplicateWindow only help when retried payloads still match the documented duplicate field set inside the configured window. Changing invoice numbers or amounts on each retry defeats that protection.
Interpretation. Hardening retries without inventing gateway guarantees
Interpretation. Treat client retries as at-least-once work that must be safe. Keep a stable merchant order idempotency key in your own database before the first createTransactionRequest. Reuse the same amount, invoice number, customer identifiers, and payment method fields on automatic retries inside the window you configure with duplicateWindow. Submit duplicateWindow explicitly so Error 11 can return the original transaction ID when Authorize.net detects a duplicate. On ambiguous network failures, call getTransactionDetails or list unsettled transactions before creating a new charge.
Interpretation. Cap automatic retries with backoff, and move exhausted attempts into a manual or async recovery queue rather than looping forever against an open INC on status.authorize.net. Subscribe to status alerts for API Connection/Endpoints and related components so on-call knows when to pause aggressive retry bots that would otherwise amplify load or create support noise.
Interpretation. Hardening webhook handlers and queues
Interpretation. Follow the documented 200-first pattern. Acknowledge the webhook quickly, verify X-ANET-Signature with the Signature Key, then enqueue durable work keyed by notification id plus entityName/id (for example transId). Deduplicate consumer side so Authorize.net's documented multi-day retry schedule cannot apply the same fulfillment twice. If processing must call other systems, do that after the 200, not before.
Interpretation. Monitor failed deliveries through the notifications history API and alert when webhooks flip inactive. An inactive webhook after exhausted retries is a documented Authorize.net behavior, not a mysterious silent failure. Rebuild or reactivate endpoints deliberately after outages, then backfill with Transaction Reporting rather than assuming missed events will appear later.
Interpretation. Do not treat webhook payload snapshots as the sole source of truth for fulfillment. The docs already say notifications reflect status at notification time and point merchants to getTransactionDetails for current status. After INC-class API disruptions, run a reconciliation job that compares open orders to unsettled and settled batch data before releasing high-risk inventory.
What remains unknown (verified gap list)
Authorize.net has not published, on the public status-page updates reviewed for this article, non-login Post Incident Reports detailing root cause, blast radius, or minute-level customer-impact curves for INC26930042 or INC26988612. This article does not invent those details. Public updates for INC26930042 describe API Service errors or delays affecting payment processing and transaction status updates. They do not, in the text reviewed here, assert a separate confirmed webhook-component outage during that same window. Undocumented behaviors (exact-once delivery, global ordering guarantees, or idempotency keys beyond the published duplicate-window field match) are omitted rather than assumed.