Authorize.Net Oct. 17 Maintenance Pauses AFDS Fraud Filters

Authorize.Net will put its production payment gateway through planned maintenance beginning at 9:00 PM Pacific time on Saturday, October 17, 2026, and its status page notice says transactions screened by the Advanced Fraud Detection Suite (AFDS) “will process as if AFDS filters are not enabled” while the work runs. On the East Coast the window opens at midnight on Sunday, October 18. The notice gives a reported end of 05:00 GMT, which is 10:00 PM Pacific and 1:00 AM Eastern.

That hour matters most to high-risk stores that count on AFDS velocity and IP rules to stop card testing. The same notice lists stored-profile billing, subscription APIs, hosted checkout CAPTCHA checks, voids, and refunds among the services that may cut in and out.

What Authorize.Net’s October 17 notice says

Authorize.Net posted the October 17 maintenance notice on its status page on September 23. It describes production maintenance “lasting for approximately 30-60 minutes with intermittent service interruption” and adds, “Though services will be impacted, no service should be unavailable for the entirety of the update window.”

The impact section of the notice names these services:

Follow-on transactions, which the notice defines as voids, refunds, and “Prior Authorization Capture” transactions
Merchant Interface access, including Virtual Point of Sale (VPOS) access
Partner Interface access
The Authorize.net hosted payment form and Simple Checkout CAPTCHA verification
The Customer Information Manager (CIM) API
The Automated Recurring Billing (ARB) API
AFDS screening, with transactions processing as if filters are not enabled
Transaction processing in the Authorize.net mobile point of sale (mPOS) app for Android and iOS
The Verified Merchant Seal

The notice points readers to a support article titled Planned System Maintenance Service Impact. That article, last modified September 29, 2026, carries the same list and adds transaction processing in the Authorize.net 2.0 VPOS app for Windows.

Which fraud checks go quiet when AFDS is bypassed

Authorize.Net’s AFDS support guide describes the suite as rules-based transaction filters and Internet Protocol (IP) address tools. Its card testing group includes an Hourly Velocity Filter, a Suspicious Transaction Filter built on Authorize.Net’s own criteria, and a Transaction IP Velocity Filter that limits how many transactions one IP address can send per hour. Other filters act on order amount, Address Verification Service (AVS) results, card code results, shipping and billing mismatches, and the region an order comes from.

Card testing is the abuse those settings are built for. Fraudsters push runs of small authorizations through a checkout to learn which stolen card numbers still work, and the guide says the card testing filters “help protect your account from abuse by fraudsters who are testing credit cards.” It pitches the Amount Filter as a way to catch “high-risk transactions often used to test the validity of credit card numbers.”

Each filter carries an action the merchant picks, from processing normally and reporting the trigger to holding for review or declining. A store that set its IP velocity rule to decline is trusting the gateway to refuse a burst of attempts from one address. Under the notice’s wording, those attempts would go to authorization as though no rule existed. EC4IM’s earlier look at AFDS settings for card testing covers how those thresholds are usually configured.

What the notice does not answer

The notice does not say whether transactions processed during the window will be screened afterward or show up in the AFDS review queues. It is also silent on the Daily Velocity Filter, which Authorize.Net offers at no charge outside the paid suite, and on the IP Address Blocking and Authorized API IP Addresses tools that sit in the AFDS settings. The notice tells merchants with questions to contact the Authorize.net support team.

Eight windows this year with the same AFDS warning

The October 17 window is part of a pattern. Authorize.Net’s status page history shows seven earlier production maintenance notices in 2026, from February through September, that carried the same sentence about AFDS transactions processing as if filters were not enabled. The most recent was the late-September production window, which the status page moved to in progress at its scheduled start and marked completed one hour later.

Analysis. A gap that has returned roughly once a month means AFDS cannot be a merchant’s only card testing control on Saturday nights. Stores with high-risk acquiring relationships, where a spike in declines or disputes can draw attention from the acquiring bank, carry the most exposure when gateway rules step aside.

How CIM and ARB billing line up with the window

CIM lets merchants store tokenized customer payment profiles on Authorize.Net’s servers and charge returning customers without handling card data again, according to the Customer Profiles developer documentation. ARB creates installment-based subscriptions that the gateway bills on a schedule, per the Recurring Billing documentation.

Timing splits the exposure. The ARB documentation says “Subscription transactions process at approximately 2:00 a.m. PST on scheduled payment dates,” hours after the October 17 window closes. On that documented schedule, gateway-generated subscription charges should fall outside the maintenance hour. Sign-up flows that call the ARB API to create or change a subscription between 9:00 and 10:00 PM Pacific could still hit errors.

Merchants that run their own rebill or retry jobs against CIM profiles have the clearest overlap if a nightly job fires inside the window. EC4IM’s coverage of Authorize.Net’s September API disruptions looked at retry handling when the gateway stops answering.

Practical steps tied to Authorize.Net’s documentation

Neither the notice nor the support article recommends specific precautions. The steps below follow from what Authorize.Net’s own documents say about the affected services, and they reflect EC4IM’s reading rather than company guidance.

Reschedule merchant-run rebills. Moving CIM-based rebill and retry jobs to after 10:00 PM Pacific (1:00 AM Eastern) keeps them away from an API the notice says may be intermittently unavailable.
Add rate limits at the store. Limits on checkout attempts per IP address, session, or card run on the merchant’s own servers, so they keep working when gateway filters do not.
Watch store-side authorization logs. With Merchant Interface access listed as intermittent, a store’s own logs are the steadier place to track decline rates and bursts of small charges during the hour.
Review Saturday’s orders before the batch closes. Authorize.Net’s cut-off time documentation says the setting “defaults to 4 PM Pacific Time,” and its settlement article says captured transactions batch right after that cut-off. At the default, charges captured Saturday night would not batch until about 4:00 PM Pacific on Sunday, October 18, which leaves time to void suspect orders once follow-on transactions are working again.

The October 17 maintenance in brief

Authorize.Net has announced the Saturday-night maintenance weeks ahead and says no service should be down for the full hour, but its notice states plainly that AFDS transactions will process as if the filters are not enabled. For high-risk stores, the practical question is what stops a card testing script between 9:00 and 10:00 PM Pacific when the gateway’s velocity and IP filters are not applied. Authorize.Net’s own documents point to a few levers that sit outside the gateway’s filters, including store-side rate limits, CIM rebill jobs moved past 10:00 PM Pacific, and a look at Saturday’s authorizations before the default 4:00 PM Pacific batch on Sunday. Open points, such as how the free Daily Velocity Filter behaves during the hour, remain questions for Authorize.Net support.

Authorize.Net October 17 Maintenance Can Run Transactions Without Fraud Filters for Up to an Hour