Skip to main content

Is Authorize.Net Down?

No — Authorize.Net is up

Reachable from all 8 checked regions

Average response time: 393ms

Last checked · checks run every 6 hours

Official status page: https://status.authorize.net

Authorize.Net uptime

100%
Last 7 days
100%
Last 30 days
100%
Last 90 days
359ms
Avg response, 30 days

Measured from multiple regions every 6 hours. Percentages count only checks that returned an availability answer — 18 days measured so far. A dash means that window does not yet hold enough measured days to publish a figure.

30-day history

18-day clean streak
Jul 19: no data
Jul 20: no data
Jul 21: no data
Jul 22: no data
Jul 23: no data
Jul 24: no data
Jul 25: no data
Jul 26: no data
Jul 27: no data
Jul 28: no data
Jul 29: no data
Jul 30: no data
Jul 31: 100.00% uptime, 24 checks
Aug 1: 100.00% uptime, 31 checks
Aug 2: 100.00% uptime, 32 checks
Aug 3: 100.00% uptime, 40 checks
Aug 4: 100.00% uptime, 32 checks
Aug 5: 100.00% uptime, 31 checks
Aug 6: 100.00% uptime, 40 checks
Aug 7: 100.00% uptime, 32 checks
Aug 8: 100.00% uptime, 40 checks
Aug 9: 100.00% uptime, 32 checks
Aug 10: 100.00% uptime, 32 checks
Aug 11: 100.00% uptime, 32 checks
Aug 12: 100.00% uptime, 32 checks
Aug 13: 100.00% uptime, 32 checks
Aug 14: 100.00% uptime, 32 checks
Aug 15: 100.00% uptime, 32 checks
Aug 16: 100.00% uptime, 32 checks
Aug 17: 100.00% uptime, 24 checks
Jul 19 Today
No downtime Partial Downtime Not measurable No data

Reachability by region

Each region runs its own request from a different part of the world. A service can be up for one continent and down for another, which is usually the first sign of a routing or CDN problem.

ams
180ms
DNS 33ms TCP 1ms TLS 11ms TTFB 171ms
arn
244ms
DNS 57ms TCP 2ms TLS 14ms TTFB 232ms
bom
338ms
DNS 24ms TCP 2ms TLS 19ms TTFB 324ms
cdg
494ms
DNS 304ms TCP 1ms TLS 11ms TTFB 485ms
ord
190ms
DNS 91ms TCP 3ms TLS 8ms TTFB 178ms
sin
1137ms
DNS 123ms TCP 2ms TLS 21ms TTFB 1126ms
sjc
172ms
DNS 43ms TCP 2ms TLS 12ms TTFB 160ms
syd
381ms
DNS 131ms TCP 1ms TLS 9ms TTFB 372ms
yyz
202ms
DNS 140ms TCP 1ms TLS 8ms TTFB 194ms

What Authorize.Net does

Authorize.Net is a payment gateway that carries card and eCheck transactions from a merchant's checkout to the bank that actually settles them. Shops reach it through the Accept Suite, the older AIM and SIM integration methods, or the Virtual Terminal for phone orders, which makes it the link every online payment crosses rather than the processor of record.

What an outage looks like

Checkout returns a gateway error or times out at the moment payment is submitted, while the rest of the store loads normally. Recurring billing runs skip, and webhooks stop arriving so orders never move out of pending. The Merchant Interface will not accept a login. Failures are often limited to one acquiring bank, so some cards decline while others succeed.

What to do about it

Check status.authorize.net, which is unusually specific: it lists each acquiring bank separately, including Chase Paymentech, Worldpay, Elavon, TSYS, Global Payments, First Data and American Express Direct, alongside the API, Webhooks, Recurring Billing and Virtual Terminal. Find your own processor in that list before assuming the gateway is down. Do not re-run a transaction that timed out until you confirm it did not settle.

Is it down for everyone, or just you?

If this page says Authorize.Net is up but it is not loading for you, the problem is between you and them. Run a check against any URL from all 18 regions to find out where it breaks.

Test it yourself

Related services

Stripe
Stripe
Square
Square
Affirm
Affirm
QuickBooks Online
QuickBooks Online

Authorize.Net outage FAQ

Is the whole gateway down or just my processor?
Usually just one processor. The Authorize.Net status page tracks every acquiring bank as an individual component, so an incident on Chase Paymentech or Worldpay leaves merchants on Elavon or TSYS unaffected. That is why one store reports total failure while another takes payments normally. Find the bank that settles your transactions in the list rather than reading the summary at the top.
If a payment timed out, was the customer charged?
Possibly, and this is the main risk during a gateway incident. A timeout means the response never came back, not that the transaction failed, so an authorisation can exist without your system recording it. Check the Merchant Interface for the transaction before refunding or re-charging, and avoid letting customers retry blindly, which is how duplicate charges happen.
Do recurring billing and subscriptions catch up afterwards?
Recurring Billing is a separate component and scheduled runs that fall inside an outage window can be missed rather than deferred. Once service returns, review which subscriptions were due during the incident instead of assuming they retried. Failed webhooks are the related problem: orders can sit unfulfilled because the notification never arrived, even though the payment succeeded.
Can I still take payments while the gateway is having problems?
Only through a path that does not use the affected component. The Virtual Terminal, Card Present processing and the API are listed separately, so if one is degraded another may still work for manual orders. If the acquiring bank itself is the failure, no route through Authorize.Net will complete, and taking card details to key in later is the safer fallback.
Is Authorize.Net the same thing as my payment processor?
No, and the distinction matters during an outage. Authorize.Net is the gateway that transports the transaction; a separate acquiring bank authorises and settles it. An outage can sit on either side. The status page reflects this by splitting API and endpoint components from the long list of individual banks under payment gateway processing.

How we measure this

  • We request Authorize.Net's public endpoint every 6 hours from Fly.io regions across six continents — 8 of them answered the most recent check.
  • A region counts as down only when it gets no usable HTTP response. A 403 or 429 means the origin answered and refused us, which we report as blocked, never as an outage.
  • A single failing region is treated as probe noise. We only change the verdict when two consecutive cycles agree.
  • Response times average only the regions that actually served the page, so a timeout never inflates the number.
  • Where Authorize.Net publishes an official status feed we read it too. An all-clear from the vendor can soften an unconfirmed degradation; a vendor-declared outage only worsens our verdict when our own checks corroborate it.

Get alerted when Authorize.Net goes down

This page refreshes every 6 hours. Your own monitors run as often as every 30 seconds, from the same 18 regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required